ModTashtalk: lt0 driver for Linux

[NJRoadfan]

Maybe @dougg3 can share what worked in atalkd.conf when he setup his adapter? I don't see anything in the atalkd commit history that would cause LocalTalk stuff to stop working, but that history only goes back to 2000.

macipgw registers a NBP entity type called "IPGATEWAY" on the AppleTalk network, and handles the translation of MacIP wrapped AppleTalk packets to TCP/IP on an interface. MacIP isn't limited to just LocalTalk, any AppleTalk client can use it on Ethernet too.

 

[cheesestraws]

MacIP is zone-scoped, so the way you do LocalTalk with macipgw is to use a separate localtalk-to-ethernet gateway, run a single zone across the two, then have your MacIP gateway on the Ethernet side.

 

[dougg3]

Maybe @dougg3 can share what worked in atalkd.conf when he setup his adapter? I don't see anything in the atalkd commit history that would cause LocalTalk stuff to stop working, but that history only goes back to 2000.

I never got MacIP working as far as I can remember, but I definitely had atalkd routing between LocalTalk and EtherTalk. I posted my atalkd.conf lines at the start of this thread:

ModTashtalk: lt0 driver for Linux

While working on my "portable" version of AirTalk I had my Powerbook 100 hooked via USB to my PC using a makeshift adapter, so I could use tashtalkd and test stuff. "How cool would it be for the PC to be a node in the LocalTalk network" I thought, so I decided I would try my hand to write a...

68kmla.org

It definitely worked. I don't recall just how important the separate zones were or if they were even required. However, I do remember needing to reboot everything after this router was on the network. My separate netatalk server in particular didn't automatically recognize that it was now supposed to be part of network 1 (as opposed to the automatically assigned network FF00 or whatever that EtherTalk defaults to when there isn't a router present)

 

[twelvetone12]

Yup your configuration does work, I was referring to the lines in the COPS document which make atalkd just overwrite them I think my problem is in the afpd configuration now, but now I'm away again and I can't work on this for a couple weeks. In any case my ping code is basically copy/pasted from netatalk and it works, so I guess it is only a question of nailing the correct configuration. Unfortunately I ran out of time for now and could not test it further.

 

[slipperygrey]

Yup your configuration does work, I was referring to the lines in the COPS document which make atalkd just overwrite them I think my problem is in the afpd configuration now, but now I'm away again and I can't work on this for a couple weeks. In any case my ping code is basically copy/pasted from netatalk and it works, so I guess it is only a question of nailing the correct configuration. Unfortunately I ran out of time for now and could not test it further.

I mentioned this elsewhere, but you should be able to stop atalkd from modifying its configuration file by making it world-read-only.

 

[NJRoadfan]

Briefly looked at this. Couldn't get it to compile on a RPi400 running Debian Bullseye with a 6.x kernel. The build system for kernel modules seems to have changed and I really don't have time to fight with a compiler and makefiles. So setting it aside for now.

 

[twelvetone12]

What is the error? I compile it with 6.2 on my ubuntu 22 box, so unless something drastic happened between this and 6.5 it should be something easy to spot and fix.

 

[NJRoadfan]

It is having problems finding the header files in the "asm" directory, starting with "asm/types.h". This is with Raspberry Pi OS based on Debian bullseye, arch is aarm64 (RPi400).

 

[NJRoadfan]

Alright, some rpi shenanigans out of the way and..... I got it to work. I have to pull out a Macintosh, but I did manage to get the first stage netboot to come up on the Apple IIgs. I can get to the password prompt to log-in. After entering credentials it locks up. I'm seeing activity on the tcpdump I have running, so I need to test with an emulator to make sure this install of A2SERVER on the pi is actually working right before continuing.

 

[NJRoadfan]

OK, outside of some atalkd wonkiness, it appears that my TashTalk is wedging itself after a few packets. I'm getting errors like "protocol 0000 is buggy, dev lt0" and the kernel keeps trying to send the packet with no response. There is no incoming communications at this point. Perhaps a "de-wedge" function like the @cheesestraws AirTalk firmware has is needed here?

The good news is MacIP works with macipgw. It works...... until it blows up.

 

[Tashtari]

Perhaps a "de-wedge" function like the @cheesestraws AirTalk firmware has is needed here?

A de-wedge function should not be necessary - it's not necessary when using tashtalkd, at least.

 

[NJRoadfan]

After a few kbs of packets, the tashtalk hat appears to just drop off the network. The RPi doesn't throw any errors, just tries to resend the last packet. The Macintosh loses all communication with the RPi at that point. Running aecho to ping the client Mac doesn't seem to wedge anything. It only happens when I actually try and use the connection on the Mac beyond just mounting a server or starting to load a simple webpage.

 

[Tashtari]

Might it be a flow control issue? If TashTalk's 128-byte buffer gets overflowed or underflowed, things can go south quick-like.

 

[NJRoadfan]

My setup_and_run is the same, other then the device name

sudo rmmod tashtalk
sudo modprobe appletalk
sudo insmod src/tashtalk.ko
sudo stty -F /dev/ttyAMA0 crtscts
sudo ldattach -d -s 1000000 PPP /dev/ttyAMA0

Looking at tashtalkd, it sets up the serial communications with the same parameters with no issue. I hate debugging weird problems like this.

 

[Tashtari]

I do hate it when debugging hits the point where I have to ask "do you have a logic analyzer", but do you have a logic analyzer? =D

If you do, it might be worthwhile clipping onto the Tx (RPi to TashTalk) and CTS lines and see whether Tx stops when CTS is asserted.

 

[NJRoadfan]

Nope, no logic analyzer on hand. At least I can rule out that its not a hardware issue. I know the tashtalk hat hardware works as I have run it without issue with tashtalkd and mini-vMac when testing. It could be a modtashtalk bug... or not. Ugh.

 

[NJRoadfan]

Well this might explain the multi-interface wonkiness: https://gist.github.com/VinDuv/4db4...-packets-handling-issue-probably-all-versions

This still hasn't been fixed in the kernel module! @dougg3 any possibility this might be addressed? I don't know if it will fix the problem I'm having with nbplkup working with more then one interface, but its worth a shot.

 

[dougg3]

Ahh, interesting! It looks like the author of that gist actually did attempt to submit this fix upstream back in 2020, but ran into some requested review changes from the networking maintainer and never resubmitted. In fact, patch 1 in the series is an attempt to fix the AppleTalk loading bug that I ended up blogging about a week later.

Do you have a way to build a custom kernel with this patch and test it out? I'm uncomfortable with trying to submit this fix upstream without at least having some recent feedback on it, and I don't have the time right now to test it myself. But I would be happy to go through the patch submission process to get it upstreamed if someone's willing to be a tester first. (Or I'm also happy to mentor someone if they want to attempt submitting it themselves). I might need help going back and forth testing a few times if I get review changes requested.

 

[twelvetone12]

@NJRoadfan what did you modify to make this work? What kernel are you using? I would like to write a bit of documentation on how to use this thing.

I worked on the module on the last couple days and while things are starting to work (i.e. I can copy some files via afp and print to my Brother printer via pap) there are still some problems. In particular the driver (or tashtalk) chokes on big outgoing packets, I have a couple theories on why but I did not have time to test it (yet). I think the kernel is messing up with hardware flow, but I need to dig into this. I'm using a regular PC with an USB adapter.

@dougg3 I have a custom kernel and I can run the patch if you want (on my PC). We can also work on resubmitting it (even if the rejection comments seems above pedantic but well...) but I think I cannot do it until mid next week.

EDIT: If you want to see more what the diriver is doing, you can tail /var/log/kern.log, at the moment the driver is extremely chatty. You will probably see some big outgoing packets and then nothing. You can also activate the hexdump of packets and see exactly what is going on before hitting the networking stack. The module now just drops control packets and those are not seen anymore in tcpdump.
Also note that tcpdump is broken since I have to strip the LLAP header from the packets before submitting it to the netif (as required from the AppleTalk layer), so you cannot trust the decoded addresses. I would like to submit a patch for this, but probably it will be rejected because the color of the train I'm on now is wrong, so I'm not sure it is worth the bother. The AppeTalk stack is also extremely silent, so if stuff is wrong it just drops packets and you will never know why. I built a custom version of the kernel with lots of debug info as it was a nightmare to figure out why packets disappeared.

 

[twelvetone12]

I had a moment today and I tried to stress the system with packets up to the MTU. I made an echo that had a 587 byte payload which translated to 597 bytes on the line (with header and checksum). I got perfect echos back. But if I run afpd and try to get a file, I see many big packets going out, then something happens, and everything halts. There is surely a problem I need to fix when the kernel cannot send all the data at once, but that does not seem a problem, since afpd for smaller files re-sends the packet, but it just hangs for bigger files. I can't really put my hand on what is happening, I will try to debug more when I have a moment next time.