[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Netatalk fails to route under OBSD 3.1


I have been working on this for a couple of weeks to make sure that _I_
was not doing something wrong. I have posted a series of questions and
the results from a range of tests (described below) to the netatalk list
over at Source Forge. The most recent reply was:

   |I think the problem is that we're scarce on OpenBSD hackers. I
   |can't think of anyone on the list who uses OpenBSD and codes

   |Steve, hoping he's wrong and somebody will pipe up

I have tested OBSD 2.9, 3.0 and 3.1 for this behavior and also a few
other *nix distros with varied success (some worked, others didn't, I
won't bore you with _all_ the details). 

I have tested pre-built binaries and also built from source the latest
version ( I am about to run some more tests to see when/where
netatalk broke.

I am hoping that someone here, with my results (and maybe other tests
yet to be done), might be interested in looking at the code to bring
this back up and on line (I would be happy to document and help bring an
updated package to fruition). Or, alternatively that "I'm f4rting
against thunder" and that I should work with another, less desirable,

Please note that netatalk seems to work fine as an AppleTalk file server
under AFP.

Any thoughts or recommendations?



PS. I'm not whining that I can do x on something else, why can't I do it
on OBSD. I'm ting to say "This is not working properly, who is
interested in helping me get it to work for everyone" (though at the
moment I recognize I might constitute a majority of said 'everyone' ;-)

PPS. My overall preference is to get this to work under OBSD as the
router will also be an internal IP firewall & VPN. I have already
installed an OBSD border-router with a DMZ and private network. This box
connects two separate groups, one Mac based the other M$ based, to the
private NW. It is complicated by politics so the Macs & PCs cannot be on
the same subnet. I would like to place something there I can trust like

Gory Details:

The problem is when two AppleTalk segments are connected to an OBSD
system configured to route, it won't. From the router, both segments are
seen (nbplkup) and devices can be "pinged" (aecho & similar). From
either segment (and in the same 'zone') I get either no devices from the
other segment or, can only 'see' the through the router unidirectionally
i.e. segment A sees segment B, but not B to A. (note that AppleTalk over
IP worked fine as it does not require netatalk for routing).

A variety of configurations have been tested for atalkd and afpd. As
this is the first router to be placed into the environment, it requires
the -seed option for both segments. Of interest is the atalkd.conf from
/etc/netatalk or /usr/local/etc/netatalk depending upon version:

fxp0 -seed -phase 2 -net 500-509 -addr -500.1 -zone "*"
fxp1 -seed -phase 2 -net 510-519 -addr -510.1 -zone "*"

Additionally, testing has been done to verify the effect or lack thereof
for different zones and types, net ranges, initialization orders, if
afpd is configured or not etc.

All of my testing has been done using the same hardware except disk
drives (I have a few extras on my shelf so I have 3 with different
distros). The configuration is an AMD Duron 700, 128mb PC133 RAM, DFI
main board, 3x Intel 100+ NICs & a mix of 5-20gb IDE mechanisms. (Yeah,
I could have multi-booted but this was effective, simple and stable).

Tested Distros:

    OBSD 2.9, 3.0 & 3.1 
        tested with OBSD package & from source
        All failed to route, though partial success was achieved.
    RH 7.2 & 7.3, 
        tested with from source
        Worked 100%, why mess with rpm and break it. ;-)
    Debian Potato 2.2  & Woody 2.4 (stable)
        tested with 1.4.2 & from apt packages
        Spud & 1.4.2 worked, Woody 2.4 kernel & failed.
    *I have authoritative notes that FreeBSD 4.5 works.
    Mac (various HW) running 9.1, 9.2.1 & X (10.1.4)

    Switched 10/100

Final note:

I have tested all of these other OSs for a couple of reasons. First to
verify the hardware and configurations are valid. If I had 100% failure,
then something I was doing/integrating was the problem. After confirming
that my settings were correct, I wanted to see if this was 100% OBSD or
if there were commonalities or patterns between the problems and