pcap: Add appropriate endianness conversions for USB pcap header #234
Conversation
The USB pcap header should always be little endian. As such, add the appropriate conversions where necessary to ensure that the data is interpreted correctly on big endian architectures.
|
Hmm, that amd64 ubuntu:devel failure does not look like a regression from this patch (failing after |
|
Uh, did the test previously pass on s390x? I am a bit confused that the urb is not reaped in https://download.copr.fedorainfracloud.org/results/packit/martinpitt-umockdev-234/fedora-rawhide-s390x/07099222-umockdev/builder-live.log.gz :-) But, I think I would need to debug on an s390x machine. Just staring at the code I don't see anything wrong. |
|
|
||
| for (; cur_buf != null; cur_buf = rec.next(ref cur_hdr), cur_waiting_since = now) { | ||
| assert(cur_hdr.caplen >= 64); | ||
|
|
There was a problem hiding this comment.
Hm, there is the assert(cur_hdr.caplen). I guess that also needs a uint32.from_little_endian, but I am not entirely sure right now. It isn't going to cause issues though and we just rely on the USB header later on anyway.
I haven't seen it fail recently, but I retried and it passed.
Yes, it did. Everything has been green for a while except for nix, and that got fixed this morning. So this is definitively a regression. Note that s390x is big-endian (for that very reason I want it in PR tests). |
That is … odd. It must be pure luck that it is working, but no idea right now how that could happen (possibly because those are mostly control transfers). Anyway, later. |
2 participants
The USB pcap header should always be little endian. As such, add the appropriate conversions where necessary to ensure that the data is interpreted correctly on big endian architectures.
Maybe this fixes the sparc SIGBUS problem