-
Hello MLAers! We've re-enabled auto-approval for accounts. If you are still waiting on account approval, please check this thread for more information.
What should a hobbyist-focussed AppleTalk router do?
- Thread starter cheesestraws
- Start date
Unfortunately like many others, I've been having a period of turbulence in my professional life that has made most non-trivial hobby projects take a back seat. I have what I believe is working hardware, but I haven't got much further with it than basic bringup. If what you want is a functional AppleTalk router without paying lots of money for it, I'd recommend having a look at @tashtari 's TashRouter, which looks like it's achieving stability and I will probably end up mercilessly cribbing implementation strategies from when I'm less exhausted.
I haven't forgotten this!
I've worked out what's wrong with my prototype hardware. (Unsurprisingly, the ESP32 doesn't like it much if it gets a 50MHz square wave in one of its strapping pins at startup, oops). So after a bodge, tonight I got the AirTalk firmware working on this board. I say "working" - the WiFi in the ESP32 doesn't really have a working antenna so it only works ... sometimes. But the software is working and most of the packets get through.
The next step is to try to bring up Ethernet on this board for AirTalk. If that works, we can file the hardware as 'working' and then I can muck it up by writing software that doesn't. Hooray!
I've worked out what's wrong with my prototype hardware. (Unsurprisingly, the ESP32 doesn't like it much if it gets a 50MHz square wave in one of its strapping pins at startup, oops). So after a bodge, tonight I got the AirTalk firmware working on this board. I say "working" - the WiFi in the ESP32 doesn't really have a working antenna so it only works ... sometimes. But the software is working and most of the packets get through.
The next step is to try to bring up Ethernet on this board for AirTalk. If that works, we can file the hardware as 'working' and then I can muck it up by writing software that doesn't. Hooray!
oh and here's a photo of it running, I don't know how you can tell it's running from a photo, you'll just have to trust me.
That made me laugh out loud. Thankyou. I needed that today.
Almost certainly CERN strong reciprocal for hardware and BSD for software, but I'm not going to waste people's time with it unless it actually works - basically, I don't want to open source something I'm going to be embarrassed by or ashamed of. Which I don't think is unreasonable
. In other words, basically the same as airtalk - as soon as it's fit for human consumption, anyone can build one.
So I guess I have a few uneducated questions:
I know TashTari was talking about duplicating the AsanteTalk - why not do that for the 99% who just want PhoneNet to Ethernet connections (at least in function if not hardware)?
What are people really using MacIP for? I can get everything done I want to using regular old AppleTalk and connecting to a server over my home network (I have an iPrint). What purpose is there for routing internet traffic to a Mac SE over PhoneNet these days…so you can download a 5 MB file off Macintosh garden over two hours?
What am I missing here?
I know TashTari was talking about duplicating the AsanteTalk - why not do that for the 99% who just want PhoneNet to Ethernet connections (at least in function if not hardware)?
What are people really using MacIP for? I can get everything done I want to using regular old AppleTalk and connecting to a server over my home network (I have an iPrint). What purpose is there for routing internet traffic to a Mac SE over PhoneNet these days…so you can download a 5 MB file off Macintosh garden over two hours?
What am I missing here?
There's only one capital 'T', Tashtari. =)
Thank you for the correction! I'll never know what it means, either...
This is kind of similar to that, except with a more robust approach to traffic management and also AirTalk support (also a modern Ethernet PHY so it's less prone to freaking out). Also, it uses all new, currently available components. I'm not sure how far @tashtari's efforts have got but I'm fairly sure that it didn't include LToUDP.
The other thing is that @tashtari's kinda thing is doing ludicrously impressive things with PIC microcontrollers, and I honour that deeply, but it's not my thing, and it's not most other people's thing. So I want to do this with a software codebase that other people can maintain and work on and hopefully learn from rather than a big mass of ultra-dense PIC assembly which (sorry, @tashtari, close your ears) may not be the most widely maintainable thing in the world.
I think you've slightly misunderstood upthread. I'm not planning to do any MacIP stuff, at least to start with. That's too much for one project that I can reasonably attempt before my mental health sinks me. This project is aiming to produce essentially a modern replacement for an AsanteTalk based on new, maintainable software, maybe with some extra bells and whistles.
Not far at all... by no means let me stop you.
Also, feel free to take whatever is useful from TashRouter, hopefully my Python code is more accessible than my PIC assembly. =)
TashRouter will be indispensible. I'm so glad you wrote it. :-D
I think I've got it now. That really would be super helpful, as far as what you are saying. One thing that I also have always wondered is this: since I have no understanding of this stuff, why is it that when you have a bunch of AirTalks on a wireless network, they essentially behave like they are having their own private party amongst themselves, and no other devices on that wireless network can see them...let alone the devices hard wired to it?
There are two different questions here, and I'm going to answer them in the opposite order you asked them.
1. Why can't other devices see them / why is the party private?
We know that some home network gear doesn't deal terribly well with AppleTalk in various irritating ways. To get around this, AirTalk "disguises" LocalTalk as normal IP, which home network gear knows how to handle somewhat better. The disguising and unmasking of this traffic is what you actually need the AirTalk for. If you see LToUDP mentioned, that is the name of the protocol that defines how the disguising is done. Devices that are hard wired to, say, the same Ethernet/WiFi network as the AirTalks don't see the AppleTalk on the AirTalk network because they only see the "disguised" traffic, and like the crappy home network boxes I'm trying to work around, just treat it as boring IP traffic.
2. Why does the party exist at all?
AirTalk - or LToUDP in general - uses something called IP Multicast. IP multicast allows multiple computers on the same network to form groups, which are kinda like subscriptions: a computer can join a group and will get all traffic for that group, and that's managed by all the network devices in the path. This sounds a bit abstract, but it's also how bonjour/mDNS work in OS X - your computer is subscribed to a group that says "hey send me a packet when a new service appears on the network" and then whenever a computer sends a "hey I've got a new service" packet, that will get to all the computers that have asked for it. If you want a rather strained analogy, you can think of it a bit like digital walkie-talkies - the sending walkie-talkie broadcasts out to all walkie-talkies that are on the same "channel". AirTalks and mini vMac with LToUDP all are on that same "channel" so can send data to each other without disturbing other senders of data, but they can all hear each other without knowing much about each other.
Multicast is actually a fairly ropy technology, and I used it with some trepidation - I will spare you the details why I chose it because they're long and technical and frankly extremely dull. It's a complex protocol suite, because it was designed for a multicast internet that never arrived, and I've been bitten by people using it badly in production systems multiple times in my career. But for this it does make sense, aside from home internet boxes that decide they don't like multicast *either*. Ho hum.
The reason for MacIP is to allow older machines, such as a Portable, which don't normally have any Ethernet devices (1) available, to use TCP and UDP protocols, like FTP, WWW and Gopher stuff.
MacIP tunnels TCP traffic inside AppleTalk packets, and is one of two options to get TCP data to and fro a serial port. The other option is PPP, which used to be used for modem -> serial port on a PC, but we don't do that anymore but you can fake a PPP connection and use port forwarding to mimic it.
(1) The alternative for a Portable is to use a SCSI to Ethernet adapter, but those are kind of hard to get these days and are somewhat expensive. Asante Micro EN/SC devices are probably a good choice -- if you can find one. Or you can use a Farallon EtherWave Mac/PB adapter, but in my experience those are somewhat flakey, but the overclocking, if it works, is very nice.
MacIP tunnels TCP traffic inside AppleTalk packets, and is one of two options to get TCP data to and fro a serial port. The other option is PPP, which used to be used for modem -> serial port on a PC, but we don't do that anymore but you can fake a PPP connection and use port forwarding to mimic it.
(1) The alternative for a Portable is to use a SCSI to Ethernet adapter, but those are kind of hard to get these days and are somewhat expensive. Asante Micro EN/SC devices are probably a good choice -- if you can find one. Or you can use a Farallon EtherWave Mac/PB adapter, but in my experience those are somewhat flakey, but the overclocking, if it works, is very nice.
There is Scuznet
