ModTashtalk: lt0 driver for Linux

[twelvetone12]

Mini update: I finally build a high-tech adapter for a real localtalk network, and tried everything with MacOS 9.1 which worked well (except copying files to the pc)



My high-tech USB to LocalTalk (not shown the PhoneNet link)


Happy MacOS 9.1 on my PowerBook G3 PDQ. I wanted to try it with my "new" PB150 but it died

 

[NJRoadfan]

Going to have to give the node assignment code a workout. If you have Open Transport installed, you can force a Macintosh to use a specific LocalTalk node number. Handy if you want to force a collision.

 

[NJRoadfan]

Tested address arbitration. It appears to work.....somewhat? I purposely powered on a Macintosh and set it to address 1.54. I did the same in atalkd.conf on the Pi and then started netatalk. Looks like it detected Node 54 being in use, randomly selected node 89, found it was empty and set to node 89, only to do arbitration again on node 55? It works, just that the arbitration runs twice. The second time appears to always be one digit higher then the node it conflicted with.

Sep 22 21:51:08 a2server kernel: [  712.543750] TashTalk: start address arbitration, requested 54
Sep 22 21:51:08 a2server kernel: [  712.543780] TashTalk: control packet 0x81 sent to 54 (6)
Sep 22 21:51:08 a2server kernel: [  712.544785] (1) TashTalk read 7
Sep 22 21:51:08 a2server kernel: [  712.544800] (2) TashTalk start new frame
Sep 22 21:51:08 a2server kernel: [  712.544810] (3) TashTalk done frame, len=5
Sep 22 21:51:08 a2server kernel: [  712.544824] (4) TashTalk next frame
Sep 22 21:51:08 a2server kernel: [  712.544833] (5) Done read, pending frame=0
Sep 22 21:51:08 a2server kernel: [  712.544866] TashTalk: addr 54 is in use, try 89
Sep 22 21:51:08 a2server kernel: [  712.544888] TashTalk: control packet 0x81 sent to 89 (6)
Sep 22 21:51:08 a2server kernel: [  712.561031] TashTalk: control packet 0x81 sent to 89 (6)
Sep 22 21:51:08 a2server kernel: [  712.581040] TashTalk: control packet 0x81 sent to 89 (6)
Sep 22 21:51:08 a2server kernel: [  712.601031] TashTalk: control packet 0x81 sent to 89 (6)
Sep 22 21:51:08 a2server kernel: [  712.621014] TashTalk: control packet 0x81 sent to 89 (6)
Sep 22 21:51:08 a2server kernel: [  712.641018] TashTalk: control packet 0x81 sent to 89 (6)
Sep 22 21:51:08 a2server kernel: [  712.661018] TashTalk: control packet 0x81 sent to 89 (6)
Sep 22 21:51:08 a2server kernel: [  712.681025] TashTalk: control packet 0x81 sent to 89 (6)
Sep 22 21:51:08 a2server kernel: [  712.701015] TashTalk: control packet 0x81 sent to 89 (6)
Sep 22 21:51:08 a2server kernel: [  712.721018] TashTalk: arbitrated address is 89
Sep 22 21:51:08 a2server kernel: [  712.721034] TashTalk: setting address 89 (byte 11 bit 1) for you.
Sep 22 21:51:08 a2server kernel: [  712.721070] TashTalk: set addr to: 0.89
Sep 22 21:51:08 a2server kernel: [  712.721081] TashTalk: read addr: 0.89
Sep 22 21:51:08 a2server kernel: [  712.721092] TashTalk: start address arbitration, requested 55
Sep 22 21:51:08 a2server kernel: [  712.721110] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:08 a2server kernel: [  712.721133] TashTalk: transmission finished, on to next
Sep 22 21:51:08 a2server kernel: [  712.741027] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:08 a2server kernel: [  712.761039] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:08 a2server kernel: [  712.781048] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:08 a2server kernel: [  712.801072] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:08 a2server kernel: [  712.821025] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:08 a2server kernel: [  712.841032] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:08 a2server kernel: [  712.861022] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:08 a2server kernel: [  712.881055] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:08 a2server atalkd[1749]: rtmp_request for lt0
Sep 22 21:51:08 a2server atalkd[1749]: rtmp_request for lt0
Sep 22 21:51:08 a2server kernel: [  712.901013] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:08 a2server kernel: [  712.921012] TashTalk: arbitrated address is 55
Sep 22 21:51:08 a2server kernel: [  712.921026] TashTalk: setting address 55 (byte 6 bit 7) for you.
Sep 22 21:51:08 a2server kernel: [  712.921062] TashTalk: set addr to: 0.55
Sep 22 21:51:08 a2server kernel: [  712.921073] TashTalk: read addr: 0.55
Sep 22 21:51:08 a2server kernel: [  712.921089] TashTalk: lt0 set_multicast_list executed
Sep 22 21:51:18 a2server atalkd[1749]: rtmp_request for lt0
Sep 22 21:51:28 a2server atalkd[1749]: as_timer configured lt0 phase 1 from seed
Sep 22 21:51:28 a2server kernel: [  712.921117] TashTalk: transmission finished, on to next
Sep 22 21:51:28 a2server kernel: [  732.541964] TashTalk: start address arbitration, requested 55
Sep 22 21:51:28 a2server kernel: [  732.541996] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:28 a2server kernel: [  732.561184] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:28 a2server kernel: [  732.581172] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:28 a2server kernel: [  732.611166] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:28 a2server kernel: [  732.631172] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:28 a2server kernel: [  732.661167] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:28 a2server kernel: [  732.681173] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:28 a2server kernel: [  732.701174] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:28 a2server kernel: [  732.721173] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:28 a2server atalkd[1749]: ready 0/0/0
Sep 22 21:51:28 a2server systemd[1]: Started Netatalk AppleTalk daemon.
Sep 22 21:51:28 a2server kernel: [  732.741173] TashTalk: control packet 0x81 sent to 55 (6)
Sep 22 21:51:28 a2server kernel: [  732.761164] TashTalk: arbitrated address is 55
Sep 22 21:51:28 a2server kernel: [  732.761179] TashTalk: setting address 55 (byte 6 bit 7) for you.
Sep 22 21:51:28 a2server kernel: [  732.761212] TashTalk: set addr to: 1.55
Sep 22 21:51:28 a2server kernel: [  732.761224] TashTalk: read addr: 1.55
Sep 22 21:51:28 a2server kernel: [  732.761239] TashTalk: lt0 set_multicast_list executed

 

[NJRoadfan]

Another bug. Manually setting lt0 to use node 254 fails.

Sep 22 22:23:30 a2server atalkd[2303]: setifaddr: lt0 (0-0): Invalid argument. try specifying a smaller net range.

I can actually use node 254 on a Macintosh, so technically this should work. This may be a Linux kernel bug. Note that if I set a Macintosh to 253 and attempt to have netatalk use 253, it loops back to node 1 instead of attempting node 254.

Edit: This appears to be a atalkd bug, unrelated to modtashtalk. Fails with Ethernet interfaces too. This might have something to do with the infamous "FIRSTNET" FreeBSD bug.

 

[twelvetone12]

The second attempt at address arbitration seems to come somewhere from the AppleTalk stack. I tried this in raw.c where I'm sure there is only one call to set the address, and I get the same result as you, but in no place I set the address twice! I will have a deeper look, personally I'm not a huge fan of doing +1, the mac seems to jump quite a bit when assigning a new anddress and I prefer this method.
I'm also not sure how many times I should send the ENQ, the mac does many, but I did not find a place in IA where it specifies a number (maybe I just missed it)

 

[robin-fo]

254

IIRC This address is forbidden in extended networks (e.g. EtherTalk) but should be valid in LT

 

[twelvetone12]

Is there anybody that knows the AppleTalk kernel stack of netatalk well that can help me out? I think I tracked the problem with sending files from the mac to the pc crashing.
Extremely long story short, the deadlock happens because the function at_addr_eq() in atp_packet.c at some point cannot match anymore the network number for the packets coming off the incoming socket. For some reason they are set to ATADDR_ANYNET and netatalk expects a non-zero network number. I have no idea why it happens here nor if something gets messed up in the socket table in the kernel. But if I add ANYNET to the check for saddr:

paddr->sat_addr.s_net == ATADDR_ANYNET || saddr->sat_addr.s_net == ATADDR_ANYNET ||

it starts to work and I get my files from the mac to the linux box.
Any wisdom is appreciated!

 

[NJRoadfan]

I haven't run across this problem. Make sure -phase 1 is set for the lt0 interface in atalkd.conf. If it is trying to set a network range, then that might be the problem as LocalTalk only supports one network.

 

[twelvetone12]

Yup indeed it is set as phase 2! But... no matter what I do, phase 1 does not work. I start atalkd + afpd and packets never make it to the tashtalk driver, they disappear in the AppleTalk stack I guess this is something else to debug another day.
On a more positive note, with my fix/hack in atp_packet.c, the system seems rock solid! I've been transferring files back and forth with my three powerbooks both via PhoneNet and my homemade modem adapter and it seems very stable. Also after adding the pull-up I rarely get frame errors. I tried it with my RPi 2, and it seems to work well there too.

 

[NJRoadfan]

Meanwhile, everything is working just fine here, no modifications. I am running the 20230701 release of netatalk-2.x. The AppleTalk stack is wonky though. It was the source of all those weird 605 byte packets after all. I found that during testing, rebooting often was a good course of action!

 

[twelvetone12]

The AppleTalk stack in Linux absolutely could use some love! I would be in to try to fix at least some of the issues I have found, but I would need help from people more knowledgeable than me in kernel affairs to guide me at least on how to submit eventual patches.

 

[NJRoadfan]

Confirming that ddp.c in the Linux AppleTalk kernel is rejecting 254 as a valid node assignment. I guess no consideration for LLAP was made there.

 

[twelvetone12]

I was studying the kernel too today, the "double" assignment of the addresses happens there too.

 

[bigmessowires]

Semi-related: Is there a way to get the LocalTalk-enabled version of Mini vMac, without needing to spend hours installing and configuring a dev environment and building it from source? My Google searches have come up empty. None of the official downloads on the Gryphel site appear to include the LocalTalk support.

 

[twelvetone12]

I have a version for Linux and MacOS (Intel) that I have compiled myself and I can share them if I'm allowed to.

 

[bigmessowires]

If you can share the MacOS version, that would be awesome. I looked at the Gryphel Mini vMac variations service, but it doesn't include LocalTalk as an option. I'm also not sure if you can still get a "subscriber code" for the variations service now that Paul Pratt is MIA and unfortunately probably deceased. Alternatively, is there a simpler way to build Mini vMac on a modern Macintosh that doesn't require a 40 GB install of XCode and an Apple developer program registration?

 

[tashtari]

If you can share the MacOS version, that would be awesome.

Here you are - I still have a working subscriber code from January.

 

[bigmessowires]

Thank you! I'm excited to try out AirTalk between my M1 Air and a Mac Plus.

 

[bigmessowires]

I had not noticed that the "advanced" version of the variations service does support LocalTalk as an option, so I paid my fee for a subscriber code.

 

[dougg3]

Thought I would point out that the COPS LocalTalk driver was just recently removed from the kernel. I was CC'ed when the patch was applied this morning and that's how I found out. Looks like this discussion about the licensing of the firmware is what led to the removal. This recently made it into net-next, so I would assume it'll be released with the next major kernel version.

This leaves, as far as I know, no remaining LocalTalk drivers in the kernel since the Farallon driver was removed last year. The next logical step I see the kernel devs taking would likely be total removal of LocalTalk support if nothing is left that supports it...