> > 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. changed the router's nic type to e1000e and the streamer's nic type to e1000, error still persists. > > > 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. > > >
