DHCPOFFER missing on interface
-
Hi,
I have an ITX PC configured for PXE boot (Intel Boot Loader) on a VLAN interface and the pfSense box is seeing the request on the VLAN interface however I cannot see the offer. I am looking with
tcpdump
on the pfSense box filtering on the MAC address. The DHCP log for the interface records the request and the offer with a suitable IP address. There is no arp entry, partial or otherwise for the MAC address.The ITX PC is connected to an unmanaged switch. If I boot another box (BeagleBone Black with uboot) connected to the same switch the pSense box sees the request and an offer is returned and the board boots.
I seem to remember this happening when the PC was connected to a FreeBSD 10 or so box using the ISC DHCP server. Using
dnsmasq
on that box worked without a problem so I never chased it down.Any hints?
Thanks
Chris -
@unforcederror said in DHCPOFFER missing on interface:
pfSense box is seeing the request on the VLAN interface however I cannot see the offer. I am looking with
You mean : the pfSense DHCP server receives the DHCP REQUEST from the 'PXE' client, but does not react to it ?
In that case, no need to heat up tcpdump (udpdump ;;) )because traffic won't get blocked at the firewall : it's outgoing traffic.@unforcederror said in DHCPOFFER missing on interface:
If I boot another box (BeagleBone Black with uboot) connected to the same switch the pSense box sees the request and an offer is returned and the board boots.
Aka : this time it recognizes the incoming DHCP REQUEST, and throws out an OFFER.
This eliminates network (cable / switch) issues.I never used PXE booting myself, but you can go two direction : it's a setup thing on the DHCP server side, or for this topical client side.
@unforcederror said in DHCPOFFER missing on interface:
o box using the ISC DHCP server
pfSense still uses that one :
Internet Systems Consortium DHCP Server 4.4.1 Copyright 2004-2018 Internet Systems Consortium.
-
@Gertjan said in DHCPOFFER missing on interface:
@unforcederror said in DHCPOFFER missing on interface:
pfSense box is seeing the request on the VLAN interface however I cannot see the offer. I am looking with
You mean : the pfSense DHCP server receives the DHCP REQUEST from the 'PXE' client, but does not react to it ?
Yes the DHCP server logs it sees the request and it seems to react ...
Jun 11 15:44:39 dhcpd DHCPOFFER on 10.10.5.192 to 00:22:4d:7a:4e:50 via em0.3 Jun 11 15:44:39 dhcpd DHCPDISCOVER from 00:22:4d:7a:4e:50 via em0.3
In that case, no need to heat up tcpdump (udpdump ;;) )because traffic won't get blocked at the firewall : it's outgoing traffic.
Agreed, in the case it is a step closer to knowing if the packet reached an interface.
@unforcederror said in DHCPOFFER missing on interface:
If I boot another box (BeagleBone Black with uboot) connected to the same switch the pSense box sees the request and an offer is returned and the board boots.
Aka : this time it recognizes the incoming DHCP REQUEST, and throws out an OFFER.
This eliminates network (cable / switch) issues.Yes.
I never used PXE booting myself, but you can go two direction : it's a setup thing on the DHCP server side, or for this topical client side.
@unforcederror said in DHCPOFFER missing on interface:
o box using the ISC DHCP server
pfSense still uses that one :
Internet Systems Consortium DHCP Server 4.4.1 Copyright 2004-2018 Internet Systems Consortium.
OK.
I am now playing with the network boot options which I had missed to see if there is something in these, that is a PXE request is handled differently. The logging of the offer is confusing me.
-
@unforcederror said in DHCPOFFER missing on interface:
Jun 11 15:44:39 dhcpd DHCPOFFER on 10.10.5.192 to 00:22:4d:7a:4e:50 via em0.3
Jun 11 15:44:39 dhcpd DHCPDISCOVER from 00:22:4d:7a:4e:50 via em0.3So it does recognize and react.
No reaction from " 00:22:4d:7a:xx:50" at this point ? It goes silent ? Or repeats the REQUEST, like it doesn't hear/wants/recognizes the OFFER ?
Starts to look like a client option.
Btw : if the DHCP logs something like
Jun 11 15:44:39 dhcpd DHCPDISCOVER from 00:22:4d:7a:4e:50 via em0.3
it leans it delivered that info the the driver/NIC, and can be considered as "send".
It's still UDP so no guarantees about reception or interpretation on the client's side.But you know PXE over the same wires/switches/ NIC pfSense side works.
-
@Gertjan said in DHCPOFFER missing on interface:
@unforcederror said in DHCPOFFER missing on interface:
Jun 11 15:44:39 dhcpd DHCPOFFER on 10.10.5.192 to 00:22:4d:7a:4e:50 via em0.3
Jun 11 15:44:39 dhcpd DHCPDISCOVER from 00:22:4d:7a:4e:50 via em0.3So it does recognize and react.
No reaction from " 00:22:4d:7a:xx:50" at this point ? It goes silent ? Or repeats the REQUEST, like it doesn't hear/wants/recognizes the OFFER ?
The PC repeats the request a few times then gives up like most BIOS machines do. I think the offer never makes it to the wire.
Starts to look like a client option.
Btw : if the DHCP logs something like
Jun 11 15:44:39 dhcpd DHCPDISCOVER from 00:22:4d:7a:4e:50 via em0.3
it leans it delivered that info the the driver/NIC, and can be considered as "send".
I am not so sure. I would expect
tcpdump
to display the offer and it does not. The DHCP packets for the other board do show up intcpdump
.It's still UDP so no guarantees about reception or interpretation on the client's side.
But you know PXE over the same wires/switches/ NIC pfSense side works.
The Uboot on Beaglebone board is not PXE, it's DHCP request does not contain any PXE type fields.
-
@unforcederror said in DHCPOFFER missing on interface:
The PC repeats the request a few times then gives up like most BIOS machines do. I think the offer never makes it to the wire.
That means that traffic from the PXE makes it, but not the other way around.
That's quiet are as a situation.
Easy to rule out : just boot your PXE device with some other OS : then Ethernet communication works ? If so, wires are ok.I tend to say right now ; your PXE device can't "work" with the received DHCP OFFER from pfSense;
-
@Gertjan said in DHCPOFFER missing on interface:
@unforcederror said in DHCPOFFER missing on interface:
The PC repeats the request a few times then gives up like most BIOS machines do. I think the offer never makes it to the wire.
That means that traffic from the PXE makes it, but not the other way around.
Yes.
Easy to rule out : just boot your PXE device with some other OS : then Ethernet communication works ? If so, wires are ok.
Using
ipxe
on a USB stick works and the packets appear intcpdump
.I tend to say right now ; your PXE device can't "work" with the received DHCP OFFER from pfSense;
I believe the offer never makes it to the wire and why I have raised it here.
I will work around the problem by booting
ipxe
from a USB stick. The process will be faster because I chained to theipxe
loader from the ROM PXE loader. -
@unforcederror said in DHCPOFFER missing on interface:
I believe the offer never makes it to the wire and why I have raised it here.
The OFFER log is logged after it was pushed to the network.
Even much more "down to the wire", you could use tcpdump to see it on the interface.
You said other devices could do a PXE boot ? -
@Gertjan said in DHCPOFFER missing on interface:
@unforcederror said in DHCPOFFER missing on interface:
I believe the offer never makes it to the wire and why I have raised it here.
The OFFER log is logged after it was pushed to the network.
Even much more "down to the wire", you could use tcpdump to see it on the interface.I had
tcpdump
running on the pSense box and did not see the packet. I saw the packets for the other devices on same switch andipxe
booting.You said other devices could do a PXE boot ?
The
ipxe
loader booted from a USB stick can to a PXE boot.I am off site until next week and when I return I will rebuild
ipxe
and move to using it from USB stick and side step this issue.Thank you for your help.
-
@unforcederror said in DHCPOFFER missing on interface:
The ipxe loader booted from a USB stick can to a PXE boot.
So that one did receive the OFFER that was on the wire thus visible in tcpdump.
If tcpdump didn't show something at that, it wasn't running with the good filters.