network config not working on newer libvirt

[daggs]

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.