TashRouter: An AppleTalk Router

[NJRoadfan]

I had some headbanging with netbooting my IIgs as well. Found out it was an issue with the zone, an issue that isn't well documented (if at all!). I did get it to work eventually, so I can confirm that TashRouter is not the cause of netbooting issues.

Despite its promises of "self configuring", diagnosing AppleTalk routing issues can be a nightmare. Figuring out the "split horizon" bug in netatalk's atalkd was a "Its Not DNS, There's No Way it is DNS, It was DNS" type of moment!

Note that TashRouter does not register a NBP entry for itself on the network like the GatorBox and FastPath do. That is why you can't "see" it.

Also,

nbplkup

only shows devices on the default zone. You can force it to show devices on other zones like this:

nbplkup @'TashTalk Network'

. You can list all zones on a network with the

getzones

command.

The good thing is TashRouter sees your GatorBox and is updating its routing table. I do see a problem with the netatalk box's configuration. It looks like atalkd on the netatalk box is setup to use network number '1' which clashes with TashRouter's network '1' setup for LToUDP. Network numbers need to be unique over the whole inter-network.

It would also be helpful to know how the GatorBox is setup. Is the GatorBox seeding the Ethernet port, or is the netatalk box seeding the network (-router switch in atalkd.conf)?

 

[shirsch]

The netatalk server 'dockstar' uses this setup:

eth0 -router -phase 2 -net 1-255 -addr 1.163 -zone "LocalTalk2ZoneA"

I edited the taprouter.py to use network 2, 3 and 4-6. No improvement. I cannot see anything on the Tashtalk network from the server. getzones shows only my zone - I don't see the other three from the ethernet side.

 

[shirsch]

A light just went on... My netatalk server definitely has the 'split horizon' mod, since that was the only way I could get it to cooperate with most of the little bridge boxes. I know there have been a bunch of changes to the netatalk code base as of late, but I was hoping to avoid having to update a server that's been working reliably for over 12 years. Could the 'split horizon' patch (which I've never understood on the technical level) be causing the issues I'm seeing?

 

[NJRoadfan]

If the netatalk box itself is routing between two networks (has two interfaces in atalkd.conf) .... yes. If it is standalone, using the -router switch, to seed the network, likely not but I can't rule it out. I haven't tested TashRouter on a separate machine, although I have tested atalkd with the -router switch and a FastPath and it works fine.

Something isn't communicating here. TashRouter's debug output should be showing something like:

DEBUG: router adding: RoutingTableEntry(extended_network=True, network_min=1 network_max=255, distance=1, port=tap2, next_network=1, next_node=28)
DEBUG: router adding network range 1-255 to zone LocalTalk2ZoneA (now default zone for this range)

Either atalkd isn't outputting the correct RTMP packets, or TashRouter isn't receiving them. If TashRouter is seeing RTMP packets from the GatorBox, then its likely atalkd not working right. A wireshark trace on the Ethernet network of RTMP packets from the netatalk box would be helpful. I would try Netatalk 2.3.1 first though.

 

[NJRoadfan]

OK, what is likely happening is the GatorBox is NOT advertising the Ethertalk segment/tuples in its RTMP broadcasts over Ethernet, only the LocalTalk side's network...... aka, it is properly implementing split horizon since another router on the network should be advertising it (but really isn't). This is why TashRouter can see the Gatorbox's LocalTalk network. My Fastpath 4 and 5 always advertise both networks over RTMP on the Ethernet side. Regardless, you should be seeing RTMP packets every couple of seconds from the netatalk box.

One additional troubleshooting step would be to disable atalkd's routing functions (fill atalkd.conf with just 'eth0', no other info) and let TashRouter OR the GatorBox seed the Ethernet network. It looks like TashRouter is already seeding the Ethernet network, which may be why atalkd is confused (always restart the atalkd service after starting TashRouter).

 

[shirsch]

I restarted the tashrouter, then stopped netatalk, modified atalkd.conf as you suggested and restarted it. The ethertalk network is now showing up as 55, but the debug message remains the same - showing

DEBUG: router adding network range 256-256 to zone LocalTalk2ZoneA (now default zone for this range)

as it did before. The Apple 2 still cannot find the file server, so aside from the ethertalk zone number nothing has changed. Getzones is not finding anything other than LocalTalk2ZoneA. nbplkup @'TashTalk Network' still shows nothing.

Also, to be clear, that LocalTalk2ZoneA zone name is found on both sides of the Gatorbox. I can plug a Mac into either the localtalk string - or - switch it to ethertalk and the zone name remains the same. Were you expecting it to differ between the LT and ethernet segments?

 

[NJRoadfan]

Do the following.
-Stop TashRouter, Stop all netatalk services, Turn off the GatorBox
-Make sure atalkd.conf contains just 'eth0' and no other network data
-Start TashRouter. This should advertise/seed network range 3-5 over Ethernet with a zone named "EtherTalk Network"
-Start all Netatalk services. After loading, atalkd.conf should update itself to be on network range 3-5 with a random node number. Run "nbplkup" to verify network assignment of the machine and "getzones" should show all TashRouter created zones.
-Finally start the GatorBox. After booting, it should show itself on network 3-5 and advertise it's configured Localtalk network number (256) and zone. This is assuming the GatorBox is set to "soft seed" or not seed the Ethernet side and seed the LocalTalk side.

 

[shirsch]

Well, that gets things a bit further. getzones shows:

root@dockstar:/etc/netatalk# getzones
EtherTalk Network
LToUDP Network
TashTalk Network

The Apple 2 finds the dockstar server on the EtherTalk Network and can list files on mounted directories. However, the connection is dropped after about a minute or so.

nbplkup:

root@dockstar:/etc/netatalk# nbplkup                     
                       dockstar:ProDOS16 Image                     3.236:3
                       dockstar:Apple //e Boot                     3.236:3
                       dockstar:Apple //gs                         3.236:3
                       dockstar:AFPServer                          3.236:128
                       dockstar:netatalk                           3.236:4
                       dockstar:Workstation                        3.236:4
               HP LaserJet 2200:SNMP Agent                         3.4:8
               HP LaserJet 2200:LaserWriter                        3.4:158
               HP LaserJet 2200:LaserJet 2200                      3.4:157
               HP LaserJet 2200:HP Zoner Responder                 3.4:156

Shortly after I switch on the Gatorbox, I see this from the tashrouter:

DEBUG: router adding: RoutingTableEntry(extended_network=False, network_min=256, network_max=256, distance=1, port=tap2, next_network=1, next_node=28)
2024-03-06 19:39:34,211 DEBUG: router adding network range 256-256 to zone LocalTalk2ZoneA (now default zone for this range)

The Gatorbox does NOT appear in the nbplkup listing, nor does getzones show the LocalTalk2ZoneA.

 

[NJRoadfan]

Looks like atalkd is now configuring itself to TashRouter's network settings, which is good. I don't know what is up with the GatorBox that the netatalk box isn't seeing it and it's configured LocalTalk zone, yet TashRouter sees it fine. I would have to see its configuration. Try "npblkup @LocalTalk2ZoneA".

Is the Apple II connected to a TashTalk on the Pi Zero or to the Gatorbox? That issue sounds exactly like the issue I was having with netatalk and the split horizon patch. After a minute of being connected to a Ethernet network, a machine would drop all connections since it wasn't getting a RTMP "tickle".

 

[shirsch]

npblkup @LocalTalk2ZoneA - returns nothing.

The Apple 2 is connected to the Tashtalk hat (Pi Zero). I had been having build problems with the latest netatalk (with fixed horizon behavior), but finally found a workaround. Tomorrow I'll try running with that code.

More information: I can no longer route to the netatalk server from machines on the localtalk side of the Gatorbox. I'm thinking there's a configuration issue that's preventing it from playing nicely with the new net number assignment (just a guess, though).

Thanks for your help!

 

[tashtari]

The latest from the Void IRC channel:

20:57 <abby> Tashtari: still need to test this on all rpis, but you can try the kernel with CONFIG_MACVTAP=m with xbps-install -R https://devspace.voidlinux.org/abby/updates/rpi/ -Su
20:58 <abby> key fingerprint is 6e:a5:91:cc:71:99:18:32:75:dc:be:b4:f8:ac:dc:19 signed by classabbyamp iirc

 

[shirsch]

The latest from the Void IRC channel:

20:57 <abby> Tashtari: still need to test this on all rpis, but you can try the kernel with CONFIG_MACVTAP=m with xbps-install -R https://devspace.voidlinux.org/abby/updates/rpi/ -Su
20:58 <abby> key fingerprint is 6e:a5:91:cc:71:99:18:32:75:dc:be:b4:f8:ac:dc:19 signed by classabbyamp iirc

After an entire morning spent chasing kernel panics on the Pi Zero W I was finally able to install this new kernel. It seems to work as advertised! The recipe for tashrouter invocation now works with macvtap and is behaving as well as my attempt yesterday with Raspbian. Currently building a new netatalk for the server that has the split horizon bug corrected. Hopefully this solves the disconnects.

The instability issue was cured by adding:

force_turbo=1

to /boot/config.txt. No idea why it works, but after reading a thread that reported a litany of problems this emerged as the least invasive fix.

 

[shirsch]

After rebuilding atalkd with the split-horizon patch reverted I'm sorry to say that the disconnects continue. It didn't seem to change much of anything.

 

[shirsch]

For completeness' sake, I tried building atalkd with all flavors of the "split horizon" patch: None present, '!=', '==' and the latest from the current sources 'if (!(iface->i_flags & IFACE_RSEED) && (rtmp->rt_iface == iface)) {'. In all cases the Apple 2e gets disconnected in about a minute. The atalkd binary is the only executable affected by that, correct?

I would be glad to gather data for troubleshooting, but need some specific guidance.

 

[NJRoadfan]

Yes, only atalkd is affected. I don't think its the problem though. Make sure getty or any other terminal is NOT running on /dev/ttyAMA0, otherwise it will interfere with things. Someone else here had that problem.

We have netatalk seeing the TashRouter seeded networks. Somewhere data is not making it thru the router. When the Apple II is up and running, does it appear in nbplkup queries? You will have to specify the zone with the command in that case.

 

[shirsch]

Yes, only atalkd is affected. I don't think its the problem though. Make sure getty or any other terminal is NOT running on /dev/ttyAMA0, otherwise it will interfere with things. Someone else here had that problem.

I'm not sure how to do this on Void Linux, but I'm going back and forth with Raspbian and there I was able to use raspi-config to ensure it wasn't presenting a console on the serial port. How can I verify whether or not getty is attached to /dev/ttyAMA0?

We have netatalk seeing the TashRouter seeded networks. Somewhere data is not making it thru the router. When the Apple II is up and running, does it appear in nbplkup queries? You will have to specify the zone with the command in that case.

Before the Apple 2 is disconnected it does show when I do "nbplkup @'Tashtalk Network'". It disappears from the this listing almost a minute before I hear the beep-of-death from the Apple to inform me "no more server".

 

[shirsch]

I built and installed the latest release of netatalk as a control. No difference. Still disconnects within a minute or so.

 

[tashtari]

I'm not sure how to do this on Void Linux, but I'm going back and forth with Raspbian and there I was able to use raspi-config to ensure it wasn't presenting a console on the serial port. How can I verify whether or not getty is attached to /dev/ttyAMA0?

I think Void doesn't run agetty on ttyAMA0 unless you've enabled the service yourself. You can check with ps aux | grep agetty. You might also check whether the kernel's console parameter points to it, with cat /proc/cmdline.

 

[shirsch]

Currently running Raspbian and I believe this indicates agetty isn't using the /dev/ttyAMA0 interface:

/sbin/agetty -o -p -- \u --noclear tty1 linux

I'd really like to help get things figured out and will be glad to grab Wireshark traces and/or debug output. Just need a few specifics on what and where to grab data.

 

[shirsch]

Important update: Whatever is going on with the session drops, it's particular to the Apple II workstation card. My //gs stays connected without incident. Do any of the active developers have access to a //e + Apple Workstation card? If not, my offer to gather data stands.

$ nbplkup @'TashTalk Network'
                         hirsch:Apple IIgs                         2.1:129

I assume a Mac will cooperate as well. Will try a bit later.