Greetings Laine, > It's just some name tcpdump used to replace the IP address of one of the > machines, and since it's the source IP of a DHCP reply packet, it most > likely is the IP of the DHCP server. ok, sounds reasonable > > > here is the requested dump: https://dpaste.com/849DMX9ND > > What I see in that dump is that the DHCP client (Mac address > 52:54:00:5a:4c:8c, hostname "streamer" repeatedly sends the exact same > DHCP request (6 times), and the DHCP server responds to each of these > requests alternating between sending the response to the client's MAC > with a destination IP already set, and to the broadcast MAC + IP > addresses) interspersed with several ARP requests directed at the MAC > address of the client asking who has the IP that the server just > suggested (so it's doing something different from what I described in my > previous message - rather than using ARP to verify that an IP isn't > already in use prior to assigning it, it's assuming it has full > authority over IP addresses in the broadcast domain, assigning that IP > to the client without checking for prior use, and then sending the ARP > request to see if the client actually decided to use it.) > > Eventually the client gives up (because it hasn't seen any valid DHCP > responses) and gives itself an IP on the 169.254.0.0/16 network, then > goes about the process of looking for other devices to connect to using > that IP. > > Was this dump taken on the host of the tap device of the client > (libreelec aka streamer)? here are the relevant adapters of the vm: 4: virtsw: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 52:54:00:6b:1b:92 brd ff:ff:ff:ff:ff:ff 5: virtsw-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virtsw state DOWN group default qlen 1000 link/ether 52:54:00:6b:1b:92 brd ff:ff:ff:ff:ff:ff 6: nic_host: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000 link/ether fe:54:00:a7:79:6b brd ff:ff:ff:ff:ff:ff inet 11.0.0.3/24 brd 11.0.0.255 scope global dynamic noprefixroute nic_host valid_lft 33053sec preferred_lft 27653sec inet6 fdab:9802:eb52::a59/128 scope global noprefixroute valid_lft forever preferred_lft forever inet6 fdab:9802:eb52:0:41d9:d311:10fd:e343/64 scope global mngtmpaddr noprefixroute valid_lft forever preferred_lft forever inet6 fe80::fc54:ff:fea7:796b/64 scope link valid_lft forever preferred_lft forever 7: virtsw-router: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virtsw state UNKNOWN group default qlen 1000 link/ether fe:54:00:53:1c:6b brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fe53:1c6b/64 scope link valid_lft forever preferred_lft forever 8: virtsw-streamer: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virtsw state UNKNOWN group default qlen 1000 link/ether fe:54:00:5a:4c:8c brd ff:ff:ff:ff:ff:ff inet6 fe80::fc54:ff:fe5a:4c8c/64 scope link valid_lft forever preferred_lft forever the dump was taken from the host tapping onto virtsw-streamer. virtsw-streamer is configured as follows: <interface type='network'> <mac address='52:54:00:5a:4c:8c'/> <source network='default' portid='77aae31e-5efa-4789-911c-c55b367cd695' bridge='virtsw'/> <target dev='virtsw-streamer'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> > If so, I can only see two options: 1) there is > something in iptables or ebtables (or nftables, if you have that on the > host) blocking the DHCP response packets from going out the tap > interface, or 2) there is something in the guest itself blocking the > traffic or preventing the packet from passing. > > For (1) you'd need to run "ebtables -L; iptables -S; nft list ruleset" > and look for something suspicious. here is what I get: utils_server /home/igor # ebtables -L; iptables -S; nft list ruleset The kernel doesn't support the ebtables 'filter' table. -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N LIBVIRT_FWI -N LIBVIRT_FWO -N LIBVIRT_FWX -N LIBVIRT_INP -N LIBVIRT_OUT -A INPUT -j LIBVIRT_INP -A FORWARD -j LIBVIRT_FWX -A FORWARD -j LIBVIRT_FWI -A FORWARD -j LIBVIRT_FWO -A OUTPUT -j LIBVIRT_OUT -A LIBVIRT_FWI -o virtsw -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWO -i virtsw -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWX -i virtsw -o virtsw -j ACCEPT -A LIBVIRT_INP -i virtsw -p udp -m udp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virtsw -p tcp -m tcp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virtsw -p udp -m udp --dport 67 -j ACCEPT -A LIBVIRT_INP -i virtsw -p tcp -m tcp --dport 67 -j ACCEPT -A LIBVIRT_OUT -o virtsw -p udp -m udp --dport 53 -j ACCEPT -A LIBVIRT_OUT -o virtsw -p tcp -m tcp --dport 53 -j ACCEPT -A LIBVIRT_OUT -o virtsw -p udp -m udp --dport 68 -j ACCEPT -A LIBVIRT_OUT -o virtsw -p tcp -m tcp --dport 68 -j ACCEPT bash: nft: command not found what about the rest of the ports? > > For (2) can you try changing both the libreelec and the DHCP server vm's > ethernet device models from virtio to e1000? (or e1000e if they are q35 > machinetypes)? If that works, then change one or the other back and see > if it stops working. will try and report. > You mean so you can ssh to the client/libreelec and run tcpdump there > agains the interface that's doing dhcp? Is tcpdump even available on > libreelec? I know it's very limited, and has no simple facilities for > adding new packages. If it has tcpdump though, then sure. The only > problem is that you would probably not be able to get tcpdump running > via that interface quick enough to see the initial boottime dhcp > exchange; instead you'll probably need to go into the UI and bring the > other interface down/up to trigger a new DHCP cycle. static tcpdump should do the trick imho. > > (BTW, if everything works when the client has a static IP address, then > that proves there is no problem related to ARP requests/responses - that > much is required in order for even a static IP to work) currently I use static ip and I can ssh to the streamer from all machines on the network.
