* 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.