Wow, thanks for linking your port of macipgw! I'm extremely excited to try that out. If I can find some time I'll try it soon. I still think the Linux kernel is doing some goofy things with native AppleTalk packets from a LocalTalk interface and might need some fixes, but this would be a good way of doing some testing.
Cool thing about using a BBB as a localtalk thingy, you could also run that webkit proxy on it as well, 1 stop shop for vintage machines. get them on the network, browse files, AND browse the internet via proxy.
I was wondering if there is a change that the Localtalk Bridge idea is continued? I would really love to see this happening!
The combination of a modern "home made" solution for localtalk and a simple device like a BeagleBone Black, Raspberry PI or even a $9 NTC C.H.I.P. would be a way of emulating a localtalk bridge with TCT/IP bridging in one device.
I recently worked with the Linux port of macipgw for the 9$ CHIP. I got it working and now have a AFP file server and macipgw thanks to the port of zero2sixd. His tip to use NAT on the device is also very nice, because you then have instant connection to the internet behind any router.
USB network device (a cheap one will do). See my link at the bottom of this page at A(piep)Express. A Davicom DM96xx USB 10/100 Ethernet clone. Connected to a powered USB hub is the best. atalk won't work over the wlan0 device.....
My Debian package '''appletalk-netatalk-macipgw-for-ntc-c.h.i.p.deb'''
This will work with the default CHIP. So with the CHIP OS and GUI on it. It will add all modules you need, like appletalk en tun device and new zImage kernel file. You can download and install the package with:
I've been talking to MacTjaap over on the Armbian boards as well, since I made a post there about some AppleTalk stuff (there's another bug in the AppleTalk stack in modern Linux that prevents correct routing between multiple interfaces that's different from the LocalTalk bug dougg3 noticed. I still need to get that patch mainlined (I haven't even sent it upstream yet), but it works as elegantly as anything in the Linux AppleTalk stack (which is pretty ugly, TBH) does.
Anyway, I'll take a look at that, but when he mentioned the BBB cape, I had the same thought as mentioned a bit upstream, about using the PRU-ICSS to drive the FM decoding and maybe some of the higher-level protocol bits. I've been looking into using that subsystem for driving 3D printer motors (so you could use a BBB for both the slicing frontend and the motor drive), and I think there's a good chance it would have the horsepower to do it. The data rate for LocalTalk is about 230400 baud, which should be slow enough for the PRU to handle (I think it runs at 200 MHz, and there are two cores). That could easily cut down on both the cost and complexity for the adaptor board if it could be made to work.
I haven't yet gotten to trying to actually run any code on there, and it looks like it involves CCS, which I recall being somewhere between "meh" and "hellscape" as far as IDEs go, but we'll see. It would be great if the code could be interactively generated on the BBB itself.
Ultimately, an ESP32-based router would be really neat, but that involves reinventing a lot more software. There are a few ways you could possibly do the SDLC encoding/decoding on the chip; I'm thinking either using the remote control peripheral (which is really just a pulse width counter meant for IR remotes), or using the ultra-low-power processor (which runs at 8 MHz) to handle the SDLC. The latter approach is intriguing, but it would be just on the edge of acceptable performance. Food for thought, though.
Totally agreed that it would be cool to use the PRU to do the decoding. I just don't have the time to play with all of that. (To be fair, I don't have time to play with it as it currently is either...) It would sure be nice if the PRU had better development tools. On the plus side, what I have now does work
I wonder if the "correct routing" bug you are referring to is what causes nbplkup to not work properly. It seems to only find stuff on Ethernet when I run it on the BBB, even though it has both eth0 and lt0 interfaces. It would also be nice to figure out exactly how to safely fix the bug I encountered. My hacky patch was just to add 16 to the number of bytes allocated in sock_alloc_send_skb and skb_reserve because it seemed that loopback packets were having too many header bytes prepended. IIRC, it was treating them like Ethernet packets even though they are really LLAP, or something like that. I'm sure my patch is not the correct way to fix it.
It sounds like two different bugs, but they might both be causing the problem you're seeing.
The routing problem I fixed pops up when you have more than one interface listening on the same port (which, with routers, you do); the routing code just marches through the list of open sockets and picks the first one that matches the port number, regardless of which interface the packet came in on. This caused a lot of obvious problems, particularly when machines on one network queried the zone info from the router, which is handled by netatalk. It would work fine on the first interface in the config file, but I'd get some confusing error messages from any other networks on the Mac side.
I eventually tracked it down with tcpdump (which, despite its name, works fine for any protocols that come in on any network interface); I noticed that tcpdump accurately saw packets coming in on the right interfaces, but atalkd was reporting them all coming in on just the one, and from there it was a fairly simple task to figure out what was going on in the AppleTalk network stack in Linux (which appears to have been maintained over the years at least to update it to the newer buffer handling methods, but clearly no one is doing much testing on it these days).
I had to fix a similar (though not identical) issue on NetBSD's AppleTalk stack a number of years ago. That patch, at least, got mainlined pretty quickly.
OpenBSD has been pretty aggressive about deprecating and dropping older protocols, so its AppleTalk stack disappeared many years ago. I'm not going to complain too much about that; OpenBSD focuses primarily on security, and dropping things that are no longer in demand reduces their exposed attack surface and the amount of code they need to audit, so it makes sense. It's a bummer, though, because my main router is OpenBSD, and it would be handy to not have to have a separate Linux machine bridging my networks.
OpenBSD's DECNet utilities like mopd (they still exist, because you can boot an Alpha over MOP and Alpha is still supported) use bpf to do their networking. If I had more spare time, I'd think about making an updated set of AppleTalk libraries to replace the current libatalk that used bpf to do all the AppleTalk comms in userland. It's not the highest performance, but it's portable (except to Solaris ≤10, which uses DLPI) and it's not as painful to develop as kernel code. And really, I'd be shocked if there were ANY existing installations that need higher AppleTalk performance than you can provide with bpf on a modern computer.
Anyway, I'm in contact with MacTjaap in re: the LocalTalk board; I'm in the middle of a fairly intense job search, but once things settle down a little I'm hoping to be able to bang on it a little. In the meantime, I have at least one BBB at my disposal and could build my own board; do you have spare blank boards, or is your OSHPark project public so I can just order some?
I'm totally on the same page as you on that...a userspace solution would sure be nice. If I could ever take off a few months off from my job, it sounds like it would be a fun project.
Unfortunately I'm out of boards at this time. The OSHPark project was not public, but even if it was, I wouldn't recommend trying to make any more until my next revision is ready -- there were several mistakes I made, some of which are documented in this thread. I also recently discovered that I swapped RX and TX on the Mini-DIN connector (whoops!). My current plan is to keep the board closed source...it was a lot of work. (The board isn't really all that complicated though...) But of course I'd be happy to hook you up with one
I mean, if you want to hook me up with a board, I'm not gonna say no... I don't mind doing a bit of white-wire work either. I'm probably going to pursue my idea of using the PRU(s) at some point with a breakout board, but I'm happy to try this one out in the meantime. I don't know when I'm going to have a load of time to debug things any time soon, so if you happen to wind up with a board you want to send out, we'll arrange something.