search

christgau / wsdd

A Web Service Discovery host daemon.
MIT License
814 stars 98 forks source link

ip link show displays an interface, but wsdd misses it. #94

Closed hcoin closed 3 years ago

hcoin commented 3 years ago

Here's a case where wsdd can't see an interface with an address, as follows:

ip link show

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:e0:d1:b1 brd ff:ff:ff:ff:ff:ff 3: enp2s0.104@enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 52:54:54:0a:69:5e brd ff:ff:ff:ff:ff:ff

ip addr show enp2s0

2: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 52:54:00:e0:d1:b1 brd ff:ff:ff:ff:ff:ff inet6 fc00:????:??::31/64 scope global (I replaced the # with ?) valid_lft forever preferred_lft forever

Debug Log:

Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: netlink message with 168 bytes Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 8 1 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: IP4 Addr b'\x7f\x00\x00\x01' Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 8 2 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: INFO: Interface lo idx 1 scope 254 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 7 3 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 8 8 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 20 6 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: new address 127.0.0.1 on lo Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: ignoring that address on lo Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 8 1 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: IP4 Addr b'\xc0\xa8\xa0\x03' Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 8 2 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 8 4 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: INFO: Interface enp2s0.104 idx 3 scope 0 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 15 3 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 8 8 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 20 6 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: new address 192.168.160.3 on enp2s0.104 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: ignoring that address on enp2s0.104 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: netlink message with 288 bytes Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: IP6 Addr b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x01' Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 20 1 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 20 6 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 8 8 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: new address ::1 on lo Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: ignoring that address on lo Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: IP6 Addr b'\xfc\x00\x??\x??\x00\x??\x00\x00\x00\x00\x00\x00\x00\x00\x001' Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 20 1 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 20 6 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 8 8 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: unknown interface index: 2 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: IP6 Addr b'\xfc\x00\x10\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\x00\x03' Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 20 1 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 20 6 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 8 8 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: new address fc00:1000:0:800::3 on enp2s0.104 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: ignoring that address on enp2s0.104 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: IP6 Addr b'\xfe\x80\x00\x00\x00\x00\x00\x00PTT\xff\xfe\ni^' Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 20 1 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 20 6 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: rt_attr 8 8 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: new address fe80::5054:54ff:fe0a:695e on enp2s0.104 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: ignoring that address on enp2s0.104 Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: netlink message with 20 bytes Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: invalid rtm_message type 3

hcoin commented 3 years ago

One idea that might ease maintainability: swap out the netlink stuff with pyroute2?

christgau commented 3 years ago

Here's a case where wsdd can't see an interface with an address, as follows: [...] ip addr show enp2s0 inet6 fc00:????:??::31/64 scope global valid_lft forever preferred_lft forever

I assume, you want to see fc00:...:31 to be detected and used by wsdd. Based on the debug log (thanks for providing it along with the issue, btw) I think that the former is actually the case, but the latter is not:

Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: IP6 Addr b'\xfc\x00\x??\x??\x00\x??\x00\x00\x00\x00\x00\x00\x00\x00\x001'

Note that the last '1' is actual a (utf-8/ascii encoded) character which maps to 0x31. So the address is actually seen, but...

Mar 02 13:05:29 fssupport3.1.quietfountain.com wsdd[39720]: DEBUG: unknown interface index: 2

...is ignored due to an unknown interface. The reason for this appears that enp2s0 "only" has an IPv6 address. However, wsdd wants to have information about an interface in order to record the new address. This includes also the name of the interface. That name is, however, apparently only emitted by the kernel to the netlink socket for interfaces that have an... IPv4 address. At least this is my impression from grepping through the kernel sources.

However, there is hope: The interface's index is reported independently from the interface's name and it could be used as well.

You may also verify that the fc00...31 address is actually correctly detected with the test/netlink_monitor.py script. That should bring something up like:

NEW addr on interface 2 [0x???]: fc00::...:31

If that works then there is a fairly good change to bring this to wsdd as well.

BUT: As hinted in the README, only link-local addresses are considered by wsdd, i.e. addresses from the fe80 subnet. fc00 addresses are neglected. I don't remember for a rationale for this right now. It might be related to the "standard", due to other technical reasons, or it was my choice. I would have to look it up again...

christgau commented 3 years ago

Although it may not be immediately related to your issue, I wonder if your IPv6 configuration is actually valid. Based on the maybe shortened output above, enp2s0 does not appears to have a link-local unicast address (fe80/10, LLA) and wsdd also does not detect such an address. This is, however, a requirement wrt to RFC4291, Sec. 2.1:

All interfaces are required to have at least one Link-Local unicast address

Is it really the case that your interface misses an LLA or is it only due to a shortened output?

IIRC, the statement from the RFC was the intention to respect LLAs only. In addition, the WSD spec defines that services should be announced in to the (IPv6) link local scope, only. Combining the RFC and the WSD spec, using LLAs made sense and so wsdd only uses those internally.

christgau commented 3 years ago

Putting the potential misconfiguration aside, the handling of interfaces without IPv4 addresses, which prevents correct handling of detected IPv6 addresses, has been fixed fdae63e. You may check if that works for you.

I was able to reproduce your issue by deleting all IPv4 addresses from an interface which has IPv6 addresses as well and then requested wsdd to use only that particular interface. With the version from master, no address is considered for usage. Opposite to that, the commit from the issue branch works.