linux-kernel - Re: [PATCH v2 net-next 0/2] net: snmp: tracepoint support for snmp

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] [day] [month] [year] [list]

Date:   Wed, 24 Nov 2021 10:56:16 +0800
From:   Menglong Dong <menglong8.dong@...il.com>
To:     David Ahern <dsahern@...il.com>
Cc:     Steven Rostedt <rostedt@...dmis.org>,
        Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>, mingo@...hat.com,
        Hideaki YOSHIFUJI <yoshfuji@...ux-ipv6.org>,
        dsahern@...nel.org, Menglong Dong <imagedong@...cent.com>,
        Yuchung Cheng <ycheng@...gle.com>, kuniyu@...zon.co.jp,
        LKML <linux-kernel@...r.kernel.org>,
        netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net-next 0/2] net: snmp: tracepoint support for snmp

On Tue, Nov 23, 2021 at 12:42 AM David Ahern <dsahern@...il.com> wrote:
>
> On 11/21/21 3:47 AM, Menglong Dong wrote:
> > On Fri, Nov 19, 2021 at 11:54 AM David Ahern <dsahern@...il.com> wrote:
> >>
> > [...]
> >>
> >> But it integrates into existing tooling which is a big win.
> >>
> >> Ido gave the references for his work:
> >> https://github.com/nhorman/dropwatch/pull/11
> >> https://github.com/nhorman/dropwatch/commit/199440959a288dd97e3b7ae701d4e78968cddab7
> >>
> >
> > I have been thinking about this all day, and I think your words make sense.
> > Indeed, this can make use of the frame of the 'drop monitor' module of kernel
> > and the userspace tools of wireshark, dropwatch, etc. And this idea is more
> > suitable for the aim of 'get the reason for packet drop'. However, the
> > shortcoming
> > of this idea is that it can't reuse the drop reason for the 'snmp'
> > frame.
> >
> > With creating a tracepoint for 'snmp', it can make use of the 'snmp' frame and
> > the modifications can be easier. However, it's not friendly to the
> > users, such as
> > dropwatch, wireshark, etc. And it seems it is a little redundant with what
> > the tracepoint for 'kfree_sbk()' do. However, I think it's not
> > difficult to develop
> > a userspace tool. In fact, I have already write a tool based on BCC, which is
> > able to make use of 'snmp' tracepoint, such as:
> >
> > $ sudo ./nettrace.py --tracer snmp -p udp --addr 192.168.122.8
> > begin tracing......
> > 785487.366412: [snmp][udplite_noports]: UDP: 192.168.122.8:35310 ->
> > 192.168.122.1:7979
> >
> > And it can monitor packet drop of udp with ip 192.168.122.8 (filter by port,
> > statistics type are supported too).
> >
> > And maybe we can integrate tracepoint of  'snmp' into 'drop monitor' with
> > NET_DM_ATTR_SNMP, just link NET_DM_ATTR_SW_DROPS and
> > NET_DM_ATTR_HW_DROPS?
> >
>
> you don't need to add 'snmp' to drop monitor; you only need to add
> NET_DM_ATTR_ to the existing one.
>
> This is the end of __udp4_lib_rcv:
>
>         __UDP_INC_STATS(net, UDP_MIB_CSUMERRORS, proto == IPPROTO_UDPLITE);
> drop:
>         __UDP_INC_STATS(net, UDP_MIB_INERRORS, proto == IPPROTO_UDPLITE);
>         kfree_skb(skb);
>
> you want to add a tracepoint at both UDP_INC_STATS making 3 consecutive
> lines that give access to the dropped skb with only slight variations in
> metadata.
>
> The last one, kfree_skb, gives you the address of the drop + the skb for
> analysis. Just add the metadata to the existing drop monitor.

Ok, get it! Thanks~

Menglong Dong

>