Hello,
Is there option to dissector know byte order of... "interface"? I am
thinking about:
1) PCAP File
2) PCAPNG file
3) live capturing
Please look at packet-usb.c.
There is:
-----------------------
/* Adds the Linux USB pseudo header fields to the tree.
* NOTE: The multi-byte fields in this header, and the pseudo-header
* extension, are in host-endian format so we can't
* use proto_tree_add_item() nor the tvb_get_xyz() routines and is
* the reason for the tvb_memcpy() and proto_tree_add_uint[64]()
* pairs below. */
static void
dissect_linux_usb_pseudo_header(tvbuff_t *tvb, packet_info *pinfo,
proto_tree *tree,
guint *bus_id, guint *device_address)
{
...
tvb_memcpy(tvb, (guint8 *)&val64, 0, 8);
proto_tree_add_uint64(tree, hf_usb_urb_id, tvb, 0, 8, val64);
...
}
-----------------------
And: http://www.tcpdump.org/linktypes.html
-----------------------
LINKTYPE_USB_LINUX_MMAPPED 220 DLT_USB_LINUX_MMAPPED
USB packets, beginning with a Linux USB header, as specified by the
struct usbmon_packet in the Documentation/usb/usbmon.txt file in the
Linux source tree. All 64 bytes of the header are present. All fields
in the header are in the host byte order for the pcap file, as
specified by the file's magic number, or for the section of the
pcap-ng file, as specified by the Section Header Block. For
isochronous transfers, the ndesc field specifies the number of
isochronous descriptors that follow.
-----------------------
> "All fields in the header are in the host byte order for the pcap file"
This USB header is in host order of capture's program. So when you
capturing on Big-endian machine and open capture file on Little-endian
machine this USB code should fail.
Probably PCAP/PCAPNG have ordering info by magic bytes, but I do not
know how to do that while live capturing (current code work for this
case)
Possible solutions:
1. Wireshark already support byte-ordering information for dissectors
(anyone seen, anyone knows?)
2. Drop LINKTYPE_USB*s (LINKTYPE_NULL?) and request for replacement
with specified byte order (network order?) - this does not solve
backward compatibility with already existing captures...
3. Wireshark already use magic and bytes are all the time in right
order (host order)
--
Pozdrawiam / Best regards
-------------------------------------------------------------------------------------------------------------
Michał Łabędzki, Software Engineer
Tieto Corporation
Product Development Services
http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk next to 5.08)
---
Please note: The information contained in this message may be legally
privileged and confidential and protected from disclosure. If the
reader of this message is not the intended recipient, you are hereby
notified that any unauthorised use, distribution or copying of this
communication is strictly prohibited. If you have received this
communication in error, please notify us immediately by replying to
the message and deleting it from your computer. Thank You.
---
Please consider the environment before printing this e-mail.
---
Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem 0000124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500 PLN
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
