TashRouter: An AppleTalk Router

[dougg3]

I resubmitted the patch, fixing the issues the maintainer brought up. We'll see how it goes.

 

[slipperygrey]

Excellent job, thank you for filing this patch, and keeping the DDP dream alive!

 

[dougg3]

Thanks! It appears that it was accepted into the net tree this morning. I'm not sure exactly what that means for which Linux release it'll be included with because 6.9 is so far into the release cycle at this point (6.9-rc7 was released a few days ago). Probably either 6.9 if we're lucky, or otherwise 6.10.

I think I didn't completely follow the correct process because I asked for the patch to go in the net tree (bug fixes) rather than net-next (new features), but I didn't add a "Fixes:" tag because the bug predates Git so I didn't have a SHA to use for the tag. I wasn't sure if you're supposed to use the first SHA in the kernel (Linus importing the whole project into Git) or what, so I just omitted it, even though I think they want you to always have a Fixes tag for commits added to the net tree. I was kind of worried that I would get some pushback on that, but it looks like they accepted it to "net" anyway.

 

[slipperygrey]

That was surprisingly smooth! This will definitely benefit us in the short to mid term.

I pushed an update to the wiki page with this new status of the patch. https://netatalk.io/docs/AppleTalk-Kernel-Module

 

[cheesestraws]

Well done and thankyou, @dougg3!

 

[twelvetone12]

Bravo! Well done!

 

[dougg3]

Thanks! It looks like the net tree for 6.9-rc8 (which might become the final 6.9) was sent to Linus today and it contains the patch. Linus already merged it and you can see that the mainline tree now contains the patch too.

So...I'm pretty sure we squeezed this in just in time before the final release of 6.9.

 

[slipperygrey]

Wow, that is incredibly fortunate! What incredibly good timing for a patch a submission.

Current stable Debian Bookworm is on Linux 6.1 and the upcoming Trixie currently on 6.7 IINM. It’ll be interesting to observe if the Debian team will pull in the bleeding edge kernel before freezing the next stable, which is at least 6 months out I think.

 

[dougg3]

6.9 came out today with the patch included. I would assume they would use a stable version of the kernel for the next Debian stable, so hopefully a new stable version comes out after 6.9 that Debian will use.

If we're lucky, this patch will get selected for backporting to the older stable kernels and percolate its way to older Debian, Ubuntu, etc. versions. Stuff I have done in the past has been picked up for stable automatically, but the lack of the "Fixes:" tag might hurt us there. I suppose if it doesn't get picked up after a while, I can ask for it to be backported. Since people are having to compile custom kernels for it, it seems like it would be useful to backport...

 

[slipperygrey]

Yippie! Blessed by the Linus.

 

[shirsch]

Nice work, all! I need to get busy and build a patched kernel for my Tashrouter Pi.

 

[NJRoadfan]

Great News!

TashRouter has been officially integrated into A2SERVER!

Coming soon is setting up a TashTalk hat if one is installing on a Raspberry Pi. One new thing I learned is how to setup a python program to gracefully shutdown when it receives a SIGTERM to shutdown the process, since SIGINT wasn't cutting it.

 

[NJRoadfan]

Here are the changes to allow systemd to terminate TashRouter cleanly. This is based on @finkmac's example above. It may not be 100% right, but it works™.

import logging
import time
import signal
import sys

import tashrouter.netlog
from tashrouter.port.ethertalk.tap import TapPort
from tashrouter.port.localtalk.ltoudp import LtoudpPort
from tashrouter.port.localtalk.tashtalk import TashTalkPort
from tashrouter.router.router import Router

def sigterm_handler(_signo, _stack_frame):
    # Raises SystemExit(0):
    sys.exit(0)

logging.basicConfig(level=logging.DEBUG, format='%(asctime)s %(levelname)s: %(message)s')
#tashrouter.netlog.set_log_str_func(logging.debug)  # comment this line for speed and reduced spam

router = Router('router', ports=(
  LtoudpPort(seed_network=1, seed_zone_name=b'LToUDP Network'),
  TashTalkPort(serial_port='/dev/ttyAMA0', seed_network=2, seed_zone_name=b'TashTalk Network'),
  TapPort(tap_name='tap2', hw_addr=b'\xDE\xAD\xBE\xEF\xCA\xFE', seed_network_min=3, seed_network_max=5, seed_zone_names=[b'EtherTalk Network']),
))
print('router away!')
router.start()
signal.signal(signal.SIGTERM, sigterm_handler)

try:
  while True: time.sleep(1)
except (KeyboardInterrupt, SystemExit):
  router.stop()

 

[tashtari]

TashRouter has been officially integrated into A2SERVER!

Cool! I hope this'll be useful to Apple II fans. Need to give it a try myself with the old IIgs sometime, too...

Here are the changes to allow systemd to terminate TashRouter cleanly.

Thanks, added this change to the example in the README.

 

[shirsch]

I have been away from Apples for a bit, but just got back to pickup the thread here again. I notice the latest TashRouter has a new interface called MacvtapPort but still retains the older TapPort. My startup program uses the latter. What is the difference between them? Is there a reason I'd want to switch?

 

[tashtari]

I have been away from Apples for a bit, but just got back to pickup the thread here again. I notice the latest TashRouter has a new interface called MacvtapPort but still retains the older TapPort. My startup program uses the latter. What is the difference between them? Is there a reason I'd want to switch?

MacvtapPort uses a different kind of network interface from a tap, a macvtap. Documentation on macvtaps is a bit scanty, but it's a sort of combination of a tap and a bridge. As for switching, it's just another method of getting EtherTalk connectivity, not necessarily better nor worse - if it ain't broke, don't fix it. =)

 

[shirsch]

Heh. Ok, thanks for clarifying. So far everything has been working as advertised!

 

[pl212]

OK, here is my TashRouter/netatalk on the same machine setup. [...]

This was extraordinarily helpful, and has Netatalk successfully communicating with both Mini vMac and LocalTalk devices connected to a TashTalk hat.

The only thing I can't seem to get working is other classic Macs on the same Ethernet segment as the Raspberry Pi running Netatalk with the TashTalk. That is, DDP packets to and from a Quadra on the same hub as the Pi. Do you think I need to make a change to the TapPort line in route.py, and/or the atalkd.conf file to get this working?

 

[NJRoadfan]

If the Ethernet connected Macs aren't seeing a reply to their GetNetInfo packets, you are running into the infamous Linux AppleTalk broadcast kernel bug present in any kernel before 6.9. Move the eth0 line to the last line in your atalkd.conf from my example if it isn't there already. Like this:

tap0 -seed -phase 2 -net 3 -zone "A2SERVER"
eth0 -seed -phase 2 -net 2 -zone "A2SERVER"

The last configured interface always gets send the replies to broadcast requests on those bugged kernels.

TashRouter is unaffected since it doesn't use GetNetInfo to configure itself.

 

[pl212]

the infamous Linux AppleTalk broadcast kernel bug

Wow, you're right -- switching those two lines did the trick! Amazing to have a 660av, 512k, and Mini vMac all on the same network talking to the same netatalk server! Thanks to you and all the rest who have contributed to these efforts...