Comment # 63
on bug 12687
from Oliver Hartkopp
(In reply to Guy Harris from comment #62)
> (In reply to Oliver Hartkopp from comment #60)
> > If we want to provide the correctly timestamped PACKET_BROADCAST packets
> > *together* with the information about the CAN frames origin we would need to
> > get back to PF_CAN RAW sockets - with some more functionality:
> >
> > http://lxr.linux.no/#linux+v4.7.2/Documentation/networking/can.txt#L631
>
> OK, so:
>
> 1) How do you make that work on an unbound PF_PACKET socket (the "any"
> device)?
Does that mean you open a PF_PACKET socket and just capture everything you see
from every network interface?
> 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?
> or 1b) we
> just discard *all* CAN packets on the "any" device, so that you don't see
> CAN interfaces with the "any" device?
Then we would need to re-introduce PF_CAN sockets??
> 2) Is the "CAN or CAN FD frame" information available if we get the packets
> from a PF_CAN socket, so we don't have to guess whether it's a CAN or CAN FD
> frame?
Yes. You can enable the reception of CAN FD what I have done in my original
attempt to extend libpcap:
https://github.com/hartkopp/libpcap/commit/5f970840aea932ba4c53b8b6687296d215f7f0fc#diff-91134676691503700c95a44e59d41cedR192
After
setsockopt(handle->fd, SOL_CAN_RAW, CAN_RAW_FD_FRAMES, &enable_canfd,
sizeof(enable_canfd));
the read/recvmsg() delivers struct can_frames or struct canfd_frames which can
be distinguished by their length (return value from read syscall).
> 3) Would this be done by putting the PF_CAN code into pcap-linux.c and, if
> we're capturing on a particular device (rather than the "any" device), and
> that device has ARPHRD_CAN as its ARP hardware type, we close the PF_PACKET
> socket, open a PF_CAN socket, and use *that* to capture, rather than trying
> to guess whether it's a CAN device based on the device's name (which didn't
> work completely in the old code - it expected devices to have names
> beginning with "can" or "can" and thus didn't find "slcan" devices)?
Checking for ARPHRD_CAN is definitely the right way to go. The check with "can"
and "vcan" was broken from the beginning.
We can also bind a PF_CAN socket to an 'any' device (ifindex = 0) where 'any'
means 'any CAN interface with ARPHDR_CAN'. In this case we need to use
recvmsg() or recvfrom() to get the interface index from the CAN interface.
You are receiving this mail because:
- You are watching all bug changes.
