Blame view

Documentation/networking/decnet.txt 10.5 KB
1da177e4c   Linus Torvalds   Linux-2.6.12-rc2
1
2
3
4
5
6
                      Linux DECnet Networking Layer Information
                     ===========================================
  
  1) Other documentation....
  
     o Project Home Pages
0ea6e6112   Justin P. Mattock   Documentation: up...
7
         http://www.chygwyn.com/                      	    - Kernel info
1da177e4c   Linus Torvalds   Linux-2.6.12-rc2
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
         http://linux-decnet.sourceforge.net/                - Userland tools
         http://www.sourceforge.net/projects/linux-decnet/   - Status page
  
  2) Configuring the kernel
  
  Be sure to turn on the following options:
  
      CONFIG_DECNET (obviously)
      CONFIG_PROC_FS (to see what's going on)
      CONFIG_SYSCTL (for easy configuration)
  
  if you want to try out router support (not properly debugged yet)
  you'll need the following options as well...
  
      CONFIG_DECNET_ROUTER (to be able to add/delete routes)
      CONFIG_NETFILTER (will be required for the DECnet routing daemon)
  
      CONFIG_DECNET_ROUTE_FWMARK is optional
  
  Don't turn on SIOCGIFCONF support for DECnet unless you are really sure
  that you need it, in general you won't and it can cause ifconfig to
  malfunction.
  
  Run time configuration has changed slightly from the 2.4 system. If you
  want to configure an endnode, then the simplified procedure is as follows:
  
   o Set the MAC address on your ethernet card before starting _any_ other
     network protocols.
  
  As soon as your network card is brought into the UP state, DECnet should
  start working. If you need something more complicated or are unsure how
  to set the MAC address, see the next section. Also all configurations which
  worked with 2.4 will work under 2.5 with no change.
  
  3) Command line options
  
  You can set a DECnet address on the kernel command line for compatibility
  with the 2.4 configuration procedure, but in general it's not needed any more.
  If you do st a DECnet address on the command line, it has only one purpose
  which is that its added to the addresses on the loopback device.
  
  With 2.4 kernels, DECnet would only recognise addresses as local if they
  were added to the loopback device. In 2.5, any local interface address
  can be used to loop back to the local machine. Of course this does not
  prevent you adding further addresses to the loopback device if you
  want to.
  
  N.B. Since the address list of an interface determines the addresses for
  which "hello" messages are sent, if you don't set an address on the loopback
  interface then you won't see any entries in /proc/net/neigh for the local
  host until such time as you start a connection. This doesn't affect the
  operation of the local communications in any other way though.
  
  The kernel command line takes options looking like the following:
2d27a9661   Robert P. J. Day   Documentation: "...
62
      decnet.addr=1,2
1da177e4c   Linus Torvalds   Linux-2.6.12-rc2
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
  
  the two numbers are the node address 1,2 = 1.2 For 2.2.xx kernels
  and early 2.3.xx kernels, you must use a comma when specifying the
  DECnet address like this. For more recent 2.3.xx kernels, you may
  use almost any character except space, although a `.` would be the most
  obvious choice :-)
  
  There used to be a third number specifying the node type. This option
  has gone away in favour of a per interface node type. This is now set
  using /proc/sys/net/decnet/conf/<dev>/forwarding. This file can be
  set with a single digit, 0=EndNode, 1=L1 Router and  2=L2 Router.
  
  There are also equivalent options for modules. The node address can
  also be set through the /proc/sys/net/decnet/ files, as can other system
  parameters.
  
  Currently the only supported devices are ethernet and ip_gre. The
  ethernet address of your ethernet card has to be set according to the DECnet
  address of the node in order for it to be autoconfigured (and then appear in
  /proc/net/decnet_dev). There is a utility available at the above
  FTP sites called dn2ethaddr which can compute the correct ethernet
670e9f34e   Paolo Ornati   Documentation: re...
84
  address to use. The address can be set by ifconfig either before or
1da177e4c   Linus Torvalds   Linux-2.6.12-rc2
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
  at the time the device is brought up. If you are using RedHat you can
  add the line:
  
      MACADDR=AA:00:04:00:03:04
  
  or something similar, to /etc/sysconfig/network-scripts/ifcfg-eth0 or
  wherever your network card's configuration lives. Setting the MAC address
  of your ethernet card to an address starting with "hi-ord" will cause a
  DECnet address which matches to be added to the interface (which you can
  verify with iproute2).
  
  The default device for routing can be set through the /proc filesystem
  by setting /proc/sys/net/decnet/default_device to the
  device you want DECnet to route packets out of when no specific route
  is available. Usually this will be eth0, for example:
  
      echo -n "eth0" >/proc/sys/net/decnet/default_device
  
  If you don't set the default device, then it will default to the first
  ethernet card which has been autoconfigured as described above. You can
  confirm that by looking in the default_device file of course.
  
  There is a list of what the other files under /proc/sys/net/decnet/ do
  on the kernel patch web site (shown above).
  
  4) Run time kernel configuration
  
  This is either done through the sysctl/proc interface (see the kernel web
  pages for details on what the various options do) or through the iproute2
  package in the same way as IPv4/6 configuration is performed.
  
  Documentation for iproute2 is included with the package, although there is
  as yet no specific section on DECnet, most of the features apply to both
  IP and DECnet, albeit with DECnet addresses instead of IP addresses and
  a reduced functionality.
  
  If you want to configure a DECnet router you'll need the iproute2 package
  since its the _only_ way to add and delete routes currently. Eventually
  there will be a routing daemon to send and receive routing messages for
  each interface and update the kernel routing tables accordingly. The
  routing daemon will use netfilter to listen to routing packets, and
  rtnetlink to update the kernels routing tables. 
  
  The DECnet raw socket layer has been removed since it was there purely
  for use by the routing daemon which will now use netfilter (a much cleaner
  and more generic solution) instead.
  
  5) How can I tell if its working ?
  
  Here is a quick guide of what to look for in order to know if your DECnet
  kernel subsystem is working.
  
     - Is the node address set (see /proc/sys/net/decnet/node_address)
     - Is the node of the correct type 
                               (see /proc/sys/net/decnet/conf/<dev>/forwarding)
     - Is the Ethernet MAC address of each Ethernet card set to match
       the DECnet address. If in doubt use the dn2ethaddr utility available
       at the ftp archive.
     - If the previous two steps are satisfied, and the Ethernet card is up,
       you should find that it is listed in /proc/net/decnet_dev and also
       that it appears as a directory in /proc/sys/net/decnet/conf/. The
       loopback device (lo) should also appear and is required to communicate
       within a node.
     - If you have any DECnet routers on your network, they should appear
       in /proc/net/decnet_neigh, otherwise this file will only contain the
       entry for the node itself (if it doesn't check to see if lo is up).
     - If you want to send to any node which is not listed in the
       /proc/net/decnet_neigh file, you'll need to set the default device
       to point to an Ethernet card with connection to a router. This is
       again done with the /proc/sys/net/decnet/default_device file.
     - Try starting a simple server and client, like the dnping/dnmirror
       over the loopback interface. With luck they should communicate.
       For this step and those after, you'll need the DECnet library
       which can be obtained from the above ftp sites as well as the
       actual utilities themselves.
     - If this seems to work, then try talking to a node on your local
       network, and see if you can obtain the same results.
     - At this point you are on your own... :-)
  
  6) How to send a bug report
  
  If you've found a bug and want to report it, then there are several things
  you can do to help me work out exactly what it is that is wrong. Useful
  information (_most_ of which _is_ _essential_) includes:
  
   - What kernel version are you running ?
   - What version of the patch are you running ?
   - How far though the above set of tests can you get ?
   - What is in the /proc/decnet* files and /proc/sys/net/decnet/* files ?
   - Which services are you running ?
   - Which client caused the problem ?
   - How much data was being transferred ?
   - Was the network congested ?
1da177e4c   Linus Torvalds   Linux-2.6.12-rc2
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
   - How can the problem be reproduced ?
   - Can you use tcpdump to get a trace ? (N.B. Most (all?) versions of 
     tcpdump don't understand how to dump DECnet properly, so including
     the hex listing of the packet contents is _essential_, usually the -x flag.
     You may also need to increase the length grabbed with the -s flag. The
     -e flag also provides very useful information (ethernet MAC addresses))
  
  7) MAC FAQ
  
  A quick FAQ on ethernet MAC addresses to explain how Linux and DECnet
  interact and how to get the best performance from your hardware. 
  
  Ethernet cards are designed to normally only pass received network frames 
  to a host computer when they are addressed to it, or to the broadcast address.
  
  Linux has an interface which allows the setting of extra addresses for
  an ethernet card to listen to. If the ethernet card supports it, the
  filtering operation will be done in hardware, if not the extra unwanted packets
  received will be discarded by the host computer. In the latter case,
  significant processor time and bus bandwidth can be used up on a busy
  network (see the NAPI documentation for a longer explanation of these
  effects).
  
  DECnet makes use of this interface to allow running DECnet on an ethernet 
  card which has already been configured using TCP/IP (presumably using the 
  built in MAC address of the card, as usual) and/or to allow multiple DECnet
  addresses on each physical interface. If you do this, be aware that if your
  ethernet card doesn't support perfect hashing in its MAC address filter
  then your computer will be doing more work than required. Some cards
  will simply set themselves into promiscuous mode in order to receive
  packets from the DECnet specified addresses. So if you have one of these
  cards its better to set the MAC address of the card as described above
  to gain the best efficiency. Better still is to use a card which supports
  NAPI as well.
  
  
  8) Mailing list
  
  If you are keen to get involved in development, or want to ask questions
  about configuration, or even just report bugs, then there is a mailing
  list that you can join, details are at:
  
  http://sourceforge.net/mail/?group_id=4993
  
  9) Legal Info
  
  The Linux DECnet project team have placed their code under the GPL. The
  software is provided "as is" and without warranty express or implied.
  DECnet is a trademark of Compaq. This software is not a product of
  Compaq. We acknowledge the help of people at Compaq in providing extra
  documentation above and beyond what was previously publicly available.
  
  Steve Whitehouse <SteveW@ACM.org>