Subject: Netatalk doing AppleShare over TCP/IP by default?

From: "Joe Rhodes" <[email-masked]>
Date: Fri, 07 Jul 2000 01:32:26 CDT

This may seem like a dumb question, but I cannot seem to figure this out.  
Does Netatalk+asun (2.1.4-39) use TCP/IP by default when connecting via the 
chooser?  Can it if it doesn't?

When I do a "get info" on a mounted volume, it always says "via AppleTalk", 
unless I click on the "server IP" button and type in the server name.

If, in my afpd.conf file, I give the -tcp option without the -transall 
option, or with the -noddp option, than the server does not appear in my 
chooser at all.

Some of the posts that I've been reading suggest that some people are doing 
this.  (And that they don't want to be for other reasons, but that's another 
story.)

I've noticed that using an AppleShare IP 6.3 server, connecting via the 
chooser (in the normal fasion) results in TCP/IP connections.  (At least, 
that's what the "get info" box has to say.

I'm very interested in this, as I am proposing replacing an aging AppleShare 
IP 6.3 machine with Linux and Netatalk.  Given the size of the network I'm 
dealing with (there's a lot more than apples talking) I'd like to keep the 
protocols over the wire as simple as possible.  (Ok, yeah, and I want to set 
up a Linux box that's blistering fast compared to anything else in the 
place!)

If you have any insight, it'd be greatly appreciated.  I get to give a preso 
tomorrow on using a linux box in this capacity.  I'd LOVE to be able to say, 
"yeah, and it talks TCP/IP too, unlike Windows and Novell services for Mac".

My log files say this when I connect locally:

Jul  5 22:42:12 decameron afpd[13221]: session from 41203.141:245 on 
65280.227:129
Jul  5 22:42:12 decameron afpd[13221]: randnum/rand2num login: jrhodes
Jul  5 22:42:12 decameron afpd[13221]: login jrhodes (uid 500, gid 500)
Jul  5 22:42:28 decameron afpd[13221]: 1.38KB read, 5.18KB written
Jul  5 22:42:28 decameron afpd[13221]: done

And this when I log in via "server IP" button:

Jul  6 16:42:41 decameron afpd[13206]: warning: /etc/hosts.allow, line 6: 
can't verify hostname: gethostbyname(nap.goliath.com) failed
Jul  6 16:42:41 decameron afpd[13756]: ASIP session:548(2) from 
156.46.248.162:56354(0)

Any suggestions?

Thanks so much in advance!
-Joe Rhodes

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

---

From: Toby Thain <[email-masked]>
Date: Fri, 07 Jul 2000 17:19:08 +1000

On our network (100BaseT) of 6-odd G3s & 3 G4s, a P233/32MB/60GB running Debian
Linux is a very fast netatalk server over TCP/IP.
All our clients connect TCP/IP by default (e.g., on my G4, AppleShare client
v.3.8.6)
We also have an intranet/file server running netatalk (TCP/IP clients) under
LinuxPPC 1999 on a Power Mac 8500 /150.
In your presentation, I would not hesitate to sell a Linux/netatalk solution on
the basis of speed and reliability .

Toby

---

From: Sak Wathanasin <[email-masked]>
Date: Fri, 7 Jul 2000 09:52:15 +0100

In reply to Joe Rhodes's message of the 07/07/2000 at 01:32 -0500,

>This may seem like a dumb question, but I cannot seem to figure this 
>out.  Does Netatalk+asun (2.1.4-39) use TCP/IP by default when 
>connecting via the chooser?  Can it if it doesn't?
>
>When I do a "get info" on a mounted volume, it always says "via 
>AppleTalk", unless I click on the "server IP" button and type in the 
>server name.

Yes, I'm seeing this too (only I'm using 2.1.4-37b) on my Linux box, 
but not with my Solaris box. When I previously asked on this list, it 
appears that only a very few people are affected. I don't know what 
triggers the problem but it has something to do with the initial 
query the AppleShare client (on the Mac) sends to the server. In the 
reply, there should be something indicating that the server supports 
ASIP, and for some reason that isn't being set. On my list of things 
to do is to compare reply pkts from the Solaris & Linux machines. I 
haven't pursued this because it's a minor inconvenience here: having 
mounted the vol once (via the "server" button), most people just make 
an alias to the vol, and that will remount via TCP/IP.
-- 
Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [email-masked]
Phone: (+44) 24 76 41 99 96        Mobile: (+44) 79 70 75 19 12 
Fax: (+44) 24 76 69 06 90

---

From: Marcus Radich <[email-masked]>
Date: Fri, 7 Jul 2000 23:02:28 +1200

At 1:32 am -0500 7/7/2000, Joe Rhodes wrote:
>
>
>I've noticed that using an AppleShare IP 6.3 server, connecting via 
>the chooser (in the normal fasion) results in TCP/IP connections. 
>(At least, that's what the "get info" box has to say.
>
>I'm very interested in this, as I am proposing replacing an aging 
>AppleShare IP 6.3 machine with Linux and Netatalk.  Given the size 
>of the network I'm dealing with (there's a lot more than apples 
>talking) I'd like to keep the protocols over the wire as simple as 
>possible.  (Ok, yeah, and I want to set up a Linux box that's 
>blistering fast compared to anything else in the place!)

We have been building our own boxes for some time, but last week we 
finished a series of tests with IBM Netfinity 3000 and 3500 boxes. 
They absolutely fly! Since then, we have installed 4 new servers to 
different clients, and all are reporting a full 9.5MB/sec read/write 
from their G3s and G4s. This is GREAT!

>Jul  6 16:42:41 decameron afpd[13206]: warning: /etc/hosts.allow, 
>line 6: can't verify hostname: gethostbyname(nap.goliath.com) failed

Yes, your Hostname+domain are not correctly specified. I have had 
this several times, and a quick trip to Linuxconf->Basic Host 
Information,and filling out all the fields correctly fixed the issue. 
You can see the error in your log file above. I have had this, and 
fixed it.

mrad01

========================================================

"Always ask the question, never assume the answer."
		Marcus Radich 1999

========================================================

---

From: "thomas.riewe" <[email-masked]>
Date: Fri, 7 Jul 2000 13:30:12 +0200 (CEST)

>Jul  6 16:42:41 decameron afpd[13756]: ASIP session:548(2) from 
 
vi /etc/hosts
or setup "bind"
(decameron needs an name-adress-mapping for nap.goliath.com)

hth,
thomas-alway light the cigarette, never assume any smoke-(R)

---

From: Jolly Roger <[email-masked]>
Date: Fri, 07 Jul 2000 11:54:02 -0500

> chooser?  Can it if it doesn't?

I have the same problem and have not been able to fix it.  i sure would
appreciate some help in fixing this!

JR

---

From: Jolly Roger <[email-masked]>
Date: Fri, 07 Jul 2000 23:15:10 -0500

Konstantin Reznitsky told me that you need to have a valid DNS entry of the
netatalk server for macs to be able to resolve the name they are getting
from chooser. Is it possible that because I do not have this set up, Mac OS
is unable to connect via TCP/IP without having the IP?

I know next to nothing about setting up valid DNS entries on Linux.  I have
no registered domain, so I am not sure how I can set a valid DNS entry on my
machine.  In Linux config, I set the domain to an arbitrary name.  Is this
not a good idea?  What should I do instead?  Can someone enlighten me?

---

From: ME <[email-masked]>
Date: Fri, 7 Jul 2000 22:46:49 -0700 (PDT)

> not a good idea?  What should I do instead?  Can someone enlighten me?

If the macs try to connect to the mac server through the chooser as a
server listed in the chooser window after clicking on the AppleShare icon
(And zone if zones are available on your LAN) you are not connecting over
TCP/IP but instead are connection over ddp.

If the macs try to connect to the mac server with the "new" Mac OS 8.0 or
later "SERVER" button from in the chooser (after selecting the AppleShare
icon in the chooser) then a new dialog box comes up asking for the server
name. in this box a server name (resolved via DNS) or an IP address should
suffice.

If you cannot connect to the server name you see listed in the chooser's
right side window after selecting the AppleShare icon and it is a netatalk
based server, then it is more likely you have something mis-configured on 
the netatalk side.

-ME

---

From: andrew morgan <[email-masked]>
Date: Sat, 8 Jul 2000 00:11:22 -0700 (PDT)

> not a good idea?  What should I do instead?  Can someone enlighten me?

I believe this is the order of events:

- I see server in chooser and tell mac to connect
- Mac connects to server using DDP
- Server says, "hey, you can connect to me using TCP/IP. Here is my DNS
name."
- Mac looks up DNS name to get IP address of server
- Mac connects to server over TCP/IP

If you have made up a DNS name for the server (e.g. my.server.com), then
the mac will try to lookup that DNS name to get the IP address (which is
what it really needs to know to connect).  Obviously, this will fail if ou
don't have a DNS server or the DNS name you set is not valid.

I'm not positive, but there should be a facility on the mac which lets you
create a static mapping of DNS name <-> IP address in a file.  In unix and
windows, there is a file called 'hosts' which looks something like:

192.168.1.3 my.server.com
192.168.1.4 other.server.com

You might poke around the TCP/IP control panel on the mac to see if this
is available.

Otherwise, you'll need to get your IP address and DNS name into a DNS
server which the mac can query.

	Andy

---

From: Sak Wathanasin <[email-masked]>
Date: Sat, 8 Jul 2000 09:34:19 +0100

In reply to Jolly Roger's message of the 07/07/2000 at 23:15 -0500,

>is unable to connect via TCP/IP without having the IP?

Necessary, but not sufficient: I have had DNS running here well 
before I installed netatalk and it still does it. You also need to be 
using a reasonably recent version of the AppleShare client (2.8 and 
up?); since you were talking about G3s and G4s, you must be.

>not a good idea?  What should I do instead?  Can someone enlighten me?

It's too big a subject to cover in a mail message; the definitive 
reference is "Bind and DNS" by Albitz and Liu aka the "Cricket book", 
but there's also a DNS "how-to" that should cover most of what you 
need (look in /usr/doc/HOWTO or wherever your distro puts its 
documentation).
-- 
Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [email-masked]

---

From: Sak Wathanasin <[email-masked]>
Date: Sat, 8 Jul 2000 14:27:59 +0100

In reply to andrew morgan's message of the 08/07/2000 at 00:11 -0700,

>- Mac connects to server over TCP/IP

Hmmm, I don't know what's going on then. Using tcpdump, I captured 2 
traces: 1) connecting by dbl-clicking on the server name in the 
Chooser window, and 2) by clicking on the "server IP addr" button. 
The command I used in both cases was

tcpdump -w /tmp/xx.dump -i eth0 'ether host ph'

where the entry for "ph" in /etc/ethers defined the MAC addr of the client Mac.

1) [root@fe /root]# tcpdump -v -r /tmp/xx.dump
13:38:36.146340 M snap atalkarp aarp len 38 op 256 htype 256 ptype 
0x9b80 halen 6 palen 4
13:38:40.214820 M snap atalkarp aarp len 38 op 256 htype 256 ptype 
0x9b80 halen 6 palen 4
13:38:40.215095 < snap 8:0:7:80:9b et1 21 > 0 at-lap#0 35
13:38:43.523526 < snap 8:0:7:80:9b et1 21 > 0 at-lap#0 35
13:38:43.524638 < snap 8:0:7:80:9b et1 21 > 0 at-lap#0 35
13:38:43.524800 < snap 8:0:7:80:9b et1 21 > 0 at-lap#0 35
13:38:43.524847 < snap 8:0:7:80:9b et1 71 > 0 at-lap#0 68
13:38:43.528300 < snap 8:0:7:80:9b et1 21 > 0 at-lap#0 35
13:38:43.563392 < snap 8:0:7:80:9b et1 105 > 0 at-lap#0 102
...
13:38:47.705980 < snap 8:0:7:80:9b et1 25 > 0 at-lap#0 35
13:38:47.706279 < snap 8:0:7:80:9b et1 21 > 0 at-lap#0 35
13:38:47.708904 < snap 8:0:7:80:9b et1 21 > 0 at-lap#0 35

2) [root@fe /root]# tcpdump -v -r /tmp/xx.dump
13:39:07.530635 < ph.nan.co.uk.49172 > fe.afpovertcp: S 
614385585:614385585(0) win 60000 <mss 1460,wscale 0,nop> (DF) (ttl 
255, id 17621)
13:39:07.531334 < ph.nan.co.uk.49172 > fe.afpovertcp: P 
614385586:614385602(16) ack 3051912320 win 60000 (DF) (ttl 255, id 
17622)
13:39:07.535413 < ph.nan.co.uk.49172 > fe.afpovertcp: F 16:16(0) ack 
422 win 60000 (DF) (ttl 255, id 17623)
13:39:07.536455 < ph.nan.co.uk.49172 > fe.afpovertcp: . 17:17(0) ack 
423 win 60000 (DF) (ttl 255, id 17624)
13:39:11.496420 < ph.nan.co.uk.49173 > fe.afpovertcp: S 
614959671:614959671(0) win 60000 <mss 1460,wscale 0,nop> (DF) (ttl 
255, id 17625)
13:39:11.497005 < ph.nan.co.uk.49173 > fe.afpovertcp: P 
614959672:614959694(22) ack 3048419183 win 60000 (DF) (ttl 255, id 
17626)
13:39:11.500131 < ph.nan.co.uk.49173 > fe.afpovertcp: P 22:88(66) ack 
23 win 60000 (DF) (ttl 255, id 17627)
13:39:11.536619 < ph.nan.co.uk.49173 > fe.afpovertcp: P 88:188(100) 
ack 89 win 60000 (DF) (ttl 255, id 17628)
13:39:11.553588 < ph.nan.co.uk.49173 > fe.afpovertcp: P 188:205(17) 
ack 105 win60000 (DF) (ttl 255, id 17629)
13:39:11.603202 < ph.nan.co.uk.49173 > fe.afpovertcp: . 205:205(0) 
ack 178 win 6
...
13:39:15.133967 < ph.nan.co.uk.49173 > fe.afpovertcp: P 4155:4172(17) 
ack 6221 win 60000 (DF) (ttl 255, id 17748)
13:39:15.134709 < ph.nan.co.uk.49173 > fe.afpovertcp: P 4172:4188(16) 
ack 6239 win 60000 (DF) (ttl 255, id 17749)
13:39:15.135325 < ph.nan.co.uk.49173 > fe.afpovertcp: P 4188:4204(16) 
ack 6255 win 60000 (DF) (ttl 255, id 17750)
13:39:15.331935 < ph.nan.co.uk.49173 > fe.afpovertcp: R 
614963860:614963878(18) win 0 (DF) (ttl 255, id 17751)

As you can see in case (1), no attempts are made to use IP: they are 
all ethertalk pkts, a clear contrast with case (2). Using etherpeek, 
which has decoders forAppleTalk, shows that the netatalk server is 
returning the following info:

ATP Header - AppleTalk Transaction Protocol
   Function Code:            2  TResp
   Control Information:      %010  ALO  EOM
   TRel Timeout Indicator:   %000  30 seconds
   Sequence Number:          0  Here is Packet 0
   Transaction ID:           2218
Further Decoding Options Available
   User Bytes:               0x00000000
   ATP Data:                
   LxÄ{fex   00 12 00 17 00 4c 00 78 80 7b 02 66 65 00 01 78
   àunixAFPVers   01 88 04 75 6e 69 78 04 0e 41 46 50 56 65 72 73
   ion 1.1AFPVersi   69 6f 6e 20 31 2e 31 0e 41 46 50 56 65 72 73 69
   on 2.0AFPVersio   6f 6e 20 32 2e 30 0e 41 46 50 56 65 72 73 69 6f
   n 2.1AFP2.2DH   6e 20 32 2e 31 06 41 46 50 32 2e 32 03 09 44 48
   CAST128Cleartxt   43 41 53 54 31 32 38 10 43 6c 65 61 72 74 78 74
    PasswrdNo User   20 50 61 73 73 77 72 64 0f 4e 6f 20 55 73 65 72
    Authent   20 41 75 74 68 65 6e 74 00 00 00 00 00 00 00 00
   üP00(   00 01 00 00 00 02 9f e0 00 04 50 30 00 08 30 28
   <Ý­Ç­   00 10 10 3c 07 a0 08 04 18 7f 04 04 10 00 82 04
   Å­Ç­Ñ­à   10 00 81 04 10 00 82 04 10 00 84 04 10 00 88 04
   ê­­ƒ   10 00 90 04 10 00 b0 04 10 00 d0 04 ff ff ff ff
   @?   40 00 00 02 3f ff ff fc 00 00 07 00 00 00 05 00
   Ä­Ä   00 00 05 00 00 00 05 00 00 00 0f 80 00 00 08 80
   Ä­Ä­Äøt   00 00 08 80 00 00 0f 80 00 00 0a 80 bf ff f2 74
   ø   00 00 05 00 bf ff f8 f4 00 00 00 00 00 00 00 00
   ü   00 01 00 00 00 03 9f e0 00 07 df f0 00 0f ff f8
   ø   00 1f ff fc 07 bf ff fc 1f ff ff fc 1f ff ff fc
      1f ff ff fc 1f ff ff fc 1f ff ff fc 1f ff ff fc
      1f ff ff fc 1f ff ff fc 1f ff ff fc ff ff ff ff
   ?   7f ff ff fe 3f ff ff fc 00 00 07 00 00 00 07 00
   Ä­Ä   00 00 07 00 00 00 07 00 00 00 0f 80 00 00 0f 80
   Ä­Ä­Äø   00 00 0f 80 00 00 0f 80 00 00 0f 80 bf ff ff f4
   øøˆ¿Ýˆ¿Ý   bf ff fd f4 bf ff f8 f4 c3 01 c0 a0 c3 01 c0 a0
   ˆ¿Ýˆ¿Ý­   c3 01 c0 a0 c3 01 c0 a0 02 06 01 7f 00 00 01 06
   îÄ              03 00 0a 94 80

It says it can do AFP 2.2, but for some reason the AShare client 
decides that the server can't do IP and never tries (no attempts to 
use DNS - but the hostname may already be in the cache).

Can't get to the Solaris system right now; when I do I'l let you know 
what's different, unless someone else gets there first...

Internet: [email-masked]

---

From: Jolly Roger <[email-masked]>
Date: Sat, 08 Jul 2000 16:50:39 -0500

I installed the latest version of netatalk (1.4b2+asun2.1.4) and openssl
(openssl-0.9.5a).

Connections to the server now default to TCP/IP.  Yey!  =)

JR

---

From: Sak Wathanasin <[email-masked]>
Date: Sun, 16 Jul 2000 20:37:20 +0100

In reply to Sak Wathanasin's message of the 08/07/2000 at 14:27 +0100,

>...etc...
>....

This weekend I decided to get to the bottom of this, so I captured a 
trace of a successful connection to netatalk on a Solaris box. The 
essential difference is in the last few bytes  of the response the 
server sends to the client:

  02 06 01 7f 00 00 01 06 03 00 0a 94 80

This tells the client that there are "02" addresses where it be 
contacted. The next octet gives the length of the addr that follows 
(6 bytes, incl the length): 01 7f 00 00 01. "01" says it's an IP 
addr, "03" an AppleTalk addr (cf  06 03 00 0a 94 80). 7f 00 00 01 is, 
of course, 127.0.0.1. Bing! A quick look in /etc/hosts reveals that 
there was an incorrect entry for the hostname as an alias for 
"localhost". Why was it looking in /etc/hosts? 'Cos I had 
/etc/nsswitch.conf set to look in /etc/hosts first in case I booted 
up single-user. Once I fixed this, the netatalk server started 
publishing the correct IP addr and all clients started to default to 
using ASIP. (For those of you who don't know, you can force AppleTalk 
connections by holdiong down the option key as you lcick "OK" or 
dbl-clicking on the server name).

So it was due to stupidity on my part and both netatalk and the 
AppleShare clients are blameless. Hoping someone else can profit from 
my mistake, and thanks for nudging me into looking into this.

Internet: [email-masked]