> 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.

Ok, thanks for your precisions. (yes, I don't know how appletalk works :)

> 
>   | 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.

There are routings problems, yes. But the fastpath is properly configured:
there hasn't been any changes for ages, and every other things on this
ethertalk zone (A SunOS/CAP server or two, a WinNT ethertalk server, printers)
work fine, and can be acceded throuh the fastpath.

Bill Studenmund started looking at this. Recompinling my 1.3.2 kernel
with a -current ddp_input.c solved a few of the problems (I can now
see all the zones, and access other ethertalk zones throuh the ethertalk
router). But the problem of routes not being installed properly is
still here.

--
Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
--