can_eth_gw Gateway Module  0.1
A bidirectional CAN to Ethernet Gateway (Kernel Module)
 All Data Structures Files Functions Variables Enumerations Enumerator Macros Groups Pages
doc/developer_doc.md
Go to the documentation of this file.
1 <a name="top"/></a>
2 
3 developer_doc.md
4 ================
5 
6 Developer documentation for the CAN Ethernet Gateway
7 
8 <a name="toc"/></a>
9 This file contains:
10 
11  1. [Overview / What is a CAN Ethernet Gateway](#chap1)
12  1. [Ethernet followed by CAN](#chap1-1)
13  2. [Ethernet followed by IP and TCP/UDP](#chap1-2)
14  3. [Ethernet followed by IP, TCP/UDP and CAN](#chap1-3)
15  2. [CAN Ethernet Gateway concept](#chap1)
16  1. [Netlink server](#chap2-1)
17  2. [Virtual ethernet device](#chap2-2)
18  3. [CAN - Ethernet Gateway](#chap2-3)
19  4. [Netlink client](#chap2-4)
20  3. [Translating CAN and ethernet](#chap3)
21  1. [Characteristics of CAN](#chap3-1)
22  1. [CAN SFF and EFF](#chap3-1-1)
23  2. [CAN FD](#chap3-1-2)
24  3. [Length calculation](#chap3-1-3)
25  2. [Translation](#chap3-2)
26  1. [Ethernet to CAN](#chap3-2-1)
27  2. [Ethernet to CAN FD](#chap3-2-2)
28  3. [CAN to ethernet](#chap3-2-3)
29  4. [CAN FD to ethernet](#chap3-2-4)
30  5. [Ethernet including complete CAN / CAN FD](#chap3-2-5)
31  3. [Special messages](#chap3-3)
32  4. [Routing](#chap4)
33  1. [Routing lists](#chap4-1)
34  5. [Useful links](#chap5)
35  6. [Copyright](#chap6)
36  7. [References](#chap7)
37 
38 <a name="chap1"/></a>
39 
40 1. Overview / What is a CAN Ethernet Gateway
41 --------------------------------------------
42 
43 The CAN Ethernet Gateway converts a CAN (controller area network) signal into
44 an ethernet signal. From a operation system perspective the gateway is
45 disguised as an ethernet device by a virtual ethernet device. Due to missing
46 equality of the frame structures there are some varying methods for translating
47 the CAN frame. In the kernel module sources the types are represented with
48 `enum ce_gw_type` (`ce_gw_main.h`) and in userspace with `enum gw_type`
49 (`netlink.h`). The Gateway connect to the CAN driver named "linux-can"
50 (formerly "socketCAN") which is built in since Linux Kernel 3.2 . But this
51 module requires at minimum Linux Kernel 3.6 . _[UP](#top)_
52 
53 <a name="chap1-1"/></a>
54 ### 1.1. Ethernet followed by CAN
55 The first idea is to add a CAN header and the following payload directly after
56 the ethernet frame. The CAN header always uses the structure implemented in the
57 can.h (see 3.1) and not the original signal. This gateway type is named
58 `TYPE_NET` (in kernel module with an prefix) in the sources, because CAN is here
59 a network layer protocol.
60 
61  +____________________+
62  | |
63  | MAC (Ethernet) |
64  +____________________+
65  | +______________+ | +______________+
66  | | | | | |
67  | | CAN header | | | CAN header |
68  | +______________+<-+------>+______________+
69  | | | | | |
70  | | payload | | | payload |
71  | +______________+ | +______________+
72  +____________________+
73 
74 This method is easy to implement but in return you need a special network on
75 side of the ethernet signals. The network of the ethernet side must not be based
76 on IP but on CAN. Otherwise the signal can't be interpreted.
77 It is appropriate for CAN brigdes, where two or more CAN networks should be
78 connected via a standart ethernet bridge. In principle this can also be done
79 with the method described in 1.3 but method 1.1 is more effictive on a local
80 computer.
81 
82 The MAC address can be a broadcast address for keeping things easy but this
83 will create a lot of traffic for the system. To keep the traffic low specific
84 addresses are needed. Therefore it is necessary to define a mapping table,
85 which definies one or more MAC address for one or more CAN identifier. The
86 table is not implemented yet. _[UP](#top)_
87 
88 <a name="chap1-2"/></a>
89 ### 1.2 Ethernet followed by IP and TCP/UDP
90 To avoid the need for a CAN network on the side of ethernet signals an IP and
91 TCP/UDP header can be added after the ethernet header. They are followed by the
92 payload of the CAN frame. The CAN header always uses the structure implemented in the
93 can.h (see 3.1) and not the original signal. This gateway type is named
94 `TYPE_ETH` (in kernel module with an prefix) in the sources.
95 
96  +______________________+ +______________________+
97  | | | |
98  | MAC (Ethernet) | | CAN header |
99  +______________________+ +______________________+
100  | +________________+ | | +________________+ |
101  | | | | | | | |
102  | | IP header | | | | IP header | |
103  | +________________+ | | +________________+ |
104  | | | | | | | |
105  | | UDP/TCP header |<-+------+->| UDP/TCP header | |
106  | +________________+ | | +________________+ |
107  | | | | | | | |
108  | | payload | | | | payload | |
109  | +________________+ | | +________________+ |
110  +______________________+ +______________________+
111 
112 For this method a CAN frame already including IP and TCP/UDP header is needed.
113 This special CAN frame makes it easier to implement but, of course, the gateway
114 will only work if all CAN frames are organized in the given way. It is also
115 necessary to use a CAN FD because standard and extended frame format CANs don't
116 own enough specificed payload for the payload of IP header, TCP/UDP and payload
117 itself. It can be used for networks using different layer two protocolls.
118 
119 If ethernet just includes a payload without IP or TCP/UDP header it can still be
120 translated into a CAN frame.
121 
122 As there is no CAN header included in the ethernet frame anymore it is important
123 to map the ID of the CAN header on the MAC address. But in comparison with the
124 first approach the ethernet frames will be compatible with all networks using
125 IP and TCP/UDP. These are not yet implemented. _[UP](#top)_
126 
127 <a name="chap1-3"/></a>
128 ### 1.3 Ethernet followed by IP, TCP/UDP and CAN
129 
130 If an ethernet frame is requested that is compatible with networks using IP and
131 TCP/UDP and additionally using every CAN frame should be possible there is
132 another option. The CAN header always uses the structure implemented in the
133 can.h _[(see 3.1) ](#chap3-1)_ and not the original signal. This gateway type
134 is named `TYPE_TCP` and `TYPE_UDP` (in kernel module with an prefix) in the
135 sources.
136 
137  +______________________+
138  | |
139  | MAC (Ethernet) |
140  +______________________+
141  | |
142  | IP header |
143  +______________________+
144  | |
145  | UDP/TCP header |
146  +______________________+
147  | +________________+ | +________________+
148  | | | | | |
149  | | CAN header | | | CAN header |
150  | |________________|<-+------>+________________+
151  | | | | | |
152  | | payload | | | payload |
153  | +________________+ | +________________+
154  +______________________+
155 
156 In this case any CAN frame is added into the payload of the TCP/UDP protokoll.
157 The ID of the CAN frame is used to map an IP and also the port for TCP or UDP.
158 Having the best functunallity the implementation of this stack is the hardest
159 out of all three options. This method can be used for a CAN bridge over an IP
160 network, e.g. internet. Another possibility is to use the gateway for sending a
161 CAN frame to an application. _[UP](#top)_
162 
163 <a name="chap2"/></a>
164 
165 2. CAN Ethernet Gateway concept
166 -------------------------------
167 
168 The CAN Ethernet Gateway consists of three parts:
169 
170 * netlink server
171 * virtual ethernet device
172 * CAN - Ethernet Gateway
173 
174 Additionally there is a netlink client in the userspace.
175 
176 This graphic showes the structur of the CAN Ethernet Gateway:
177 
178 ~~~~~~~
179  _______________________________________________________
180  | |
181  | CAN Ethernet Gateway Kernel Module (ce_gw) |
182  |_______________________________________________________|
183  | |
184  | Ethernet Frame +----------------------+ | CAN Frame
185  | +-----o---------->|CAN - Ethernet Gateway|<-+-------o----+
186  | | | ce_gw_main.c | | |
187  | | +----------------------+ | v
188  | v | +----------+
189  | +--------------------+ | |CAN Device|
190  | |virtual Ethernet dev| | | can.c |
191  | |('cegw#' Interface) | +---------------+ | +----------+
192  | | ce_gw_dev.c | |Netlink Server | | ^
193  | +--------------------+ |ce_gw_netlink.c| | |
194  | ^ +---------------+ | v
195  | | ^ | +----------+
196  |___________|____________________________|______________| |CAN Driver|
197  | o Netlink Frame +----------+
198  v Kernelspace | ^
199  +----+ __________________|_____________ |
200  | OS | Userspace | v
201  +----+ v +-------+
202  +------------------+ |CAN NIC|
203  | Netlink Client | +-------+
204  | netlink.c |
205  |(can-eth-gw-utils)|
206  +------------------+
207 
208 Diagramm which shows the relation and packet transmission between
209 the components of this kernel module (ce_gw) and others of the OS.
210  _[UP](#top)_
211 ~~~~~~~
212 
213 <a name="chap2-1"/></a>
214 
215 ### 2.1 Netlink server
216 
217 The netlink server administrates the communication between kernel- and
218 userspace. It enables a configuration of the gateway by the user.
219  _[UP](#top)_
220 
221 <a name="chap2-2"/></a>
222 ### 2.2 Virtual ethernet device
223 
224 The virtual ethernet device theoretical disguises the CAN Ethernet Gateway as
225 ethernet device. Therefore it is possible to use the gateway just like every
226 other ethernet device without knowing the structure behind.
227 
228 <a name="chap2-3"/></a>
229 ### 2.3 CAN - Ethernet Gateway
230 
231 The CAN - Ethernet Gateway is responsible for receiving CAN frames and
232 translating them. Additionally it theoretical simulates an ethernet network so
233 that it is possible to use every ethernet function on the translated CAN frame. _[UP](#top)_
234 
235 <a name="chap2-4"/></a>
236 ### 2.4 Netlink client
237 
238 The netlink client controls the gateway in the userspace. See application
239 'cegwctl' in package "can-eth-gw-utils":
240 ([Link](https://github.com/can-eth-gw/can-eth-gw-utils "Sources on Github")) _[UP](#top)_
241 
242 <a name="chap3"/></a>
243 
244 3. Translating CAN and ethernet
245 -------------------------------
246 
247 <a name="chap3-1"/></a>
248 ### 3.1 Characteristics of CAN
249 
250 While working with the CAN struct there are a few things to keep an eye on.
251 First thing is that there are basicly three different CAN formats:
252 
253 * CAN SFF (standard frame format)
254 * CAN EFF (extended frame format)
255 * CAN FD (fexible data)
256 
257  _[UP](#top)_
258 
259 <a name="chap3-1-1"/></a>
260 #### 3.1.1 CAN SFF and EFF
261 
262 CAN SFF and EFF use the same struct (can_frame). The difference between this
263 two types can found in the header. While an SFF has eleven bit for the
264 identifier plus three additional flags, EFF uses 29 bit for the identifier plus
265 the same three flags. To detect which of this two types is used the
266 CAN_EFF_FLAG needs to be checked. The original CAN signal has a different structure
267 than the signal produced by the CAN struct.
268 
269 Here is the original signal:
270 
271 
272 __SFF header:__
273 
274 ~~~~~~~
275  1 1 1
276  11 bit bit bit bit 4 bit
277  +___________+___+___+___+______+___...
278  | | | | | | Raw
279  |identifier |RTR|EFF|res| DLC | Data
280  +___________+___+___+___+______+___...
281  | | |
282  |<------------->|<------------>|
283  Arbitration Control
284  Field Field
285 ~~~~~~~
286 
287 __EFF header:__
288 
289 ~~~~~~~
290  1 1 1 1 1
291  11 bit bit bit 18 bit bit bit bit 4 bit
292  +___________+___+___+__________________+___+___+___+______+___...
293  | |sub| | extended | | | | | Raw
294  |identifier |RTR|EFF| identifier |RTR|res|res| DLC | Data
295  +___________+___+___+__________________+___+___+___+______+___...
296  | | |
297  |<---------------------------------------->|<------------>|
298  Arbitration Field Control Field
299 ~~~~~~~
300 
301 The 13th bit decides whether the sent signal is SFF or EFF. (1 = EFF, 0 =
302 SFF).
303 
304 The struct can_frame changes the signal:
305 
306 ~~~~~~~
307  1 1 1 4 4
308  11 bit 18 bit bit bit bit bit bit 3 byte
309 +___________+__________________+___+___+___+_____+_____+________________+___...
310 | | extended | | | | DLC | | | Raw
311 |identifier | identifier |ERR|RTR|EFF| pad | DLC | padding | Data
312 +___________+__________________+___+___+___+_____+_____+________________+___...
313 
314 ~~~~~~~
315 
316 To see if the message is a SFF or EFF the 32th bit needs to be checked. (1 =
317 EFF, 0 = SFF). As both, SFF and EFF, use the same struct the 18 bit of extended
318 identifier are set to 0 and ignored if the EFF flag is 0.
319 Also there is an extended DLC field of 8 bit but only 4 bit are used. The first
320 4 bit are just padded. An additional flag for an error (ERR) is added which is
321 not present in the original signal. There, an error is represented as a complete
322 different signal. After the DLC an additional padding field of 3 byte is between
323 the header and following data.
324 
325 Both original SFF and EFF and the struct add a data field of eight byte. _[UP](#top)_
326 
327 <a name="chap3-1-2"/></a>
328 #### 3.1.2 CAN FD
329 
330 The CAN FD allows the use of a up to 64 byte data field. It also adds some
331 additional flags and reserved fields. Therefore it is implemented in a new
332 struct (canfd_frame). The structure of identifier, the ERR, RTR, EFF and the
333 len field (same as DLC) is alike. After that part there are 24 bits of new FD
334 specific fields, followed by 64 byte data.
335 
336 ~~~~~~~
337  1 1 1
338  11 bit 18 bit bit bit bit 4 bit 4 bit 8 bit 8 bit 8 bit
339 +___________+__________________+___+___+___+_____+_____+______+______+______+
340 | | Extended | | | | len | | | res0 | res1 |
341 |identifier | identifier |ERR|RTR|EFF| pad | len |flags | pad | pad |
342 +___________+__________________+___+___+___+_____+_____+______+______+______+
343 ~~~~~~~
344  _[UP](#top)_
345 
346 <a name="chap3-1-3"/></a>
347 #### 3.1.3 Length calculation
348 
349 As the 64 byte data length should be represented by a only eight bit long
350 len-field a calculation for the real length is needed. This is done by the
351 can_dlc2len function included in can/dev.h. That function is also need for
352 calculating the length of a can_frame. _[UP](#top)_
353 
354 <a name="chap3-2"/></a>
355 ### 3.2 Translation
356 
357 For sending the ethernet and CAN packages the sk buffer is used. _[UP](#top)_
358 
359 <a name="chap3-2-1"/></a>
360 #### 3.2.1 Ethernet to CAN
361 
362 As a CAN frame can only hold eight byte of data there is no space for including
363 an IP or TCP/UDP header. Therefore we assume that the sk buffer includes only
364 payload after the ethernet header as shown in the picture:
365 
366 ~~~~~~~
367 mac header mac header
368 data pointer-->+----------------------+ +----------------------+<--data pointer
369  | | | |
370  | MAC (Ethernet) [14 B]| | CAN header [5 bit] |
371  network-->+----------------------+ +----------------------+<--network
372  header | +----------------+ | | +----------------+ | header
373  | | | | | | | |
374  | | payload [8 B] |--+--+->| payload [8 B] | |
375  | +----------------+ | | +----------------+ |
376  transport-->+----------------------+ +----------------------+<--transport
377  header header
378 ~~~~~~~
379 
380 The sk buffer has various pointers included. Here the mac header points
381 correctly at the beginning of the ethernet or CAN header, whereas the network
382 pointer dosen't point at the beginning of an IP header but at the start of the
383 payload. Because there is no TCP/UDP header the transport pointer will point
384 at the end of the data.
385 
386 Even if the pointers of mac, network and transport header are set on the side of
387 the CAN frame there is no guarentee that they will be used. _[UP](#top)_
388 
389 <a name="chap3-2-2"/></a>
390 #### 3.2.2 Ethernet to CAN FD
391 
392 When a ethernet frame is translated into a CAN FD it is possible to copy IP
393 header as well as TCP/UDP header. It is just important that the total length of
394 IP header, TCP/UDP header and payload is not more then 64 byte. Otherwise data
395 will be lost.
396 
397 ~~~~~~~
398 mac header mac header
399 data pointer-->+______________________+ +______________________+<--data pointer
400  | | | |
401  | MAC (Ethernet) [14 B]| | CAN FD header [8 B] |
402  __+______________________+ +______________________+__
403  network--/--+->+________________+ | | +________________+<-+--\--network
404  header | | | | | | | | | | header
405  | | | IP header | | | | IP header | | |
406  transport--+--+->+________________+ | | +________________+<-+--+--transport
407  header / | | | | | | | | \ header
408  [64 B] < | | UDP/TCP header |--+-+->| UDP/TCP header | | > [64 B]
409  \ | +________________+ | | +________________+ | /
410  | | | | | | | | | |
411  | | | payload | | | | payload | | |
412  | | +________________+ | | +________________+ | |
413  \__+______________________+ +______________________+__/
414 ~~~~~~~
415 
416 The mac and network header can be set correctly to the start of the CAN frame
417 and IP header.
418 There could only occour problems if the ethernet sk buffer is not including IP
419 and TCP/UPD and just a short data field. Then the transport header will not be
420 set at the beginning of UDP/TCP but at the end of the payload like in the
421 ethernet to CAN translation.
422 
423 Even if the pointers of mac, network and transport header are set on the side of
424 the CAN frame there is no guarentee that they will be used. _[UP](#top)_
425 
426 <a name="chap3-2-3"/></a>
427 #### 3.2.3 CAN to ethernet
428 
429 To translate a CAN frame into an ethernet frame the payload will be copied at
430 the end of the ethernet header. In this direction there is no danger to exceed
431 the ethernet frame.
432 
433 ~~~~~~~
434  mac header
435 data pointer-->+----------------------+ +----------------------+<--data pointer
436  | | | |
437  | CAN header [5 bit] | | MAC (Ethernet) [14 B]|
438  +----------------------+ +----------------------+<--network
439  | +----------------+ | | +----------------+ | header
440  | | | | | | | |
441  | | payload [8 B] |--+--+->| payload [8 B] | |
442  | +----------------+ | | +----------------+ |
443  +----------------------+ +----------------------+<--transport
444  header
445 ~~~~~~~
446 
447 However it can not be assumed that all pointers are set correctly in the CAN
448 frame. Only the data pointer will point to the start of the CAN header. All
449 other pointers: mac, network and transport header could point anywhere.
450 Therefore it is neccessary to calculate the start and end of payload.
451 Additional the transport header can still not be set correctly as there is no
452 TCP/UDP header. Therefore it needs to be set at the and of the payload.
453  _[UP](#top)_
454 
455 <a name="chap3-2-4"/></a>
456 #### 3.2.4 CAN FD to ethernet
457 
458 The translation of CAN FD to ethernet is quite similar to ethernet to CAN FD.
459 
460 ~~~~~~~
461  mac header
462 data pointer-->+______________________+ +______________________+<--data pointer
463  | | | |
464  | CAN FD header [8 B] | | MAC (Ethernet) [14 B]|
465  __+______________________+ +______________________+__
466  / | +________________+ | | +________________+<-+--\--network
467  | | | | | | | | | | header
468  | | | IP header | | | | IP header | | |
469  | | +________________+ | | +________________+<-+--+--transport
470  / | | | | | | | | \ header
471  [64 B] < | | UDP/TCP header |--+-+->| UDP/TCP header | + > [64 B]
472  \ | +________________+ | | +________________+ | /
473  | | | | | | | | | |
474  | | | payload | | | | payload | | |
475  | | +________________+ | | +________________+ | |
476  \__+______________________+ +______________________+__/
477 ~~~~~~~
478 
479 However again it can not be assumed that all pointers are set correctly in the
480 CAN frame. Only the data pointer will point to the start of the CAN FD header.
481 All other pointers: mac, network and transport header could point anywhere.
482 Therefore it is neccessary to calculate the start and end of payload as well as
483 start of IP and TCP/UDP header, if they are part of the CAN FD frame.
484 If the CAN FD includes IP and TCP/UDP header both pointers can be set correctly
485 as shown in the picture. Otherwise the transport pointer will be set to the end
486 of the payload. _[UP](#top)_
487 
488 <a name="chap3-2-5"/></a>
489 #### 3.2.5 Ethernet including complete CAN / CAN FD
490 
491 If an ethernet frame includes a complete CAN or CAN FD frame the data after
492 the ethernet header is just copied into a new sk buffer.
493 
494 ~~~~~~~
495 mac header
496 data pointer-->+_______________________+
497  | |
498  | MAC (Ethernet) [14 B] |
499  network-->+_______________________+
500  header | +__________________+ | +_________________+<--data pointer
501  | | CAN/CAN FD header| | |CAN/CAN FD header|
502  | | [5 B/8 B] | | | [5 B/8 B] |
503  | +__________________+<-+-->+_________________+
504  | | payload | | | payload |
505  | | [8 B/64 B] | | | [8 B/64 B] |
506  | +__________________+ | +_________________+
507  transport-->+_______________________+
508  header
509 ~~~~~~~
510 
511 On the ethernet side mac, data and network pointer are set correctly. Only the
512 transport pointer is pointing to the end of the payload. On CAN or CAN FD side
513 only the data pointer is set. All other pointers can point anywhere.
514 _[UP](#top)_
515 
516 <a name="chap3-3"/></a>
517 ### 3.3 Special messages
518 
519 On both sides, ethernet and CAN, there are some special messages that can not
520 be translated directly.
521 The ARP-requests could be managed by the gateway itself. The gateway could
522 answer the requests by the mapping table described in 1.3. For the method of
523 1.1 and 1.2 new tables would be needed.
524 When the CAN header is not included in the ethernet package the error bit of
525 the CAN message will be lost. There is no way to translate it.
526 Also a ping could be realized using the RTR bit (remote transmission bit) of
527 the CAN header.
528 Beside those messages described there are some other messages that can't be
529 translated directly but are not relevant.
530 These messages are not implemented yet. _[UP](#top)_
531 
532 <a name="chap4"/></a>
533 
534 4. Routing
535 ----------
536 
537 In the CAN Ethernet Gateway there are two routs. One goes from the virtual
538 ethernet device over the "CAN - ethernet gateway" to the CAN device. The other
539 one routs excatly the other way round. _[UP](#top)_
540 
541 <a name="chap4-1"/></a>
542 ### 4.1 Routing lists
543 
544 ~~~~~~~
545  +------------------+ /--------------------------------------\
546  | <<Ethernet>> | |ce_gw_job has ethernet as dst and CAN |
547  |struct net_device | |as source OR has ethernet as src and |
548  +------------------+ |CAN as dst. hlist_node annotations are|
549  +-->| .... | |members of the structs where the arrow|
550  | +------------------+ |points to. The hlist structs are not |
551  | | |directly represented here and have |
552  | |void *priv |been simplyfied. |
553  | | \--------------------------------------/
554  | v
555  | +---------------------+ struct hlist_head ce_gw_job_list
556  | |struct ce_gw_job_info| |
557  | +---------------------+ |
558  | | | struct hlist_node |
559  | +---------------------+ list \ |
560  | | | struct \|
561  | struct | |hlist_head | +------------------+
562  | hlist_head| | job_src | | <<CAN>> |
563  | job_dst | | | |struct net_device |
564  | | |\ | +------------------+
565  | | | struct hlist_node | | .... |
566  | | |/ list_dev | +------------------+
567  | | / | ^
568  | |/| |0...* |
569  | struct | | 0...* v | struct
570  |net_device | +--------->+----------------------+ |net_device
571  | *dev +----------->| struct ce_gw_job | | *dev
572  | 0...* +----------------------+ |
573  | +-------------+ |struct rcu_head rcu | +-------------+
574  | | union | |u32 id | | union |
575  +--------+-------------+ |enum ce_gw_type type | +-------------+
576  | |<>-----|u32 flags |----<>| |
577  +-------------+ dst/ |u32 handled_frames | src/ +-------------+
578  src |u32 dropped_frames | dst
579  |union { struct can_ |
580  |filter can_rcv_filter}|
581  +----------------------+
582 ~~~~~~~
583 
584 All routes between CAN and ethernet are saved in the ce_gw_job_list, which is
585 part of the ce_gw_job struct.
586 
587 Additionally the virtual ethernet device manages two lists:
588 
589 * job_dst
590 * job_src
591 
592 Every ethernet device has it's own 2 lists.
593 
594 In job_dst all entrys point to a instance of ce_gw_job. Here the saved source
595 must be identical to the ethernet device, that owns the list.
596 
597 Job_src works in the same way. It lists all instances of ce_gw_job, that
598 reference the ethernet device as source. _[UP](#top)_
599 
600 <a name="chap5"/></a>
601 
602 5. Useful links
603 ---------------
604 
605 * bosch CAN documentation: [http://www.bosch-semiconductors.de/media/pdf_1/canliteratur/can_fd_spec.pdf](http://www.bosch-semiconductors.de/media/pdf_1/canliteratur/can_fd_spec.pdf)
606 * socket can: [https://gitorious.org/linux-can](https://gitorious.org/linux-can)
607 
608 <a name="chap6"/></a>
609 
610 6. Copyright
611 ------------
612 
613 (C) Copyright 2013 Fabian Raab, Stefan Smarzly
614 
615 This file is part of CAN-Eth-GW.
616 
617 CAN-Eth-GW is free software: you can redistribute it and/or modify
618 it under the terms of the GNU General Public License as published by
619 the Free Software Foundation, either version 3 of the License, or
620 (at your option) any later version.
621 
622 CAN-Eth-GW is distributed in the hope that it will be useful,
623 but WITHOUT ANY WARRANTY; without even the implied warranty of
624 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
625 GNU General Public License for more details.
626 
627 You should have received a copy of the GNU General Public License
628 along with CAN-Eth-GW. If not, see <http://www.gnu.org/licenses/>.
629 
630 <a name="chap7"/></a>
631 
632 7. References
633 -------------
634 
635 __Sources:__
636  [https://github.com/can-eth-gw/can_eth_gw/](https://github.com/can-eth-gw/can_eth_gw/ "Sources")
637 
638 __Homepage:__
639  [http://can-eth-gw.github.io/](http://can-eth-gw.github.io/ "Homepage")
640 
641 __Authors:__
642 
643  + Ann Katrin Gibtner
644  + Fabian Raab _<fabian.raab@tum.de>_
645  + Stefan Smarzly _<stefan.smarzly@in.tum.de>_
646 
647 __Date:__ 17. July 2013
648