Comment # 43
on bug 12687
from Guy Harris
(In reply to Oliver Hartkopp from comment #42)
> (In reply to Guy Harris from comment #41)
>
> > Or how about doing a cooked capture for ARPHRD_CAN, so that the link-layer
> > type is DLT_LINUX_SLL, add LINUX_SLL_P_CANFD (with the same numerical value
> > as ETH_P_CANFD) to libpcap's pcap/sll.h and Wireshark's
> > epan/dissectors/packet-sll.h,
>
> In the latest Wireshark patch set on
> https://code.wireshark.org/review/#/c/16787/ Michael already defined
> LINUX_SLL_P_CANFD as suggested by you.
>
> > add it to the byte-swapping code in libpcap's
> > pcap-common.c and Wireshark's wiretap/pcap-common.c, add it to the table in
> > epan/dissectors/packet-sll.c, and have epan/dissectors/packet-socketcan.c
> > register for it, as well as LINUX_SLL_P_CAN, in the "sll.ltype" dissector
> > table.
> >
> > Then the dissector for LINUX_SLL_P_CANFD would dissect a CANFD header, and
> > the dissector for LINUX_SLL_P_CAN would dissect a non-CANFD header.
> >
> > Then we don't need any DLT_/LINKTYPE_ values for CANFD, and might even not
> > need to bother with DLT_CAN_SOCKETCAN_HOSTENDIAN.
>
> That would be great!
>
> I hoped the possibility to remove some code paths would create this
> opportunity to simplify the interface provided by libpcap.
>
> Even though I did not get completely behind your suggestion it seems the way
> of simplification I had in mind too :-)
Done on the libpcap master branch with change
https://github.com/the-tcpdump-group/libpcap/commit/93ca5ff7030aaf1219e1de05ec89a68384bfc50b.
I reverted to just having DLT_CAN_SOCKETCAN/LINKTYPE_CAN_SOCKETCAN;
pcap-linux.c will now use DLT_LINUX_SLL/LINKTYPE_LINUX_SLL, so the protocol
field can be used to distinguish between "classic" CAN and CAN FD frames.
You are receiving this mail because:
- You are watching all bug changes.
