Subject: Re: Netatalk doing AppleShare over TCP/IP by default?
From: Sak Wathanasin (sw@nan.co.uk)
Date: Sat Jul 08 2000 - 09:27:59 EDT
In reply to andrew morgan's message of the 08/07/2000 at 00:11 -0700,
>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
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...
-- Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UKInternet: sw@nan.co.uk Phone: (+44) 24 76 41 99 96 Mobile: (+44) 79 70 75 19 12 Fax: (+44) 24 76 69 06 90
This archive was generated by hypermail 2b28 : Wed Jan 17 2001 - 14:31:27 EST