3 Socket CAN concept
3.1 receive lists
- 3.2 loopback
+ 3.2 local echo of sent frames
3.3 network security issues (capabilities)
3.4 network problem notifications
4.1 RAW protocol sockets with can_filters (SOCK_RAW)
4.1.1 RAW socket option CAN_RAW_FILTER
4.1.2 RAW socket option CAN_RAW_ERR_FILTER
- 4.1.3 RAW socket option CAN_RAW_LOOPBACK
+ 4.1.3 RAW socket option CAN_RAW_ECHO
4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
4.3 connected transport protocols (SOCK_SEQPACKET)
6 CAN network drivers
6.1 general settings
- 6.2 loopback
+ 6.2 echo of sent frames
6.3 CAN controller hardware filters
6.4 currently supported CAN hardware
6.5 todo
into several specific lists per device that match the requested
filter complexity for a given use-case.
- 3.2 loopback
+ 3.2 local echo of sent frames
As known from other networking concepts the data exchanging
applications may run on the same or different nodes without any
To ensure that application A receives the same information in the
example (2) as it would receive in example (1) there is need for
- some kind of local loopback on the appropriate node.
+ some kind of local echo of the sent CAN frames on the appropriate node.
The Linux network devices (by default) just can handle the
transmission and reception of media dependent frames. Due to the
arbritration on the CAN bus the transmission of a low prio CAN-ID
may be delayed by the reception of a high prio CAN frame. To
- reflect the correct* traffic on the node the loopback of the sent
+ reflect the correct* traffic on the node the local echo of the sent
data has to be performed right after a successful transmission. If
- the CAN network interface is not capable of performing the loopback for
- some reason the SocketCAN core can do this task as a fallback solution.
+ the CAN network interface is not capable of performing this echo handling
+ for some reason the SocketCAN core can do this task as a fallback solution.
See chapter 6.2 for details (recommended).
- The loopback functionality is enabled by default to reflect standard
+ The echo functionality is enabled by default to reflect standard
networking behaviour for CAN applications. Due to some requests from
- the RT-SocketCAN group the loopback optionally may be disabled for each
+ the RT-SocketCAN group the local echo optionally may be disabled for each
separate socket. See sockopts from the CAN RAW sockets in chapter 4.1.
* = you really like to have this when you're running analyser tools
- The filters are set to exactly one filter receiving everything
- The socket only receives valid data frames (=> no error frames)
- - The loopback of sent CAN frames is enabled (see chapter 3.2)
- - The socket does not receive its own sent frames (in loopback mode)
+ - The local echo of sent CAN frames is enabled (see chapter 3.2)
+ - The socket does not receive its own sent and echoed frames
These default settings may be changed before or after binding the socket.
To use the referenced definitions of the socket options for CAN_RAW
setsockopt(s, SOL_CAN_RAW, CAN_RAW_ERR_FILTER,
&err_mask, sizeof(err_mask));
- 4.1.3 RAW socket option CAN_RAW_LOOPBACK
+ 4.1.3 RAW socket option CAN_RAW_ECHO
- To meet multi user needs the local loopback is enabled by default
+ To meet multi user needs the local echo is enabled by default
(see chapter 3.2 for details). But in some embedded use-cases
- (e.g. when only one application uses the CAN bus) this loopback
+ (e.g. when only one application uses the CAN bus) this echo
functionality can be disabled (separately for each socket):
- int loopback = 0; /* 0 = disabled, 1 = enabled (default) */
+ int echo = 0; /* 0 = disabled, 1 = enabled (default) */
- setsockopt(s, SOL_CAN_RAW, CAN_RAW_LOOPBACK, &loopback, sizeof(loopback));
+ setsockopt(s, SOL_CAN_RAW, CAN_RAW_ECHO, &echo, sizeof(echo));
4.1.4 RAW socket option CAN_RAW_RECV_OWN_MSGS
- When the local loopback is enabled, all the sent CAN frames are
+ When the local echo is enabled, all the sent CAN frames are
looped back to the open CAN sockets that registered for the CAN
frames' CAN-ID on this given interface to meet the multi user
needs. The reception of the CAN frames on the same socket that was
can_rx_register - subscribe CAN frames from a specific interface
can_rx_unregister - unsubscribe CAN frames from a specific interface
- can_send - transmit a CAN frame (optional with local loopback)
+ can_send - transmit a CAN frame (optional with local echo)
For details see the kerneldoc documentation in net/can/af_can.c or
the source code of net/can/raw.c or net/can/bcm.c .
The struct can_frame is the payload of each socket buffer in the
protocol family PF_CAN.
- 6.2 loopback
+ 6.2 echo of sent frames
As described in chapter 3.2 the CAN network device driver should
- support a local loopback functionality. In this case the driver flag
- IFF_LOOPBACK has to be set to cause the PF_CAN core to not perform the
- loopback as fallback solution:
+ support a local echo functionality. In this case the driver flag
+ IFF_ECHO has to be set to cause the PF_CAN core to not perform the
+ local echo as fallback solution:
- dev->flags = (IFF_NOARP | IFF_LOOPBACK);
+ dev->flags = (IFF_NOARP | IFF_ECHO);
6.3 CAN controller hardware filters
Please check the Mailing Lists on the berlios OSS project website.
- 6.5 todo (May 2007)
+ 6.5 todo (September 2007)
The configuration interface for CAN network drivers is still an open
issue that has not been finalized in the socketcan project. Also the
Matthias Brukner (first SJA1000 CAN netdevice implementation Q2/2003)
Klaus Hitschler (PEAK driver integration)
Uwe Koppe (CAN netdevices with PF_PACKET approach)
- Michael Schulze (driver layer loopback requirement, RT CAN drivers review)
+ Michael Schulze (driver layer echo requirement, RT CAN drivers review)
projects / socketcan-devel.git / commitdiff