TashRouter: An AppleTalk Router

[shirsch]

Here's an updated zip file with the 'Watcher' utilitiy and original capture files in a SIT to preserve resource forks. By installing the app on a Mac system 7 platform you can load the pkt file and browse / expand at will.

 

[shirsch]

For comparison, here is a localtalk capture of the IIe connecting to the server over the Tashtalk router. Session was dead almost immediately after listing the mounted directory.

 

[shirsch]

So, there are a few differences in the traces that jump out. In no particular order:

• The Gatorbox session advertises the zone, while tashtalk router does not:

E 80 0.0000 lap dst 255 lap src 133 NBP: LkUp id=0 (hirsch:Apple IIe@LocalTalk2ZoneA)
vs.
E 80 0.0000 lap dst 255 lap src 254 NBP: LkUp id=0 (a2e:Apple IIe@*)

• The Gatorbox session starts off with session id = 0, then a session 1 appears. This does not happen with the TT session.

E 80 0.0000 lap dst 133 lap src 68 ASP: OpenSess, sess bf, userBytes 0100
E 80 0.0000 lap dst 68 lap src 133 ATP: TRsp, tid 0004, userBytes 89010000
E 80 0.0000 lap dst 133 lap src 68 ATP: TRel, tid 0004, userBytes 04bf0100
E 80 0.0000 lap dst 133 lap src 68 ASP: Tickle, sess 01, userBytes 0000
vs.
E 80 0.0000 lap dst 254 lap src 111 ASP: OpenSess, sess bf, userBytes 0100
E 80 0.0000 lap dst 111 lap src 254 ATP: TRsp, tid 0004, userBytes 90000000
E 80 0.0000 lap dst 254 lap src 111 ATP: TRel, tid 0004, userBytes 04bf0100
E 80 0.0000 lap dst 254 lap src 111 ASP: Tickle, sess 00, userBytes 0000

Just putting this out there for the more network savvy.

 

[NJRoadfan]

TashRouter knows the zone name, so it should be sending it with NBPLkup requests per the source code. Maybe a bug? Is the Apple IIe responding to the NBPLookup requests in both cases?

The session IDs have to do with AFP, which is outside of what TashRouter would handle. It would be interesting to see if the "tickle" isn't being transmitted between client and host with TashRouter at regular intervals. Not receiving that packet would cause either side to drop the connection after a timeout.

 

[shirsch]

If you have a Mac System 7.x environment the Watcher utility can load the raw data I posted. Then you can filter and dive into each packet for a full decoding with payload.

Otherwise, here are the very end of the traces. First is the Gatorbox (stable sessions):

E 80   0.0000 lap dst 133  lap src  68  AFP: GetVolParms, sess 01, tid 002a
E 80   0.0000 lap dst  68  lap src 133  ATP: TRsp, tid 002a, userBytes 00000000
E 80   0.0000 lap dst 133  lap src  68  ATP: TRel, tid 002a, userBytes 02010024
E 80   0.0000 lap dst 133  lap src  68  ASP: Tickle, sess 01, userBytes 0000
E 80   7.0000 lap dst 255  lap src 133  RTMP: network 256, node 133
E 80   2.0000 lap dst  68  lap src 133  ASP: Tickle, sess 01, userBytes 0000
E 80   4.0000 lap dst 133  lap src  68  ASP: Tickle, sess 01, userBytes 0000
E 80   3.0000 lap dst 255  lap src 133  RTMP: network 256, node 133
E 80  10.0000 lap dst 255  lap src 133  RTMP: network 256, node 133
E 80   1.0000 lap dst 133  lap src  68  ASP: Tickle, sess 01, userBytes 0000
E 80   8.0000 lap dst 255  lap src 133  RTMP: network 256, node 133
E 80   1.0000 lap dst  68  lap src 133  ASP: Tickle, sess 01, userBytes 0000
E 80   4.0000 lap dst 133  lap src  68  ASP: Tickle, sess 01, userBytes 0000
E 80   4.0000 lap dst 255  lap src 133  RTMP: network 256, node 133
E 80   9.0000 lap dst 133  lap src  68  ASP: Tickle, sess 01, userBytes 0000
E 80   0.0000 lap dst 255  lap src 133  RTMP: network 256, node 133
E 80   9.0000 lap dst  68  lap src 133  ASP: Tickle, sess 01, userBytes 0000
E 80   0.0000 lap dst 255  lap src 133  RTMP: network 256, node 133
E 80   4.0000 lap dst 133  lap src  68  ASP: Tickle, sess 01, userBytes 0000
E 80   5.0000 lap dst 255  lap src 133  RTMP: network 256, node 133
E 80   8.0000 lap dst 133  lap src  68  ASP: Tickle, sess 01, userBytes 0000
E 80   1.0000 lap dst 255  lap src 133  RTMP: network 256, node 133

and this is the TashTalk + TashRouter session (dead by the time the trace was stopped):

E 80   0.0000 lap dst 254  lap src 111  AFP: GetVolParms, sess 00, tid 001e
E 80   0.0000 lap dst 111  lap src 254  ATP: TRsp, tid 001e, userBytes 00000000
E 80   0.0000 lap dst 254  lap src 111  ATP: TRel, tid 001e, userBytes 02000018
E 80   4.0000 lap dst 255  lap src 254  RTMP: network 3, node 254
E 80   7.0000 lap dst 254  lap src 111  ASP: Tickle, sess 00, userBytes 0000
E 80   2.0000 lap dst 255  lap src 254  RTMP: network 3, node 254
E 80   4.0000 lap dst 111  lap src 254  ASP: Tickle, sess 00, userBytes 0000
E 80   5.0000 lap dst 255  lap src 254  RTMP: network 3, node 254
E 80   2.0000 lap dst 254  lap src 111  ASP: Tickle, sess 00, userBytes 0000
E 80   7.0000 lap dst 255  lap src 254  RTMP: network 3, node 254
E 80   7.0000 lap dst 254  lap src 111  ASP: Tickle, sess 00, userBytes 0000
E 80   2.0000 lap dst 255  lap src 254  RTMP: network 3, node 254
E 80   4.0000 lap dst 111  lap src 254  ASP: Tickle, sess 00, userBytes 0000
E 80   5.0000 lap dst 255  lap src 254  RTMP: network 3, node 254
E 80   9.0000 lap dst 255  lap src 254  RTMP: network 3, node 254
E 80   9.0000 lap dst 255  lap src 254  RTMP: network 3, node 254
E 80   4.0000 lap dst 111  lap src 254  ASP: Tickle, sess 00, userBytes 0000
E 80   5.0000 lap dst 255  lap src 254  RTMP: network 3, node 254

Hmm. Now does the tashrouter decide to claim 254? That's kinda, almost a magic number which makes me suspect an off-by-one somewhere. How can I convince tashrouter to assign itself, e.g. 150?

 

[tashtari]

Now does the tashrouter decide to claim 254?

TashRouter does intentionally go for 254 first on LocalTalk networks.

 

[shirsch]

I was worried about another Apple firmware issue that wasn't properly handling node 254 due to an off-by-one in the code. Just for fun I patched the constructor for LocalTalkPort() to use 151 - no joy. Still the same dropped session. I'll keep chipping away.

Forgot to mention: An SE/30 running 7.5.5 fails to get a zone when its on the localtalk side of tashrouter. When I switch to ethernet it sees it immediately.

 

[NJRoadfan]

I'm not seeing ASP tickle packets coming from your netatalk box when used with TashRouter. The IIe is sending them out and isn't getting a response. I'll have to get Watcher installed and look at the whole packet including the headers to see what is different.

 

[NJRoadfan]

I got Watcher installed. I am unable to correctly view the GatorBox dumps. Files keep loading as EtherTalk format dumps.

 

[shirsch]

Which exact file are you trying to load? I may have gotten things mixed up on my end.

 

[NJRoadfan]

in traces.sit........2eGatorbox_pkt.

Also I might need Wireshark dumps (use filter "atalk") on the Ethernet side to see what the packet headers are there. Something is getting "lost in translation".

 

[shirsch]

I'll take another run at this tomorrow - thanks for looking at it! In the interim, can you try loading `a2e_tt_raw` from `a2e_tt.sit` above? I may have posted the wrong exported file in that first one.

 

[NJRoadfan]

The TashRouter traces are working correctly.

 

[shirsch]

The TashRouter traces are working correctly.

Thanks for confirming. I'll be more careful tomorrow.

 

[shirsch]

@NJRoadfan - Can you take a quick peek at these captures (Wireshark / Ethernet and Watcher / Localtalk) and let me know if the packets you need to see are there? This is for the problematic case of networking the IIe over tashrouter.

 

[NJRoadfan]

Took a peek. Not seeing anything unusual as packets seem to be getting passed between the networks with no issue. Nothing sticking out on the packet headers either. Of note, like the ImageWriter LT card, The Apple IIe Workstation Card does NOT compute a checksum for the extended DDP packet header (its always 0x0000). It looks like TashRouter is computing a checksum for them before transmitting on Ethernet. Maybe that is a problem? Don't really know.

I am also seeing tickle packets from both the netatalk server and the IIe in this dump on both sides of the network, so I suspect that isn't the problem. WireShark flagged some AFP packets as malformed from the netatalk server, but that isn't TashRouter's fault!

Now I just need to see what the GatorBox is doing differently (if anything).

 

[shirsch]

@NJRoadfan - Here is the same set of capture files, but from a Gatorbox session.

 

[NJRoadfan]

I'll dig in. I'm seeing a weird problem with the tickle packets with TashRouter. The source and destination ports aren't matching up.... which is the same with the GatorBox trace. The biggest difference I see between the two on the Ethernet side is as follows.

The Gatorbox does NOT add a checksum to DDP packets coming from the IIe card, it passes the headers unmodified with a checksum of 0x0000. Also the Gatorbox seems to add some garbage trailing bytes to it's Ethernet output.

Looking at the LocalTalk dumps, The Gatorbox RTMP packets advertise two networks/tuples, both the LocalTalk and the Ethernet networks are present. TashRouter appears to do split horizon and only advertises the Ethernet side.

 

[tashtari]

TashRouter appears to do split horizon and only advertises the Ethernet side.

You can disable this, if you want, by changing split_horizon=True to False on line 23 of service/rtmp/__init__.py - hard to believe this would be causing trouble, but I guess you never know.

The Gatorbox does NOT add a checksum to DDP packets coming from the IIe card, it passes the headers unmodified with a checksum of 0x0000.

This is a little harder to duplicate in TashRouter, since the datagram data gets unserialized into a Datagram object and then serialized again with a recalculated checksum, but you can force it to not calculate checksums by commenting lines 110-113 in datagram.py:

    #for byte in data:
    #  checksum += byte
    #  checksum = (checksum & 0x7FFF) << 1 | (1 if checksum & 0x8000 else 0)
    #checksum = checksum or 0xFFFF  # because a zero value in the checksum field means one was not calculated

Even harder to believe that's causing problems, but again, guess you never know...

 

[NJRoadfan]

Note that checking extended DDP packet checksums might cause problems for Mac clients as well. System 7.1 doesn't appear to calculate them on packets it transmits over Ethernet. Apple certainly took the "optional" approach with their software!