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:����������������
�����L�x�{�fe��x 00 12 00 17 00 4c 00 78 80 7b 02 66 65 00 01 78
��unix��AFPVers 01 88 04 75 6e 69 78 04 0e 41 46 50 56 65 72 73
ion�1.1�AFPVersi 69 6f 6e 20 31 2e 31 0e 41 46 50 56 65 72 73 69
on�2.0�AFPVersio 6f 6e 20 32 2e 30 0e 41 46 50 56 65 72 73 69 6f
n�2.1�AFP2.2��DH 6e 20 32 2e 31 06 41 46 50 32 2e 32 03 09 44 48
CAST128�Cleartxt 43 41 53 54 31 32 38 10 43 6c 65 61 72 74 78 74
�Passwrd�No�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
����������P0��0( 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, UK
Internet: [EMAIL PROTECTED]
Phone: (+44) 24 76 41 99 96 Mobile: (+44) 79 70 75 19 12
Fax: (+44) 24 76 69 06 90
