Netatalk 2.x + LToUDP

[Andrew]

Hi all,

I have got an SE/30 with a nic card to successfully connect to a netatalk 2.x share. I've also been successful in connecting the se/30 to a mini vmac share through a tashtari raspberry hat (using tashtalk daemon which converts appletalk packets to multicast UDP and vice versa).

Is there a way to connect both worlds? I.e. for mini vmac to connect to the netatalk 2.x share, or the physical SE/30 to see the appletalk share on mini vmac?

I've already tried with multitalk, which produces the following errors when the physical se30 makes traffic:

2022-12-09T15:32:14.412Z ERROR udp/multicast.go:106 convert failed {"bridge": "udp", "iface": "wlan0"}
github.com/sfiera/multitalk/internal/udp.(*bridge).transmit
/home/pi/multitalk/internal/udp/multicast.go:106
2022-12-09T15:32:15.239Z ERROR bridge/bridge.go:160 unmarshal failed {"protocol": "ddp", "error": "read ddp: excess data"}
github.com/sfiera/multitalk/internal/bridge.(*Group).logAppleTalkPacket
/home/pi/multitalk/internal/bridge/bridge.go:160
github.com/sfiera/multitalk/internal/bridge.broadcast.func1
/home/pi/multitalk/internal/bridge/bridge.go:98
github.com/sfiera/multitalk/internal/bridge.(*Group).Run
/home/pi/multitalk/internal/bridge/bridge.go:88
github.com/sfiera/multitalk/internal/cmd.Main
/home/pi/multitalk/internal/cmd/multitalk.go:82
main.main
/home/pi/multitalk/cmd/multitalk/multitalk.go:38
runtime.main
/usr/lib/go-1.15/src/runtime/proc.go:204

@cheesestraws I know you have great experience in this field. Do you think it is possible?

Thanks to all,

Andrew

 

[Andrew]

I sort of fixed the issue. In the code, I had to comment out the following lines (3 occurrences)
_, err = r.ReadByte()
if err != io.EOF {
return fmt.Errorf("read ddp: excess data")
}

I don't know why multitalk is broken only for me but seems to work with other forum members...

Now the physical SE30 speaks with mini vmac, however mini vmac does not see the netatalk share. It seems that netatalk and multitalk on the same device is not supported. Any thoughts?

 

[robin-fo]

I just tried it (without modifications) on my Raspberry Pi and I get similar errors. But after a while, they disappear and networking works fine in both directions. However, I have the same issues with networking services on the Pi. I will do some investigations

 

[cheesestraws]

I haven't got any real tips for using multitalk, I'm afraid—I don't use it personally, I've already got a machine I use for LT to Ethernet that has a spare LT port on it, so I've just got a spare AirTalk permanently plugged into that port. Which isn't ideal, but works.

Netatalk, unfortunately, being a system designed for big networks which are centrally managed and have routers, can exhibit weird behaviours on networks that aren't centrally managed and don't. And while I don't know for certain, I wouldn't be totally surprised if that fought with multitalk somehow, given that mulitalk does have edge cases in what it does with network numbers. At some point I want to work out how to fix that but I'm afraid I've not got round to it yet, and I don't know when I'm going to get to it, if at all. I wish I had unlimited time and executive function but, alas, I do not. :-(

@robin-fo I really like your avatar, btw

 

[robin-fo]

@robin-fo I really like your avatar, btw

Thanks @cheesestraws

 

[Andrew]

I haven't got any real tips for using multitalk, I'm afraid—I don't use it personally, I've already got a machine I use for LT to Ethernet that has a spare LT port on it, so I've just got a spare AirTalk permanently plugged into that port. Which isn't ideal, but works.

Netatalk, unfortunately, being a system designed for big networks which are centrally managed and have routers, can exhibit weird behaviours on networks that aren't centrally managed and don't. And while I don't know for certain, I wouldn't be totally surprised if that fought with multitalk somehow, given that mulitalk does have edge cases in what it does with network numbers. At some point I want to work out how to fix that but I'm afraid I've not got round to it yet, and I don't know when I'm going to get to it, if at all. I wish I had unlimited time and executive function but, alas, I do not. :-(

@robin-fo I really like your avatar, btw

Thanks for your message. It seems however that netatalk on its own does a perfectly good job (thanks @slipperygrey btw) and works great with physical machines over ethernet. Also, given some difficulties i've had with multitalk it would also seem to work great in the end (thanks again @sfiera).
Problem is that when both run on the same OS, netatalk cannot see the packets generated by multitalk because they are outgoing. Ideally netatalk would adopt ltou protocol but in the mean time I would appreciate any workaround.

 

[cheesestraws]

but in the mean time I would appreciate any workaround

Oh, right. OK. I was thrown off by the excess DDP errors If it works aside from that, I can make a suggestion. Note though that I can't remember how to do this in detail under Linux (I do it very rarely), so you're going to have to go and do a bit of extra research, but here's the basic idea:

What you want is a bridge. A bridge is like a little ethernet switch inside the OS, and it works like you'd expect: interfaces that are part of the bridge forward traffic to one another. So if outgoing frames from multitalk are actually destined for netatalk, they'll be switched through the bridge to it.

This depends on netatalk and multitalk being on different interfaces, though. So you'll need to create a dummy interface for multitalk to speak to. I think what you want here is a 'tap' interface, which is a virtual ethernet interface that bits of software can sit on.

So I think what you want to do, in handwave, is:

• Create a persistent tap interface. Get multitalk to use that interface.
• Create a bridge. Bridge your physical ethernet port and the tap interface.

There are tutorials out there for both parts of this—I know because I have to keep looking them up whenever I do it . Try something like this...

 

[Andrew]

Thanks, I will try this way. I tried earlier a similar approach i.e. to use interface aliases e.g. wlan0:0 which multitalk does not want to bind to …

 

[cheesestraws]

Thanks, I will try this way. I tried earlier a similar approach i.e. to use interface aliases e.g. wlan0:0 which multitalk does not want to bind to …

Yeah, interface aliases aren't real interfaces, it won't work. You need a bridge

 

[Andrew]

Yeah, interface aliases aren't real interfaces, it won't work. You need a bridge

root@rpi:/home/pi# ip link set wlan0 master br0
Error: Device does not allow enslaving to a bridge.

Nobody likes slavery however this configuration is valid even in windows...

 

[teovall]

I figured out a way to get Netatalk and MultiTalk working on the same system. I believe it will work with wireless interfaces as well, including on Raspberry Pi. The downside is, when MultiTalk and LToU is working, I can't get EtherTalk to work at the same time. So it's one or the other. If you find a way to get both working at once, please let me know.

These instructions assume that you have Netatalk 2.2 already installed and working over EtherTalk and that iproute2 commands are available.

First you need to set up a VETH pair. VETH interfaces are like two virtual Ethernet ports connected by a crossover cable. On one side, veth0, you will have Netatalk. On the other side, veth1, you will have MultiTalk.

ip link add veth0 type veth peer name veth1
ip link set veth0 up
ip link set veth1 up

Next, you need to configure Netatalk to only use veth0. Open /etc/netatalk/atalkd.conf in your favorite text editor. Comment out or delete every line and then add a single line with just the interface name veth0, nothing else. Then, restart Netatalk.

/etc/netatalk/atalkd.conf:

veth0

Finally, you need to start MultiTalk. It will convert EtherTalk traffic from veth1 to LToU traffic on your physical Ethernet interface. Change enp0s3 to the name of your physical Ethernet interface.

multitalk --ethertalk veth1 --multicast enp0s3

Once you've tested this and it works, you'll probably want to make the VETH pair persistent so they'll still be there after a reboot. I haven't tested this, but I beleive you just need to create a file called /etc/systemd/network/25-veth.netdev with the following contents:

[NetDev]
Name=veth0
Kind=veth

[Peer]
Name=veth1

I used the latest commit of Netatalk 2.2 from here:

GitHub - Netatalk/netatalk at branch-netatalk-2-2

Netatalk is a Free and Open Source AFP fileserver. A *NIX or BSD system running Netatalk is capable of serving many Macintosh clients simultaneously as an AppleShare file server. - GitHub - Netatal...

github.com

The problem with getting both LToU and EtherTalk working at the same time, is when I put both veth0 and my physical Ethernet interface in atalkd.conf or just leave it blank and let atalkd auto-configure itself, atalkd gives the physical interface an AppleTalk address of 0.0 which is invalid. Even if I specify a valid address in atalkd.conf, atalkd ignores it and changes it to 0.0. Again, if you figure out a way to make this work, let me know.

 

[NJRoadfan]

Have you tried running netatalk on a seperate machine.... or in another VM with a seperate physical NIC assigned to it? DDP Appletalk doesn't like packet injection done by VMs and generally clients (ex: Basilisk II using winpcap) won't see a netatalk server running in VirtualBox using bridged networking on the same machine.