1 | initial version |
The TCP Flags is a Unicode string, and rather than being shown as "TCP Flags: \xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7A\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7"
, it should be displayed as: "TCP Flags: ·······A····"
. This just means that the ACK bit, and only the ACK bit, is set in the TCP flags field.
2 | No.2 Revision |
The TCP Flags is a Unicode string, and rather than being shown as "TCP Flags: \xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7A\xc2\xb7\xc2\xb7\xc2\xb7\xc2\xb7"
, it should be displayed as: "TCP Flags: ·······A····"
. This just means that the ACK bit, and only the ACK bit, is set in the TCP flags field.
By the way, the value="5010"
also tells you this same information; however, it's showing you not only the TCP flags, but also the header length (in number of 32-bit words). If you rewrite the value in binary, you get:
5 010
101 000000010000
... so 5 is the header length in 32-bit words, in other words 20 bytes, and the remaining data represents the TCP flags, all of which are 0 except for the ACK bit.
See RFC 793 for a better diagram of these fields (although note that more flags were defined in subsequent RFC's, so RFC 793 doesn't depict all of them.)