X11 negotiates the byte order at startup time DCE RPC/MS-RPC puts an indication of the byte order into the packet header. However, fields in SMB packets are little-endian, regardless of whether the machine that wrote the capture was little-endian or big-endian.Īnd 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. The packet data is a raw array of bytes, exactly as they were transmitted on the network.įor 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. Is it correct that captured packet headers are written in the byte order of the host that wrote the file? 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. 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. However, SMB, the IBM/Intel/Microsoft file sharing protocol, originally ran directly on top of LAN protocols. IPv4, IPv6, and UDP are other protocols that do.
big-endian byte order, for multi-byte integral values. TCP is a protocol that uses "network byte order", i.e. "Network byte order" means big-endian, so it's big-endian everywhere.Ĭonfusingly, it does not mean "the byte order for all fields in network traffic", so not all network traffic uses big-endian byte order.
0 kommentar(er)
