Unfortunately I had to time box myself from this issue while doing
initial investigation...

I was able to reproduce the issue: after installing openbsd-inetd, tcpd
and rstatd + rstat-client I could observe that only xenial and bionic
hosts are the ones responding to UDP broadcast requests from "rup"
binary:

(c)rafaeldtinoco@xenial:~$ rup 
xenial.lxd            20:09 up              1:39, load 0.58 0.63 0.54
bionic.lxd            20:09 up              1:43, load 0.58 0.63 0.54

(c)rafaeldtinoco@bionic:~$ rup
xenial.lxd            20:12 up              1:42, load 0.39 0.50 0.51
bionic.lxd            20:12 up              1:46, load 0.39 0.50 0.51

(c)rafaeldtinoco@eoan:~$ sudo rup
xenial.lxd            20:12 up              1:51, load 0.62 0.52 0.49
bionic.lxd            20:12 up              1:55, load 0.62 0.52 0.49

(c)rafaeldtinoco@focal:~$ rup 
xenial.lxd            20:12 up              1:42, load 0.28 0.46 0.50
bionic.lxd            20:12 up              1:47, load 0.28 0.46 0.50

So it is clear that the rpc-rstatd is the one to blame, as all clients
can receive info from older ubuntu versions. I was curious because there
were practically no changes in all related packages:

- openbsd-inetd
- tcpd (tcp-wrappers)
- rstatd

to justify a change of behavior so I checked syslog in the working
nodes:

----
when hostname is given:
xenial rpc.rstatd[2961]: connect from 10.250.97.142 (10.250.97.142)

when broadcast is attempted:
xenial rpc.rstatd[2965]: connect from 127.0.0.1 (127.0.0.1)

and when broadcast is attempted with remote bionic (works):
bionic rpc.rstatd[6264]: connect from 127.0.0.1 (127.0.0.1)
bionic rpc.rstatd[6267]: connect from 127.0.0.1 (127.0.0.1)

----

and there might be something related to UDP broadcast and lo
interface...

I backported:

openbsd-inetd 0.20160825-4build1 
tcpd 7.6.q-30
rstatd 4.0.1-10

to bionic expecting to brake it and it did not happen =).

As I was running all as containers, on top of the same kernel, it is
likely some environmental thing related to how tcp-wrappers are dealing
with an UDP socket listening to broadcast.

----

Running inetd by hand (outside systemd scope) did not help also, the
broadcast request did not even arrive to the socket as it seems, just
the direct one:

(c)rafaeldtinoco@eoan:~$ sudo inetd -idl
pmap_set: 100001 1 17 41139
pmap_set: 100001 2 17 41139
pmap_set: 100001 3 17 41139
pmap_set: 100001 4 17 41139
pmap_set: 100001 5 17 41139
ADD: rstatd rpcprog=100001, rpcvers=5/1, proto=rpc/udp, wait.max=1.256 
user:group=nobody:(default) builtin=0 server=/usr/sbin/tcpd
someone wants rstatd
2830 execv /usr/sbin/tcpd
reaping asked for
2830 reaped, status 0
restored rstatd, fd 7
pmap_unset(100001, 1)
pmap_unset(100001, 2)
pmap_unset(100001, 3)
pmap_unset(100001, 4)
pmap_unset(100001, 5)

----

Checking tcpdump:

$ rup eoan.lxd and the eoan container shows:

20:46:39.145376 IP 10.250.97.227.57183 > 10.250.97.200.111: UDP, length 56
20:46:39.145486 IP 10.250.97.200.111 > 10.250.97.227.57183: UDP, length 28
20:46:39.145562 IP 10.250.97.227.51090 > 10.250.97.200.60135: UDP, length 40
20:46:39.150911 IP 10.250.97.200.60135 > 10.250.97.227.51090: UDP, length 132

$ rup with no args and eoan container shows:

20:46:42.906008 IP 10.250.97.227.42901 > 10.250.97.255.111: UDP, length
100

meaning that the broadcast address was simply ignored by eoan as it
looks like, while it was fully responded by the xenial container:

20:49:45.199018 IP 10.250.97.227.44449 > 10.250.97.255.111: UDP, length 100
20:49:45.204090 IP 10.250.97.213.713 > 10.250.97.227.44449: UDP, length 140

----

The only way I was able to reproduce something similar was if daemon
side was not listening (or have bind) the broadcast address...

My "tests" were done using netcat like:

# client

(c)rafaeldtinoco@eoan:~$ nc -b -u 10.250.97.255 8080
one
two
three

# server

(c)rafaeldtinoco@bionic:~$ sudo nc -D -k -l -s 10.250.97.255 -p 8080 -u -b
one
two
three

----

Still need to figure what takes rpc.statd not to bind broadcast address
in newer Ubuntu versions.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890276

Title:
  inetd does not answer broadcast requests

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openbsd-inetd/+bug/1890276/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to