netdev - Re: What causes these TCP packet getting lost in linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1397453221.4222.15.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Sun, 13 Apr 2014 22:27:01 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	chptx y <chptxy@...il.com>
Cc:	Sharat Masetty <sharat04@...il.com>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: What causes these TCP packet getting lost in linux kernel

On Mon, 2014-04-14 at 13:02 +0800, chptx y wrote:
> Text exporting from wireshark, is it OK?
> ---------------------------------------------------------------------------------------------------------
> Frame 30: 168 bytes on wire (1344 bits), 168 bytes captured (1344 bits)
> Transmission Control Protocol, Src Port: http (80), Dst Port: 34865
> (34865), Seq: 12517, Ack: 3086, Len: 100
>     Source port: http (80)
>     Destination port: 34865 (34865)
>     [Stream index: 0]
>     Sequence number: 12517    (relative sequence number)
>     [Next sequence number: 12617    (relative sequence number)]
>     Acknowledgement number: 3086    (relative ack number)
>     Header length: 32 bytes
>     Flags: 0x010 (ACK)
>     Window size value: 7541
>     [Calculated window size: 7541]
>     [Window size scaling factor: 1]
>     Checksum: 0x89d8 [correct]
>         [Good Checksum: True]
>         [Bad Checksum: False]
>     Options: (12 bytes)
>     [SEQ/ACK analysis]
>     [Reassembled PDU in frame: 34]
>     TCP segment data (100 bytes)
> 
> Frame 31: 68 bytes on wire (544 bits), 68 bytes captured (544 bits)
> Transmission Control Protocol, Src Port: 34865 (34865), Dst Port: http
> (80), Seq: 3086, Ack: 12617, Len: 0
>     Source port: 34865 (34865)
>     Destination port: http (80)
>     [Stream index: 0]
>     Sequence number: 3086    (relative sequence number)
>     Acknowledgement number: 12617    (relative ack number)
>     Header length: 32 bytes
>     Flags: 0x010 (ACK)
>     Window size value: 5001
>     [Calculated window size: 40008]
>     [Window size scaling factor: 8]
>     Checksum: 0x8213 [incorrect, should be 0x1614 (maybe caused by
> "TCP checksum offload"?)]
>         [Good Checksum: False]
>         [Bad Checksum: True]
>     Options: (12 bytes)
>     [SEQ/ACK analysis]
> 
> Frame 32: 1416 bytes on wire (11328 bits), 1416 bytes captured (11328 bits)
> Transmission Control Protocol, Src Port: http (80), Dst Port: 34865
> (34865), Seq: 12617, Ack: 3086, Len: 1348
>     Source port: http (80)
>     Destination port: 34865 (34865)
>     [Stream index: 0]
>     Sequence number: 12617    (relative sequence number)
>     [Next sequence number: 13965    (relative sequence number)]
>     Acknowledgement number: 3086    (relative ack number)
>     Header length: 32 bytes
>     Flags: 0x010 (ACK)
>     Window size value: 7541
>     [Calculated window size: 7541]
>     [Window size scaling factor: 1]
>     Checksum: 0x4139 [correct]
>         [Good Checksum: True]
>         [Bad Checksum: False]
>     Options: (12 bytes)
>     [SEQ/ACK analysis]
>     [Reassembled PDU in frame: 34]
>     TCP segment data (1348 bytes)

Hard to say. We do not see the content of the TCP options. You might
receive invalid timestamps.

tcpdump -vv would tell us the needed information, with minimal
verbosity.



--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html