netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Cyrill Gorcunov <gorcunov@gmail.com>
To: David Ahern <dsa@cumulusnetworks.com>,
	Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	David Miller <davem@davemloft.net>,
	kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org,
	kaber@trash.net, avagin@openvz.org, stephen@networkplumber.org
Subject: Re: [PATCH v3] net: ip, diag -- Add diag interface for raw sockets
Date: Tue, 27 Sep 2016 01:38:28 +0300	[thread overview]
Message-ID: <20160926223828.GL1876@uranus.lan> (raw)
In-Reply-To: <20160920211343.GI26044@uranus.lan>

On Wed, Sep 21, 2016 at 12:13:43AM +0300, Cyrill Gorcunov wrote:
> On Fri, Sep 16, 2016 at 11:07:22PM +0300, Cyrill Gorcunov wrote:
> > > It may well be a ss bug / problem. As I mentioned I am always seeing 255 for the protocol which
> > 
> > It is rather not addressed in ss. I mean, look, when we send out a diag packet
> > the kernel look ups for a handler, which for raw protocol we register as
> > 
> > static const struct inet_diag_handler raw_diag_handler = {
> > 	.dump= raw_diag_dump,
> > 	.dump_one= raw_diag_dump_one,
> > 	.idiag_get_info= raw_diag_get_info,
> > 	.idiag_type= IPPROTO_RAW,
> > 	.idiag_info_size= 0,
> > #ifdef CONFIG_INET_DIAG_DESTROY
> > 	.destroy= raw_diag_destroy,
> > #endif
> > };
> > 
> > so if we patch ss and ask for IPPROTO_ICMP in netlink packet the
> > kernel simply won't find anything. Thus I think we need (well, I need)
> > to extend the patch and register IPPROTO_ICMP diag type, then
> > extend ss as well. (If only I didn't miss somethin obvious).
> > 
> > > is odd since ss does a dump and takes the matches and invokes the kill.
> > > Thanks for taking the time to do the kill piece.
> 
> Sorry for delay in reply (I got flu unexpectedly). You know, it eventually
> become uneasy to implement handling for sock-raw because they are special.
> They described as ipproto-ip in net/ipv4/af_inet.c, so it matches any
> protocol specified with the socket call. In turn inet-diag module handled
> predefined protocols only, in particular IPPROTO_RAW in our case. Thus
> to fecth some real protocol sitting in raw sockets hashes we need some
> kind of additional argument passed in the request. I guess we may
> use @idiag_ext field for this sake? Or require @idiag_ext to have
> INET_DIAG_PROTOCOL bit set and then fetch real protocol from
> additional attribute? Sounds ok?

Something like

Index: linux-ml.git/include/uapi/linux/inet_diag.h
===================================================================
--- linux-ml.git.orig/include/uapi/linux/inet_diag.h    2016-09-11 20:56:18.191584145 +0300
+++ linux-ml.git/include/uapi/linux/inet_diag.h 2016-09-27 01:34:08.413172394 +0300
@@ -38,7 +38,7 @@ struct inet_diag_req_v2 {
        __u8    sdiag_family;
        __u8    sdiag_protocol;
        __u8    idiag_ext;
-       __u8    pad;
+       __u8    sdiag_raw_protocol;     /* SOCK_RAW only, @pad for others */
        __u32   idiag_states;
        struct inet_diag_sockid id;
 };

and in raw-diag module we will use @sdiag_raw_protocol instead of
@sdiag_protocol field. Didn't cover ss tool source code yet but
I think the idea is seen. Still not sure if start using @pad here
is a good idea (it's uapi), maybe beter to ask nla attribute which would
come right afterh the inet_diag_req_v2 message?

	Cyrill

  reply	other threads:[~2016-09-26 22:38 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-13 17:19 [PATCH v3] net: ip, diag -- Add diag interface for raw sockets Cyrill Gorcunov
2016-09-13 18:33 ` Greg
2016-09-13 20:18   ` Rustad, Mark D
2016-09-13 20:32     ` Greg
2016-09-15 19:53 ` David Ahern
2016-09-15 20:22   ` Cyrill Gorcunov
2016-09-15 20:25     ` David Ahern
2016-09-15 20:36       ` Eric Dumazet
2016-09-15 20:39         ` David Ahern
2016-09-15 20:54     ` David Ahern
2016-09-15 21:01       ` Cyrill Gorcunov
2016-09-15 22:48         ` Eric Dumazet
2016-09-15 23:45           ` David Ahern
2016-09-16  7:06             ` Cyrill Gorcunov
2016-09-16 19:00               ` Cyrill Gorcunov
2016-09-16 19:30                 ` David Ahern
2016-09-16 19:39                   ` Cyrill Gorcunov
2016-09-16 19:47                     ` David Ahern
2016-09-16 19:52                       ` Cyrill Gorcunov
2016-09-16 19:55                         ` David Ahern
2016-09-16 20:07                           ` Cyrill Gorcunov
2016-09-20 21:13                             ` Cyrill Gorcunov
2016-09-26 22:38                               ` Cyrill Gorcunov [this message]
2016-09-27  1:54                                 ` David Ahern
2016-09-27  7:48                                   ` Cyrill Gorcunov
  -- strict thread matches above, loose matches on Subject: below --
2016-09-09 18:26 [PATCH] " Cyrill Gorcunov
2016-09-10 16:31 ` David Ahern
2016-09-10 22:05   ` [PATCH v2] " Cyrill Gorcunov
2016-09-10 22:28     ` David Ahern
2016-09-11 19:17       ` [PATCH v3] " Cyrill Gorcunov
2016-09-13 15:57         ` David Miller
2016-09-13 16:31           ` Cyrill Gorcunov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160926223828.GL1876@uranus.lan \
    --to=gorcunov@gmail.com \
    --cc=avagin@openvz.org \
    --cc=davem@davemloft.net \
    --cc=dsa@cumulusnetworks.com \
    --cc=eric.dumazet@gmail.com \
    --cc=jmorris@namei.org \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stephen@networkplumber.org \
    --cc=yoshfuji@linux-ipv6.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).