Subject: Re: NetBSD/i386 and netatalk
To: Manuel Bouyer <firstname.lastname@example.org>
From: Robert Elz <kre@munnari.OZ.AU>
Date: 06/26/1998 19:49:03
Date: Thu, 25 Jun 1998 19:30:20 +0200
From: Manuel Bouyer <email@example.com>
| [ Please followup-to firstname.lastname@example.org ]
| Active ATALK connections
| Proto Recv-Q Send-Q Local Address Foreign Address (state)
| ddp 0 0 34087.125.4 *.*.*
| abInit: [ddp: 133.32, 252] starting
| Looking for =:=@Info LIP6 RP (P6) ...
| 17 - garfield:netatalk@* [Net:133.39 Node:125 Skt: 4]
| Note that the net adresses are not the same,
Yes they are. CAP uses IP style dotted octet numbering, the CAP net number
is 133.39 not 133. 133 * 56 + 39 == 34087.
The two entries shown above, one from netstat (reporting on netatalk) and
the other from atlook from CAP are reporting the exact same entity
(net number 34087 (133.39) node number 125, and socket 4).
And this one from your PC tool ...
| garfield:netatalk 34087.125:4
is the same thing.
| Does someone have an idea of what's going wrong ?
It does look from the messages extract that there is some kind of routing
problem, you probably need to be looking at the routing tables in the
fastpath as well. A common appletalk config problem however is attempting
to change the config without completely restarting everything (simultaneously)
which could have the old config in it (appletalk routers that is). Especially
with respect to zone information, the appletalk protocols are just a fraction
light on time to lives, and such, but cache data nevertheless.