Troubleshooting TFTP/PXE with WDS VM and MoFi Network MOFI4500-4GXeLTE-V3 OpenWrt router

Cerulean

[H]F Junkie
Joined
Jul 27, 2006
Messages
9,476
This posting is basically the same thing as Troubleshooting TFTP/PXE with WDS VM and Ubiquiti Dream Machine but using a MoFi Network MOFI4500-4GXeLTE-V3 OpenWrt router instead of a Ubiquiti Dream Machine. Same exact WDS VM, so nothing has changed on the VM itself and we know that WDS and Windows Firewall are configured correctly and work with a Ubiquiti Dream Machine.

The difference in configuration detail between the two routers is that the OpenWrt web-interface does not present options like specifying a PXE boot server and PXE boot file. The router is using dnsmasq for DHCP and DNS.

For extra measure, I did validate and confirm that I can GET the boot file through TFTP from another machine on the same network and running Windows OS using this command:
tftp -i 172.16.32.4 GET "\boot\x64\wdsmgfw.efi"

So now focusing on OpenWrt, my procedure is to connect via SSH with PuTTY and test configurations. When I make changes, I finish it off with the following two commands:
uci commit dhcp
/etc/init.d/dnsmasq restart

To undo changes, I usually either reboot the router OR re-execute the same commands but with del_list instead of add_list.

So what have I tried?

1)
uci add_list dhcp.@dnsmasq[0].dhcp_boot='\boot\x64\wdsmgfw.efi,CON-MDT.contoso.lan,172.16.32.4'
Additionally, I added hostname CON-MDT for IP address 172.16.32.4 to the static DNS resolv list so that CON-MDT always resolves to 172.16.32.4.

2)
uci add_list dhcp.@dnsmasq[0].dhcp_boot='boot\x64\wdsmgfw.efi,CON-MDT.contoso.lan,172.16.32.4'

3)
uci add_list dhcp.@dnsmasq[0].dhcp_boot='\boot\x64\wdsmgfw.efi,CON-MDT,172.16.32.4'

4)
uci add_list dhcp.@dnsmasq[0].dhcp_boot='boot\x64\wdsmgfw.efi,CON-MDT,172.16.32.4'

5)
uci add_list dhcp.lan.dhcp_option="66,172.16.32.4"
uci add_list dhcp.lan.dhcp_option="67,boot\x64\wdsmgfw.efi"

6)
uci add_list dhcp.lan.dhcp_option="66,172.16.32.4"
uci add_list dhcp.lan.dhcp_option="67,\boot\x64\wdsmgfw.efi"

7)
uci add_list dhcp.@dnsmasq[0].dhcp_option="66,172.16.32.4"
uci add_list dhcp.@dnsmasq[0].dhcp_option="67,\boot\x64\wdsmgfw.efi"

8)
uci add_list dhcp.@dnsmasq[0].dhcp_option="66,172.16.32.4"
uci add_list dhcp.@dnsmasq[0].dhcp_option="67,boot\x64\wdsmgfw.efi"

I am still unable to get a blank VM to PXE boot. I have made sure that the VM NIC is set correctly so that it is trying to get DHCP from the same network. The point of failure is trying to PXE boot:

1625784148915.png


That's all I get. OpenWrt does not show any DHCP leases for this blank VM. I've tested another VM that already has Windows 10 installed and uses the same NIC settings to confirm that a DHCP lease is successfully acquired.

Maybe I am not setting or adding the correct settings, missing a step or two, or something. I'm hoping someone here has ideas.

EDIT 8 Jul 2021 2008 CST:
I took a look under Advanced > Status > System Log and found this:
Thu Jul 8 15:40:51 2021 daemon.info dnsmasq-dhcp[24802]: DHCPDISCOVER(br-lan) 00:0c:29:c4:84:9f ignored
Thu Jul 8 15:40:55 2021 daemon.info dnsmasq-dhcp[24802]: DHCPDISCOVER(br-lan) 00:0c:29:c4:84:9f ignored
Thu Jul 8 15:41:00 2021 cron.info crond[2441]: USER root pid 24880 cmd /vnstat/vnstat.cron
Thu Jul 8 15:41:00 2021 user.notice vnstat_scheduler: Updating Databases...
Thu Jul 8 15:41:03 2021 daemon.info dnsmasq-dhcp[24802]: DHCPDISCOVER(br-lan) 00:0c:29:c4:84:9f ignored
Thu Jul 8 15:41:14 2021 daemon.info dnsmasq-dhcp[24802]: DHCPDISCOVER(br-lan) 00:0c:29:c4:84:9f ignored
Thu Jul 8 15:41:18 2021 daemon.info dnsmasq-dhcp[24802]: DHCPDISCOVER(br-lan) 00:0c:29:c4:84:9f ignored
Thu Jul 8 15:41:26 2021 daemon.info dnsmasq-dhcp[24802]: DHCPDISCOVER(br-lan) 00:0c:29:c4:84:9f ignored
Thu Jul 8 15:41:35 2021 user.notice internet-ledstatus: Checking... IPv4/IPv6
Thu Jul 8 15:41:42 2021 daemon.info dnsmasq-dhcp[24802]: DHCPDISCOVER(br-lan) 00:0c:29:c4:84:9f ignored
Thu Jul 8 15:41:50 2021 daemon.info dnsmasq-dhcp[24802]: DHCPDISCOVER(br-lan) 00:0c:29:c4:84:9f ignored
Thu Jul 8 15:41:54 2021 daemon.info dnsmasq-dhcp[24802]: DHCPDISCOVER(br-lan) 00:0c:29:c4:84:9f ignored
Thu Jul 8 15:42:00 2021 cron.info crond[2441]: USER root pid 24954 cmd /etc/conn.sh
Thu Jul 8 15:42:00 2021 cron.info crond[2441]: USER root pid 24955 cmd /vnstat/vnstat.cron
Thu Jul 8 15:42:00 2021 user.notice vnstat_scheduler: Backing Up Databases...
Thu Jul 8 15:42:02 2021 user.notice SIM7 Watcher: DNS[1] -> 8.8.8.8
Thu Jul 8 15:42:02 2021 user.notice SIM7 Watcher: DNS[2] -> 172.26.38.1
Thu Jul 8 15:42:02 2021 daemon.info dnsmasq-dhcp[24802]: DHCPDISCOVER(br-lan) 00:0c:29:c4:84:9f ignored
Thu Jul 8 15:42:09 2021 daemon.info dnsmasq-dhcp[24802]: DHCPDISCOVER(br-lan) 172.16.32.34 00:0c:29:22:10:d7
Thu Jul 8 15:42:09 2021 daemon.info dnsmasq-dhcp[24802]: DHCPOFFER(br-lan) 172.16.32.34 00:0c:29:22:10:d7
Thu Jul 8 15:42:09 2021 daemon.info dnsmasq-dhcp[24802]: DHCPREQUEST(br-lan) 172.16.32.34 00:0c:29:22:10:d7
Thu Jul 8 15:42:09 2021 daemon.info dnsmasq-dhcp[24802]: DHCPACK(br-lan) 172.16.32.34 00:0c:29:22:10:d7 CON-W10-2004
Thu Jul 8 15:42:12 2021 user.notice SIM7 Watcher: Host: 172.26.38.1 failed
Thu Jul 8 15:42:12 2021 user.notice SIM7 Watcher: DNS[3] -> 4.2.2.2
My blank VM that is trying to PXE boot are the lines containing "00:0c:29:c4:84:9f ignored", whereas the VM that has a test install of Windows 10 is "172.16.32.34 00:0c:29:22:10:d7". I wonder why dnsmasq is doing this... looks like this person was also experiencing the same problem.

EDIT 8 Jul 2021 2034 CST:
I did some reading of https://openwrt.org/docs/guide-user/base-system/dhcp and tried the following but continued to receive "00:0c:29:c4:84:9f ignored" in the System Log.

9)
uci add_list dhcp.lan.dhcp_vendorclass="BIOS,PXEClient:Arch:00000"
uci add_list dhcp.lan.dhcp_vendorclass="UEFI32,PXEClient:Arch:00006"
uci add_list dhcp.lan.dhcp_vendorclass="UEFI,PXEClient:Arch:00007"
uci add_list dhcp.lan.dhcp_vendorclass="UEFI64,PXEClient:Arch:00009"
uci add_list dhcp.lan.dhcp_option="net:UEFI32,\boot\x64\wdsmgfw.efi,,172.16.32.4"
uci add_list dhcp.lan.dhcp_option="net:UEFI,\boot\x64\wdsmgfw.efi,,172.16.32.4"
uci add_list dhcp.lan.dhcp_option="net:UEFI64,\boot\x64\wdsmgfw.efi,,172.16.32.4"
uci add_list dhcp.lan.dhcp_boot="\smsboot\x64\wdsnbp.com,,172.16.32.4"

10)
uci add_list dhcp.lan.dhcp_option="66,172.16.32.4"
uci add_list dhcp.lan.dhcp_option="67,\boot\x64\wdsmgfw.efi"

11)
uci add_list dhcp.lan.dhcp_option="66,,172.16.32.4"
uci add_list dhcp.lan.dhcp_option="67,,\boot\x64\wdsmgfw.efi"
 
Last edited:
Did you confirm same nic (vm net 3 or E1000) is being used between running Vm and blank ones?
 
Yes. In fact, with VMware Workstation, I do not have the ability to decide between those like you can with ESXi.
 
Is that mac address already in use/being reserved? Have you tried recreating the NIC with a new mac? Maybe check the arp cache of your router/any switches and see if that mac pops up somewhere.
 
I am running the latest firmware from MoFi Network at https://mofinetwork.com/mofi4500v3_downloads/ which would be "MOFI4500-V3-1.2.4-std"

Under Advanced > System > Software > Installed Packages the dnsmasq-full package is listed as Version 2.81-3.

The OPKG-Configuration page has this config:
Code:
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
src/gz barrier_breaker_base http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/base
src/gz barrier_breaker_telephony http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/telephony
src/gz barrier_breaker_oldpackages http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/oldpackages
src/gz barrier_breaker_packages http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/packages
src/gz barrier_breaker_routing http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/routing
src/gz barrier_breaker_luci http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/luci
src/gz barrier_breaker_management http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/management

I checked the following repositories for dnsmasq but both repositories have older versions of dnsmasq, so my MoFi4500v3 has a newer dnsmasq version.
The only place I was able to find a dnsmasq that matches "2.81-3" is at https://launchpad.net/debian/+source/dnsmasq/+changelog which tells me that 2.81-3 was released 2020-04-20.

The bug report suggested by scrappymouse was published 2017-02-04 and closed on 2017-05-01 as indicated in the GitHub pull request.

I wager that 2.81-3 already includes the fix.

As far as the idea of blacklisted MAC addresses, I have tried to PXE boot a laptop with no success -- same symptoms of DHCP request being ignored by dnsmasq. But if I let the same laptop boot into Windows OS, it successfully acquires an IP lease.
 
Looks like I got it working!

I removed any entries I had added with these commands:
Code:
uci del dhcp.lan.dhcp_option
uci del dhcp.lan.dhcp_range
uci del dhcp.lan.dhcp_boot
uci commit
If you are using factory default of a MoFi4500 you do not have to execute the above. It was executed via SSH using PuTTY logged into username root with the same password used to login to the HTTPS admin pages.

Then, using WinSCP, connect to the router using the SCP protocol (not SSH) with the same credentials and browse to directory path /etc/.

Right-click on dnsmasq.conf and select to edit it.

When I looked at my dnsmasq.conf, I found these lines and had to comment them out by putting a # at the beginning of lines 2 and 3:
Code:
#disable BOOTP (April 21 2017)
dhcp-vendorclass=pxestuff,PXEClient
dhcp-ignore=pxestuff

After:
Code:
#disable BOOTP (April 21 2017)
#dhcp-vendorclass=pxestuff,PXEClient
#dhcp-ignore=pxestuff

Then I added the following a couple new empty lines below:
Code:
dhcp-option=66,172.16.32.4 67,\boot\x64\wdsmgfw.efi
dhcp-boot=\boot\x64\wdsmgfw.efi,CON-MDT,172.16.32.4
dhcp-range=172.16.32.25,172.16.32.252

And, of course, save the changes.

Finally, execute the following command in SSH via PuTTY:
Code:
/etc/init.d/dnsmasq restart

This works. My blank VM is now able to boot from my Microsoft Windows Server 2019 VM that is configured with Windows Deployment Services (WDS) and a fully configured installation of Microsoft Deployment Toolkit (MDT). Yipee!

I tested each option from the original code and confirm that the "dhcp-ignore=pxestuff" was indeed the culprit for instructing dnsmasq to ignore DHCP requests if the client identifies as PXEClient. Even just commenting this one line out solved the first problem.

I hope someone else out there will find this valuable. :)

1627162893187.png
 
Last edited:
I am running the latest firmware from MoFi Network at https://mofinetwork.com/mofi4500v3_downloads/ which would be "MOFI4500-V3-1.2.4-std"

Under Advanced > System > Software > Installed Packages the dnsmasq-full package is listed as Version 2.81-3.

The OPKG-Configuration page has this config:
Code:
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
src/gz barrier_breaker_base http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/base
src/gz barrier_breaker_telephony http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/telephony
src/gz barrier_breaker_oldpackages http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/oldpackages
src/gz barrier_breaker_packages http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/packages
src/gz barrier_breaker_routing http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/routing
src/gz barrier_breaker_luci http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/luci
src/gz barrier_breaker_management http://downloads.openwrt.org/barrier_breaker/14.07/ramips/mt7620/packages/management

I checked the following repositories for dnsmasq but both repositories have older versions of dnsmasq, so my MoFi4500v3 has a newer dnsmasq version.
The only place I was able to find a dnsmasq that matches "2.81-3" is at https://launchpad.net/debian/+source/dnsmasq/+changelog which tells me that 2.81-3 was released 2020-04-20.

The bug report suggested by scrappymouse was published 2017-02-04 and closed on 2017-05-01 as indicated in the GitHub pull request.

I wager that 2.81-3 already includes the fix.

As far as the idea of blacklisted MAC addresses, I have tried to PXE boot a laptop with no success -- same symptoms of DHCP request being ignored by dnsmasq. But if I let the same laptop boot into Windows OS, it successfully acquires an IP lease.

So the issue exists both with your virtual machines and physical ones? If so that may rule out VMware weirdness, though moving over to virutalbox (or a hypervisor like Proxmox) could be a good option to test with. I assume all of your machines are configured to EFI boot? IIRC the older legacy PXE bootfiles ended in .kpxe rather than .efi, which some machines need. Would you be able to create a standalone DHCP server to test with? I have used dnsmasq before, but I generally prefer ISC DHCP, I recommend using a dedicated physical box running that just to test with, that way you dont need to worry about strange virtual devices doing strange things. If you do decide to test with a standalone DHCP server, let me know and I can help you set it up if needed, I have a guide for that on my wiki.
 
So the issue exists both with your virtual machines and physical ones? If so that may rule out VMware weirdness, though moving over to virutalbox (or a hypervisor like Proxmox) could be a good option to test with. I assume all of your machines are configured to EFI boot? IIRC the older legacy PXE bootfiles ended in .kpxe rather than .efi, which some machines need. Would you be able to create a standalone DHCP server to test with? I have used dnsmasq before, but I generally prefer ISC DHCP, I recommend using a dedicated physical box running that just to test with, that way you dont need to worry about strange virtual devices doing strange things. If you do decide to test with a standalone DHCP server, let me know and I can help you set it up if needed, I have a guide for that on my wiki.
Problem is solved, see my post right after the one you quoted.

TLDR; dhcp-ignore option was set for clients presenting themselves as PXEClient. And, the dhcp-option, dhcp-boot, and dhcp-range settings needed to be set in /etc/dnsmasq.conf instead of through UCI via SSH.
 
Back
Top