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]

Date:   Tue, 25 Jul 2017 14:17:52 +0200
From:   Paolo Abeni <pabeni@...hat.com>
To:     Marc Haber <mh+netdev@...schlus.de>
Cc:     netdev@...r.kernel.org
Subject: Re: After a while of system running no incoming UDP any more?

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.

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

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

/P