| |
| 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 <SteveW@ACM.org> |
| |