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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1397212866.16584.93.camel@edumazet-glaptop2.roam.corp.google.com>
Date:	Fri, 11 Apr 2014 03:41:06 -0700
From:	Eric Dumazet <eric.dumazet@...il.com>
To:	chptx y <chptxy@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: What causes these TCP packet getting lost in linux kernel

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