使用 tun/tap 接口的错误序列号

Question

I'm trying to read TCP packets into a struct using tun/tap, So IFF_TUN flag is set to use tun device (no ethernet headers).

I have structs like these (I don't care about endian issues):

Tcp Header:

struct tcphdr {
  uint16_t sport;
  uint16_t dport;
  uint32_t seq;
  uint32_t ack_seq;
  uint8_t rsvd : 4;
  uint8_t dataoff : 4;
  uint8_t fin : 1,
          syn : 1,
          rst : 1,
          psh : 1,
          ack : 1,
          urg : 1,
          ece : 1,
          cwr : 1;
  uint16_t win;
  uint16_t csum;
  uint16_t urp;
} __attribute__((packed));

Ipv4 Header:

struct ipv4hdr {
  uint8_t ihl : 4;
  uint8_t version : 4;
  uint8_t tos;
  uint16_t len;
  uint16_t id;
  uint16_t frag_offset;
  uint8_t ttl;
  uint8_t proto;
  uint16_t csum;
  uint32_t saddr;
  uint32_t daddr;
} __attribute__((packed));

and read packets like this:

size_t nbytes = read(fd, bytes, 1504); // fd is eg. fd = open("/dev/net/tun", O_RDWR)

uint16_t eth_flags = bytes[0] << 8 | bytes[1]; // big-endian
uint16_t eth_proto = bytes[2] << 8 | bytes[3]; // big-endian

if (eth_proto != 0x800)
  // ignore no ipv4 packets
  // https://en.wikipedia.org/wiki/EtherType
  continue;

if (ip_hdr->proto != 0x06)
  // ignore non-TCP packets
  // https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers
  continue;

and so far, so good. but when i try to read the TCP sequece number i get wrong number:

ipv4hdr *ip_hdr = (ipv4hdr *)(bytes + 4); // 4 first bytes are packet information provided by kernel
tcphdr *tcp_hdr = (tcphdr *)(bytes + 4 + ip_hdr->ihl * 4); // reading TCP at the end of the IP header
std::cout << std::hex << ntohl(tcp_hdr->seq) << std::endl; // the output number is wrong!

tshark output shows seq=0 (like below):

Capturing on 'tun0'
    1 0.000000000  192.168.0.1 → 192.168.0.2  TCP 60 44248 → 8000 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=1233752815 TSecr=0 WS=128

but my code output is 7be53b39

Answer 1

After some search i found the solution.

refer to wireshark wiki :

By default Wireshark and TShark will keep track of all TCP sessions and convert all Sequence Numbers (SEQ numbers) and Acknowledge Numbers (ACK Numbers) into relative numbers. This means that instead of displaying the real/absolute SEQ and ACK numbers in the display, Wireshark will display a SEQ and ACK number relative to the first seen segment for that conversation.

all sequence numbers always start at 0 for the first packet seen in each conversation, so my output wasn't wrong:)