blob: 4d7453aa308b27adfef8b216ce81a78b75e9f930 [file] [log] [blame]
Here are a few quick points about DECnet support...
o No name resolution is available as yet, all addresses must be
entered numerically.
o The neighbour cache may well list every entry as having the address
0.170. This is due to a problem that I need to sort out kernel side.
It is harmless (but don't try and use neigh add yet) just look in
/proc/net/decnet_neigh to see the real addresses for now.
o The rtnetlink support in the kernel is rather exprimental, expect a
few odd things to happen for the next few DECnet kernel releases.
o Whilst you can use ip addr add to add more than one DECnet address to an
interface, don't expect addresses which are not the same as the
kernels node address to work properly. i.e. You will break the DECnet
protocol if you do add anything other than the automatically generated
interface addresses to ethernet cards. This option is there for future
link layer support, where the device will have to be configed for
DECnet explicitly.
o The DECnet support is currently self contained. You do not need the
libdnet library to use it. In fact until I've sent the dnet_pton and
dnet_ntop functions to Patrick to add, you can't use libdnet.
o If you are not using the very latest 2.3.xx series kernels, don't
try and list DECnet routes if you've got IPv6 compiled into the
kernel. It will oops.
o My main reason for writing the DECnet support for iproute2 was to
check out the DECnet routing code, so the route get and
route show cache commands are likely to be the most debugged out of
all of them.
o If you find bugs in the DECnet support, please send them to me in the
first instance, and then I'll send Alexey a patch to fix it. IPv4/6
bugs should be sent to Alexey as before.
Steve Whitehouse <>