[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 65 on bug 12687 from Oliver Hartkopp

(In reply to Guy Harris from comment #64)
> (In reply to Oliver Hartkopp from comment #63)

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

ok

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

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

Ok. Whenever we open an ARPHRD_CAN type network interface -> use PF_CAN?

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

Just for the records: A PF_CAN socket *always* has to be bound to an interface
index to provide CAN frames. When we bind a PF_CAN socket to ifindex = 0 this
leads to the functionality to get CAN traffic from all ARPHDR_CAN interfaces on
the system.

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

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?

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.

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

Yes. But you know best whether we open one PF_CAN socket for all CAN traffic or
one for each.

Tnx for your time to check for the best solution.
Oliver

---

      You are receiving this mail because:

• You are watching all bug changes.