DHCP: pilot error led to bricked router

Hi,

Newbie to OpenWRT, but fairly Linux/network fluent. Set up DHCP to start at 50 with limit 250 (my bad, thought it was a start-end, not a start-length). There is a bug hiding there somewhere. Auto-revert didn't work. The router continued functioning but could not login to it (web or ssh). In the end, used the debricking power option https://openwrt.org/toh/linksys/linksys_wrt3200acm#power_switch to restart with stock firmware, and then continued from backup.

Lessons learnt:

  1. debricking
  2. read the page before submitting
  3. keep a recent backup of your config.

LinkSYS WRT3200ACM (4 of them).

Michael Hirsch

1 Like

Welcome Michael!

A series console is always a good idea when getting into this kind of thing. For the device you linked, it looks like it's internal rather than easily accessible, but might be worth taking a look for the future if you are going to play with OpenWrt at anything but the flash and forget level (and even then....)

Something similar to https://www.amazon.com/JBtek-WINDOWS-Supported-Raspberry-Programming/dp/B00QT7LQ88/ (There are some device specific notes listed about the console interface for your device, I'd highly suggest taking a look at that section!)

If you had this, you could have manually changed the config settings rather than de-bricking and reflashing.

1 Like

triggering failsafe with the reset button is vastly easier than whatever you did

3 Likes

For posterity: A misconfigured DHCP server can never "brick" a router (besides "bricked" being the wrong term here anyway.)

Without any deeper insight into the concrete network setup, I would guess that you lucked out and DHCP assigned your client one of the IPs that spilled over into the next network segment.

E.g., if your LAN is at the default 192.168.1.1/24, and you erroneously set DHCP to start at .50 with limit 250, 45* of those IPs would spill over into the next range, i.e. into 192.168.2.1~192.168.2.45, which the rest of the router's configuration does not recognize as LAN. Reconnecting wouldn't help either because DHCP assigns IP addresses pseudorandomly based on the client's MAC address, would still be assigned the same one every time.

*) don't quote me on that exact number, there might be one or more off-by-one errors in there, but you get the point

However, I don't see why you couldn't still manually set your client to an IP in the router's LAN range. Following the above example, if you manually set 192.168.1.2 for your client, you would be able to connect again and correct your mistake.

You mean the spillover? Nope. Granted, the setting is a bit clunky, but that's intended behaviour, some people want/need to use a larger range than /24, and DHCP to give out IPs across a larger range too.

3 Likes

It it helps, this was an otherwise unused VLAN destined to become a guest network. My laptop received its IP on the default LAN (with DHCP from a different server).

Thanks for the suggestion. Fairly comfortable with serial from ESP8266. This was the next option but hesitant to open the box to get to the serial header.

Thanks for pointing this out. Fairly sure there will be a next time :grinning:

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