Comment # 66
on bug 12687
from Guy Harris
(In reply to Oliver Hartkopp from comment #65)
> > > > Or can it simply not be made to work *at all* on a PF_PACKET socket, in
> > > > which case either 1a) users will have to live with duplicate CAN packets if
> > > > they capture with the "any" device on a system with CAN interfaces
> > >
> > > Which is what we see right now, right?
> >
> > Yes, that's what we get now with the "any" device. The question is whether
> > there's any way to get something *better* than that.
>
> 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;
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;
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.
Is that *always* the case? I.e., can we *rely* on the PACKET_BROADCAST
delivery of outgoing packets for *all* CAN interfaces?
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.
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.
You are receiving this mail because:
- You are watching all bug changes.