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:	Sat, 12 Apr 2014 12:35:00 -0600
From:	Sharat Masetty <sharat04@...il.com>
To:	chptx y <chptxy@...il.com>
Cc:	Eric Dumazet <eric.dumazet@...il.com>,
	Linux Netdev List <netdev@...r.kernel.org>
Subject: Re: What causes these TCP packet getting lost in linux kernel

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@...il.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@...il.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@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
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