netdev - Re: [Bugme-new] [Bug 12327] New: Intermittent TCP issues with => 2.6.27

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: <Pine.LNX.4.64.0901081510360.1889@wrl-59.cs.helsinki.fi>
Date:	Thu, 8 Jan 2009 15:13:24 +0200 (EET)
From:	"Ilpo Järvinen" <ilpo.jarvinen@...sinki.fi>
To:	Herbert Xu <herbert@...dor.apana.org.au>
cc:	Speedster <speedster@...eacry.com>,
	Netdev <netdev@...r.kernel.org>,
	bugme-daemon@...zilla.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [Bugme-new] [Bug 12327] New: Intermittent TCP issues with =>
 2.6.27

On Thu, 8 Jan 2009, Herbert Xu wrote:

> On Wed, Jan 07, 2009 at 10:49:55PM +0900, Speedster wrote:
> >
> > Done. I also realised my wireshark display filter was dst_host rather  
> > than simply host - it looks as though replies _do_ come back but for  
> > some reason are ignored? My apologies.
> 
> Great I think we're getting closer.  With your latest dumps it'd
> appear that there is an odd difference between the replies that
> get through and the ones that don't.  The ones that're somehow
> dropped have 2 bytes of transport padding at the end.  I suspect
> there's something buggy in your system that's dropping it because
> of this.
> 
> Can you please take a look at /proc/net/snmp on the host and the
> guest to see if IP InDiscards is non-zero?
> 
> Also now that we know the problem is definitely in the host/guest
> please take another set of dumps on the interfaces leading to and
> within the guest to see exactly which path of the system is dropping
> the reply.

Another possiblity that comes into my mind is that at TCP side seqnos get 
messed up because of skb->len getting that padding counted in (end_seq 
is depending on skb->len) and something don't like encountering such 
a synack.


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