* What causes these TCP packet getting lost in linux kernel
@ 2014-04-11 7:19 chptx y
2014-04-11 10:41 ` Eric Dumazet
0 siblings, 1 reply; 13+ messages in thread
From: chptx y @ 2014-04-11 7:19 UTC (permalink / raw)
To: netdev
Hi,
I captured these packets with tcpdump on Android device(linux 3.4.39),
these packets are in a HTTP GET Stream:
1 385.447794 Server -> Client: SEQ 12517, LEN 100
2 385.498345 Client -> Server: SEQ 3086, LEN 0, ACK 12617
3 385.497836 Server -> Client: SEQ 12617, LEN 1348
4 385.498644 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617
5 385.498735 Server -> Client: SEQ 13965, LEN 619
6 385.498978 Client -> Server: [Dup ACK] SEQ 3086, LEN 0, ACK 12617
7 385.718843 Server -> Client: [Retrans] SEQ 13965, LEN 619
8 385.719280 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617
9 385.733230 Server -> Client: [Retrans] SEQ 12617, LEN 1348
10 385.733602 Client -> Server: SEQ 3086, LEN 0, ACK 14584
11 385.909921 Server -> Client: [Retrans] SEQ 12617, LEN 1348
12 385.910449 Client -> Server: [DUP ACK][Window Upd.] SEQ 3086, LEN
0, ACK 14584
13 388.031541 Client -> Server: SEQ 832, LEN 0, ACK 4192, FIN
14 388.031681 Client -> Server: SEQ 3086, LEN 0, ACK 14584, FIN
Client is my device run tcpdump on.
packet #3 (SEQ 12617) has been captured yet, Is there any problem in
kernel causes this packet getting lost in upper layer? why does kernel
send packet #4 (DUP ACK) repeatedly?
Thanks.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-11 7:19 What causes these TCP packet getting lost in linux kernel chptx y
@ 2014-04-11 10:41 ` Eric Dumazet
2014-04-12 3:06 ` chptx y
0 siblings, 1 reply; 13+ messages in thread
From: Eric Dumazet @ 2014-04-11 10:41 UTC (permalink / raw)
To: chptx y; +Cc: netdev
On Fri, 2014-04-11 at 15:19 +0800, chptx y wrote:
> Hi,
>
> I captured these packets with tcpdump on Android device(linux 3.4.39),
> these packets are in a HTTP GET Stream:
>
> 1 385.447794 Server -> Client: SEQ 12517, LEN 100
> 2 385.498345 Client -> Server: SEQ 3086, LEN 0, ACK 12617
> 3 385.497836 Server -> Client: SEQ 12617, LEN 1348
> 4 385.498644 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617
> 5 385.498735 Server -> Client: SEQ 13965, LEN 619
> 6 385.498978 Client -> Server: [Dup ACK] SEQ 3086, LEN 0, ACK 12617
> 7 385.718843 Server -> Client: [Retrans] SEQ 13965, LEN 619
> 8 385.719280 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617
> 9 385.733230 Server -> Client: [Retrans] SEQ 12617, LEN 1348
> 10 385.733602 Client -> Server: SEQ 3086, LEN 0, ACK 14584
> 11 385.909921 Server -> Client: [Retrans] SEQ 12617, LEN 1348
> 12 385.910449 Client -> Server: [DUP ACK][Window Upd.] SEQ 3086, LEN
> 0, ACK 14584
> 13 388.031541 Client -> Server: SEQ 832, LEN 0, ACK 4192, FIN
> 14 388.031681 Client -> Server: SEQ 3086, LEN 0, ACK 14584, FIN
>
> Client is my device run tcpdump on.
>
> packet #3 (SEQ 12617) has been captured yet, Is there any problem in
> kernel causes this packet getting lost in upper layer? why does kernel
> send packet #4 (DUP ACK) repeatedly?
Frame could be rejected because of a checksum error
tcpdump -vv (On the android device)
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-11 10:41 ` Eric Dumazet
@ 2014-04-12 3:06 ` chptx y
2014-04-12 18:35 ` Sharat Masetty
0 siblings, 1 reply; 13+ messages in thread
From: chptx y @ 2014-04-12 3:06 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
Thanks, Wireshark shows tcp checksum of this packet is correct, Any reason else?
2014-04-11 18:41 GMT+08:00 Eric Dumazet <eric.dumazet@gmail.com>:
> On Fri, 2014-04-11 at 15:19 +0800, chptx y wrote:
>> Hi,
>>
>> I captured these packets with tcpdump on Android device(linux 3.4.39),
>> these packets are in a HTTP GET Stream:
>>
>> 1 385.447794 Server -> Client: SEQ 12517, LEN 100
>> 2 385.498345 Client -> Server: SEQ 3086, LEN 0, ACK 12617
>> 3 385.497836 Server -> Client: SEQ 12617, LEN 1348
>> 4 385.498644 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617
>> 5 385.498735 Server -> Client: SEQ 13965, LEN 619
>> 6 385.498978 Client -> Server: [Dup ACK] SEQ 3086, LEN 0, ACK 12617
>> 7 385.718843 Server -> Client: [Retrans] SEQ 13965, LEN 619
>> 8 385.719280 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617
>> 9 385.733230 Server -> Client: [Retrans] SEQ 12617, LEN 1348
>> 10 385.733602 Client -> Server: SEQ 3086, LEN 0, ACK 14584
>> 11 385.909921 Server -> Client: [Retrans] SEQ 12617, LEN 1348
>> 12 385.910449 Client -> Server: [DUP ACK][Window Upd.] SEQ 3086, LEN
>> 0, ACK 14584
>> 13 388.031541 Client -> Server: SEQ 832, LEN 0, ACK 4192, FIN
>> 14 388.031681 Client -> Server: SEQ 3086, LEN 0, ACK 14584, FIN
>>
>> Client is my device run tcpdump on.
>>
>> packet #3 (SEQ 12617) has been captured yet, Is there any problem in
>> kernel causes this packet getting lost in upper layer? why does kernel
>> send packet #4 (DUP ACK) repeatedly?
>
> Frame could be rejected because of a checksum error
>
> tcpdump -vv (On the android device)
>
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-12 3:06 ` chptx y
@ 2014-04-12 18:35 ` Sharat Masetty
2014-04-12 19:32 ` Eric Dumazet
0 siblings, 1 reply; 13+ messages in thread
From: Sharat Masetty @ 2014-04-12 18:35 UTC (permalink / raw)
To: chptx y; +Cc: Eric Dumazet, Linux Netdev List
Check /proc/net/netstat and /proc/net/snmp
In netstat look for
LINUX_MIB_TCPOFODROP and LINUX_MIB_BACKLOGDROP
On Fri, Apr 11, 2014 at 9:06 PM, chptx y <chptxy@gmail.com> wrote:
> Thanks, Wireshark shows tcp checksum of this packet is correct, Any reason else?
>
> 2014-04-11 18:41 GMT+08:00 Eric Dumazet <eric.dumazet@gmail.com>:
>> On Fri, 2014-04-11 at 15:19 +0800, chptx y wrote:
>>> Hi,
>>>
>>> I captured these packets with tcpdump on Android device(linux 3.4.39),
>>> these packets are in a HTTP GET Stream:
>>>
>>> 1 385.447794 Server -> Client: SEQ 12517, LEN 100
>>> 2 385.498345 Client -> Server: SEQ 3086, LEN 0, ACK 12617
>>> 3 385.497836 Server -> Client: SEQ 12617, LEN 1348
>>> 4 385.498644 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617
>>> 5 385.498735 Server -> Client: SEQ 13965, LEN 619
>>> 6 385.498978 Client -> Server: [Dup ACK] SEQ 3086, LEN 0, ACK 12617
>>> 7 385.718843 Server -> Client: [Retrans] SEQ 13965, LEN 619
>>> 8 385.719280 Client -> Server: [DUP ACK] SEQ 3086, LEN 0, ACK 12617
>>> 9 385.733230 Server -> Client: [Retrans] SEQ 12617, LEN 1348
>>> 10 385.733602 Client -> Server: SEQ 3086, LEN 0, ACK 14584
>>> 11 385.909921 Server -> Client: [Retrans] SEQ 12617, LEN 1348
>>> 12 385.910449 Client -> Server: [DUP ACK][Window Upd.] SEQ 3086, LEN
>>> 0, ACK 14584
>>> 13 388.031541 Client -> Server: SEQ 832, LEN 0, ACK 4192, FIN
>>> 14 388.031681 Client -> Server: SEQ 3086, LEN 0, ACK 14584, FIN
>>>
>>> Client is my device run tcpdump on.
>>>
>>> packet #3 (SEQ 12617) has been captured yet, Is there any problem in
>>> kernel causes this packet getting lost in upper layer? why does kernel
>>> send packet #4 (DUP ACK) repeatedly?
>>
>> Frame could be rejected because of a checksum error
>>
>> tcpdump -vv (On the android device)
>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-12 18:35 ` Sharat Masetty
@ 2014-04-12 19:32 ` Eric Dumazet
2014-04-14 5:02 ` chptx y
0 siblings, 1 reply; 13+ messages in thread
From: Eric Dumazet @ 2014-04-12 19:32 UTC (permalink / raw)
To: Sharat Masetty; +Cc: chptx y, Linux Netdev List
On Sat, 2014-04-12 at 12:35 -0600, Sharat Masetty wrote:
> Check /proc/net/netstat and /proc/net/snmp
>
> In netstat look for
>
> LINUX_MIB_TCPOFODROP and LINUX_MIB_BACKLOGDROP
The packet is not out of order, according to tcpdump.
Note that the receiver reacts to incoming packet, sending a DUPACK, so
its not a backlogdrop.
tcpdump trace is really incomplete, I asked tcpdump -vv but got nothing
from chptx, assuming this is a real name.
packet might be rejected because of a zero receiver window, who knows.
I might search in my basement this crystal ball I might have.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-12 19:32 ` Eric Dumazet
@ 2014-04-14 5:02 ` chptx y
2014-04-14 5:27 ` Eric Dumazet
2014-04-14 8:39 ` David Newall
0 siblings, 2 replies; 13+ messages in thread
From: chptx y @ 2014-04-14 5:02 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sharat Masetty, Linux Netdev List
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)
Frame 33: 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 34: 687 bytes on wire (5496 bits), 687 bytes captured (5496 bits)
Transmission Control Protocol, Src Port: http (80), Dst Port: 34865
(34865), Seq: 13965, Ack: 3086, Len: 619
Source port: http (80)
Destination port: 34865 (34865)
[Stream index: 0]
Sequence number: 13965 (relative sequence number)
[Next sequence number: 14584 (relative sequence number)]
Acknowledgement number: 3086 (relative ack number)
Header length: 32 bytes
Flags: 0x018 (PSH, ACK)
Window size value: 7541
[Calculated window size: 7541]
[Window size scaling factor: 1]
Checksum: 0xf362 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Options: (12 bytes)
[SEQ/ACK analysis]
TCP segment data (619 bytes)
[7 Reassembled TCP Segments (3415 bytes): #28(1348), #30(100),
#32(1348), #38(1348), #40(1348), #34(619), #36(619)]
Hypertext Transfer Protocol
Line-based text data: text/plain
Frame 35: 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 36: 687 bytes on wire (5496 bits), 687 bytes captured (5496 bits)
Transmission Control Protocol, Src Port: http (80), Dst Port: 34865
(34865), Seq: 13965, Ack: 3086, Len: 619
Source port: http (80)
Destination port: 34865 (34865)
[Stream index: 0]
Sequence number: 13965 (relative sequence number)
[Next sequence number: 14584 (relative sequence number)]
Acknowledgement number: 3086 (relative ack number)
Header length: 32 bytes
Flags: 0x018 (PSH, ACK)
Window size value: 7541
[Calculated window size: 7541]
[Window size scaling factor: 1]
Checksum: 0xeb4e [correct]
[Good Checksum: True]
[Bad Checksum: False]
Options: (12 bytes)
[SEQ/ACK analysis]
[Reassembled PDU in frame: 34]
TCP segment data (619 bytes)
Frame 37: 80 bytes on wire (640 bits), 80 bytes captured (640 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: 44 bytes
Flags: 0x010 (ACK)
Window size value: 5001
[Calculated window size: 40008]
[Window size scaling factor: 8]
Checksum: 0x821f [incorrect, should be 0xec6d (maybe caused by
"TCP checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
Options: (24 bytes)
[SEQ/ACK analysis]
Frame 38: 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: 0x3925 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Options: (12 bytes)
[SEQ/ACK analysis]
[Reassembled PDU in frame: 34]
TCP segment data (1348 bytes)
Frame 39: 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: 14584, Len: 0
Source port: 34865 (34865)
Destination port: http (80)
[Stream index: 0]
Sequence number: 3086 (relative sequence number)
Acknowledgement number: 14584 (relative ack number)
Header length: 32 bytes
Flags: 0x010 (ACK)
Window size value: 5246
[Calculated window size: 41968]
[Window size scaling factor: 8]
Checksum: 0x8213 [incorrect, should be 0x0ba3 (maybe caused by
"TCP checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
Options: (12 bytes)
[SEQ/ACK analysis]
Frame 40: 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: 0x3844 [correct]
[Good Checksum: True]
[Bad Checksum: False]
Options: (12 bytes)
[SEQ/ACK analysis]
[Reassembled PDU in frame: 34]
TCP segment data (1348 bytes)
Frame 41: 80 bytes on wire (640 bits), 80 bytes captured (640 bits)
Transmission Control Protocol, Src Port: 34865 (34865), Dst Port: http
(80), Seq: 3086, Ack: 14584, Len: 0
Source port: 34865 (34865)
Destination port: http (80)
[Stream index: 0]
Sequence number: 3086 (relative sequence number)
Acknowledgement number: 14584 (relative ack number)
Header length: 44 bytes
Flags: 0x010 (ACK)
Window size value: 5293
[Calculated window size: 42344]
[Window size scaling factor: 8]
Checksum: 0x821f [incorrect, should be 0xe985 (maybe caused by
"TCP checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
Options: (24 bytes)
[SEQ/ACK analysis]
Frame 42: 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: 14584, Len: 0
Source port: 34865 (34865)
Destination port: http (80)
[Stream index: 0]
Sequence number: 3086 (relative sequence number)
Acknowledgement number: 14584 (relative ack number)
Header length: 32 bytes
Flags: 0x011 (FIN, ACK)
Window size value: 5293
[Calculated window size: 42344]
[Window size scaling factor: 8]
Checksum: 0x8213 [incorrect, should be 0x09a7 (maybe caused by
"TCP checksum offload"?)]
[Good Checksum: False]
[Bad Checksum: True]
Options: (12 bytes)
2014-04-13 3:32 GMT+08:00 Eric Dumazet <eric.dumazet@gmail.com>:
> On Sat, 2014-04-12 at 12:35 -0600, Sharat Masetty wrote:
>> Check /proc/net/netstat and /proc/net/snmp
>>
>> In netstat look for
>>
>> LINUX_MIB_TCPOFODROP and LINUX_MIB_BACKLOGDROP
>
> The packet is not out of order, according to tcpdump.
>
> Note that the receiver reacts to incoming packet, sending a DUPACK, so
> its not a backlogdrop.
>
> tcpdump trace is really incomplete, I asked tcpdump -vv but got nothing
> from chptx, assuming this is a real name.
>
> packet might be rejected because of a zero receiver window, who knows.
>
> I might search in my basement this crystal ball I might have.
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-14 5:02 ` chptx y
@ 2014-04-14 5:27 ` Eric Dumazet
2014-04-14 6:00 ` chptx y
2014-04-14 8:39 ` David Newall
1 sibling, 1 reply; 13+ messages in thread
From: Eric Dumazet @ 2014-04-14 5:27 UTC (permalink / raw)
To: chptx y; +Cc: Sharat Masetty, Linux Netdev List
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-14 5:27 ` Eric Dumazet
@ 2014-04-14 6:00 ` chptx y
0 siblings, 0 replies; 13+ messages in thread
From: chptx y @ 2014-04-14 6:00 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Sharat Masetty, Linux Netdev List
[-- Attachment #1: Type: text/plain, Size: 3077 bytes --]
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@gmail.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.
>
>
>
[-- Attachment #2: tcpdump.pcap --]
[-- Type: application/vnd.tcpdump.pcap, Size: 25191 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-14 5:02 ` chptx y
2014-04-14 5:27 ` Eric Dumazet
@ 2014-04-14 8:39 ` David Newall
2014-04-14 9:20 ` chptx y
1 sibling, 1 reply; 13+ messages in thread
From: David Newall @ 2014-04-14 8:39 UTC (permalink / raw)
To: chptx y; +Cc: Linux Netdev List
It's interesting that all of the packets from source port 34865 to
destination port 80 have invalid checksums. The hint, that it could be
a TCP offload engine, doesn't sound entirely believable because some
value is being calculated and stored, not just a fixed or random value;
and as the destination is port 80, I'm guessing that these the packets
from your Android device, which probably doesn't have a TCP offload engine.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-14 8:39 ` David Newall
@ 2014-04-14 9:20 ` chptx y
2014-04-14 14:13 ` Eric Dumazet
0 siblings, 1 reply; 13+ messages in thread
From: chptx y @ 2014-04-14 9:20 UTC (permalink / raw)
To: David Newall; +Cc: Linux Netdev List
i don't know why, no matter I capture packets on my Ubuntu PC or
Android device with tcpdump, open the output file with wireshark, all
output packets are marked with "incorrect checksum", but it seems that
this problem don't affect subsequent packets interaction. why?
2014-04-14 16:39 GMT+08:00 David Newall <davidn@davidnewall.com>:
> It's interesting that all of the packets from source port 34865 to
> destination port 80 have invalid checksums. The hint, that it could be a
> TCP offload engine, doesn't sound entirely believable because some value is
> being calculated and stored, not just a fixed or random value; and as the
> destination is port 80, I'm guessing that these the packets from your
> Android device, which probably doesn't have a TCP offload engine.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-14 9:20 ` chptx y
@ 2014-04-14 14:13 ` Eric Dumazet
2014-04-14 17:58 ` Sharat Masetty
0 siblings, 1 reply; 13+ messages in thread
From: Eric Dumazet @ 2014-04-14 14:13 UTC (permalink / raw)
To: chptx y; +Cc: David Newall, Linux Netdev List
On Mon, 2014-04-14 at 17:20 +0800, chptx y wrote:
> i don't know why, no matter I capture packets on my Ubuntu PC or
> Android device with tcpdump, open the output file with wireshark, all
> output packets are marked with "incorrect checksum", but it seems that
> this problem don't affect subsequent packets interaction. why?
Checksums are filled by the NIC on TX packets, some tcpdump/wireshark
versions do not really know of this.
packet 30 (which is accepted) has TSval=4054079470 & TSecr=22894,
but packet 32 has TSval=4054078149 & TSecr=22863, while its sequence is
correct (coming after the prior packet)
Sender has a wrong implementation of TCP Timestamps (RFC 1323), or a
middlebox mangles timestamps badly.
Receiver considers this as an old packet.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-14 14:13 ` Eric Dumazet
@ 2014-04-14 17:58 ` Sharat Masetty
2014-04-14 18:32 ` Eric Dumazet
0 siblings, 1 reply; 13+ messages in thread
From: Sharat Masetty @ 2014-04-14 17:58 UTC (permalink / raw)
To: Eric Dumazet; +Cc: chptx y, David Newall, Linux Netdev List
Thats a good find.. Is this drop count documented in netstat stats?
Thanks
Sharat
On Mon, Apr 14, 2014 at 8:13 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Mon, 2014-04-14 at 17:20 +0800, chptx y wrote:
>> i don't know why, no matter I capture packets on my Ubuntu PC or
>> Android device with tcpdump, open the output file with wireshark, all
>> output packets are marked with "incorrect checksum", but it seems that
>> this problem don't affect subsequent packets interaction. why?
>
> Checksums are filled by the NIC on TX packets, some tcpdump/wireshark
> versions do not really know of this.
>
> packet 30 (which is accepted) has TSval=4054079470 & TSecr=22894,
> but packet 32 has TSval=4054078149 & TSecr=22863, while its sequence is
> correct (coming after the prior packet)
>
> Sender has a wrong implementation of TCP Timestamps (RFC 1323), or a
> middlebox mangles timestamps badly.
>
> Receiver considers this as an old packet.
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: What causes these TCP packet getting lost in linux kernel
2014-04-14 17:58 ` Sharat Masetty
@ 2014-04-14 18:32 ` Eric Dumazet
0 siblings, 0 replies; 13+ messages in thread
From: Eric Dumazet @ 2014-04-14 18:32 UTC (permalink / raw)
To: Sharat Masetty; +Cc: chptx y, David Newall, Linux Netdev List
On Mon, 2014-04-14 at 11:58 -0600, Sharat Masetty wrote:
> Thats a good find.. Is this drop count documented in netstat stats?
Sure : LINUX_MIB_PAWSESTABREJECTED
nstat -a | grep PAWSEstab
>
> On Mon, Apr 14, 2014 at 8:13 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> > On Mon, 2014-04-14 at 17:20 +0800, chptx y wrote:
> >> i don't know why, no matter I capture packets on my Ubuntu PC or
> >> Android device with tcpdump, open the output file with wireshark, all
> >> output packets are marked with "incorrect checksum", but it seems that
> >> this problem don't affect subsequent packets interaction. why?
> >
> > Checksums are filled by the NIC on TX packets, some tcpdump/wireshark
> > versions do not really know of this.
> >
> > packet 30 (which is accepted) has TSval=4054079470 & TSecr=22894,
> > but packet 32 has TSval=4054078149 & TSecr=22863, while its sequence is
> > correct (coming after the prior packet)
> >
> > Sender has a wrong implementation of TCP Timestamps (RFC 1323), or a
> > middlebox mangles timestamps badly.
> >
> > Receiver considers this as an old packet.
> >\
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-04-15 4:20 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-04-11 7:19 What causes these TCP packet getting lost in linux kernel chptx y
2014-04-11 10:41 ` Eric Dumazet
2014-04-12 3:06 ` chptx y
2014-04-12 18:35 ` Sharat Masetty
2014-04-12 19:32 ` Eric Dumazet
2014-04-14 5:02 ` chptx y
2014-04-14 5:27 ` Eric Dumazet
2014-04-14 6:00 ` chptx y
2014-04-14 8:39 ` David Newall
2014-04-14 9:20 ` chptx y
2014-04-14 14:13 ` Eric Dumazet
2014-04-14 17:58 ` Sharat Masetty
2014-04-14 18:32 ` Eric Dumazet
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.