(2017-02-06 09:55)robinsmidsrod Wrote: [ -> ]cjs: I wonder if the iPXE version you use to start KVM/QEMU with has had ProxyDHCP disabled with a compilation config switch. Either that or the dnsmasq server running on port 67 is somehow telling iPXE not to send a request to port 4011.
I think I covered all this in my posts above; I chainloaded the most recent version from
http://boot.ipxe.org/ipxe.pxe and got the same behaviour, so this "don't query port 4011" thing is compiled into that one, too, if that's what's doing it. And, as per my post of the DHCP reply from port 67, I don't see any options that would indicate to iPXE not to query the proxy DHCP server.
Quote:Have you tried booting ipxe from e.g. the floppy image (ipxe.dsk) instead of via --pxe, as this could change some behavior.
I've not, but I can go set that up if you think it's really worthwhile. Is that likely to be different from the behaviour when doing the chain load?
Quote:It is also possible that you have a network issue not allowing packets properly out of the VM.
Could you please elaborate on how your VM interacts with the rest of your network, especially routers, firewalls and topology?
There are no routers involved during the DHCP or TFTP portions of the boot. I am using the standard libvirt configuration:
* The host has an (internal) bridge,
virbr0, which is the layer 2 network being used.
* The host uses interface
virbr0-nic on this bridge and is configured for address 192.168.122.1. libvirt's DHCP server is listening on
*:67, which listens on this interface as well as all others.
* The guest is also set up with an interface on this bridge, which is what it's using to send the DHCP requests, etc.
* I run tcpdump on the host on this interface to see what's going on.
I don't have any special firewall tools installed (e.g., CentOS firewalld), and the iptables rules in place on the INPUT chain allow everything through. When I monitor everything on this network I see all sorts of traffic, including DHCP, TFTP and HTTP from the VM, all of which works fine from the VM's point of view. (NAT on the host is forwarding requests from the VM to off-network hosts, e.g., HTTP to chain load from ipxe.org and pull down packages from a CentOS mirror, and that's all working.) The only place I can see where a firewall rule would be blocking port 4011 such that I wouldn't see it on the bridge (using tcpdump as above) would be on the VM, but that would have to be done by QEMU/KVM itself since the DHCP I'm looking at is happening before a Linux kernel is even loaded, and QEMU/KVM doesn't do that.
Has anybody else here actually seen iPXE send DHCP requests to port 4011? That really does appear to be the problem here, and I'm thinking the best thing to do might be to walk through the code and figure out how and where it's supposed to be doing this and doing enough tweaking on a test version of iPXE that we can see if this code path is actually being followed, if indeed it even exists at all.
The relevant code appears to be
#define PXE_PORT 4011 (
src/include/ipxe/dhcp.h rev 3f814f08e from Michael Brown <mcb30@etherboot.org> 2009-01-23) and the
dhcp_proxy_tx function (
src/net/udp/dhcp.c, various commits from Michael Brown). A quick look says that this may have something to do with iPXE's
pxebs command? Or the end of the
dhcp_request_rx seems to have some code that sends a proxy request under certain circumstances, but I've not looked at it too closely to find out what's going on there with that.
Michael Brown still seems to be active (he's had several commits in the last few weeks); is he around on these forums? Maybe I should contact him directly by e-mail to see what's up with all this?
(2017-02-07 03:13)BitBub Wrote: [ -> ]Not sure it matters here, but as far as I know, dnsmasq does not use port 4011 for anything when responding to legacy bios clients.
dnsmasq listens on port 4011 when given the
dhcp-alternate-port option, though there are some bugs related to that that I have worked around. I've confirmed with
lsof that it's actually listening on that port when run with my configuration.
Here's my configuration if you're curious. Note again that this is a
second DHCP server that's not running on port 67 that's supposed to supplement (for PXE boots) the other DHCP server on port 67 which is configured only to hand out addresses and whose configuration I cannot change.
Code:
enable-tftp
tftp-secure
#tftp-root= # Set from command line
############################################################
# DHCP Configuration
# This is mainly to document how we can set this up as a "DHCP proxy"
# server that can supply other information to a PXE-booting host even
# though a different DHCP server running on the standard port supplies
# the address.
#
# Unfortunately, this doesn't actually work since the iPXE boot code
# used by the VM doesn't send a request on the proxy port (4011). I
# am not clear why it does not do this.
# The address below is ignored since as a proxy we don't give out addresses.
dhcp-range=127.0.0.1,proxy
# This option causes the server to listen on the given port (default
# 1067) _and_ on the PXE port 4011. Specifying the PXE port directly
# (with `=4011` actually causes the server to fail because it appears
# to try to bind to the port twice. this behaviour is not documented
# in the manpage.
#
dhcp-alternate-port
dhcp-boot=/pxelinux.0
pxe-prompt="Press F8 for boot menu", 8
pxe-service=X86PC, "Boot from network", /pxelinux
pxe-service=X86PC, "Boot from local hard disk", 0
Quote:Everything is done using Option 43 on port 67/68. The port 4011 stuff was added for EFI clients. http://lists.thekelleys.org.uk/pipermail...10551.html
This I don't understand. Maybe reading through the
PXE specification would help, but that link (from the
Wikipedia PXE entry) wants a user name and password to let me download it. Is there an alternate source for this?