1 | @c |
---|
2 | @c Written by Eric Norum |
---|
3 | @c |
---|
4 | @c COPYRIGHT (c) 1988-2002. |
---|
5 | @c On-Line Applications Research Corporation (OAR). |
---|
6 | @c All rights reserved. |
---|
7 | @c |
---|
8 | @c $Id$ |
---|
9 | @c |
---|
10 | |
---|
11 | @chapter Using Networking in an RTEMS Application |
---|
12 | |
---|
13 | @section Makefile changes |
---|
14 | @subsection Including the required managers |
---|
15 | The FreeBSD networking code requires several RTEMS managers |
---|
16 | in the application: |
---|
17 | |
---|
18 | @example |
---|
19 | MANAGERS = io event semaphore |
---|
20 | @end example |
---|
21 | |
---|
22 | @subsection Increasing the size of the heap |
---|
23 | The networking tasks allocate a lot of memory. For most applications |
---|
24 | the heap should be at least 256 kbytes. |
---|
25 | The amount of memory set aside for the heap can be adjusted by setting |
---|
26 | the @code{CFLAGS_LD} definition as shown below: |
---|
27 | |
---|
28 | @example |
---|
29 | CFLAGS_LD += -Wl,--defsym -Wl,HeapSize=0x80000 |
---|
30 | @end example |
---|
31 | |
---|
32 | This sets aside 512 kbytes of memory for the heap. |
---|
33 | |
---|
34 | @section System Configuration |
---|
35 | |
---|
36 | The networking tasks allocate some RTEMS objects. These |
---|
37 | must be accounted for in the application configuration table. The following |
---|
38 | lists the requirements. |
---|
39 | |
---|
40 | @table @b |
---|
41 | @item TASKS |
---|
42 | One network task plus a receive and transmit task for each device. |
---|
43 | |
---|
44 | @item SEMAPHORES |
---|
45 | One network semaphore plus one syslog mutex semaphore if the application uses |
---|
46 | openlog/syslog. |
---|
47 | |
---|
48 | @item EVENTS |
---|
49 | The network stack uses @code{RTEMS_EVENT_24} and @code{RTEMS_EVENT_25}. |
---|
50 | This has no effect on the application configuration, but |
---|
51 | application tasks which call the network functions should not |
---|
52 | use these events for other purposes. |
---|
53 | |
---|
54 | @end table |
---|
55 | |
---|
56 | @section Initialization |
---|
57 | @subsection Additional include files |
---|
58 | The source file which declares the network configuration |
---|
59 | structures and calls the network initialization function must include |
---|
60 | |
---|
61 | @example |
---|
62 | #include <rtems/rtems_bsdnet.h> |
---|
63 | @end example |
---|
64 | |
---|
65 | @subsection Network Configuration |
---|
66 | The network configuration is specified by declaring |
---|
67 | and initializing the @code{rtems_bsdnet_config} |
---|
68 | structure. |
---|
69 | |
---|
70 | @example |
---|
71 | @group |
---|
72 | struct rtems_bsdnet_config @{ |
---|
73 | /* |
---|
74 | * This entry points to the head of the ifconfig chain. |
---|
75 | */ |
---|
76 | struct rtems_bsdnet_ifconfig *ifconfig; |
---|
77 | |
---|
78 | /* |
---|
79 | * This entry should be rtems_bsdnet_do_bootp if BOOTP |
---|
80 | * is being used to configure the network, and NULL |
---|
81 | * if BOOTP is not being used. |
---|
82 | */ |
---|
83 | void (*bootp)(void); |
---|
84 | |
---|
85 | /* |
---|
86 | * The remaining items can be initialized to 0, in |
---|
87 | * which case the default value will be used. |
---|
88 | */ |
---|
89 | rtems_task_priority network_task_priority; /* 100 */ |
---|
90 | unsigned long mbuf_bytecount; /* 64 kbytes */ |
---|
91 | unsigned long mbuf_cluster_bytecount; /* 128 kbytes */ |
---|
92 | char *hostname; /* BOOTP */ |
---|
93 | char *domainname; /* BOOTP */ |
---|
94 | char *gateway; /* BOOTP */ |
---|
95 | char *log_host; /* BOOTP */ |
---|
96 | char *name_server[3]; /* BOOTP */ |
---|
97 | char *ntp_server[3]; /* BOOTP */ |
---|
98 | @}; |
---|
99 | @end group |
---|
100 | @end example |
---|
101 | |
---|
102 | The structure entries are described in the following table. |
---|
103 | If your application uses BOOTP/DHCP to obtain network configuration |
---|
104 | information and if you are happy with the default values described |
---|
105 | below, you need to provide only the first two entries in this structure. |
---|
106 | |
---|
107 | @table @code |
---|
108 | |
---|
109 | @item struct rtems_bsdnet_ifconfig *ifconfig |
---|
110 | A pointer to the first configuration structure of the first network |
---|
111 | device. This structure is described in the following section. |
---|
112 | You must provide a value for this entry since there is no default value for it. |
---|
113 | |
---|
114 | |
---|
115 | @item void (*bootp)(void) |
---|
116 | This entry should be set to @code{rtems_bsdnet_do_bootp} |
---|
117 | if your application will use BOOTP/DHCP |
---|
118 | to obtain network configuration information. |
---|
119 | It should be set to @code{NULL} |
---|
120 | if your application does not use BOOTP/DHCP. |
---|
121 | |
---|
122 | |
---|
123 | @item int network_task_priority |
---|
124 | The priority at which the network task and network device |
---|
125 | receive and transmit tasks will run. |
---|
126 | If a value of 0 is specified the tasks will run at priority 100. |
---|
127 | |
---|
128 | @item unsigned long mbuf_bytecount |
---|
129 | The number of bytes to allocate from the heap for use as mbufs. |
---|
130 | If a value of 0 is specified, 64 kbytes will be allocated. |
---|
131 | |
---|
132 | @item unsigned long mbuf_cluster_bytecount |
---|
133 | The number of bytes to allocate from the heap for use as mbuf clusters. |
---|
134 | If a value of 0 is specified, 128 kbytes will be allocated. |
---|
135 | |
---|
136 | @item char *hostname |
---|
137 | The host name of the system. |
---|
138 | If this, or any of the following, entries are @code{NULL} the value |
---|
139 | may be obtained from a BOOTP/DHCP server. |
---|
140 | |
---|
141 | @item char *domainname |
---|
142 | The name of the Internet domain to which the system belongs. |
---|
143 | |
---|
144 | @item char *gateway |
---|
145 | The Internet host number of the network gateway machine, |
---|
146 | specified in `dotted decimal' (@code{129.128.4.1}) form. |
---|
147 | |
---|
148 | @item char *log_host |
---|
149 | The Internet host number of the machine to which @code{syslog} messages |
---|
150 | will be sent. |
---|
151 | |
---|
152 | @item char *name_server[3] |
---|
153 | The Internet host numbers of up to three machines to be used as |
---|
154 | Internet Domain Name Servers. |
---|
155 | |
---|
156 | @item char *ntp_server[3] |
---|
157 | The Internet host numbers of up to three machines to be used as |
---|
158 | Network Time Protocol (NTP) Servers. |
---|
159 | |
---|
160 | @end table |
---|
161 | |
---|
162 | In addition, the following fields in the @code{rtems_bsdnet_ifconfig} |
---|
163 | are of interest. |
---|
164 | |
---|
165 | @table @b |
---|
166 | |
---|
167 | @item int port |
---|
168 | The I/O port number (ex: 0x240) on which the external Ethernet |
---|
169 | can be accessed. |
---|
170 | |
---|
171 | @item int irno |
---|
172 | The interrupt number of the external Ethernet controller. |
---|
173 | |
---|
174 | @item int bpar |
---|
175 | The address of the shared memory on the external Ethernet controller. |
---|
176 | |
---|
177 | |
---|
178 | @end table |
---|
179 | |
---|
180 | @subsection Network device configuration |
---|
181 | Network devices are specified and configured by declaring and initializing a |
---|
182 | @code{struct rtems_bsdnet_ifconfig} structure for each network device. |
---|
183 | |
---|
184 | The structure entries are described in the following table. An application |
---|
185 | which uses a single network interface, gets network configuration information |
---|
186 | from a BOOTP/DHCP server, and uses the default values for all driver |
---|
187 | parameters needs to initialize only the first two entries in the |
---|
188 | structure. |
---|
189 | |
---|
190 | @table @code |
---|
191 | @item char *name |
---|
192 | The full name of the network device. This name consists of the |
---|
193 | driver name and the unit number (e.g. @code{"scc1"}). |
---|
194 | The @code{bsp.h} include file usually defines RTEMS_BSP_NETWORK_DRIVER_NAME as |
---|
195 | the name of the primary (or only) network driver. |
---|
196 | |
---|
197 | @item int (*attach)(struct rtems_bsdnet_ifconfig *conf) |
---|
198 | The address of the driver @code{attach} function. The network |
---|
199 | initialization function calls this function to configure the driver and |
---|
200 | attach it to the network stack. |
---|
201 | The @code{bsp.h} include file usually defines RTEMS_BSP_NETWORK_DRIVER_ATTACH as |
---|
202 | the name of the attach function of the primary (or only) network driver. |
---|
203 | |
---|
204 | @item struct rtems_bsdnet_ifconfig *next |
---|
205 | A pointer to the network device configuration structure for the next network |
---|
206 | interface, or @code{NULL} if this is the configuration structure of the |
---|
207 | last network interface. |
---|
208 | |
---|
209 | @item char *ip_address |
---|
210 | The Internet address of the device, |
---|
211 | specified in `dotted decimal' (@code{129.128.4.2}) form, or @code{NULL} |
---|
212 | if the device configuration information is being obtained from a |
---|
213 | BOOTP/DHCP server. |
---|
214 | |
---|
215 | @item char *ip_netmask |
---|
216 | The Internet inetwork mask of the device, |
---|
217 | specified in `dotted decimal' (@code{255.255.255.0}) form, or @code{NULL} |
---|
218 | if the device configuration information is being obtained from a |
---|
219 | BOOTP/DHCP server. |
---|
220 | |
---|
221 | |
---|
222 | @item void *hardware_address |
---|
223 | The hardware address of the device, or @code{NULL} if the driver is |
---|
224 | to obtain the hardware address in some other way (usually by reading |
---|
225 | it from the device or from the bootstrap ROM). |
---|
226 | |
---|
227 | @item int ignore_broadcast |
---|
228 | Zero if the device is to accept broadcast packets, non-zero if the device |
---|
229 | is to ignore broadcast packets. |
---|
230 | |
---|
231 | @item int mtu |
---|
232 | The maximum transmission unit of the device, or zero if the driver |
---|
233 | is to choose a default value (typically 1500 for Ethernet devices). |
---|
234 | |
---|
235 | @item int rbuf_count |
---|
236 | The number of receive buffers to use, or zero if the driver is to |
---|
237 | choose a default value |
---|
238 | |
---|
239 | @item int xbuf_count |
---|
240 | The number of transmit buffers to use, or zero if the driver is to |
---|
241 | choose a default value |
---|
242 | Keep in mind that some network devices may use 4 or more |
---|
243 | transmit descriptors for a single transmit buffer. |
---|
244 | |
---|
245 | @end table |
---|
246 | |
---|
247 | A complete network configuration specification can be as simple as the one |
---|
248 | shown in the following example. |
---|
249 | This configuration uses a single network interface, gets |
---|
250 | network configuration information |
---|
251 | from a BOOTP/DHCP server, and uses the default values for all driver |
---|
252 | parameters. |
---|
253 | |
---|
254 | @example |
---|
255 | static struct rtems_bsdnet_ifconfig netdriver_config = @{ |
---|
256 | RTEMS_BSP_NETWORK_DRIVER_NAME, |
---|
257 | RTEMS_BSP_NETWORK_DRIVER_ATTACH |
---|
258 | @}; |
---|
259 | struct rtems_bsdnet_config rtems_bsdnet_config = @{ |
---|
260 | &netdriver_config, |
---|
261 | rtems_bsdnet_do_bootp, |
---|
262 | @}; |
---|
263 | @end example |
---|
264 | |
---|
265 | |
---|
266 | @subsection Network initialization |
---|
267 | The networking tasks must be started before any network I/O operations |
---|
268 | can be performed. This is done by calling: |
---|
269 | |
---|
270 | |
---|
271 | @example |
---|
272 | rtems_bsdnet_initialize_network (); |
---|
273 | @end example |
---|
274 | |
---|
275 | This function is declared in @code{rtems/rtems_bsdnet.h}. |
---|
276 | t returns 0 on success and -1 on failure with an error code |
---|
277 | in @code{errno}. It is not possible to undo the effects of |
---|
278 | a partial initialization, though, so the function can be |
---|
279 | called only once irregardless of the return code. Consequently, |
---|
280 | if the condition for the failure can be corrected, the |
---|
281 | system must be reset to permit another network initialization |
---|
282 | attempt. |
---|
283 | |
---|
284 | |
---|
285 | |
---|
286 | @section Application Programming Interface |
---|
287 | |
---|
288 | The RTEMS network package provides almost a complete set of BSD network |
---|
289 | services. The network functions work like their BSD counterparts |
---|
290 | with the following exceptions: |
---|
291 | |
---|
292 | @itemize @bullet |
---|
293 | @item A given socket can be read or written by only one task at a time. |
---|
294 | |
---|
295 | @item The @code{select} function only works for file descriptors associated |
---|
296 | with sockets. |
---|
297 | |
---|
298 | @item You must call @code{openlog} before calling any of the @code{syslog} functions. |
---|
299 | |
---|
300 | @item @b{Some of the network functions are not thread-safe.} |
---|
301 | For example the following functions return a pointer to a static |
---|
302 | buffer which remains valid only until the next call: |
---|
303 | |
---|
304 | @table @code |
---|
305 | @item gethostbyaddr |
---|
306 | @item gethostbyname |
---|
307 | @item inet_ntoa |
---|
308 | (@code{inet_ntop} is thread-safe, though). |
---|
309 | @end table |
---|
310 | |
---|
311 | @item The RTEMS network package gathers statistics. |
---|
312 | |
---|
313 | @item Addition of a mechanism to "tap onto" an interface |
---|
314 | and monitor every packet received and transmitted. |
---|
315 | |
---|
316 | @item Addition of @code{SO_SNDWAKEUP} and @code{SO_RCVWAKEUP} socket options. |
---|
317 | |
---|
318 | @end itemize |
---|
319 | |
---|
320 | Some of the new features are discussed in more detail in the following |
---|
321 | sections. |
---|
322 | |
---|
323 | @subsection Network Statistics |
---|
324 | |
---|
325 | There are a number of functions to print statistics gathered by |
---|
326 | the network stack. |
---|
327 | These function are declared in @code{rtems/rtems_bsdnet.h}. |
---|
328 | |
---|
329 | @table @code |
---|
330 | @item rtems_bsdnet_show_if_stats |
---|
331 | Display statistics gathered by network interfaces. |
---|
332 | |
---|
333 | @item rtems_bsdnet_show_ip_stats |
---|
334 | Display IP packet statistics. |
---|
335 | |
---|
336 | @item rtems_bsdnet_show_icmp_stats |
---|
337 | Display ICMP packet statistics. |
---|
338 | |
---|
339 | @item rtems_bsdnet_show_tcp_stats |
---|
340 | Display TCP packet statistics. |
---|
341 | |
---|
342 | @item rtems_bsdnet_show_udp_stats |
---|
343 | Display UDP packet statistics. |
---|
344 | |
---|
345 | @item rtems_bsdnet_show_mbuf_stats |
---|
346 | Display mbuf statistics. |
---|
347 | |
---|
348 | @item rtems_bsdnet_show_inet_routes |
---|
349 | Display the routing table. |
---|
350 | |
---|
351 | @end table |
---|
352 | |
---|
353 | @subsection Tapping Into an Interface |
---|
354 | |
---|
355 | RTEMS add two new ioctls to the BSD networking code: |
---|
356 | SIOCSIFTAP and SIOCGIFTAP. These may be used to set and get a |
---|
357 | @i{tap function}. The tap function will be called for every |
---|
358 | Ethernet packet received by the interface. |
---|
359 | |
---|
360 | These are called like other interface ioctls, such as SIOCSIFADDR. |
---|
361 | When setting the tap function with SIOCSIFTAP, set the ifr_tap field |
---|
362 | of the ifreq struct to the tap function. When retrieving the tap |
---|
363 | function with SIOCGIFTAP, the current tap function will be returned in |
---|
364 | the ifr_tap field. To stop tapping packets, call SIOCSIFTAP with a |
---|
365 | ifr_tap field of 0. |
---|
366 | |
---|
367 | The tap function is called like this: |
---|
368 | |
---|
369 | @example |
---|
370 | int tap (struct ifnet *, struct ether_header *, struct mbuf *) |
---|
371 | @end example |
---|
372 | |
---|
373 | The tap function should return 1 if the packet was fully handled, in |
---|
374 | which case the caller will simply discard the mbuf. The tap function |
---|
375 | should return 0 if the packet should be passed up to the higher |
---|
376 | networking layers. |
---|
377 | |
---|
378 | The tap function is called with the network semaphore locked. It must |
---|
379 | not make any calls on the application levels of the networking level |
---|
380 | itself. It is safe to call other non-networking RTEMS functions. |
---|
381 | |
---|
382 | @subsection Socket Options |
---|
383 | |
---|
384 | RTEMS adds two new @code{SOL_SOCKET} level options for @code{setsockopt} and |
---|
385 | @code{getsockopt}: @code{SO_SNDWAKEUP} and @code{SO_RCVWAKEUP}. For both, the |
---|
386 | option value should point to a sockwakeup structure. The sockwakeup |
---|
387 | structure has the following fields: |
---|
388 | |
---|
389 | @example |
---|
390 | @group |
---|
391 | void (*sw_pfn) (struct socket *, caddr_t); |
---|
392 | caddr_t sw_arg; |
---|
393 | @end group |
---|
394 | @end example |
---|
395 | |
---|
396 | These options are used to set a function to be called when there is |
---|
397 | data available from the socket (@code{SO_RCVWAKEUP}) and when there is space |
---|
398 | available to accept data written to the socket (@code{SO_SNDWAKEUP}). |
---|
399 | |
---|
400 | If @code{setsockopt} is called with the @code{SO_RCVWAKEUP} option, and the |
---|
401 | @code{sw_pfn} field is not zero, then when there is data |
---|
402 | available to be read from |
---|
403 | the socket, the function pointed to by the @code{sw_pfn} field will be |
---|
404 | called. A pointer to the socket structure will be passed as the first |
---|
405 | argument to the function. The @code{sw_arg} field set by the |
---|
406 | @code{SO_RCVWAKEUP} call will be passed as the second argument to the function. |
---|
407 | |
---|
408 | If @code{setsockopt} is called with the @code{SO_SNDWAKEUP} |
---|
409 | function, and the @code{sw_pfn} field is not zero, then when |
---|
410 | there is space available to accept data written to the socket, |
---|
411 | the function pointed to by the @code{sw_pfn} field |
---|
412 | will be called. The arguments passed to the function will be as with |
---|
413 | @code{SO_SNDWAKEUP}. |
---|
414 | |
---|
415 | When the function is called, the network semaphore will be locked. |
---|
416 | The function must be careful not to call any networking functions. It |
---|
417 | is OK to call an RTEMS function; for example, it is OK to send an |
---|
418 | RTEMS event. |
---|
419 | |
---|
420 | The purpose of these functions is to permit a more efficient |
---|
421 | alternative to the select call when dealing with a large number of |
---|
422 | sockets. |
---|
423 | |
---|
424 | @subsection Time Synchronization Using NTP |
---|
425 | |
---|
426 | @example |
---|
427 | int rtems_bsdnet_synchronize_ntp (int interval, rtems_task_priority priority); |
---|
428 | @end example |
---|
429 | |
---|
430 | If the interval argument is 0 the routine synchronizes the RTEMS time-of-day |
---|
431 | clock with the first NTP server in the rtems_bsdnet_ntpserve array and |
---|
432 | returns. The priority argument is ignored. |
---|
433 | |
---|
434 | If the interval argument is greater than 0, the routine also starts an |
---|
435 | RTEMS task at the specified priority and polls the NTP server every |
---|
436 | `interval' seconds. NOTE: This mode of operation has not yet been |
---|
437 | implemented. |
---|
438 | |
---|
439 | On successful synchronization of the RTEMS time-of-day clock the routine |
---|
440 | returns 0. If an error occurs a message is printed and the routine returns -1 |
---|
441 | with an error code in errno. |
---|
442 | There is no timeout -- if there is no response from an NTP server the |
---|
443 | routine will wait forever. |
---|
444 | |
---|
445 | |
---|
446 | |
---|
447 | |
---|