I would like to replicate the behavior of ethtool -r when auto-negotiation is active in my C++ code with NETLINK sockets. I search the CLI ethtool [source code](https://git.kernel.org/pub/scm/network/ethtool/ethtool.git/tree/ethtool.c#n3435) and I found that they use IOCTL sockets and the command of ethtool ETHTOOL_NWAY_RST. According to kernel docs [here](https://docs.kernel.org/networking/ethtool-netlink.html#request-translation) , this command has not been translated to NETLINK sockets. Before I give up, I just want know if there is another approach to get the same behavior. ### What I tried so far - I have static routes in the interface, so turning down and up the interface would not work because I lose those routes. This does not happen with ethtool -r. - For the same reason the ip link set down/up [dev] behavior also would not be ideal in my case. My code is currently working using the CLI of ethtool, but a more clean and better approach would be to use the userspace API directly. My code has already been made for NETLINK sockets and that's why I prefer this approach. I would appreciate any help. Thanks

I'm using AFPS on Unixware, just for curiosity and learning (I already know there is Samba and AFPS is not supported since the 2008). Searching on net I see a product which has the same paths (/var/opt/lanman) and some identical commands (net, euctosjis, etc.) called Solaris PC NetLink Simple question: is the same program maybe re-licensed or renamed? I also found a manual of a old server for AT&T and Siemens Unix called "Advanced Server for UNIX" which has the same commands of AFPS. I think probably is the same program re-licensed or renamed.

On udev wiki page , it has this picture: Kernel -> udev -> NetworkManager DBus Firefox. Kernel sends uevents to udevd via netlink sockets. NetworkManager talks to Firefox via dbus. All good. What is the communication mechanism between udev (I assume it is udevd daemon) and NetworkManager? I can see besides NETLINK_ROUTE, which is necessary to configure links/routes etc, the NetworkManager opens several NETLINK_KOBJECT_UEVENT sockets itself. Does that mean the wiki picture is outdated, and the NetworkManager listens/gather device information directly from kernel uevents? Otherwise, if udevd is supposedly responsible to disseminate all device related information to all user applications (daemons), how does it do it? Maybe a unix domain socket, if so what's the name of it? And, what does /run/udev/control do exactly?

I would like to run a l2 evpn (vxlan) bgp speaker in a different namespace and advertise the learned addresses into another namespace. In building the following topology, the BGP daemon populates the fdb table in the namespace it runs in, however addresses that then appear in the fdb table aren't advertised or discovered on the connected bridge. What am I fundamentally missing in this deployment?

I want apply the following rules for TOS based traffic shaping. All rules works but the final rule which mask the IP header shows **illegal "match"** error sudo tc qdisc del dev tun0 root handle 1: htb default 10 sudo tc qdisc add dev tun0 root handle 1: htb default 10 sudo tc filter add dev tun0 parent 1: prio 99 handle 1: u32 divisor 16 alias tclass='sudo tc class add dev tun0 parent 1:1' tclass classid 1:16 htb rate 50kbit ceil 50kbit prio 1 tclass classid 1:10 htb rate 90mbit ceil 95mbit prio 2 tclass classid 1:12 htb rate 1mbit ceil 1mbit prio 3 sudo tc qdisc add dev tun0 parent 1:16 sfq perturb 60 sudo tc qdisc add dev tun0 parent 1:10 sfq perturb 60 sudo tc qdisc add dev tun0 parent 1:12 sfq perturb 60 alias tcfilter='sudo tc filter add dev tun0 parent 1: prio 99' tcfilter u32 match u8 0 0 ht 1:0: classid 1:16 tcfilter u32 match u8 0 0 ht 1:1: classid 1:16 tcfilter u32 match u8 0 0 ht 1:2: classid 1:16 tcfilter u32 match u8 0 0 ht 1:3: classid 1:16 tcfilter u32 match u8 0 0 ht 1:4: classid 1:12 tcfilter u32 match u8 0 0 ht 1:5: classid 1:12 tcfilter u32 match u8 0 0 ht 1:6: classid 1:12 tcfilter u32 match u8 0 0 ht 1:7: classid 1:12 tcfilter u32 match u8 0 0 ht 1:8: classid 1:16 tcfilter u32 match u8 0 0 ht 1:9: classid 1:16 tcfilter u32 match u8 0 0 ht 1:a: classid 1:16 tcfilter u32 match u8 0 0 ht 1:b: classid 1:16 tcfilter u32 match u8 0 0 ht 1:c: classid 1:10 tcfilter u32 match u8 0 0 ht 1:d: classid 1:10 tcfilter u32 match u8 0 0 ht 1:e: classid 1:10 tcfilter u32 match u8 0 0 ht 1:f: classid 1:10 # up to this all commands work. But following command doesn't works sudo tc filter add dev tun0 parent 1: prio 1 protocol ip u32 \ link 1: hashkey mask 0x001e0000 match u8 0 0 Illegal "match" **UPDATE** The problem solved by putting all instruction in a single line: sudo tc filter add dev tun0 parent 1: prio 1 protocol ip u32 link 1: hashkey mask 0x001e0000 match u8 0 0

Netlink (as in, the kernel internal protocol) seems to be very difficult to debug without additional tools - which I can't actually use because I'm on a very confined embedded system. Is there an in-kernel debugging option for netlink if I recompile from source? e.g. logs confirming messages have been received and understood I've set debug verbosity to 15 but I can't find an option that specifically relates to netlink

The linux kernel has support for IPv6 SLAAC (stateless address auto-configuration) and is able to process received router advertisement messages. **BUT:** As much as I can understand, the kernel is not processing two things of the router advertisement: 1. 'M'/'O' flag to indicate the existence of a DHCPv6 server in the network *(this is stored in the inet6_dev, but never used)* 2. DNS option to pass a DNS server in the RA *(this is ignored completely)* **Is there a way to retrieve this information from the userspace?**

If I inspect information about established TCP connections as returned by sock_diag(7) (or in /proc/net/tcp ), how can I determine whether a given connection originated with the local side owning the passive , listening socket or the active, connecting one? **UPDATE** I am interested in doing this at the level of APIs, i.e. without launching commands such as ss or netstat.

My problem =========== AF_NETLINK queries to the kernel intermittently take many seconds before being answered, for example in this strace trace:

10:42:38.864353 socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3
10:42:38.864377 setsockopt(3, SOL_SOCKET, SO_SNDBUF, , 4) = 0
10:42:38.864399 setsockopt(3, SOL_SOCKET, SO_RCVBUF, , 4) = 0
10:42:38.864418 setsockopt(3, SOL_NETLINK, NETLINK_EXT_ACK, , 4) = 0
10:42:38.864436 bind(3, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
10:42:38.864459 getsockname(3, {sa_family=AF_NETLINK, nl_pid=16296, nl_groups=00000000}, ) = 0
10:42:38.864491 sendto(3, {{len=40, type=RTM_GETLINK, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1588581759, pid=0}, {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=0, ifi_flags=0, ifi_change=0}, {{nla_len=8, nla_type=IFLA_EXT_MASK}, 1}}, 40, 0, NULL, 0) = 40
10:42:51.894848 recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=NULL, iov_len=0}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC}, MSG_PEEK|MSG_TRUNC) = 2608

Background ========== I noticed that, every now and then, software would hang while trying to resolve an IP address. Mainly browsers, but also new sshs or anything else that needs DNS. Using Wireshark I was able to check that the hang occurred before a DNS query packet ever gets sent to the name server, so it's not a lagging nameserver by itself. Tracing a few relevant processes showed that, every now and then, the process would read /etc/resolv.conf first, which has IPV6 addresses:

# Generated by NetworkManager
search example.de otherexample.de
nameserver 192.168.178.1
nameserver 2a02:8070:c19e:b400:xxxx:xxxx:xxxx:xxxx
nameserver fd00::9a9b:cbff:xxxx:xxxx

then read /etc/gai.conf which doesn't contain anything but comments, and then, obviously, get the list of interfaces using an AF_NETLINK socket. Most of the time, the sendto and corresponding recvmsg are just a few milliseconds apart, but in some cases, this hangs what feels like forever. Which made me realize that the problem isn't even DNS, and indeed, running ip a in a loop would, sometimes hang for several seconds as well. So I did this while stracing each ip a and logging the output and the strace` to two different files. This shows the problem happens about once per minute, for about 12-13 seconds:

10:41:58.561713 sendto(3, {{len=40, type=RTM_GETLINK, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1588581719, pid=0}, {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=0, ifi_flags=0, ifi_change=0}, {{nla_len=8, nla_type=IFLA_EXT_MASK}, 1}}, 40, 0, NULL, 0) = 40
10:41:58.561943 recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=NULL, iov_len=0}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC}, MSG_PEEK|MSG_TRUNC) = 2608

10:42:38.864491 sendto(3, {{len=40, type=RTM_GETLINK, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1588581759, pid=0}, {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=0, ifi_flags=0, ifi_change=0}, {{nla_len=8, nla_type=IFLA_EXT_MASK}, 1}}, 40, 0, NULL, 0) = 40
10:42:51.894848 recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=NULL, iov_len=0}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC}, MSG_PEEK|MSG_TRUNC) = 2608

10:43:42.269435 sendto(3, {{len=40, type=RTM_GETLINK, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1588581823, pid=0}, {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=0, ifi_flags=0, ifi_change=0}, {{nla_len=8, nla_type=IFLA_EXT_MASK}, 1}}, 40, 0, NULL, 0) = 40
10:43:54.894689 recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=NULL, iov_len=0}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC}, MSG_PEEK|MSG_TRUNC) = 2608

10:44:45.276410 sendto(3, {{len=40, type=RTM_GETLINK, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1588581886, pid=0}, {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=0, ifi_flags=0, ifi_change=0}, {{nla_len=8, nla_type=IFLA_EXT_MASK}, 1}}, 40, 0, NULL, 0) = 40
10:44:57.894722 recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=NULL, iov_len=0}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC}, MSG_PEEK|MSG_TRUNC) = 2608

10:45:48.273509 sendto(3, {{len=40, type=RTM_GETLINK, flags=NLM_F_REQUEST|NLM_F_DUMP, seq=1588581949, pid=0}, {ifi_family=AF_UNSPEC, ifi_type=ARPHRD_NETROM, ifi_index=0, ifi_flags=0, ifi_change=0}, {{nla_len=8, nla_type=IFLA_EXT_MASK}, 1}}, 40, 0, NULL, 0) = 40
10:46:00.894574 recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base=NULL, iov_len=0}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_TRUNC}, MSG_PEEK|MSG_TRUNC) = 2608

The first pair is an example of what happens normally; the other pairs show how the problem happens once per minute and lasts for ~ 12 seconds. There is no significant network change during those times; here's an example of the output of ip a before and after one the first of those pauses:

Mon May  4 10:42:38 CEST 2020
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether a8:5e:45:60:e4:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.131/24 brd 192.168.178.255 scope global dynamic noprefixroute enp3s0
       valid_lft 83515sec preferred_lft 83515sec
    inet6 2a02:8070:c19e:b400:bec7:94b4:34f1:86b4/64 scope global dynamic noprefixroute 
       valid_lft 7078sec preferred_lft 3478sec
    inet6 fe80::d27:8efd:f696:3c47/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlp7s0:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d0:ab:d5:0e:02:09 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.10/24 brd 192.168.10.255 scope global dynamic noprefixroute wlp7s0
       valid_lft 602858sec preferred_lft 602858sec
    inet6 fe80::c694:6683:6353:e9c9/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: wlxf4f26d08d54e:  mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether f4:f2:6d:08:d5:4e brd ff:ff:ff:ff:ff:ff
Mon May  4 10:42:52 CEST 2020
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether a8:5e:45:60:e4:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.178.131/24 brd 192.168.178.255 scope global dynamic noprefixroute enp3s0
       valid_lft 83514sec preferred_lft 83514sec
    inet6 2a02:8070:c19e:b400:bec7:94b4:34f1:86b4/64 scope global dynamic noprefixroute 
       valid_lft 7077sec preferred_lft 3477sec
    inet6 fe80::d27:8efd:f696:3c47/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
3: wlp7s0:  mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether d0:ab:d5:0e:02:09 brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.10/24 brd 192.168.10.255 scope global dynamic noprefixroute wlp7s0
       valid_lft 602857sec preferred_lft 602857sec
    inet6 fe80::c694:6683:6353:e9c9/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: wlxf4f26d08d54e:  mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether f4:f2:6d:08:d5:4e brd ff:ff:ff:ff:ff:ff

The question ============ What could cause the kernel to delay replies to AF_NETLINK/RTM_GETLINK socket calls for several seconds, once per minute? As far as I know, those calls are handled by the kernel directly, not by some other process (that I could strace for a timeout). Is this correct? If so, what could make the kernel block on those requests, again and again? How could one debug that?

What do Local Address and Port mean in ss -f netlink output? I was expecting the -n numeric version Local Address to be pid but they do not seem to match.

I want to understand the netlink messages exchanged with the kernel when I run the following commmand to create a pair of veth devices (I am using Ubuntu 16.04): $ sudo ip link add veth1 type veth peer name veth2 I tried to follow the tutorial at this [link](https://docs.pyroute2.org/debug.html) . I used strace and got the following trace related to netlink: $ sudo strace -e trace=network -x -s 16384 -f -o out ip link add veth1 type veth peer name veth2 $ cat out socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC, NETLINK_ROUTE) = 3 setsockopt(3, SOL_SOCKET, SO_SNDBUF, , 4) = 0 setsockopt(3, SOL_SOCKET, SO_RCVBUF, , 4) = 0 bind(3, {sa_family=AF_NETLINK, pid=0, groups=00000000}, 12) = 0 getsockname(3, {sa_family=AF_NETLINK, pid=6001, groups=00000000}, ) = 0 send(3, "\x20\x00\x00\x00\x10\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 32, 0) = 32 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\x34\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\x71\x17\x00\x00\xed\xff\xff\xff\x20\x00\x00\x00\x10\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00", 16384}], msg_controllen=0, msg_flags=0}, 0) = 52 socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 4 sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\x5c\x00\x00\x00\x10\x00\x05\x06\x38\xa2\x16\x5d\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0a\x00\x03\x00\x76\x65\x74\x68\x31\x00\x00\x00\x30\x00\x12\x00\x08\x00\x01\x00\x76\x65\x74\x68\x24\x00\x02\x00\x20\x00\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x0a\x00\x03\x00\x76\x65\x74\x68\x32\x00\x00\x00", 92}], msg_controllen=0, msg_flags=0}, 0) = 92 recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\x24\x00\x00\x00\x02\x00\x00\x00\x38\xa2\x16\x5d\x71\x17\x00\x00\x00\x00\x00\x00\x5c\x00\x00\x00\x10\x00\x05\x06\x38\xa2\x16\x5d\x00\x00\x00\x00", 32768}], msg_controllen=0, msg_flags=0}, 0) = 36 For example, I try decoding the messages related to sending. // my test did not have any line breaks $ echo'\x20\x00\x00\x00\x10\x00\x05\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00' >> message $ python tests/decoder/decoder.py pyroute2.netlink.rtnl.rtmsg.rtmsg message 20:00:00:00:10:00:05:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00 :00:00:00:00:00:00:00:00:00:00 {'attrs': [('RTA_UNSPEC', None)], 'dst_len': 0, 'family': 0, 'flags': 0, 'header': {'flags': 5, 'length': 32, 'pid': 0, 'sequence_number': 0, 'type': 16}, 'proto': 0, 'scope': 0, 'src_len': 0, 'table': 0, 'tos': 0, 'type': 0} ........................................ $ echo '\x5c\x00\x00\x00\x10\x00\x05\x06\x38\xa2\x16\x5d\x00\x00 \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x0a\x00\x03\x00\x76\x65\x74\x68\x31\x00\x00\x00\x30\x00 \x12\x00\x08\x00\x01\x00\x76\x65\x74\x68\x24\x00\x02\x00\x20\x00 \x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x0a\x00\x03\x00\x76\x65\x74\x68\x32\x00\x00\x00' >> message $ python tests/decoder/decoder.py pyroute2.netlink.rtnl.rtmsg.rtmsg message 5c:00:00:00:10:00:05:06:38:a2:16:5d:00:00:00:00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00:00:00:0a:00:03:00:76:65:74:68:31:00:00:00: 30:00:12:00:08:00:01:00:76:65:74:68:24:00:02:00:20:00:01:00:00:00: 00:00:00:00:00:00:00:00:00:00:00:00:00:00:0a:00:03:00:76:65:74:68: 32:00:00:00 {'attrs': [('RTA_UNSPEC', None), ('RTA_IIF', 1752458614), ('RTA_VIA', {'addr': '01:00:76:65:74:68:24:00:02:00:20:00:01:00:00:00:00:00:00:00:00: 00:00:00:00:00:00:00:00:00:0a:00:03:00:76:65:74:68:32:00:00:00', 'family': 8})], 'dst_len': 0, 'family': 0, 'flags': 0, 'header': {'flags': 1541, 'length': 92, 'pid': 0, 'sequence_number': 1561764408, 'type': 16}, 'proto': 0, 'scope': 0, 'src_len': 0, 'table': 0, 'tos': 0, 'type': 0} I was expecting the decoding to indicate something about veth1 or veth2, but the decoding does not seem to correlate with veth devices. I did repeat the decoding in a related [tutorial](https://jvns.ca/blog/2017/09/03/debugging-netlink-requests/) and could get the same result as in the tutorial. I want to ask if the decoding above is correct, and if so, how can it be interpreted ?