network config not working on newer libvirt

[Laine Stump]

On 9/4/20 6:47 PM, daggs wrote:
> Greetings Laine,
> 
>>>
>>> I would start troubleshooting by making sure that the dhcp server is
>>> running, and that you can communicate between the machine with DHCP
>>> server and the guest once a manual IP is assigned. Then use tcpdump or
>>> wireshark at different places on the path between those two to see how
>>> far the DHCP request is getting out, whether a response is being sent by
>>> the server, and if so how far the response is getting back (i.e. on the
>>> host, run tcpdump on the guest's tap device; if you see the DHCP request
>>> there, then run tcpdump on the bridge, if you see it there, run it on
>>> the tap device for the guest, if you see it there, then run tcpdump
>>> inside the guest; then check the dhcp server logs to see if it's
>>> receiving requests. While you're doing all of this, you can also be
>>> noticing whether or not a DHCP response is arriving at each step (and if
>>> you see the response, you can skip looking further ahead in the packet
>>> path, since you know by inference that it made it all the way to the
>>> DHCP server). Once you find the point that the packet is blocked, you'll
>>> be better able to determine why.
>>>
>>>
>>
>> alright, I'll try that, thanks.
>>
> 
> I've ran tcpdump on the vm's tap device, here is what I see:

When you say "the vm", you mean the one running libreelec, that is 
trying to get and IP address, correct?

> 01:42:15.404754 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 52:54:00:5a:4c:8c (oui Unknown), length 548
> 01:42:15.405075 IP Broadcom.Home.bootps > 10.0.0.40.bootpc: BOOTP/DHCP, Reply, length 300

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" :-/)


> 01:42:15.735893 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:6b:1b:92.8003, length 35
> 01:42:17.718941 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:6b:1b:92.8003, length 35
> 01:42:17.846918 IP6 fe80::fc54:ff:fe5a:4c8c > ff02::2: ICMP6, router solicitation, length 16
> 01:42:19.702944 STP 802.1d, Config, Flags [none], bridge-id 8000.52:54:00:6b:1b:92.8003, length 35
> 01:42:20.450441 ARP, Request who-has 10.0.0.40 tell Broadcom.Home, length 28
> 
> I think that issue is this:
> 01:42:20.450441 ARP, Request who-has 10.0.0.40 tell Broadcom.Home, length 28
> 
> I'm not sure if this is expected but looks like my dhcp server ignores it.
> any thoughts on the matter?

It looks strange, but is normal. What usually happens is this:

1) The guest sends a DHCP Discover Request, suggesting that it would 
like to use the addres 10.0.0.40 (These details will be revealed once 
you add "-v" to your tcpdump commandline.


2) The DHCP server says to itself "Hmm, this guy wants to use 10.0.0.40, 
which is okay with me, but first I should see if someone else is using 
it", so it sends out an ARP request for 10.0.0.40. Then just to be sure, 
it sends another.

(at this point, if the server is dnsmasq and it hasn't received an ARP 
request, for some reason it sends an ICMP echo request to 10.0.0.40 (the 
requested/suggested IP) with destination MAC address of the client that 
just sent the DHCP request. No idea why. It won't be answered though 
(unless the client actually still had a lease on that address and was 
just renewing; but the DHCP server would know it if that's what was 
happening, so...)

3) If the server doesn't receive any response to the ARP request, then 
it will send a DHCP response to the requested IP + client MAC saying 
"Yes, you can use that IP address.

4) I'm not sure why (because it's been > 20 years since I last read the 
DHCP RFC), but in the case I just looked at on my host (which is using 
dnsmasq as the server, and dhclient as the client), the same request and 
response are sent/received at the same IP+MAC addresses a 2nd time.

5) at this point everybody agrees on the new IP address, the client sets 
its IP address, the server updates its leases table, and life carries on.

But to back up for a minute - it's completely normal for the DHCP server 
to send out an ARP request and get no response. I think things are going 
south sometime after that. Are you seeing a DHCP reply at all? If you 
don't see it on the libreelec (client) machine's tap device, check if 
you see it going *out* on the DHCP server's tap. If it's not there, then 
you'll need to debug inside the guest running the DHCP server.

Before this packet is receivd, the guest doesn't yet know that's its IP 
address, but it does know that's its MAC address, and it's waiting for a 
DHCP reply, so it takes the info from the reply, then sends another 
request, this time including all the options it received in the first reply.

4) Now