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 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 11:06:51 +0800
From:	chptx y <chptxy@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: What causes these TCP packet getting lost in linux kernel

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