netdev - Re: After a while of system running no incoming UDP any more?

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]

Message-ID: <20170726081047.562anntu5uhwirze@torres.zugschlus.de>
Date:   Wed, 26 Jul 2017 10:10:47 +0200
From:   Marc Haber <mh+netdev@...schlus.de>
To:     Paolo Abeni <pabeni@...hat.com>
Cc:     netdev@...r.kernel.org
Subject: Re: After a while of system running no incoming UDP any more?

On Tue, Jul 25, 2017 at 02:17:52PM +0200, Paolo Abeni wrote:
> On Tue, 2017-07-25 at 13:57 +0200, Marc Haber wrote:
> > On Mon, Jul 24, 2017 at 04:19:10PM +0200, Paolo Abeni wrote:
> > > Once that a system enter the buggy status, do the packets reach the
> > > relevant socket's queue?
> > > 
> > > ss -u
> > 
> > That one only shows table headers on an unaffected system in normal
> > operation, right?
> 
> This one shows the current lenght of the socket receive queue (Recv-Q,
> the first column). If the packets land into the skbuff (and the user
> space reader for some reason is not woken up) such value will grow over
> time.

Only that there is no value:
[4/4992]mh@...vel:~ $ ss -u
Recv-Q Send-Q Local Address:Port                 Peer Address:Port              
[5/4992]mh@...vel:~ $

(is that the intended behavior on a system thiat is not affected by the
issue?)

> > > nstat |grep -e Udp -e Ip
> > > 
> > > will help checking that.
> > 
> > An unaffected system will show UdpInDatagrams, right?
> > 
> > But where is the connection to the relevant socket's queue?
> 
> If the socket queue lenght (as reported above) does not increase,
> IP/UDP stats could give an hint of where and why the packets stop
> traversing the network stack.

We'll see. Still waiting for the phenomenon to show up again.

> Beyond that, you can try using perf probes or kprobe/systemtap to [try
> to] track the relevant packets inside the kernel.

That's way beyond my kernel foo, I'm afraid.

Thanks for helping, I'll report back.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421