Meraki Z1 OWRT 19.07 WAN DHCP problems

I have several devices: direct ethernet port on PC, old "dumb" router and a new OpenWRT. ISP provides addresses on DHCP request from the device, the ISP has a permanent MAC whitelist for a single device. For some reason neither the default configuration, nor other options ticked in the WAN interface allow the OpenWRT device to get the address.

OpenWRT correctly asks for the proper external address, but the ISP device constantly returns "DHCP NACK". After ~100 tries ISP device gets bored, gives it an internal LAN address 10.X.X.X, but doesn't allow it to visit the net.

I have tried calling the tech support, but the OpenWRT router could not reach their place properly. In the end the tech guy whitelisted the PC MAC address. Spoofing it on the dumb router works fine, but spoofing on the OpenWRT does not work, it experiences the above mentioned problem. WAN interface lists ~10MBs of RX, just several 10KBs of TX, some packets are coming in, but ISP does not let it through properly.
Connecting the OpenWRT device to the dumb router works fine, that how it works right now. I have searched the forum and someone mentions that an additional option/options should be provided, but what could they be? And where can they be found (PC is running Linux). Any help would be appreciated!

There is an another topic with a problem similar to mine, but it got auto-locked.

The usual advice would be to upgrade OpenWrt 23.05.0 first (for security reasons alone!), maybe that already 'fixes' udhcpc's behaviour already. However the Meraki Z1 doesn't appear to have been ported from ar71xx to ath79 (the specs would allow this, ar9344+ar9344+ar9280, 128/128), which is a problem - either you should look into porting it to ath79 and current OpenWrt (master) yourself or switch to supported hardware. 19.07.x has been EOL for over 1.5 years already, so you won't find that many who'd look into the details with it anymore, especially as nothing would be 'fixed' in that codebase anymore anyways…

That aside, 19.07.x/ ar71xx has been used by many users and their various ISPs for 2+ years (and as it builds the basis for a few commercial SDKs as well, you'd see similar issues with commercial devices as well, which would put the ball back into the ISP's court) - and I don't remember (but it's been years, so memory fades…) any similar issue reports about something like that. Some ISPs have quite weird requirements in terms of non-standard fields in the DHCP request and luci has gotten more tricks in its sleeve regarding that recent versions, which might help with your situation as well. MAC cloning should work (no, I cannot make a firm statement about that for ar71xx in 19.07, I've already been on ath79 by then, but it 'should'), but depending on the networking setup it might require one out of two potential approaches.

In short, upgrade to current -security supported- OpenWrt for further debugging first. In the short term that would imply switching to different -supported- hardware, unless you're up for a challenge to do the necessary development work yourself (steep learning curve, but within the realm of possibilities).


Considering that 19.07.x is quite old, how did you get into this situation?
Has this scenario (with the Meraki Z1 and OpenWrt 19.07.x) worked for you before or did your working setup break suddenly (eventually caused by ISP side changes)?
Did you change ISPs?
Did you switch hardware?
Could the hardware have aged/ gotten broken over time (this hardware would be ~11 years old by now, PSUs can age over that time, capacitors die, etc. pp. - some issues more subtle than others)?

2 Likes

Thanks for the elaborate answer, but it is what it is. Updating to an unstable software or swapping hardware is not an option for me.

As mentioned above every other piece of hardware does DHCP requests properly. Again, OpenWRT receives DHCP from a dumb router just fine, it's DHCP on the ISP side it has problems with. The linked thread mentioned pretty new hardware, presumably with a newer software, so the problem persists across OpenWRT distributions. The thread died before we could get an answer what was the reason.
I believe the problem lies somewhere in the DHCP client software used in OpenWRT.

After a bit of tinkering I have managed to bring it up. Can't check if everything is rock solid, just marking this as a note. Too afraid to even reboot the device now.

Immediately after installation of dhcpcd package the log went much more verbose:

daemon.info [dhcpcd]: eth0.2: offered 10.X.X.X from %DNS_SERVER%
daemon.warn [dhcpcd]: eth0.2: ignoring offer of 10.X.X.X from %DNS_SERVER%
daemon.warn [dhcpcd]: eth0.2: NAK: from %DNS_SERVER%
daemon.notice netifd: wan (%PID%): udhcpc: sending select for %PROPER_WAN_IP%
daemon.notice netifd: wan (%PID%): udhcpc: received DHCP NAK

Here are the approximate steps to beat the WAN DHCP problem:

  1. WAN interface flags (they should not matter anyway, because we are not using udhcpcd anymore):
  • force link ON
  • broadcast OFF
  • default gateway ON
  • use peer DNS OFF
  1. install dhcpcd, it should automatically add a service
  2. Changes in /etc/init.d/dhcpcd:
  • /sbin/dhcpcd should have -B -J --lastlease (lastlease might be useless, but it works)
  1. Changes in /etc/dhcpcd.conf:
  • uncomment clientid, comment 'duid'
  • comment dhcp_server_identifier line
  1. Try your luck with 'dhcpcd -B -J eth0.2', it should stop ignoring DHCP server responses.

Unfortunately the WAN port diode is constantly lighting up and down, like it has a problem connecting anywhere.

These are coming from your ISP... OpenWrt doesn't have any ability to change what the ISP's DHCP server does in terms of the DORA process... in this case, your router is being told that it cannot take a lease of 10.x.x.x (which, BTW, is not a public IP).

I would suggest that you ask your ISP (again, ask to talk to tier 2 or tier 3 support) what the are seeing on their end that is causing these NAKs.

Also...

You shouldn't need to install a DHCP daemon... this functionality is built-in by default to any normal OpenWrt image.

What is the output of

ubus call system board

I understand that 10XXX is a LAN address, the internal address of mine, a client. The next step is getting the %PROPER_WAN_IP%, which router could not perform using a default busybox dhcp client package. Performing the above mentioned steps (in a post marked as solution) resolves the problem of connection to this ISP's DHCP server.

Again, search forums, there are lots of unresolved topics with a problem very similar to mine on default installations of various versions of an OWRT, which means that it has something to do with the packages in default installations. I believe packing the "fullest" dhcp client package is a must for all kinds of UNIX based router distributions nowadays. Never had a problem like this with either OpnSense or pfSense.
Contacting the small local ISP would not result in something productive because i am not a business client. Anyway all they could say was: "the packets aren't coming".

Here you go, the info about the MerakiZ1 router with OWRT19.07:

{
	"kernel": "4.14.275",
	"hostname": "linksys",
	"system": "Atheros AR9344 rev 2",
	"model": "Meraki Z1",
	"board_name": "z1",
	"release": {
		"distribution": "OpenWrt",
		"version": "19.07.10",
		"revision": "r11427-9ce6aa9d8d",
		"target": "ar71xx/nand",
		"description": "OpenWrt 19.07.10 r11427-9ce6aa9d8d"
	}
}

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.