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@swivel:~ $ ss -u Recv-Q Send-Q Local Address:Port Peer Address:Port [5/4992]mh@swivel:~ $ (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
