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