Comment # 23
on bug 12687
from Oliver Hartkopp
(In reply to Michael Mann from comment #22)
> (In reply to Michael Mann from comment #21)
> > I should have something posted today.
>
> Done.
You patch has at least two issues:
1. The frame_type_vals still contain RTR. Please check my patch to fix this up.
2. Don't know what canfd_actual_length() is for. Wireshark uses libpcap.
libpcap uses PF_CAN raw sockets. PF_CAN raw sockets and CAN network interfaces
provide a plain length value and no data length _code_ (DLC) - so there's no
need to do any DLC-to-length conversion anywhere in userspace (see my provided
PDF slides).
> Only potential outstanding issue is how to handle SLL frames. Since
> CANFD has it's own "type" within SLL, will it still set the "CANFD" flag
> (0x4), or will its dissection need to be tweaked?
I'm not sure about this either.
Picking up the stuff above: Wireshark uses libpcap. libpcap uses PF_CAN raw
sockets. As you can see from the libpcap patch the CAN RAW socket just can
handle both types of CAN frames (CAN / CAN FD). To distinguish CAN and CAN FD
I'm setting the CANFD_USE bit in the provided content which is used by
wireshark.
Alternatively we might split this traffic into two separate paths?!?
Having different SSL definitions was intended for PF_PACKET users to make clear
which kind of frame is provided. But when libpcap is mandatory for Wireshark -
where do you see the SSL types then?
You are receiving this mail because:
- You are watching all bug changes.
