TashRouter: An AppleTalk Router

[shirsch]

I'll try the changes that @tashtari outlined above and see if it has any effect.

UPDATE: I'm back. Neither of these changes made any difference to the session durability. Still goes down inside of a minute or two.

 

[NJRoadfan]

Also, what is the trace of? Are you trying to netboot the Apple IIe, or just connect and browse an AFP Share? If trying to netboot, it won't work if the netatalk server is not in the same zone as the LocalTalk network, which is clearly the case when TashRouter is in play. A nbplkup should show both the LocalTalk and Ethernet connected devices if everything is in the same zone, like the Gatorbox output.

 

[NJRoadfan]

The only other thing sticking out is NBPLkUps from the LocalTalk side of the Gatorbox (generated by the router) have a zone name and are extended DDP packets, (no checksum).

 

[shirsch]

Also, what is the trace of? Are you trying to netboot the Apple IIe, or just connect and browse an AFP Share? If trying to netboot, it won't work if the netatalk server is not in the same zone as the LocalTalk network, which is clearly the case when TashRouter is in play. A nbplkup should show both the LocalTalk and Ethernet connected devices if everything is in the same zone, like the Gatorbox output.

I outlined the test conditions previously, but it's strictly connect to the server as a named user (a2e) and list the directory of an AFP share.

 

[shirsch]

The only other thing sticking out is NBPLkUps from the LocalTalk side of the Gatorbox (generated by the router) have a zone name and are extended DDP packets, (no checksum).

I think I mentioned this already, but the Mac SE/30 does not report a zone when connecting through the tashrouter. Would this be why?

 

[NJRoadfan]

If TashRouter is seeding the network, it should be replying to ZIP requests (GetMyZoneRequest) from the SE/30 when you open up Chooser or the Network Control Panel. This is happening without a problem on the Apple IIe per the packet dumps.

 

[NJRoadfan]

Also found another anomaly with TashRouter. It is not incrementing the "hop count" value on extended DDP Packets that pass thru the router. I don't know if this is really that important though.

 

[tashtari]

It is not incrementing the "hop count" value on extended DDP Packets that pass thru the router.

I only increment the hop count when sending a datagram to another router, not when sending it directly to its destination. Unless I've misread it, this is consistent with the flowchart on page 5-26 of Inside AppleTalk.

If TashRouter is seeding the network, it should be replying to ZIP requests (GetMyZoneRequest) from the SE/30 when you open up Chooser or the Network Control Panel.

It should be responding to ZIP requests whether or not it's a seed router, if that's somehow not happening I'd be interested to know about it...

The only other thing sticking out is NBPLkUps from the LocalTalk side of the Gatorbox (generated by the router) have a zone name

If TashRouter is sending out LkUps with a zone of * in response to a BrRq from a LocalTalk network whose zone name it knows, something's wrong - it should be substituting in the zone name.

 

[NJRoadfan]

I'm guessing the GatorBox engineers read page 4-17 and interpreted it as saying any packet going through a router....oops. Not that it harms anything. I'm guessing this was another programming optimization as just incrementing it saves the overhead of a branching statement.

 

[shirsch]

It should be responding to ZIP requests whether or not it's a seed router, if that's somehow not happening I'd be interested to know about it...

All I can tell you is what I'm observing. The IIe does get a zone name, but an SE/30 on the same LT network just calls out "unknown". If I switch the SE/30 to ethertalk it gets the zone without incident. The traces show a difference in behavior from the Gatorbox, specifying '*' as the zone.

If TashRouter is sending out LkUps with a zone of * in response to a BrRq from a LocalTalk network whose zone name it knows, something's wrong - it should be substituting in the zone name.

Then I can only conclude something's amiss because the packets on the localtalk side just carry a wildcard.

 

[NJRoadfan]

I can confirm that the Apple IIgs does something similar (NBP BrRq packets with zone *) and netatalk's atalkd relays the LkRq with the zone filled in. None of this should really matter though. Looking at IIgs DDP stack source and Wireshark dumps, it appears that machine does calculate checksums for extended DDP packets unlike the IIe card and ImageWriter.

All of this has my head spinning. Something is broken, but who knows what the heck it is. I decided to check the Linux kernel source and see how it handles some of this stuff. A few observations:

-The kernel DOES check the validity of extended DDP header checksums and will drop them if they aren't correct. If it receives a checksum of 0x0000, it assumes no checksum and doesn't drop the packet.

-The kernel unconditionally increments the hop court of all routed DDP packets just like the GatorBox does.

Really, the only problem area I could possibly see is the maybe TashRouter's generated checksums are incorrect? The GatorBox is passing thru extended packets with checksums of 0x0000, which the kernel or any other host would ignore.

 

[tashtari]

Really, the only problem area I could possibly see is the maybe TashRouter's generated checksums are incorrect? The GatorBox is passing thru extended packets with checksums of 0x0000, which the kernel or any other host would ignore.

Hm, @shirsch tried a change earlier that has TashRouter stick zero checksums in datagrams and it doesn't seem to have made any difference.

 

[NJRoadfan]

Another subtle difference with the GatorBox. The GatorBox always sends RTMP broadcasts as non-extended DDP packets on LocalTalk. Given the symptoms, I'm betting the IIe card (and maybe the ImageWriter) can't accept RTMP broadcasts on extended packets. I know when I was debugging netatalk, client machines started to lock up and become unresponsive after about a minute of no RTMP packets after a ZIP request gave the machine network info.

 

[tashtari]

You can turn off use of the short header entirely by changing these lines in port/localtalk/__init__.py

    if datagram.destination_network == datagram.source_network and datagram.destination_network in (0, self.network):
      self.send_frame(bytes((node, self.node, self.LLAP_APPLETALK_SHORT_HEADER)) + datagram.as_short_header_bytes())
    else:
      self.send_frame(bytes((node, self.node, self.LLAP_APPLETALK_LONG_HEADER)) + datagram.as_long_header_bytes())

to

    if 0: #datagram.destination_network == datagram.source_network and datagram.destination_network in (0, self.network):
      self.send_frame(bytes((node, self.node, self.LLAP_APPLETALK_SHORT_HEADER)) + datagram.as_short_header_bytes())
    else:
      self.send_frame(bytes((node, self.node, self.LLAP_APPLETALK_LONG_HEADER)) + datagram.as_long_header_bytes())

 

[NJRoadfan]

What would the code be to force all RTMP broadcasts to short DDP on LocalTalk? I'm also recalling @RolandJuno's ImageWriter stalling out after a minute or so of printing. That would line up with a client throwing its hands up in the air and timing out from not getting a RTMP packet. Given the limited CPU resources and lack of system timer on the Apple IIe, the Workstation card likely handles RTMP with it's onboard CPU and firmware routines. Those routines may not be able to handle an extended packet.

 

[tashtari]

What would the code be to force all RTMP broadcasts to short DDP on LocalTalk?

Hmm, try changing source_network=port.network on line 46 of service/rtmp/sending.py to source_network=0x0000 - looks like the way I implemented it, they'd always be sent with the extended header...

 

[NJRoadfan]

Pulled out the Fastpath 5 and Fastpath 4, it too is broadcasting RTMP with short DDP packets.

 

[tashtari]

Pulled out the Fastpath 5, it too is broadcasting RTMP with short DDP packets.

Yeah, that's not surprising, I guess there's no reason to broadcast RTMP with extended header DDP datagrams. Whether it makes a difference to the IIe is the question, though...

 

[tashtari]

Question for the network experts out there... when sending RTMP broadcasts over EtherTalk, what destination network number should a router use? I've been using 0x0000, but Inside AppleTalk seems to be silent on this point...

 

[tashtari]

That would line up with a client throwing its hands up in the air and timing out from not getting a RTMP packet. Given the limited CPU resources and lack of system timer on the Apple IIe, the Workstation card likely handles RTMP with it's onboard CPU and firmware routines. Those routines may not be able to handle an extended packet.

The thing that confounds me about this as a potential explanation, though, is why does it work at all in the first place, if this is the case? If TashRouter is sending all its RTMP broadcasts over LocalTalk as extended-header datagrams, which it is, then why would the workstation card and/or ImageWriter be able to parse them at first but not later?