On 9/6/20 12:02 PM, daggs wrote:> Greetings LAine, > >> When you say "the vm", you mean the one running libreelec, that is >> trying to get and IP address, correct? > > yes, you are correct. > >> I guess Broadcom.home is the IP of the VM that's running the dhcp >> server? (I should have suggested using "tcpdump -n -e -v" :-/) >> > > frankly, I have no idea who is Broadcom.home.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.> here is the requested dump: https://dpaste.com/849DMX9NDWhat 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)? 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. 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. > should I add another nic with static ip and try to trace the pkts from there? > 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. (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)
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.
> > 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. > > >
Seemingly Similar Threads
- Re: network config not working on newer libvirt
- Re: network config not working on newer libvirt
- Re: vms doesn't coomunicate via network
- [Bug 1289] New: iptables build fails with kernel 4.20-rc1 - gnu_inline attributes
- [Bug 1291] New: iptables 1.8.0+ no longer builds against kernel 3.10.108