|
@@ -164,7 +164,7 @@ The Linux network devices (by default) just can handle the
|
|
|
transmission and reception of media dependent frames. Due to the
|
|
|
arbitration 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 [#f1]_ traffic on the node the loopback 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.
|
|
@@ -175,7 +175,7 @@ networking behaviour for CAN applications. Due to some requests from
|
|
|
the RT-SocketCAN group the loopback optionally may be disabled for each
|
|
|
separate socket. See sockopts from the CAN RAW sockets in :ref:`socketcan-raw-sockets`.
|
|
|
|
|
|
-.. [*] you really like to have this when you're running analyser
|
|
|
+.. [#f1] you really like to have this when you're running analyser
|
|
|
tools like 'candump' or 'cansniffer' on the (same) node.
|
|
|
|
|
|
|