On Sat, 29 Apr 2000, Frederick Bruckman wrote:

> IIRC, Manuel Bouyer made a change to the kernel sources between
> 1.4.1-1.4.2 to allow the packaged netatalk to be used as a router.
> This required a change to the netatalk package to permit netatalk to
> be used as a non-router, "patch-be". Maybe you'd like to pull that one
> up to the sources you're using.

If patch-be is the work-around, then that's not what's up.

netatalk has always been usable as a router.

Manuel's initial change was to deal with an interaction between NetBSD's
routing table system and Appletalk routes. Under certain instances, you
could have a perfectly valid appletalk setup and not be able to talk to a
router(*). The problem is that when he did this, he made it so that routes
couldn't overlap.

Before with netatalk, if you didn't have a router, you had two routes. One
was for net 0 and pointed to localhost, and the other was from net 0 to
net 65XXX (XXX are some digits above 280 I've forgotten). Those routes
overlap. Before, since they were distinct, that didn't matter. After
Manuel's initial change, that wasn't permitted.

patch-be makes the second route start from net 1, and all is well.

I haven't checked out Manuel's latest change.

Take care,

Bill

(*) NetBSD's (and I think a lot of *nix's) routing table system uses
routes written like IP subnets. i.e. the route covers a power-of-two worth
of addresses on a power-of-two boundry. Appletlak just says net number foo
to net number bar. So *BSD conveniently turnst that into a set of Po2
routes. As an example, say your network was nets 10 through 15. You'd get
a route to nets 10 to 11, and a route to nets 12 to 15.

For the problem to show up, your default router has to have an address on
one of these routes which is not the route your address is on. So if your
router was either 10.X or 11.Y, your address would have to be 12.Z, 13.Z,
14.Z, or 15.Z in the above example.

The problem was when you tried to add routes to other netowrks. You'd use
your Appletalk router on your network as the gateway. The problem is that
the code which adds these routes makes sure that the gateway is reachable
from your machine (rather good sanity check). But since your gateway is on
a different route from the one with your local address (10-11 vs 12-15 in
the above example), the sanity check code says no. :-) Manuel's code fixed
that problem, but introduced the above. :-(