1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Stupid mistake locked me out of my router. Help please.

Discussion in 'Tomato Firmware' started by opmetal, Jul 2, 2013.

  1. opmetal

    opmetal Reformed Router Member

    Long story short while setting up a new cable modem I set my router's WAN IP to a static (I changed it from DHCP) and now can't get back into it via the web console or ssh. I would hate to have to re-flash it and enter all my settings manually (I also don't have a config backup - ugh!).

    It's a Belkin (Sharemax N300) f7d7301 running tomato-K26USB-1.28.7497.1MIPSR2-Toastman-RT-Ext.trx.

    Ideally I'd change a couple of nvram settings and reboot but I don't know how to do this. Can anyone point me in the right direction, please?

    Thanks for any help.
  2. Malitiacurt

    Malitiacurt Networkin' Nut Member

    The router's WAN IP/configuration is wrong at the moment but it shouldn't affect access from the LAN side.

    Is it cause your new cable modem is a modem/router combo and also has an IP of If so, disconnect ethernet cable from WAN on router.
  3. Monk E. Boy

    Monk E. Boy Network Guru Member

    Yes, if you disconnect the Ethernet cable from your WAN port your LAN should certainly be functional, at least over LAN Ethernet.
  4. opmetal

    opmetal Reformed Router Member

    The cable modem is disconnected so that doesn't factor into it.

    The problem is that my LAN is on the 192.168.1.x network and this router's LAN IP hasn't changed, it's still But now both LAN and WAN IPs are the same. When I connect a laptop via cable it gets an IP from the router but then I can't ping the router.
  5. Monk E. Boy

    Monk E. Boy Network Guru Member

    Are you sure it gets a 192.168.1.x address? Or is it getting a self-assigned IP address? (169.254.x.x)

    Try manually assigning to the ethernet card and see if responds.

    Did you have telnet or ssh enabled by any chance? It's possible the web server is crashed but one of the others could still be functional.
  6. opmetal

    opmetal Reformed Router Member

    Yes I'm sure as it gets I did try a static IP of but it still can't get to I do have ssh enabled but can't get to it, either.
  7. PetervdM

    PetervdM Network Guru Member

    what if you connect your ws with the static address of to the wan connector instead of the lan connector?
  8. opmetal

    opmetal Reformed Router Member

    Good idea but still no go. Can't ping or connect to router.
  9. PetervdM

    PetervdM Network Guru Member

    do you have a link pulse? maybe you need a cross cable or a switch inbetween.
  10. mstombs

    mstombs Network Guru Member

    I haven't had need for cross cable for years, doesn't everything auto-sense these days?

    The routers route table is fubared. I suspect router replies out the wan interface when accessed on lan, but default firewall rejects connections from the wan to the lan ip address! I don't think combining the ports externally with a hub will help, because a MAC address can have many IPs but not the other way round!

    This sort of thing is easy to do during firmware development on an Ethernet router - a serial console cable can be a big help - if you don't have that I don't think you any option but to press reset and re-enter all your config (no need to reload firmware).
  11. opmetal

    opmetal Reformed Router Member

    Yeah I also tried a crossover cable on both the WAN connector and regular LAN connectors.
  12. opmetal

    opmetal Reformed Router Member

    Yeah I don't have a serial console in this case. That would entail taking the thing apart, which is probably more work than re-entering my config.

    Ok so will a 30/30/30 reset wipe the nvram and put it back to my "stock" Toastman firmware? I'm thinking this is my only remaining option.
  13. Malitiacurt

    Malitiacurt Networkin' Nut Member

  14. Monk E. Boy

    Monk E. Boy Network Guru Member

    Yup, you need to do a nvram reset (depending on the router that means holding the reset button or the WPS button), at which point the firmware on the device will be back to factory settings. You don't need to place another firmware on the device unless you're unhappy with the one its currently running.

    In other words, resetting nvram doesn't erase Toastman's firmware from the router, it just wipes settings from Toastman back to stock values.

    You may want to switch to a custom LAN subnet to avoid any possibility of this happening in the future. 172.16.0-31.x is infrequently used, at best, by ISPs. With 10.x.x.x you can come up with any two number combinations and for your class C and you'll be unlikely to see that same combo on the WAN port.
  15. opmetal

    opmetal Reformed Router Member

    Thanks for the clarification. Did the 30/30/30 and erased nvram, re-entered all my settings and took a config backup ;) Everything is back to working.
  16. opmetal

    opmetal Reformed Router Member

    Thanks everyone for your quick assistance. Great forum!

  17. Monk E. Boy

    Monk E. Boy Network Guru Member

    I'm still amazed the DHCP server was able to respond/send queries on the interface with the IP stack basically blown to smithereens.

    You learn something every day.
  18. koitsu

    koitsu Network Guru Member

    Barring routing table anomalies, I can actually explain how this would work -- it has to do with the fact that packets are tracked/bound (within the kernel/internally) to an interface. It doesn't matter if a packet goes out eth0 with a source address of -- the exact same can happen if the packet goes out eth1 or vlan2 or br0 or anywhere else.

    You see, the the DHCP server (dnsmasq) software is still going to be sending out packets across that Ethernet port that have the IP source header set to, and the daemon is still going to be listening on INADDR_ANY on UDP port 67, so communication with a client in space connected via LAN would still happily work. That doesn't surprise me at all.

    Routing-table-wise, however, things are a total mess as mstombs said. I imagine to some degree some firewall rules would be too (heed my words: now you understand why whenever I poke about in iptables you will see me ranting/raving about the fact that so many rules on these routers lack -i xxx for specifying an interface -- it's dangerous unless you really want it to be that way!); packet forwarding would be completely and entirely buggered.

    You want to know what does surprise me? If I'm reading this right, it would mean that potentially Linux had permitted assignment of to two interfaces simultaneously: vlan2 and br0. That, if it is what happened, is utterly broken behaviour, if you ask me. Of course I'm speculating as to that actually happening -- this is where serial console would be a blessing, because one could reproduce this mistake + get on serial console and start poking about with ifconfig -a, netstat -rn, arp, and so on, just to see what "state" the system is in.

    It could honestly be that Linux didn't allow two interfaces to have the same IP, but the NVRAM variable change + daemon restarts really confused the hell out of everything (daemons/software thought one thing, including iptables, while the kernel/rest of the stuff thought something else). Lots of the software/daemons/etc. on these routers rely on reading those NVRAM variables -- there is just a blind assumption that "everything is in sync". Nature of the beast...
  19. mstombs

    mstombs Network Guru Member

    Linux doesn't restrict IPs to interfaces. In my understanding the kernel owns the IP and just publishes it out an interface - which is why there is an explicit rule in the firewall to prevent connection to the LAN IP via the WAN port, and the fiddling around in iptables rules to provide the 'WAN IP local nat loopback' functionality. By default the router would be happy to allow connections from the lan to itself using its WAN IP. There was a lot of discussion in forums years ago about the Linux kernels tendency to use all available interfaces and there was even a 'hidden' patch which was proposed to allow more control - but I think it was rejected in favour of explicit filtering rules. Note the router can also respond on an interface on behalf of IPs owned by other devices behind another interface using 'proxy_arp' - useful in building transparent routing operations (as required in half-bridge modems, for example).

    I assume dhcp worked because it is broadcast/unicast udp before the client uses the ip it is given?
  20. koitsu

    koitsu Network Guru Member

    Well I just tried it out on my Debian VM (with two NICs) -- sure enough I can assign both eth0 and eth1 the same IP address and as part of the same netblock. netstat -rn just makes me laugh. Remarkable.

    Below I'm talking about IPv4 DHCP (i.e. DHCPv4):

    1. DHCP worked, and continued working, because the client broadcasts a packet on the broadcast address (ex., or possibly in some cases) for a DHCP server to respond -- this is called DHCPDISCOVER.

    ARP would have been working at this point too (almost certainly I would think) so I won't discuss that part.

    2. The server (router + dnsmasq) on the router sees DHCPDISCOVER (because there's no reason it wouldn't, given that it's on a LAN segment (br0 presumably) still has assigned to it), and responds to it -- this is called DHCPOFFER.

    The response packet from the server would have an IP source address of because that's what dnsmasq would use when creating the IP packet (not the DHCP part of the payload).

    3. The client then would get the DHCPOFFER and respond back to acknowledging its offer, but with some additional parameters ("hey I want this stuff if possible") -- won't go into the DHCP option semantics here -- and this is called DHCPREQUEST.

    4. The server gets the DHCPREQUEST and responds (assuming it approves it) with DHCPACK.

    5. The client sees DHCPACK, assigns the IP it was given to its interface, along with any DHCP options it was given (NTP server, default gateway, DNS servers, blah blah) and goes along its merry way using what it was given.

    Renewal is a different and much shorter situation:

    1. Client sends DHCPREQUEST to the server directly.

    2. Server responds with DHCPACK.

    There's also a form of "rebinding" where it's identical to renewal except instead of the client sending DHCPREQUEST to the server, it sends it to the broadcast (either or and the behaviour is the same. I don't have much familiarity with this scenario.

    Anyway enough about DHCP.

    The problems would begin when packets on the client system got forwarded through They'd arrive at the router, which would then say "I need to forward this, because the destination is not something within my own routing table, so punt these out my default gateway", except the IP of the WAN (vlan2 presumably) was also, which surely confused things. If it didn't confuse things, the packet got NAT'd and forwarded out the WAN interface coming from a source address of, and I pray the users' ISP blocked that before it made it out onto the Internet (proper ISP routers will blackhole any reserved IANA space before such traffic can get anywhere close to an Internet-facing border router -- but lots of ISPs, particularly in third-world countries, don't do this so folks are allowed to spew crap all over the Internet with "spoofed IPs", as you will). It's also possible that the actual routing tables on the router were really messed up and the packet instead of being forwarded just went off into lala land. Same could happen with certain iptables configurations. Then there's the NAT piece too, of rewriting headers/etc. before it goes out the WAN along with port number mappings, and who knows if that happened.

    I'm having to grasp at straws here though because there's no hard evidence as to what the condition of the router was in. We just know "I made this mistake", we don't really know what ramifications it had on the actual kernel and underlying systems (routing, iptables, conntrack tables, possibly ARP, etc.). This is why if the user had serial console, he could have gotten on and actually got all that info and it would have made for an interesting examination case. The solution though is still the 30/30/30 method -- it just isn't worth futzing around otherwise.

Share This Page