Comment # 67
on bug 12687
from Oliver Hartkopp
(In reply to Guy Harris from comment #66)
> (In reply to Oliver Hartkopp from comment #65)
> > Hm. Generally I like the idea to use PF_PACKET sockets. But I wonder if it
> > puzzles users when they get the outgoing (pkttype 4) traffic too.
>
> So:
>
> 1) the Linux core networking stack loops back sent packets in
> dev_queue_xmit_nit(), with the time stamp being the time at which it gets
> looped back, and with a packet type of PACKET_OUTGOING;
ack
> 2) the Linux CAN networking stack loops backs sent packets either in
> hardware or the driver or the common CAN code, with the time stamp being the
> time the "transmission OK" interrupt occurred for hardware where that can be
> done by the hardware or driver and the time the loopback was done where that
> can't, and with a packet type of PACKET_BROADCAST;
ack
> so, for CAN interfaces, sent packets are delivered twice to a PF_PACKET
> socket, once with a packet type of PACKET_OUTGOING and a time stamp that
> does *not* reflect the time when the packet was put on the wire, and once
> with a packet type of PACKET_BROADCAST and a time stamp that, ideally,
> *does* reflect the time when the packet was put on the wire.
Yes. You summarized it perfectly.
> Is that *always* the case? I.e., can we *rely* on the PACKET_BROADCAST
> delivery of outgoing packets for *all* CAN interfaces?
Generally yes.
There is a special socket option for PF_CAN RAW sockets that allows to disable
the IFF_ECHO mechanism:
http://lxr.linux.no/#linux+v4.7.2/Documentation/networking/can.txt#L534
But if when you disable the IFF_ECHO you won't even see the frames on PF_CAN
sockets. This CAN_RAW_LOOPBACK is a really weird option for embedded single
application use-cases which brakes the intended multi-user capable approach of
SocketCAN. When you enable this option you are aware that other applications on
the host intentionally don't see outgoing traffic. So it's ok and assumed hat
neither candump nor Wireshark see any outgoing traffic then.
> If so, then we can use PF_PACKET sockets and, in linux_check_direction() in
> pcap-linux.c, reject PACKET_OUTGOING packets with a protocol of ETH_P_CAN or
> ETH_P_CANFD.
Yes. IMO we can do it like this.
> That will work with the "any" device and with a PF_PACKET socket bound to a
> CAN device.
>
> It will also...
>
> > Yes. But the point is that I would like to split up the CAN and CAN FD after
> > reading it from the PF_CAN socket in the way we now have defined the SLL
> > data flows. Do you think this is possible?
>
> ...have different protocols in the SLL header, so the Wireshark dissector
> will use different dissector routines for CAN and CANFD frames.
:-)
> > At least the 'hack' to add a flag inside struct canfd_frame is something I
> > would like to avoid. The best approach would be to have some meta data about
> > CAN/CANFD coming along with the struct can[fd]_frame - like we now have with
> > LINUX_SLL_P_CAN and LINUX_SLL_P_CANFD.
>
> That's exactly what we'll have - it'll be in the protocol field of the
> LINKTYPE_LINUX_SLL header.
Great.
When you agree that ignoring the PACKET_OUTGOING CAN frames in
linux_check_direction() is ok for you (after my explanation above) this should
be added directly. Especially before our (your) last SocketCAN clean-up hits an
official release.
You are receiving this mail because:
- You are watching all bug changes.
