https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12687
--- Comment #64 from Guy Harris <g...@alum.mit.edu> --- (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.
___________________________________________________________________________ Sent via: Wireshark-bugs mailing list <wireshark-bugs@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://wireshark.org/mailman/options/wireshark-bugs mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe
