Finding messages or log from a failed pxe boot

george1421

@kdm Is the FOG server on the same IP subnet as the pxe booting computer? If yes then we can grab a packet capture of the pxe booting process. If no then we can use wireshark installed on a witness (extra computer) on the same subnet to capture what the target computer is being told.

Also make sure if you have more than one dhcp server on your network, that both of them are configured for pxe booting.

KDM

This post is deleted!

KDM

@george1421

Yes, the computer (10.58.1.207) is on the same IP subnet as the fogserver (10.58.5.88)

I did do a pcap, but I’m a bit puzzled about this message:

Dynamic Host Configuration Protocol (Request)
    Message type: Boot Request (1)
    Hardware type: Ethernet (0x01)
    Hardware address length: 6
    Hops: 0
    Transaction ID: 0xd37bd5de
    Seconds elapsed: 3
        [Expert Info (Note/Protocol): Seconds elapsed appears to be encoded as little-endian]
            [Seconds elapsed appears to be encoded as little-endian]
            [Severity level: Note]
            [Group: Protocol]
    Bootp flags: 0x0000 (Unicast)
        0... .... .... .... = Broadcast flag: Unicast
        .000 0000 0000 0000 = Reserved flags: 0x0000
    Client IP address: 10.58.1.207
    Your (client) IP address: 0.0.0.0
    Next server IP address: 0.0.0.0
    Relay agent IP address: 0.0.0.0
    Client MAC address: a8:b1:3b:53:28:8e (a8:b1:3b:53:28:8e)
    Client hardware address padding: 00000000000000000000
    **Server host name not given
    Boot file name not given**

“Server host name not given” and “Boot file not given”

They are clearly set on the DCHP server.

george1421

@kdm Yes something looks amiss. I have a bit more detailed instructions on capturing a pcap here: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

If you want to review it, look at the dhcp OFFER packet it needs to have in the ethernet header both the next-server and boot-file set as well as dhcp options 66 and 67. On your dhcp server make sure it sends both bootp and dhcp information.

If you are unsure what you are looking at post the pcap to a internet file share then either post the link here or IM me the link via FOG chat and I will take a look at the results.

KDM

@george1421
it looks like my DHCP server does the OFFER with all required parameters:

george1421

@kdm ok two things jump out here.

PXE booting actually involves 2 protocols bootp (fields in ethernet header [not show in the picture below] and dhcp (dhcp options 66 and 67 [as shown below]). Its up to the pxe booting computer mfg to decide which to look at.
I see you have a ProxyDHCP request there too. That proxydhcp overrides the settings set by dhcp options 66 and 67. What is device 10.58.1.207 (or 10.58.5.88 I can’t remember which column is the server). That is the device that is responding to the proxy response.

It would be much easier to have the pcap file instead of screen shots to narrow in on the issue. But your dhcp process looks normal typical DORA response (discover, offer, request, ack). The proxy response is not normal but is used in certain circumstances. A Windows WDS server may give this type of response. Look at the OFFER packet make sure that dhcp option 60 is not being set for some reason. This says the response is a proxydhcp response.

KDM

In my search to figure out why my clients are not booting PXE I tried booting a virtual Win10 client.

On booting I got the warning “pxe-e55 proxydhcp service did not reply to request on port 4011”

Googling this, everywhere I read the suggestion to remove option 60 on my DHCP server. But option 60 is not set on my one and only DHCP server (Windows Server 2008R2). It’s not in the DHCP scope and not in the Server options.

I’m sorry but I don’t feel comfortable uploading the Wireshark captures as for now.

george1421

@kdm said in Finding messages or log from a failed pxe boot:

I’m sorry but I don’t feel comfortable uploading the Wireshark captures as for now.

Uploading would be the quickest way to an answer but I think we have enough info to point you in the right direction. Actually you provided what is needed. Look at your posted picture of the pcap, for the OFFER packet.

Look in the details section. Do you see option 60 being set? That is the problem. Its coming from dhcp server 10.58.0.4. That option being set specifically with “PXEClient” value tells the client to reach out to the server on port 4011 (proxydhcp) to find out where to boot from. DHCP options 66 and 67 will be ignored by the target computer.

If your dhcp server is not configured to do that, then I was ask is a wds service installed on this dhcp server? Something is putting that value in the response packet.

FWIW This is not a fog issue, but network infrastructure.

KDM

@george1421

Thanks again, I did do a PCAP and I’m getting Option (60) Vendor class identier

This is not set by our DHCP, but we had WDS running in the past. The service is disabled, but I guess it is still answering…

To clearify: WDS was NOT installed on the DHCP server, but a separate server. That server is still running, but WDS is disabled.

KDM

@george1421

I have uninstalled the WDS service from the other server, double and triple checked and rebooted the DHCP server.

And option 60 is still being offered…

I’m lost…

george1421

@kdm Well I don’t have a good answer for you. The short answer is that option needs to go to be able to pxe boot.

Maybe you can reverse engineer these instructions that shows how to add it" https://www.azure365pro.com/add-option-60-in-dhcp-server-for-sccm/

I little bit harder answer is to upgrade that windows 2008 server to something that is currently supported by Microsoft leaving this bad setting behind.

Thinking out of the box installing dnsmasq configured as proxy dhcp server could fool the client into pxe booting too. Not ideal in the least but something that might work if all other things fail.

KDM

@george1421 said in Finding messages or log from a failed pxe boot:

I little bit harder answer is to upgrade that windows 2008 server to something that is currently supported by Microsoft leaving this bad setting behind.

Yes, an upgrade of this DHCP server has been on the planning for a very long time but has always been delayed for al kinds of reasons. “it works and we have other priorities”

@george1421 said in Finding messages or log from a failed pxe boot:

Thinking out of the box installing dnsmasq configured as proxy dhcp server could fool the client into pxe booting too. Not ideal in the least but something that might work if all other things fail.

Yes I have been thinking about this, but that’s a serious hassle and will probably cause more issues than it solves…

I’ll leave it for now, upgrade the DHCP first and get back in touch if needed

KDM

@george1421
Well I’ll be damned

Finding messages or log from a failed pxe boot

280

11.7k

17.2k

154.8k