network config not working on newer libvirt

[Laine Stump]

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/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)? 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)