2

I get the following line from ss -lun:

udp       UNCONN     0          0                0.0.0.0%virbr0:67                  0.0.0.0:*         users:(("dnsmasq",pid=950,fd=3))

I wonder what 0.0.0.0%virbr0 means here. No trace of it in man, hard to find in search engines.

2 Answers2

1

That would be for sockets that are bound to a particular interface in addition to that IPv4 wildcard address using the SO_BINDTODEVICE socket option. From socket(7):

SO_BINDTODEVICE
Bind this socket to a particular device like “eth0”, as specified in the passed interface name. If the name is an empty string or the option length is zero, the socket device binding is removed. The passed option is a variable-length null-terminated interface name string with the maximum size of IFNAMSIZ. If a socket is bound to an interface, only packets received from that particular interface are processed by the socket. Note that this works only for some socket types, particularly AF_INET sockets. It is not supported for packet sockets (use normal bind(2) there).

Before Linux 3.8, this socket option could be set, but could not retrieved with getsockopt(2). Since Linux 3.8, it is readable. The optlen argument should contain the buffer size available to receive the device name and is recommended to be IFNAMSIZ bytes. The real device name length is reported back in the optlen argument.

(emphasis mine)

Normally, instead, you'd bind your socket to the IP address(es) of the interface instead. SO_BINDTODEVICE is slightly different though. Except if blocked by rp_filter or firewall, a system will accept a connection to a given address as long as the destination address of the incoming packet matches the address the socket is bound to (even if the packet doesn't come from that interface¹). With SO_BINDTODEVICE, as explained above, only packets coming from that very interface are considered.

As an example:

$ sudo socat udp-listen:1234,so-bindtodevice=guest-bridge - &
$ ss -Hau 'sport = 1234'
UNCONN    0         0            0.0.0.0%guest-bridge:1234         0.0.0.0:*

In your case, it's probably a DHCP server UDP socket bound by a dnsmasq instance started by libvirt. And you can see that software does set that option when asked to bind to interface(s), or exclude some interface(s).

For a DHCP server, you don't want to bind to the address of the interface, as a DHCP server is meant to accept broadcast "discover" packets with 255.255.255.255 as destination. Here using the wildcard address and SO_BINDTODEVICE means you can have that dnsmasq serving DHCP requests from that virbr0 bridge interface and a separate dnsmasq (or other software) serving them on the same wildcard address on a different interface.

¹ which is a perfectly normal and common thing. Think for instance of a router which will typically accept incoming connections from any of its interfaces to any of its inbound addresses, or the local loopback connections you can normally do to the local addresses of any of your network interfaces

Stéphane Chazelas
  • 522,931
  • 91
  • 1,010
  • 1,501
  • But how should I interpret the IP (0.0.0.0) in connection with an interface? What's the point and relation to routing? Is it a wildcard on that interface? Is an interface not enough? –  Aug 16 '21 at 13:25
  • Usually 0.0.0.0 means "all IP addresses", which makes the binding / listening work regardless of the IP address(es) configured on the interface in the unicast case. I suppose it also allows the DHCP server to receive broadcast traffics (which is typically the case unless it's e.g. relayed DHCP). – Tom Yan Aug 16 '21 at 13:41
  • @tomasz, see edit. – Stéphane Chazelas Aug 16 '21 at 13:42
0

Local address (0.0.0.0) of virbr0 interface and port 67.

Toor
  • 1