Following instructions I found at
<http://web.archive.org/web/20050312004913/http://ebv.mimnet.northwestern
.edu/~aiyar/appletalk.html>, I downloaded, built and installed vtun 2.6
on both Linux boxes, and turned on netatalk, configuring it to use both
the eth0 and tap0 devices.
All this works, up to a point. nblkup on the Linux box at location B can
see AppleTalk services on machines in location A, but so far that on the
Linux box at A cannot see any AppleTalk services on machines at location
B. Also actual Macs at location B can't seem to see any services at
location A.
And to top it all off, what connectivity I do get stops working after
about a half an hour or so, so I have to stop and restart netatalk and
vtun on both Linux boxes to get it functioning again.
Has anybody had any experience doing anything similar? I can post
detailed config files if there's any interest.
Thanks for any help.
>> sn's note: I asked a friend of mine who tried to answer your request.
Unfortunately you're using a faked e-mail address, so this went wrong.
Now he sent the answer to me and I'm posting for him. It would be nice
if you could ease helping _you_ ... <<
> I've got a client wanting AppleTalk connectivity between two physically
> separate premises. He's got TCP/IP connectivity between the two
> locations, plus a Linux box at each place (running OpenSuSE 10.0,
> installed by me).
>
> Following instructions I found at
> <http://web.archive.org/web/20050312004913/http://ebv.mimnet.northwestern
> .edu/~aiyar/appletalk.html>, I downloaded, built and installed vtun 2.6
> on both Linux boxes, and turned on netatalk, configuring it to use both
> the eth0 and tap0 devices.
>
> All this works, up to a point. nblkup on the Linux box at location B can
> see AppleTalk services on machines in location A, but so far that on the
> Linux box at A cannot see any AppleTalk services on machines at location
> B. Also actual Macs at location B can't seem to see any services at
> location A.
This is a problem related to Netatalk. As far as I digged into this
issue a few years ago, NBP Propagation (which is done via Multicasting)
doesn't work reliably when only Netatalk is involved.
I remember the problems to be at least partly gone when using more Apple
conform seed routing devices on at least on end of the link. I remember
getting it at least partly with a Netware 3.12 box with AppleTalk
services running. Since this was unpleasant and my reports on the
netatalk list constantly got ignored, I eventually get fed up with this
issue and declared that AppleTalk over WAN links isn't an option for me.
One solution I'll try one day with a friend is to use two old Cisco 2500
devices (rather cheap these days) with AppleTalk capability in IOS to
tunnel AppleTalk over IP with aid of this devices. VPN connectivity
itself runs over ipsec (Free/openswan).
> And to top it all off, what connectivity I do get stops working after
> about a half an hour or so, so I have to stop and restart netatalk and
> vtun on both Linux boxes to get it functioning again.
I could see this problem with IP also when using udp mode in vtun.
Restarting vtun deletes the interface under atalkd's back, so it just
stops using it, even after it reappears. You need to restart netatalk,
too. Nice if the box has some ten users using afpd via AppleTalk.
Switching to tcp tunneling makes vtund way more reliable but has major
disadvantages. Latency is increased overproportional. Fiddling with the
tunnel mtu doesn't really get desired results (lessen latency for no
packets must be split). Furthermore, any packet less from outside the
tunnel results in TCP retransmits for the tunnel itself, which can
result in peak round trip times up to 10s! Last and worst, vtun scales
bad. If you run it over a low bandwidth link, it's just OK.
Over a small 128K link you get full 14Kbytes/s, with compression even
more, depending on the data being transferred. We tried to use vtun over
a WLAN link which transfers 2.5 Mbytes/s outside the tunnel. From inside
the tcp connection we're down to 400Kbytes/s.
Vtun has a wonderful configuration concept. It's most easy to set up,
it's transparent: What you send into the pipe comes out on the other
end. Ipsec is much more complicated, you'll have to specify exact ip
addresses for both ends of the link, for any combination of destination
and source address pairs of the LANs you'll have to specify an extra
configuration for the tunnels. No I don't like ipsec.
> Has anybody had any experience doing anything similar? I can post
> detailed config files if there's any interest.
Yes, I had.
:wq! PoC