Does the Linux Build of Basilisk II Support AppleTalk?

Short answer: yes — the Linux build of Basilisk II supports AppleTalk, and Linux is arguably the cleanest platform on which to get it working. But “supports AppleTalk” hides an important distinction: it depends entirely on which Ethernet backend you use, and the backend that AppleBridge installs by default is the one that does not carry AppleTalk. This note lays out what works, what doesn’t, and why.

The one rule that explains everything

AppleTalk (specifically DDP, the AppleTalk datagram protocol) needs a path that carries raw Ethernet frames between the emulated Mac and the physical network. Basilisk II on Linux offers three network backends, and only two of them provide that path:

Everything below is just the consequence of this table.

Backend 1: sheep_net — the native path

This is the classic way and the one most retro-Mac users pick. Basilisk’s own README is explicit: the sheep_net kernel module lets you run all MacOS networking protocols — TCP/IP, AppleTalk, IPX — directly against a real Ethernet card. There is no translation; the emulated Mac appears on your physical Ethernet segment as if it were a genuine machine.

The module ships in the Basilisk II / macemu source tree under BasiliskII/src/Unix/Linux/NetDriver. You build and load it yourself:

git clone https://github.com/cebix/macemu.git
cd macemu/BasiliskII/src/Unix/Linux/NetDriver
make
sudo make install
sudo modprobe sheep_net
sudo chmod 666 /dev/sheep_net

Then, in Basilisk’s Serial/Network tab, set the Ethernet Interface to your real wired (or wireless) LAN device. On the next boot the Mac can see other AppleTalk machines through the Chooser.

Two caveats that trip people up:

• Kernel coupling. Because it is a kernel module, you have to rebuild it after every kernel upgrade. It is not a “set once and forget” install.
• No bridge to Linux’s own networking. The README is clear that with sheep_net the Mac can talk to other machines on the same Ethernet, but not to networks that Linux routes (a second interface, a PPP/Internet link). It is a window onto one physical segment, nothing more.

Backend 2: ethertap + netatalk — the routed path

The second documented approach puts Basilisk II on a virtual Ethernet via a tap interface. The important consequence, straight from the README: with ethertap you can only use protocols Linux itself can route, so to get AppleTalk you must install and configure netatalk and run its atalkd daemon. A minimal /etc/atalk/atalkd.conf seeds the zones, for example:

eth0 -seed -phase 2 -net 1 -addr 1.47 -zone "Ethernet"
tap0 -seed -phase 2 -net 2 -addr 2.47 -zone "Basilisknet"

This is more work than sheep_net and is really aimed at bridging AppleTalk into larger or segmented networks. As a lighter variant you can attach the tap interface to a Linux bridge, which lets AppleTalk frames be forwarded without Linux having to route them at all.

Backend 3: slirp — convenient, but no AppleTalk

slirp is the user-mode network stack (borrowed from QEMU). Its great virtue is that it needs no root privileges and no kernel modules — the Mac sits behind a virtual firewall/DHCP server and gets TCP/IP “for free.” This is why it is the path of least resistance, and why AppleBridge’s Linux installer standardizes on it.

The catch: slirp does not carry AppleTalk. You can still reach an AppleShare server by typing its IP address into Chooser → AppleShare (that is TCP/IP, i.e. AFP-over-IP), but the Mac will not appear on, or discover, an AppleTalk network. If you were hoping for classic AppleTalk zone browsing over slirp, it simply is not there.

What this means for AppleBridge

This is the practical upshot for anyone running AppleBridge on Linux. AppleBridge’s own transport is TCP-based and is perfectly happy on slirp — that is a deliberate, low-friction choice, and it is why the installer sets slirp as the Ethernet backend. But it also means a stock AppleBridge-on-Linux guest has no AppleTalk.

If you specifically want EtherTalk/AppleTalk from that same guest — to reach a real Mac, a LaserWriter, or a netatalk share over AppleTalk rather than AFP-over-IP — you have to move that guest off slirp and onto sheep_net (or the tap/bridge route). That is exactly the “more demanding configuration” the AppleBridge notes allude to when they mention EtherTalk. The two goals — zero-config bridge transport and real AppleTalk — pull toward different backends, and you pick per guest.

One historical footnote: LocalTalk

Do not confuse AppleTalk (the protocol family) with LocalTalk (the serial-cable physical layer). Basilisk II’s README states plainly that LocalTalk is not supported: there is no way to make it work through Basilisk’s serial drivers, and any attempt to enable it either crashes or falls back to Ethernet. AppleTalk over Ethernet (EtherTalk) is the supported route; AppleTalk over LocalTalk wiring is not — though people bridge real LocalTalk hardware onto the network with external gadgets like TashTalk/TashRouter and then reach it over EtherTalk.

Bottom line

The Linux build of Basilisk II supports AppleTalk fully — over sheep_net (simplest, talks to your local Ethernet) or ethertap+netatalk (routed, more setup). It does not support AppleTalk over slirp, which is TCP/IP only, and slirp is what AppleBridge uses by default. So the answer to “does the Linux build support AppleTalk?” is: yes, but not in the configuration AppleBridge ships — switching backends is the price of admission.