 | 1 | initial version |
network byte order is big-endian for TCP
"Network byte order" means big-endian, so it's big-endian everywhere.
Confusingly, it does not mean "the byte order for all fields in network traffic", so not all network traffic uses big-endian byte order.
TCP is a protocol that uses "network byte order", i.e. big-endian byte order, for multi-byte integral values. IPv4, IPv6, and UDP are other protocols that do.
However, SMB, the IBM/Intel/Microsoft file sharing protocol, originally ran directly on top of LAN protocols. It was mainly for IBM-compatible PCs, which have x86 processors, and those processors are little-endian, so multi-byte integral values in SMB packets are little-endian.
SMB can also run over TCP (and UDP), so that's a protocol using little-endian byte order running on top of protocols using big-endian byte order.
Is it correct that captured packet headers are written in the byte order of the host that wrote the file?
No. The packet data is a raw array of bytes, exactly as they were transmitted on the network.
For example, the Ethernet type field (the "08 00" field you've put in red) and the TCP port number field are always in big-endian order in packets, regardless of whether the machine that wrote the capture was little-endian or big-endian.
However, fields in SMB packets are little-endian, regardless of whether the machine that wrote the capture was little-endian or big-endian.
And there are some protocols - for example, the X11 display protocol and the DCE RPC/MS-RPC protocols - that can use either byte order; the byte order of the machine sending the packet is used. X11 negotiates the byte order at startup time; DCE RPC/MS-RPC puts an indication of the byte order into the packet header. However, "network byte order is big-endian for TCP" means that "multi-byte integral values in TCP headers are big-endian", and "This is a protocol-level property." means it's true of TCP but is not necessarily true of other protocols - including protocols running on top of TCP!
is it possible that, while a protocol-level property of TCP is big-endian, there is no guarantee that a packet that I inspect on Wireshark will have TCP headers that are written in big-endian?
No, it is not; there is such a guarantee (if it's not big-endian, it's not valid TCP).
However, there's no guarantee that fields in the protocol running on top of TCP are big-endian; if it's SMB-over-TCP, for example, the fields in the SMB packet will be little-endian, as per the above.
And the CME Group's iLink 3 Binary Order Entry protocol's Simple Binary Encoding encodes the Simple Open Framing Header in little-endian.
(It's "CME", all caps, which used to stand for Chicago Mercantile Exchange, which is one of the financial exchanges they run.)
So your packet has some big-endian fields and some little-endian fields in it.
(If anyone's curious, the dissectors being used there are probably the Lua dissectors from the Open Market Initiative.
