AppleTalk Bridge

abridge is a way to bridge AppleTalk (EtherTalk really) over the internet with multiple other sites. The intention is to provide a way to play old AppleTalk only network games with other people around the world.

Currently, abridge uses libpcap to read atalk and aarp Ethernet frames from the local network and send them to a server. The server then sends these frames to each connected client, which then uses libpcap to inject these received frames onto the local network. Some checking is done to avoid sending entirely local frames (both source and destination MAC addresses on the local network) to the server. Additionally, some checking is done to avoid injecting non-AppleTalk related frames into the local network.

DANGER! The entire purpose of this software is to inject foriegn network packets onto your local network. Be careful what networks you run this on. Running it at work on a production network for example, would probably be a bad idea. You have been warned.

Download

abridge-0.2.tar.gz - Dec. 14 2009
README.txt - Dec. 13 2009

Usage

kwai is the server and toofar is the client/bridge program. These are intended to run on a unixy system that has a recent version of libpcap installed. So far, the server has been tested on Ubuntu Linux and Mac OS X 10.6. The client has only been tested on Ubuntu. The client builds and runs, but does not seem to function correctly on Mac OS X 10.6.
The server can run unprivileged, and by default will daemonize its self into the background and listen for incoming connections from clients. 

./kwai

The client needs to run as root so it can sniff atalk packets from the desired interface. It too will daemonize its self into the background, listening for and sending packets out over the network. 
sudo ./toofar -i eth0 -s servername
The machine the client runs on will not be able to interact via AppleTalk with machines on the other side of the bridge. So if you want remote machines to talk to your netatalk server, don't run the client software on that machine. This is due to the way packets received from the server are injected onto the network by the client. The local netatalk process won't see the packets we're injecting, but all the other machines on the network will.

Additionally, pcap has a warning about some OS' and some network drivers not working properly with packet injection. The README.txt file repeats that warning.

Troubleshooting

The first thing to do when troubleshooting is build both client and server with debugging enabled and run them in the foreground: 

make clean; make CFLAGS="-DDEBUG=1"
./kwai -d
sudo ./toofar -d -i eth0 -s servername
Next, if you have another machine on the network with netatalk installed (remember, you can't run this on a machine the client is running on), run nbplkup. This should show the machines visible on the network: 
bbraun@bbraun-desktop:~/abridge$ nbplkup
                 bbraun-desktop:AFPServer                          65280.34:128
                 bbraun-desktop:netatalk                           65280.34:4
                 bbraun-desktop:Workstation                        65280.34:4
                         server:ProDOS16 Image                     65280.1:236
                         server:Apple //gs                         65280.1:236
                         server:Apple //e Boot                     65280.1:236
                         server:AFPServer                          65280.1:251
                         server:  Macintosh                        65280.1:252
                         server:Workstation                        65280.1:4
And finally, tcpdump or ethereal to log/inspect the network can be helpful.
When reporting a problem, the debug output of both the server and client (or only client if you're connecting to a server you can't get the output of) and a tcpdump capture file of the problem: 
tcpdump -n -i eth0 -s0 -w outfile atalk or aarp
Running tcpdump on the same host as the client is ok.

- Rob Braun <bbraun at this domain>