EA7300(v1) with Openwrt install went haywire

Hello Folks,

In the far away past, I did install dd-wrt in an Asus Router and had to solder a header on the Asus router in order to be able to connect a usb-uart serial interface to the router using ttl logic. It worked fine back then. Recently, I used different approaches in order to flash an OpenWrt firmware to a Netgear R7900P; including using a usb-uart-ttl (cp2102) via a CFE terminal access (minicom) and also tried using nmprflash, all to no avail (always had invalid image error or checksum error) – was able to flash Netgear’s factory firmwares to this router using both the CFE and the nmprflash. Amazingly enough, I was able to flash a Linksys EA7300 router using OpenWrt by simply using Linksys webinterface without any incident; but now, I facing some issues due to some configuration mishaps regarding the Linksys EA7300.

The EA7300 was hooked up via its WAN port to another router’s LAN port (the R7900P, using netgear firmware). The R7900P was using 192.168.1.0/24 subnet, and the EA7300 (with OpenWrt installed) was using 192.168.4.0/24, and everything was quiet on the Western Front. Then, a virtual bridge interface was configured for Guest-Wifi on the EA7300, all Guest wifi clients were connected to the EA7300 and working just fine. For guest wifi (managed by the EA7300) another subnet was created, consisting on 192.168.5.0/24, has it’s own dhcp server, parameters were properly configured, etc; and everything was working good.

Then, I decided to create one single subnet for both the two routers, but having each using its own dhcp server by using a different range ips for each dhcpd server; as follows: 192.168.0.0/24 (192.168.0.0 with netmask 255.255.248.0). I should have made more consideration before taking those steps, but at first everything was working ok. But, I did somet changes in cascade (mostly related to the dhcp server and the interfaces) without testing each individual change and now, and quite possibly a typo while entering configurations via luci. As of now, I have no access to the EA7300 – it does not lease any ip configuration to clients, can not ping (yeah, I configured the computer interfaces (eth0, etc) manually, etc) the EA7300, not able to ssh into the router, nothing. When I try to request a lease the ip configuration from the router, it gives an error related to the DHCPv6 (the router is connected via ethernet to a Linux Slackware64 current, and I use dhcpcd to request a lease). In spite of everything, the EA7300’s wifi guest network (dhcp server, internet connection, etc) is working fine, but I am unable (so far) to access the router itself via the wifi guest network (only mobile phones use it). Tried to failsafe the router during boot-up, tried to reset it, and nothing seems to work. Maybe, I am missing something simple given that the router clearly is not dead.

One of the two firmwares were installed in the router:

root@darkstar:/opt/routers_firmware/EA7300/factory# ls -lh
total 9.2M
-rw-r--r-- 1 root root 9.2M Sep 24 04:49 openwrt-23.05.5-ramips-mt7621-linksys_ea7300-v1-squashfs-factory.bin
root@darkstar:/opt/routers_firmware/EA7300/factory# ls .. -lh
total 5.5M
drwxr-xr-x 2 root root 4.0K Feb 12 17:44 factory/
-rw-r--r-- 1 root root 5.5M Sep 24 04:48 openwrt-23.05.5-ramips-mt7621-linksys_ea7300-v1-initramfs-kernel.bin
root@darkstar:/opt/routers_firmware/EA7300/factory# 

Almost sure that the squash images was installed.

Thanks for any input.

As you've already discovered, this is not possible -- it will break in a few different ways, depending on how things are actually connected right now and the details about how you did the configuration.

Given your situation, I would suggest that you take the easy route back to a known-good configuration. That is, reset the Linksys device to defaults.

To do this, disconnect it from everything, including power. Plug an ethernet cable into one of the lan ports and the other end into your computer (turn off wifi, make sure this is the only network connection). You'll need to set a static IP on that computer, and then power on the router and enter failsafe mode -- the specifics of all of this is in the failsafe wiki article.

Once you're there, you can reset by simply issuing

firstboot -y && reboot

This will reset your Linksys back to defaults.

Before you begin configuring again, please explain your goals (as in, what you hoped to achieve when things went south).

The initial objective was to have both routers within the same subnet domain, but still distinguishable parts of the network. I made a typo, instead of “192.168.0.0/24 (192.168.0.0 with netmask 255.255.248.0)” it should be “192.168.0.0/21 (thus, netmask 255.255.248.0). The R7900P would operate in the segment 192.168.1.0 (sort of a routing prefix) and the OpenWrt (EA7300) would operate in the segment 192.168.4.0 (sort of another routing prefix); the IP for the routers themselves would be 192.168.1.1 (dhcp server serving leases in the range 192.168.1.40-192.168.1.250) and 192.168.4.1 (dhcp server serving leases in the range 192.168.4.40-192.168.4.250), respectively.

The design goal was mainly redundancy. In case one router is removed (replaced, repaired, reflashed, etc), the network would continue to chug along with minimum changes. Being the same subnet would imply that they both routers would be in the same broadcast domain, thus with less overhead, latency and potential issues among hosts trying to communicate within the different subnets. I did not plan ahead, simply got inspired by the way the wifi guest network operates (albeit, the wifi guest network is more insulated and operated on its own subnet) and started making changes without any planing or considerations.

One mistake I probably in this initial phase was to connected the R7900P to the WAN port which act as a bridge (I believe it has no actual physical bridge hardware or logic built in the WAN port) since it has a gateway, it probably also has a firewall configured, etc. If the WAN port is actually just another LAN port configured by softeware, I imagine that it could be configured to act more like a LAN port. I have to educate myself regarding those matters and the many aspects of OpenWrt (so much potential and flexibility)

I tried to reboot the EA7300 in failsafe mode earlier today, but it not work out. I tried the following approach to get the router in failsafe mode:

“
The LEDs provide clues for timing the button press. Watch the LED blinking speeds immediately after powering up the router. Most routers show three different (power) LED blinking speeds during boot:
• A power-on sequence of lights that is specific to the device's bootloader
• Then a semi-rapid 5-per-second blinking rhythm during four seconds, while router waits for a button press
• Then either:
â—¦ A really fast 10-per-second blink if failsafe mode was triggered. The device is listening on 192.168.1.1
â—¦ A slower, 2.5-per-second blink continuing to the end of normal boot, if the failsafe was not triggered
• If you missed the timing and see the slower blink rate, just power off the device, wait a couple seconds, and try again.
“
I assume that the sequence of commands must be entered once one has access to the router via terminal or a ssh session. I entered static IP for the ethernet port connected to the router (ifconfig eth0 192.168.1.1 netmask 255.255.255.0). Maybe my timing was off. I will try back tomorrow.

Thanks!

This is fine, and even a good thing. However, only one can run a DHCP server.

Typo or not, this is not a valid approach. There is no need to go with a larger subnet, though -- the key fact here is that only a single DHCP server is allowed. Typically, this will be on the main router. The other device will operate as a basic bridged switch/AP and its DHCP server will be disabled. It's certainly possible for the second device to setup a guest/iot network or whatever that is routed and independent of the primary network.

In general, ports can be re-assigned however they are needed within OpenWrt. So don't get hung up on the port labels... what matters is the network configuration to which those ports are assigned.

First, you need to do the hardware part of entering failsafe mode... For most (but not all) devices, that involves rapidly clicking (spamming) the button on the router or sometimes holding it down immediately upon applying power, and looking for that fast blinking sequence.

This should happen before, but your computer must not be set to 192.168.1.1 -- that's the address of the router. You can use 192.168.1.2/24 on your PC.

Once the LED is blinking rapidly, you can ssh (ssh root@192.168.1.1) into the router and reset it to defaults.

Just to address this… what you are talking about here is known as high availability. But achieving HA is rather complicated and requires advanced networking skills to configure properly. It is not trivial to implement, and is not a standard feature or commonly implemented technique with OpenWrt or even small business routers

For all practical purposes, the best approach is to have a cold spare (in other words, a router that is pre-configured but not plugged in; if/when needed, swap it in, physically replacing the one that is down.

1 Like

You raised very good points. I understand that splitting the ip addresses (two addresses scopes) between two dhcp server within the same subnet can be prone to issues, especially in devices that were not design for that. In more complex networks, though, it would create more redundancy (high availability) and also help with the load balance (I read a lot about those topics when studying for the Server+ long time ago).

But in my case, at first, I had both dhcp server working in conjuction (different ranges/scopes of ip addresses for each within the same subnet), and it was working well at first. At some point, I did a series of different changes; I believe that I made some changes regarding the DHCPv6 among other changes; and then everything went haywire. I need to refresh some aspects of my knowledge regarding tpc/ip networks and learn more about OpenWrt itself. It also is not clear to me what role does IPv6 addressing plays in a LAN (if any).

Having a two identical routers with the same baseline configuration is the safe bet in my situation. But wouldn’t subnetting be a safe alternative as well (albeit with the issues of latency, overhead, etc), like having each router within different subnet broadcast domains. Having both routers within the same subnet and using each with its own dhcp server and using different ip scopes is not something I will try for the time being.

I was able to rejuvenate the router, and now have access to it. The failsafe mode did not quite work as intended. I followed your advice and kept pressing the WSP button on and off as the router was powered on, then the “Linksys” light started to blink quickly. After that, I was able to ping the router (192.168.1.1), but once I tried to ssh into the router it kept asking for a password (tried the typical default passwords, and my previous ones) and it refuted all the passwords entered. So, I power cycled the router and then had normal access to the router web interface (luci) with all the default configurations; it seems that the router was reset. Anyhow, it all worked out in the end.

Thanks for your inputs!

Yes, but in these networks, the DHCP servers are coordinating with each other... load balancing / fail-over, but still working with a shared DHCP lease table. It's only necessary for very large networks or (properly designed) HA.

I think you got lucky that it was working properly.... while a conflict of address space is obviously not an issue in your case, you can have a bunch of NAKs and other issues when clients go to renew their lease. That can cause all sorts of problems.

I'm not really an IPv6 expert, but assuming you're talking about globally routed IPv6, this is going to come from the upstream, so attempting HA as you've proposed won't work properly.

This is not exactly trivial to achieve... the latency and overhead isn't the issue, but rather the fact that you're still dealing with single-point-of-failure situations for ~half the network.

Good. Like I said, you're best served by a single DHCP server on a single router.

Glad it is working now!

2 Likes

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