Comment # 32
on bug 12687
from Oliver Hartkopp
(In reply to Michael Mann from comment #30)
> (In reply to Oliver Hartkopp from comment #29)
> > The two SLL types are not really relevant for CAN application programmers.
> > It's a Linux internal thing which only becomes visible when programming
> > PF_PACKET sockets.
> >
> > For that reason my suggested changes to libpcap make sense to me as they are
> > using PF_CAN sockets to get the CAN frames - and this would be a reasonable
> > extension then.
>
> I think I'll leave the SLL support in there for now for the same reason the
> other SLL types are supported - people may use them, even if it's
> "internal". If the flag becomes an issue, we can worry about it then.
I took a deeper look into libpcap to (hopefully) get behind the concepts.
libpcap can use PF_PACKET sockets or protocol specific sockets (e.g. PF_CAN) to
get PDUs. With PF_PACKET sockets you are able to filter for both ETH_P_ types
like ETH_P_CAN and ETH_P_CANFD which would have matching LINUX_SLL_P_CAN[FD]
types in wireshark.
BUT in fact CAN interfaces (ARPHRD_CAN = 280) are handled with PF_CAN RAW
sockets. The PDUs read from the socket are provided by libpcap as link type
DLT_CAN_SOCKETCAN ("CAN-bus with SocketCAN headers") to be used e.g. by
Wireshark which takes this data source and tags it as LINUX_SLL_P_CAN.
With CAN FD we now have two options:
1. Create a second link type DLT_CANFD_SOCKETCAN and provide a separate data
source to Wireshark. Additionally libpcap could be moved to use PF_PACKET too.
2. Enhance the PDU that contain the current CAN frames to be able to transport
CAN FD frames too. This kind of tunnelling from libpcap to Wireshark is
currently done with the CANFD_USE bit - and that's why this bit must not show
up in the Wiresharks proto bits.
As you can see from our patches option 2 is obviously easy to do.
But is it the right way to go?
You are receiving this mail because:
- You are watching all bug changes.
