That's not it.
Same story with 1.2.5-7 from unstable.
This is after NIS restart on the client on the NIS server:
root@jain:# tcpdump -nvvv -i enp7s0f1.502 udp and port 111
tcpdump: listening on enp7s0f1.502, link-type EN10MB (Ethernet), capture
size 262144 bytes
192.168.20.41.36268 > 192.168.20.63.111: [udp sum ok] UDP, length 92
09:02:57.820457 IP (tos 0x0, ttl 64, id 55627, offset 0, flags [DF],
proto UDP (17), length 120)
192.168.20.41.36268 > 192.168.20.63.111: [udp sum ok] UDP, length 92
09:03:03.826888 IP (tos 0x0, ttl 64, id 55969, offset 0, flags [DF],
proto UDP (17), length 120)
And on - the RPC retransmits to broadcast address (63 on this subnet it
is /26)
Traffic only one way, strace on rpcbind shows only netlink messages, no
udp recv
Same thing after setting a nis server address on the client and
restarting nis - immediate response
tcpdump -nvvv -i enp7s0f1.502 udp and port 111
192.168.20.41.800 > 192.168.3.3.111: [udp sum ok] UDP, length 56
09:05:00.429940 IP (tos 0x0, ttl 64, id 22755, offset 0, flags [DF],
proto UDP (17), length 56)
192.168.3.3.111 > 192.168.20.41.800: [bad udp cksum 0x98b2 ->
0x1245!] UDP,
strace of the rpcbind process
sendmsg(6, {msg_name={sa_family=AF_INET, sin_port=htons(800),
sin_addr=inet_addr("192.168.20.41")}, msg_namelen=16,
msg_iov=[{iov_base=".{\272q\0\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\2\265",
iov_len=28}], msg_iovlen=1, msg_control=[{cmsg_len=28,
cmsg_level=SOL_IP, cmsg_type=IP_PKTINFO, cmsg_data={ipi_ifindex=0,
ipi_spec_dst=inet_addr("192.168.3.3"),
ipi_addr=inet_addr("192.168.3.3")}}], msg_controllen=32, msg_flags=0},
0) = 28
That line (strace) never occurs in the broadcast case.
It simply is not listening to broadcast queries.
I will try to wade through the source to see exactly how it manages it,
because listening on INADDR_ANY should in theory get you broadcasts.
On 09/09/2019 22:00, Debian Bug Tracking System wrote:
This is an automatic notification regarding your Bug report
which was filed against the rpcbind package:
#939877: rpcbind: Does not receive any broadcast queries resulting in complete
breakage of NIS
It has been closed by Josue Ortega <jo...@debian.org>.
Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Josue Ortega
<jo...@debian.org> by
replying to this email.
--
Anton R. Ivanov
https://www.kot-begemot.co.uk/
