[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: network config not working on newer libvirt

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 > BOOTP/DHCP, Request from 52:54:00:5a:4c:8c (oui Unknown), length 548
01:42:15.405075 IP Broadcom.Home.bootps > 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 tell Broadcom.Home, length 28

I think that issue is this:
01:42:20.450441 ARP, Request who-has 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 (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, which is okay with me, but first I should see if someone else is using it", so it sends out an ARP request for 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 (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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]