netatalk icon indicating copy to clipboard operation
netatalk copied to clipboard

Support for LToUDP

Open lampmerchant opened this issue 7 months ago • 3 comments

Is your feature request related to a problem? Please describe. Describe the solution you'd like

As Netatalk already includes a router in atalkd, it'd be nice if support could be added for LocalTalk over UDP (LToUDP) to enable clients using LocalTalk (over AirTalk or other TashTalk-based interfaces, for example) to access files and printers shared using Netatalk.

Describe alternatives you've considered

It is currently possible to do this using TashRouter but this approach adds a redundant router to the equation, besides which TashRouter is less thoroughly maintained and tested than Netatalk.

lampmerchant avatar Jun 04 '25 14:06 lampmerchant

Why hello @lampmerchant fancy seeing you here ;-)

The thing that makes this harder than it might look is that atalkd isn't actually all of a router, it's only the control plane; the actual forwarding path is done in-kernel, kind of like IP forwarding. That means it's non-trivial to add a new "layer 2" or encapsulation without mucking around with the kernel side of things.

So while something might be bodgeable, my suspicion is that this will have to wait for support for a userland DDP implementation.

cheesestraws avatar Jun 05 '25 19:06 cheesestraws

You would have to: -Write a kernel driver to present the LToUDP bridge as a network adapter, similar to what the kernel level TashTalk driver does. OR -Write a bridge application that opens a TAP interface. Seeing that TashRouter can be configured to do this already, this is technically done.

The biggest issue with anything kernel related is how LocalTalk connections are handled. The kernel treats everything as EtherTalk Phase 2 with some extra hacks added in to support LocalTalk. There is no in-kernel LLAP address auto configuration as that was handled at the driver level. All packets from the kernel use long DDP headers, which causes problems with older devices that expect RTMP broadcast packets to be in short headers (ie: The Apple IIe Workstation card and some LaserWriters).

Basically, LLAP and ELAP are different enough that its actually preferable to have a full router handling the bridging and packet translation. TashRouter has been pretty stable in my day-to-day use. Having TashTalk support built-in is a nice added bonus.

NJRoadfan avatar Jun 06 '25 22:06 NJRoadfan

@rofore Just bringing this to your attention since we discussed LToUDP in the context of userland AppleTalk stack development a few years ago.

rdmark avatar Jun 07 '25 13:06 rdmark