On Wed, 17 Nov 1999, Hans-Christian Becker wrote:

> [1] The combination of pre-asun-2.1.4-35 & NetBSD-macppc-1.4 (as of 
> the July snapshot) was unreliable with respect to the "devices shown" 
> issue. Apparently this was somehow fixed in 1.4.1.

"July snapshot?" I think that's the problem. The only time releases (1.4,
1.4.1, etc.) have snapshots is during the release cycle. We were not in
the 1.4 release cycle in July. There was, however, a snapshot of
NetBSD-current made in July.

The difference is that changes were made to -current over the summer which
fixed netatalk in certain circumstances, but broke it in others. Well,
netatalk was breaking the rules, and this change caught it.

<Asside>
The problem is that Appletalk assigns one contiguous range of network
numbers to a physical netowrk.  These numbers are arbirtary - you could do
255 -> 310 if you wanted (the reasons why you wouldn't want to are a
seperate issue). NetBSD's routing system (the radix code) (as well as Free
and OpenBSD's AFAIK) was written and optimized for IP. It works in terms
of masks, so routing entries have to cover a power of 2 number of
addresses, and be aligned to that power of 2. So a route which covers 8
addresses must start on a number divisable by 8, and go to that number +
7. You'll note appletalk doesn't follow those rules. So netatalk will add
multiple routing entries to map to the connected wire. One of these
routes will of course contain the interface address. The problem was if
your router was covered by a different route, portions of the routing
code would think it was unreachable.

For instance, say we have a net range of 255->256. We will have one route
for net number 255, and one for 256. Say our machine is 256.34, and our
gateway to the rest of the world is 255.56. The code in 1.4 (and 1.4.1,
etc.) would not let us add routes using 255.56 as a gateway for other
routes because it didn't use the route our interface was on. If our
address were 255.X, we'd have been fine.

Over the summer, one of the network subroutines was changed to make sure
that things would work right in the above case. Unfortunatly that in turn
broke the fact that netatalk wants to assign network range 0-0 to the
loopback and then 0-65534 to the physical interface. We've fixed things by
having netatalk now assign 1-65534 to the physical interface.
</Asside>

The reason 1.4.1 worked is that this change was never made to the 1.4
branch. :-)

Oh, just as a note, when you moved from the snapshot to 1.4.1, you didn't
"upgrade." The snapshot was of current, while 1.4.1 is a release. The
difference is that one represents a snapshot of on-going development while
the other (the release) represents somethign we consider more stable. They
differ in stability and features. :-)

Take care,

Bill