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.
