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]

Date:	Mon, 14 Apr 2014 14:00:16 +0800
From:	chptx y <chptxy@...il.com>
To:	Eric Dumazet <eric.dumazet@...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

sorry, I dont know how to export options to text, Attachment is full
content of the capture.

2014-04-14 13:27 GMT+08:00 Eric Dumazet <eric.dumazet@...il.com>:
> 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.
>
>
>

Download attachment "tcpdump.pcap" of type "application/vnd.tcpdump.pcap" (25191 bytes)