ModTashtalk: lt0 driver for Linux

[dougg3]

They already replied, and were very kind! Sincerely I was a bit nervous to to post on the Linux mailing list for the first time

Congrats on your first successful interaction with the Linux kernel developers! I would say the response seems to be really good news. They probably appreciate getting your feedback right away too.

 

[twelvetone12]

I did some browsing of the kernel source. Looks like the COPS driver and friends were the only ones using ndo_do_ioctl to do SIOCGIFADDR and SIOCSIFADDR. Looks like these commands are normally reserved for higher level protocols (like TCP/IP) and not directly implemented in network devices. Clearly it was an acceptable hack 20+ years ago, but I can see why they want it removed.

I think a first stage I can remove that, it is relatively minor (I hope, it is mostly to make Netatalk happy!) I think then further redesign of the localtalk stuff is due, which is old and quite messy.
They proposed to switch to userspace and make a tun/tap driver, I'm not 100% sure how it would work but I will have a look into that, the main reason I like the lt driver is that software already supports it as-is. I guess I could use tap to create phase2 frames and pass them to the kernel?

 

[NJRoadfan]

I looked into using a TAP interface (TUN is IP p2p only). The biggest issue is that it is a virtual Ethernet interface, which AppleTalk deals with in a very different manner vs. LocalTalk. You'd have to add the following to your driver, which is a bit of work:

-Build a ELAP-to-LLAP packet translation bridge. This would convert the AppleTalk SNAP DDP packets to/from LocalTalk DDP packets. It goes without saying that you would have to filter out all non-AppleTalk packets going to the interface.

-Handle Ethernet AARP requests. This would be how the virtual interface gets/sets its network and node ID. Thing is you have to be careful with all this since LocalTalk is a non-extended network (only one network number).

I can see why LocalTalk was implemented the way it was in the Linux AppleTalk stack. They basically bypass the AARP probe when a LocalTalk interface is detected and pass whatever node number the interface auto acquired. The DDP packet handling code also has a LocalTalk specific mode.

TL;DR: Yes it can be done in userspace. GSPort does it to allow an emulated Apple IIgs to access AppleTalk resources on Ethernet. No, it is NOT easy, particularly when you have a kernel AppleTalk stack that only makes assumptions that it is running on a Phase 2 EtherTalk network and thinks it's talking to an Ethernet card. I don't know how well versed the kernel mailing list folks are on AppleTalk in general. I'm betting they don't know that LocalTalk is VERY different from Ethernet when it comes to the data and network layers.

Even the GSPort example may not work as-is in this case. That senario is a LocalTalk client on an Ethernet network. The bridge handles the AARP requests on behalf of the client and some workarounds are done on the LocalTalk side with node address assignment. This would be the opposite (Ethernet on a LocalTalk network).

 

[twelvetone12]

Firstly the good news: they vert kindly changed the patch so I have time to submit the tashtalk driver!
I think the userspace solution is interesting to explore, but I'm not sure it is 100% doable. Basically as you said we need to transform LLAP into ELAP, which is something the kernel already does (it is the thing that breaks tcpdump!), but the kernel also has more logic, for example in the DDP code you mentioned, to make LLAP work.
The kernel maintainers did not seem in a rush to remove this code, so I think it is worth exploring both solutions, also keeping an eye on what it the best and easier solution to manage in the future. I like a lot the tashtalk driver but it is a bit complex to use, with the line discipline, ifconfig setup, and all the rest. The tap solution may be more easy for the end user if it works (and if it can be integrated with tools like netatalk, which do make assumptions on how the stack works!)

 

[NJRoadfan]

You can wrap the line discipline into a shell script that accepts the desired port as a command line argument and launch the whole thing as a systemd service. I think other line disciplines already do this.

One sidequest on any userspace solution would be a fully functioning LToUDP endpoint. Instead of speaking to a tashtalk, you'd be injecting UDP packets into the host's interface.

 

[twelvetone12]

LT2USB is finally working and I would like to resume this long overdue project. While there is quite a bit of great work in userspace solutions I think there is still place to have a tashtalk in the the kernel, in particular because this way netatalk works basically out of the box with it, and I also think it is nice to have a varied toolbox with different tools for different needs. I should have some free time in the next month, so I will prepare a patch restoring all the localtalk stuff that was removed from the kernel and modify the driver to use a private callback as we discussed on the kernel mailing list.
Would there be anyone willing to review my code before I submit it? Also if anybody has experience with the process and can help out, it would be appreciated!

 

[dougg3]

That is so awesome! I would be happy to review the code to the best of my knowledge level, and to try to provide any info I can about the submission process, although I will admit I've never submitted a brand new kernel driver before, only smaller patches to existing drivers.

 

[Tashtari]

Any news from this endeavor? It's been a while and I thought I might shake the tree...

 

[twelvetone12]

I'm here! More or less! This summer with great help from @dougg3 I made an attempt at submitting the module to the Linux kernel, and it was rejected with some comments. Nothing to impossible to fix, but unfortunately I got a nasty case of the virus, my window of opportunity was lost, real life became quite real again and I"ve been scrambling to find a couple days to try to fix everything and try again...

 

[Tashtari]

I'm here! More or less! This summer with great help from @dougg3 I made an attempt at submitting the module to the Linux kernel, and it was rejected with some comments. Nothing to impossible to fix, but unfortunately I got a nasty case of the virus, my window of opportunity was lost, real life became quite real again and I"ve been scrambling to find a couple days to try to fix everything and try again...

Sorry to hear that! I hope you're able to amend and resubmit soon.