[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 64 on bug 12687 from Guy Harris

(In reply to Oliver Hartkopp from comment #63)
> (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?

The "any" device means libpcap opens a PF_PACKET/SOCK_DGRAM socket and doesn't
bind it to an interface, so it receives packets from *all* interfaces, not just
from one 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?

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.

> > 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??

We can re-introduce PF_CAN sockets for individual interfaces.

We can't use it for the "any" device, however.  Even reading from an unbound
PF_CAN socket would get CAN frames from all CAN interfaces but wouldn't get
packets from other interfaces.

> > 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).

So that's not just a heuristic, it's something *guaranteed* to indicate whether
the frame is a CAN frame or a CAN FD frame?

> > 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.

OK, so that would be an "anycan" device if we were to implement it.

---

      You are receiving this mail because:

• You are watching all bug changes.