Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0
Hello Guy, On 2024-02-13 01:28, Guy Harris wrote: On Feb 12, 2024, at 1:15 PM, Oliver Hartkopp wrote: Excellent! That seems to be the right approach. OK, so: fix libpcap to put the priority/VCID field in big-endian order in CAN XL frames: https://github.com/the-tcpdump-group/libpcap/commit/eb6cfd8feae85b67529bb3c82f6a97bfd98c73f3 in the main branch https://github.com/the-tcpdump-group/libpcap/commit/23904ebe85c4556b77578fd8d61ef82d9bab62b4 in the 1.10 branch change Wireshark to treat that field as big-endian: https://gitlab.com/wireshark/wireshark/-/commit/38a29e82cc96f727aeab7f10e751fa6e8d5e45b6 in the main branch https://gitlab.com/wireshark/wireshark/-/commit/b763663904b6101764c414056b9248803569d6d2 in the 4.2 branch update the LINKTYPE_CAN_SOCKETCAN spec to reflect all that: https://github.com/the-tcpdump-group/tcpdump-htdocs/commit/9c357d9ed6d214bd2fc44850138c2f8861782d88 and it'll show up on the site within 24 hours. I can confirm that all type of CAN frames (CAN CC/FD/XL) are now displayed correctly with the latest Wireshark v4.3.0rc0-1528-g37937ef51444. As expected I just don't see the CAN FD flags due to my current (outdated) Debian libpcap 1.10.4. Great job!! Many thanks and best regards, Oliver ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SocketCAN Support is broken in latest Wireshark-v4.3.0rc0-1430-g600de02805d0
On 2024-02-12 21:53, Guy Harris wrote:
On Feb 12, 2024, at 11:09 AM, Oliver Hartkopp wrote:
On 2024-02-12 18:54, Guy Harris wrote:
Thus, I specified that all multi-byte fields in the CAN XL header, in
LINKTYPE_CAN_SOCKETCAN packets, are little-endian (unlike the header for CAN
classic and CAN FD, in which the CAN ID/flags field is big-endian):
https://www.tcpdump.org/linktypes/LINKTYPE_CAN_SOCKETCAN.html
So the question is whether the first 4 bytes of the CAN XL header are:
a single little-endian field in the form
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
1 0 9 8 6 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
+---+---+-+-+
|Reserved | VCID |Reserved | Priority |
+---+---+-+-+
Yes! This is the correct plan.
But in fact this is a 32 bit value.
Yes, that's exactly what the figure I drew showed it as, and that's what a
single field containing 4 bytes is on any machine likely to run
{Linux,libpcap,Wireshark} would be.
Currently the first 4 bytes in the Wireshark data window (in the bottom right) for
CAN CC & CAN look like this for CAN ID 0123:
00 00 01 23 (which looks like big endian)
That's because, in LINKTYPE_CAN_SOCKETCAN captures, that field, *in CAN classic
and CAN FD captures* is *defined* to be big-endian, and libpcap *explicitly
puts it into big-endian order before handing the packet to the caller*.
And CAN XL with VCID 0xCD and Prio 0x242 looks like this
00 CD 02 42 (which also looks like big endian, right?)
That's because libpcap doesn't currently distinguish between CAN XL and the
other packet types, and thus puts the first 4 bytes of the SocketCAN header
into big-endian byte order.
It doesn't *have* to do that and, in fact, the libpcap code on the tip of the
main and 1.10 branches puts that field into *little-endian* order for CAN XL.
However, if the goal is to allow programs that read LINKtYPE_CAN_SOCKETCAN
captures to be able to handle both captures made with the existing libpcap
*and* with the upcoming libpcap, the right way to handle this would be to have
libpcap put those 4 bytes into *big-endian* byte order and put the *other two*
multi-byte integral-valued fields - the payload length and the acceptance field
- into *little-endian* byte order, as that's the order they'd be in with the
libpcap 1.10.4 code if capturing on a little-endian machine.
I will update the libpcap code to put the first 4-byte field in the CAN XL
header into big-endian order, and update the LINKTYPE_CAN_SOCKETCAN spec to
indicate that it's big-endian (but not that the *other* multi-byte fields are).
Excellent! That seems to be the right approach.
Many thanks!
I've also answered to your summary about the two potential approaches to
integrate the VCID here:
https://lore.kernel.org/linux-can/dec6ca6e-c768-4537-ac56-2cbafac58...@hartkopp.net/
I think this all fits together now with maintaining the existing 32 bit
prio value.
Best regards,
Oliver
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] SCTP association analysis & selection does not work correctly
Hi, I have checked the pull request and saw that it was merged into master one month ago... I shall eventually compile wireshark from master and test it with _very large_ pcaps containing lots of SCTP associations :-) I'll let you know. Thanks a lot, Cristian On Sat, Dec 23, 2023 at 4:45 AM John Thacker wrote: > > On Thu, Dec 7, 2023 at 3:32 AM Cristian Constantin via Wireshark-dev > wrote: >> >> Hi Jeff, >> >> Yes, after enabling the respective protocol decoding option, SCTP >> association analysis works. >> SCTP association analysis is _quite_ slow, though. I'll check why it >> is so slow when I have some spare time. > > > If you have some time, can you see if > https://gitlab.com/wireshark/wireshark/-/merge_requests/13786 > works for you and if it's faster (at least the dissection part, this doesn't > affect the tapping)? It works > on my samples, and it uses hashmaps instead of lists so it should be better > on large files. > > Thanks, > John > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
