In criu we are actively using diag interface to collect sockets
present in the system when dumping applications. And while for
unix, tcp, udp[lite], packet, netlink it works as expected,
the raw sockets do not have. Thus add it.
v2:
- add missing sock_put calls in raw_diag_dump_one (by eric.dumazet@)
- implement @destroy for diag requests (by dsa@)
v3:
- add export of raw_abort for IPv6 (by dsa@)
- pass net-admin flag into inet_sk_diag_fill due to
changes in net-next branch (by dsa@)
CC: David S. Miller <davem@davemloft.net>
CC: Eric Dumazet <redacted>
CC: David Ahern <redacted>
CC: Alexey Kuznetsov <redacted>
CC: James Morris <jmorris@namei.org>
CC: Hideaki YOSHIFUJI <redacted>
CC: Patrick McHardy <redacted>
CC: Andrey Vagin <redacted>
CC: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Cyrill Gorcunov <redacted>
---
include/net/raw.h | 6 +
include/net/rawv6.h | 7 +
net/ipv4/Kconfig | 8 +
net/ipv4/Makefile | 1
net/ipv4/raw.c | 21 ++++
net/ipv4/raw_diag.c | 226 ++++++++++++++++++++++++++++++++++++++++++++++++++++
net/ipv6/raw.c | 7 +
7 files changed, 272 insertions(+), 4 deletions(-)
Index: linux-ml.git/include/net/raw.h
===================================================================
On Tue, 2016-09-13 at 20:19 +0300, Cyrill Gorcunov wrote:
quoted hunk
In criu we are actively using diag interface to collect sockets
present in the system when dumping applications. And while for
unix, tcp, udp[lite], packet, netlink it works as expected,
the raw sockets do not have. Thus add it.
v2:
- add missing sock_put calls in raw_diag_dump_one (by eric.dumazet@)
- implement @destroy for diag requests (by dsa@)
v3:
- add export of raw_abort for IPv6 (by dsa@)
- pass net-admin flag into inet_sk_diag_fill due to
changes in net-next branch (by dsa@)
CC: David S. Miller <davem@davemloft.net>
CC: Eric Dumazet <redacted>
CC: David Ahern <redacted>
CC: Alexey Kuznetsov <redacted>
CC: James Morris <jmorris@namei.org>
CC: Hideaki YOSHIFUJI <redacted>
CC: Patrick McHardy <redacted>
CC: Andrey Vagin <redacted>
CC: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Cyrill Gorcunov <redacted>
---
include/net/raw.h | 6 +
include/net/rawv6.h | 7 +
net/ipv4/Kconfig | 8 +
net/ipv4/Makefile | 1
net/ipv4/raw.c | 21 ++++
net/ipv4/raw_diag.c | 226 ++++++++++++++++++++++++++++++++++++++++++++++++++++
net/ipv6/raw.c | 7 +
7 files changed, 272 insertions(+), 4 deletions(-)
Index: linux-ml.git/include/net/raw.h
===================================================================
Someday Linux will be a modern OS that just includes IPV6 and forces a
config option to NOT have it.
That'll be great. All the IS_ENABLED_(CONFIG_IPV6) scattered everywhere
is nuts.
</editorial comment>
- Greg
From: Rustad, Mark D <hidden> Date: 2016-09-13 20:18:47
Greg [off-list ref] wrote:
Someday Linux will be a modern OS that just includes IPV6 and forces a
config option to NOT have it.
That'll be great. All the IS_ENABLED_(CONFIG_IPV6) scattered everywhere
is nuts.
</editorial comment>
Better wait until everyone at least *has* IPv6! I have yet to have IPv6 deployed on any of my employer's networks or get IPv6 service from any ISP at my home. When I was at Apple in the 90's I was told that Apple needed IPv6 by next year or "we were dead". Well Apple nearly died, but IPv6 had nothing to do with that! And I still haven't experienced an IPv6 deployment! Yeah, I have run it a bit point-to-point to resolve technical issues, but that isn't a "deployment" and not very interesting.
As much as we would like things to move faster, much of the world just doesn't. Witness the e1000 discussion today for example. Hardware doesn't vanish overnight, and I know that my ISP has a network full of CPE that doesn't do IPv6, so I'm not expecting their status to change any time soon.
It would be great though.
</pipedream>
--
Mark Rustad, Networking Division, Intel Corporation
On Tue, 2016-09-13 at 20:18 +0000, Rustad, Mark D wrote:
Greg [off-list ref] wrote:
quoted
Someday Linux will be a modern OS that just includes IPV6 and forces a
config option to NOT have it.
That'll be great. All the IS_ENABLED_(CONFIG_IPV6) scattered everywhere
is nuts.
</editorial comment>
Better wait until everyone at least *has* IPv6! I have yet to have IPv6
deployed on any of my employer's networks or get IPv6 service from any ISP
at my home. When I was at Apple in the 90's I was told that Apple needed
IPv6 by next year or "we were dead". Well Apple nearly died, but IPv6 had
nothing to do with that! And I still haven't experienced an IPv6
deployment! Yeah, I have run it a bit point-to-point to resolve technical
issues, but that isn't a "deployment" and not very interesting.
As much as we would like things to move faster, much of the world just
doesn't. Witness the e1000 discussion today for example. Hardware doesn't
vanish overnight, and I know that my ISP has a network full of CPE that
doesn't do IPv6, so I'm not expecting their status to change any time soon.
Well that's why we can have a configuration to turn it off...
But yeah. /pipedream
- Greg
It would be great though.
</pipedream>
--
Mark Rustad, Networking Division, Intel Corporation
From: David Ahern <hidden> Date: 2016-09-15 19:53:24
On 9/13/16 11:19 AM, Cyrill Gorcunov wrote:
In criu we are actively using diag interface to collect sockets
present in the system when dumping applications. And while for
unix, tcp, udp[lite], packet, netlink it works as expected,
the raw sockets do not have. Thus add it.
v2:
- add missing sock_put calls in raw_diag_dump_one (by eric.dumazet@)
- implement @destroy for diag requests (by dsa@)
v3:
- add export of raw_abort for IPv6 (by dsa@)
- pass net-admin flag into inet_sk_diag_fill due to
changes in net-next branch (by dsa@)
CC: David S. Miller <davem@davemloft.net>
CC: Eric Dumazet <redacted>
CC: David Ahern <redacted>
CC: Alexey Kuznetsov <redacted>
CC: James Morris <jmorris@namei.org>
CC: Hideaki YOSHIFUJI <redacted>
CC: Patrick McHardy <redacted>
CC: Andrey Vagin <redacted>
CC: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Cyrill Gorcunov <redacted>
---
ss -K is not working. Socket lookup fails to find a match due to a protocol mismatch.
haven't had time to track down why there is a mismatch since the kill uses the socket returned from the dump. Won't have time to come back to this until early next week.
On Thu, Sep 15, 2016 at 01:53:13PM -0600, David Ahern wrote:
On 9/13/16 11:19 AM, Cyrill Gorcunov wrote:
quoted
In criu we are actively using diag interface to collect sockets
present in the system when dumping applications. And while for
unix, tcp, udp[lite], packet, netlink it works as expected,
the raw sockets do not have. Thus add it.
v2:
- add missing sock_put calls in raw_diag_dump_one (by eric.dumazet@)
- implement @destroy for diag requests (by dsa@)
v3:
- add export of raw_abort for IPv6 (by dsa@)
- pass net-admin flag into inet_sk_diag_fill due to
changes in net-next branch (by dsa@)
CC: David S. Miller <davem@davemloft.net>
CC: Eric Dumazet <redacted>
CC: David Ahern <redacted>
CC: Alexey Kuznetsov <redacted>
CC: James Morris <jmorris@namei.org>
CC: Hideaki YOSHIFUJI <redacted>
CC: Patrick McHardy <redacted>
CC: Andrey Vagin <redacted>
CC: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Cyrill Gorcunov <redacted>
---
ss -K is not working. Socket lookup fails to find a match due to a protocol mismatch.
haven't had time to track down why there is a mismatch since the kill uses the socket returned
from the dump. Won't have time to come back to this until early next week.
Have you ran iproute2 patched? I just ran ss -K and all sockets get closed
(including raw ones), which actually kicked me off the testing machine sshd :/
Cyrill
From: David Ahern <hidden> Date: 2016-09-15 20:25:13
On 9/15/16 2:22 PM, Cyrill Gorcunov wrote:
quoted
ss -K is not working. Socket lookup fails to find a match due to a protocol mismatch.
haven't had time to track down why there is a mismatch since the kill uses the socket returned
from the dump. Won't have time to come back to this until early next week.
Have you ran iproute2 patched? I just ran ss -K and all sockets get closed
(including raw ones), which actually kicked me off the testing machine sshd :/
From: Eric Dumazet <hidden> Date: 2016-09-15 20:36:13
On Thu, 2016-09-15 at 14:25 -0600, David Ahern wrote:
On 9/15/16 2:22 PM, Cyrill Gorcunov wrote:
quoted
quoted
ss -K is not working. Socket lookup fails to find a match due to a protocol mismatch.
haven't had time to track down why there is a mismatch since the kill uses the socket returned
from the dump. Won't have time to come back to this until early next week.
Have you ran iproute2 patched? I just ran ss -K and all sockets get closed
(including raw ones), which actually kicked me off the testing machine sshd :/
yes.
And CONFIG_INET_DIAG_DESTROY is also set in your .config ?
From: David Ahern <hidden> Date: 2016-09-15 20:39:52
On 9/15/16 2:36 PM, Eric Dumazet wrote:
On Thu, 2016-09-15 at 14:25 -0600, David Ahern wrote:
quoted
On 9/15/16 2:22 PM, Cyrill Gorcunov wrote:
quoted
quoted
ss -K is not working. Socket lookup fails to find a match due to a protocol mismatch.
haven't had time to track down why there is a mismatch since the kill uses the socket returned
from the dump. Won't have time to come back to this until early next week.
Have you ran iproute2 patched? I just ran ss -K and all sockets get closed
(including raw ones), which actually kicked me off the testing machine sshd :/
yes.
And CONFIG_INET_DIAG_DESTROY is also set in your .config ?
yes
dsa@kenny:~/kernel.git$ grep INET_DIAG_DESTROY kbuild/perf/.config
CONFIG_INET_DIAG_DESTROY=y
raw_diag_destroy is getting called, but protocol is 255:
From: David Ahern <hidden> Date: 2016-09-15 20:55:08
On 9/15/16 2:22 PM, Cyrill Gorcunov wrote:
quoted
ss -K is not working. Socket lookup fails to find a match due to a protocol mismatch.
haven't had time to track down why there is a mismatch since the kill uses the socket returned
from the dump. Won't have time to come back to this until early next week.
Have you ran iproute2 patched? I just ran ss -K and all sockets get closed
(including raw ones), which actually kicked me off the testing machine sshd :/
This is the patch I applied to iproute2; the change in your goo.gl link plus a debug to confirm the kill action is initiated by ss:
@@ -2334,6 +2334,10 @@ static int show_one_inet_sock(const struct sockaddr_nl *addr,if(diag_arg->f->f&&run_ssfilter(diag_arg->f->f,&s)==0)return0;+if(diag_arg->f->kill){+printf("want to kill:\n");+err=inet_show_sock(h,&s,diag_arg->protocol);+}if(diag_arg->f->kill&&kill_inet_sock(h,arg)!=0){if(errno==EOPNOTSUPP||errno==ENOENT){/* Socket can't be closed, or is already closed. */
@@ -2631,6 +2635,10 @@ static int raw_show(struct filter *f)dg_proto=RAW_PROTO;+if(!getenv("PROC_NET_RAW")&&!getenv("PROC_ROOT")&&+inet_show_netlink(f,NULL,IPPROTO_RAW)==0)+return0;+if(f->families&(1<<AF_INET)){if((fp=net_raw_open())==NULL)gotoouterr;
On Thu, Sep 15, 2016 at 02:54:57PM -0600, David Ahern wrote:
quoted hunk
On 9/15/16 2:22 PM, Cyrill Gorcunov wrote:
quoted
quoted
ss -K is not working. Socket lookup fails to find a match due to a protocol mismatch.
haven't had time to track down why there is a mismatch since the kill uses the socket returned
from the dump. Won't have time to come back to this until early next week.
Have you ran iproute2 patched? I just ran ss -K and all sockets get closed
(including raw ones), which actually kicked me off the testing machine sshd :/
This is the patch I applied to iproute2; the change in your goo.gl link plus a debug to confirm the kill action is initiated by ss:
@@ -2334,6 +2334,10 @@ static int show_one_inet_sock(const struct sockaddr_nl *addr,if(diag_arg->f->f&&run_ssfilter(diag_arg->f->f,&s)==0)return0;+if(diag_arg->f->kill){+printf("want to kill:\n");+err=inet_show_sock(h,&s,diag_arg->protocol);+}if(diag_arg->f->kill&&kill_inet_sock(h,arg)!=0){if(errno==EOPNOTSUPP||errno==ENOENT){/* Socket can't be closed, or is already closed. */
@@ -2631,6 +2635,10 @@ static int raw_show(struct filter *f)dg_proto=RAW_PROTO;+if(!getenv("PROC_NET_RAW")&&!getenv("PROC_ROOT")&&+inet_show_netlink(f,NULL,IPPROTO_RAW)==0)+return0;+if(f->families&(1<<AF_INET)){if((fp=net_raw_open())==NULL)gotoouterr;
Hmm. Weird. I'm running net-next kernel
---
[root@pcs7 ~]# /root/sock &
[1] 5108
This is a trivial program which opens raw sockets
[root@pcs7 iproute2]# misc/ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 127.0.0.1:ipproto-255 127.0.0.10:ipproto-9090
UNCONN 0 0 127.0.0.10:ipproto-255 *:*
UNCONN 0 0 :::ipv6-icmp :::*
UNCONN 0 0 :::ipv6-icmp :::*
ESTAB 0 0 ::1:ipproto-255 ::1:ipproto-9091
UNCONN 0 0 ::1:ipproto-255 :::*
[root@pcs7 iproute2]#
[root@pcs7 iproute2]# misc/ss -K
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port
u_str ESTAB 0 0 /var/run/dbus/system_bus_socket 18071 * 16297
u_str ESTAB 0 0 /run/systemd/journal/stdout 18756 * 16188
u_str ESTAB 0 0 /run/systemd/journal/stdout 23014 * 23013
u_str ESTAB 0 0 * 18909 * 16298
u_str ESTAB 0 0 /var/run/dbus/system_bus_socket 19154 * 18163
...
??? ESTAB 0 0 127.0.0.1:ipproto-255 127.0.0.10:ipproto-9090
??? UNCONN 0 0 127.0.0.10:ipproto-255 *:*
??? ESTAB 0 0 ::1:ipproto-255 ::1:ipproto-9091
??? UNCONN 0 0 ::1:ipproto-255 :::*
---
Here I get kicked off the server. Login back
[cyrill@uranus ~] ssh root@pcs7
Last login: Thu Sep 15 23:20:42 2016 from gateway
[root@pcs7 ~]# cd /home/iproute2/
[root@pcs7 iproute2]# misc/ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 :::ipv6-icmp :::*
UNCONN 0 0 :::ipv6-icmp :::*
Maybe I do something wrong for testing?
From: Eric Dumazet <hidden> Date: 2016-09-15 22:48:22
On Fri, 2016-09-16 at 00:01 +0300, Cyrill Gorcunov wrote:
Here I get kicked off the server. Login back
[cyrill@uranus ~] ssh root@pcs7
Last login: Thu Sep 15 23:20:42 2016 from gateway
[root@pcs7 ~]# cd /home/iproute2/
[root@pcs7 iproute2]# misc/ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 :::ipv6-icmp :::*
UNCONN 0 0 :::ipv6-icmp :::*
Maybe I do something wrong for testing?
If you kill your shell, maybe /root/sock is killer as well, thus its raw
sockets are closed.
Try to be selective in the -K , do not kill tcp sockets ?
From: David Ahern <hidden> Date: 2016-09-15 23:45:16
On 9/15/16 4:48 PM, Eric Dumazet wrote:
On Fri, 2016-09-16 at 00:01 +0300, Cyrill Gorcunov wrote:
quoted
Here I get kicked off the server. Login back
[cyrill@uranus ~] ssh root@pcs7
Last login: Thu Sep 15 23:20:42 2016 from gateway
[root@pcs7 ~]# cd /home/iproute2/
[root@pcs7 iproute2]# misc/ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 :::ipv6-icmp :::*
UNCONN 0 0 :::ipv6-icmp :::*
Maybe I do something wrong for testing?
If you kill your shell, maybe /root/sock is killer as well, thus its raw
sockets are closed.
Try to be selective in the -K , do not kill tcp sockets ?
I am running
ss -aKw 'dev == red'
to kill raw sockets bound to device named 'red'.
On Fri, Sep 16, 2016 at 10:06:23AM +0300, Cyrill Gorcunov wrote:
On Thu, Sep 15, 2016 at 05:45:02PM -0600, David Ahern wrote:
quoted
quoted
Try to be selective in the -K , do not kill tcp sockets ?
I am running
ss -aKw 'dev == red'
to kill raw sockets bound to device named 'red'.
Thanks David, Eric! I'll play with this option today and report the results.
I created veth pair and bound raw socket into it.
[root@pcs7 iproute2]# misc/ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 127.0.0.1:ipproto-255 127.0.0.10:ipproto-9090
UNCONN 0 0 127.0.0.10:ipproto-255 *:*
UNCONN 0 0 :::ipv6-icmp :::*
UNCONN 0 0 :::ipv6-icmp :::*
ESTAB 0 0 ::1:ipproto-255 ::1:ipproto-9091
UNCONN 0 0 ::1%vm1:ipproto-255 :::*
[root@pcs7 iproute2]#
[root@pcs7 iproute2]# misc/ss -aKw 'dev == vm1'
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 ::1%vm1:ipproto-255 :::*
[root@pcs7 iproute2]# misc/ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 127.0.0.1:ipproto-255 127.0.0.10:ipproto-9090
UNCONN 0 0 127.0.0.10:ipproto-255 *:*
UNCONN 0 0 :::ipv6-icmp :::*
UNCONN 0 0 :::ipv6-icmp :::*
ESTAB 0 0 ::1:ipproto-255 ::1:ipproto-9091
so it get zapped out. Is there some other way to test it?
From: David Ahern <hidden> Date: 2016-09-16 19:30:42
On 9/16/16 1:00 PM, Cyrill Gorcunov wrote:
I created veth pair and bound raw socket into it.
[root@pcs7 iproute2]# misc/ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 127.0.0.1:ipproto-255 127.0.0.10:ipproto-9090
UNCONN 0 0 127.0.0.10:ipproto-255 *:*
UNCONN 0 0 :::ipv6-icmp :::*
UNCONN 0 0 :::ipv6-icmp :::*
ESTAB 0 0 ::1:ipproto-255 ::1:ipproto-9091
UNCONN 0 0 ::1%vm1:ipproto-255 :::*
[root@pcs7 iproute2]#
[root@pcs7 iproute2]# misc/ss -aKw 'dev == vm1'
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 ::1%vm1:ipproto-255 :::*
[root@pcs7 iproute2]# misc/ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 127.0.0.1:ipproto-255 127.0.0.10:ipproto-9090
UNCONN 0 0 127.0.0.10:ipproto-255 *:*
UNCONN 0 0 :::ipv6-icmp :::*
UNCONN 0 0 :::ipv6-icmp :::*
ESTAB 0 0 ::1:ipproto-255 ::1:ipproto-9091
so it get zapped out. Is there some other way to test it?
I'm guessing you passed IPPROTO_RAW (255) as the protocol to socket(). If you pass something else (IPPROTO_ICMP for example) it won't work.
On Fri, Sep 16, 2016 at 01:30:28PM -0600, David Ahern wrote:
quoted
[root@pcs7 iproute2]# misc/ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 127.0.0.1:ipproto-255 127.0.0.10:ipproto-9090
UNCONN 0 0 127.0.0.10:ipproto-255 *:*
UNCONN 0 0 :::ipv6-icmp :::*
UNCONN 0 0 :::ipv6-icmp :::*
ESTAB 0 0 ::1:ipproto-255 ::1:ipproto-9091
so it get zapped out. Is there some other way to test it?
I'm guessing you passed IPPROTO_RAW (255) as the protocol to socket(). If you pass something
else (IPPROTO_ICMP for example) it won't work.
True. To support IPPROTO_ICMP it need enhancement. I thought start with
plain _RAW first and then extend to support _ICMP.
Cyrill
From: David Ahern <hidden> Date: 2016-09-16 19:49:05
On 9/16/16 1:39 PM, Cyrill Gorcunov wrote:
On Fri, Sep 16, 2016 at 01:30:28PM -0600, David Ahern wrote:
quoted
quoted
[root@pcs7 iproute2]# misc/ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
ESTAB 0 0 127.0.0.1:ipproto-255 127.0.0.10:ipproto-9090
UNCONN 0 0 127.0.0.10:ipproto-255 *:*
UNCONN 0 0 :::ipv6-icmp :::*
UNCONN 0 0 :::ipv6-icmp :::*
ESTAB 0 0 ::1:ipproto-255 ::1:ipproto-9091
so it get zapped out. Is there some other way to test it?
I'm guessing you passed IPPROTO_RAW (255) as the protocol to socket(). If you pass something
else (IPPROTO_ICMP for example) it won't work.
True. To support IPPROTO_ICMP it need enhancement. I thought start with
plain _RAW first and then extend to support _ICMP.
I thought raw in this case was SOCK_RAW as in the socket type.
Since the display is showing sockets in addition to IPPROTO_RAW:
$ ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 *%eth0:icmp *:*
It is going to be confusing if only ipproto-255 sockets can be killed.
On Fri, Sep 16, 2016 at 01:47:57PM -0600, David Ahern wrote:
quoted
quoted
I'm guessing you passed IPPROTO_RAW (255) as the protocol to socket(). If you pass something
else (IPPROTO_ICMP for example) it won't work.
True. To support IPPROTO_ICMP it need enhancement. I thought start with
plain _RAW first and then extend to support _ICMP.
I thought raw in this case was SOCK_RAW as in the socket type.
Since the display is showing sockets in addition to IPPROTO_RAW:
$ ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 *%eth0:icmp *:*
It is going to be confusing if only ipproto-255 sockets can be killed.
OK, gimme some time to implement it. Hopefully on the weekend or monday.
Thanks a huge for feedback!
From: David Ahern <hidden> Date: 2016-09-16 19:55:55
On 9/16/16 1:52 PM, Cyrill Gorcunov wrote:
On Fri, Sep 16, 2016 at 01:47:57PM -0600, David Ahern wrote:
quoted
quoted
quoted
I'm guessing you passed IPPROTO_RAW (255) as the protocol to socket(). If you pass something
else (IPPROTO_ICMP for example) it won't work.
True. To support IPPROTO_ICMP it need enhancement. I thought start with
plain _RAW first and then extend to support _ICMP.
I thought raw in this case was SOCK_RAW as in the socket type.
Since the display is showing sockets in addition to IPPROTO_RAW:
$ ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 *%eth0:icmp *:*
It is going to be confusing if only ipproto-255 sockets can be killed.
OK, gimme some time to implement it. Hopefully on the weekend or monday.
Thanks a huge for feedback!
It may well be a ss bug / problem. As I mentioned I am always seeing 255 for the protocol which 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.
On Fri, Sep 16, 2016 at 01:55:42PM -0600, David Ahern wrote:
quoted
quoted
Since the display is showing sockets in addition to IPPROTO_RAW:
$ ss -A raw
State Recv-Q Send-Q Local Address:Port Peer Address:Port
UNCONN 0 0 *%eth0:icmp *:*
It is going to be confusing if only ipproto-255 sockets can be killed.
OK, gimme some time to implement it. Hopefully on the weekend or monday.
Thanks a huge for feedback!
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.
On Fri, Sep 16, 2016 at 11:07:22PM +0300, Cyrill Gorcunov wrote:
quoted
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).
quoted
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?
Cyrill
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:
quoted
quoted
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).
quoted
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
===================================================================
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
Seems like that should be a union to keep the API.
__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?
seems reasonable to me since 2 protocols need to be sent to the kernel.
Alternatively, sdiag_protocol could be the actual protocol and the pad union be a flag field with say bit 0 = INET_DIAG_FLAG_SOCK_RAW. Allows other overrides in the future if needed.
Seems like that should be a union to keep the API.
Is anonymous union (which is not part of c99) are acceptable in uapi?
Initially I declared it as union but then scratched my head if this
would be acceptable.
quoted
__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?
seems reasonable to me since 2 protocols need to be sent to the kernel.
Alternatively, sdiag_protocol could be the actual protocol and the pad union be a flag field
with say bit 0 = INET_DIAG_FLAG_SOCK_RAW. Allows other overrides in the future if needed.
The @sdiag_protocol used for matching in diag module handler, so no, I think
we should not change this semantics. I would stick with @pad usage and if
anonymous unions are acceptable this would be just great.
Cyrill