network config not working on newer libvirt

Wed Sep 9 21:47:53 UTC 2020

> > 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.
>
>
>