Newly reset openwrt router, problems accessing web

I recently reset (mount_root, firstboot, reboot -f) a router (it was working -mostly- fine but could no longer ssh to it)
now, once I ssh to it, I cannot ping reliably to a network hostname or IP address. This makes opkg update very unhappy.

Here are two pings pretty much simultaneously from two different windows that were ssh'ed into from my laptop to the newly reset router:

root@OpenWrt:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: seq=22 ttl=118 time=1975.550 ms
64 bytes from 8.8.8.8: seq=23 ttl=118 time=974.537 ms
64 bytes from 8.8.8.8: seq=24 ttl=118 time=26.202 ms
64 bytes from 8.8.8.8: seq=25 ttl=118 time=25.061 ms
64 bytes from 8.8.8.8: seq=26 ttl=118 time=24.720 ms
64 bytes from 8.8.8.8: seq=27 ttl=118 time=24.994 ms
64 bytes from 8.8.8.8: seq=28 ttl=118 time=24.402 ms
64 bytes from 8.8.8.8: seq=29 ttl=118 time=24.473 ms
64 bytes from 8.8.8.8: seq=30 ttl=118 time=27.002 ms
64 bytes from 8.8.8.8: seq=31 ttl=118 time=26.755 ms
64 bytes from 8.8.8.8: seq=32 ttl=118 time=26.393 ms
64 bytes from 8.8.8.8: seq=75 ttl=118 time=1030.826 ms
64 bytes from 8.8.8.8: seq=76 ttl=118 time=26.019 ms
64 bytes from 8.8.8.8: seq=77 ttl=118 time=24.166 ms
64 bytes from 8.8.8.8: seq=78 ttl=118 time=30.817 ms
64 bytes from 8.8.8.8: seq=79 ttl=118 time=24.940 ms
64 bytes from 8.8.8.8: seq=80 ttl=118 time=25.732 ms
64 bytes from 8.8.8.8: seq=81 ttl=118 time=24.909 ms
64 bytes from 8.8.8.8: seq=82 ttl=118 time=24.978 ms
64 bytes from 8.8.8.8: seq=83 ttl=118 time=26.598 ms
64 bytes from 8.8.8.8: seq=84 ttl=118 time=25.235 ms
64 bytes from 8.8.8.8: seq=126 ttl=118 time=971.681 ms 
64 bytes from 8.8.8.8: seq=127 ttl=118 time=27.603 ms
64 bytes from 8.8.8.8: seq=128 ttl=118 time=25.456 ms
64 bytes from 8.8.8.8: seq=129 ttl=118 time=24.790 ms
64 bytes from 8.8.8.8: seq=130 ttl=118 time=27.964 ms
64 bytes from 8.8.8.8: seq=131 ttl=118 time=25.062 ms
64 bytes from 8.8.8.8: seq=132 ttl=118 time=25.580 ms
64 bytes from 8.8.8.8: seq=133 ttl=118 time=30.217 ms
64 bytes from 8.8.8.8: seq=134 ttl=118 time=24.959 ms
64 bytes from 8.8.8.8: seq=135 ttl=118 time=26.026 ms
^C
--- 8.8.8.8 ping statistics ---
167 packets transmitted, 31 packets received, 81% packet loss
round-trip min/avg/max = 24.166/182.375/1975.550 ms

root@OpenWrt:~# ping yahoo.com
PING yahoo.com (98.137.246.7): 56 data bytes
64 bytes from 98.137.246.7: seq=20 ttl=44 time=2005.585 ms
64 bytes from 98.137.246.7: seq=21 ttl=44 time=1004.774 ms
64 bytes from 98.137.246.7: seq=22 ttl=44 time=98.909 ms
64 bytes from 98.137.246.7: seq=23 ttl=44 time=95.550 ms
64 bytes from 98.137.246.7: seq=24 ttl=44 time=97.769 ms
64 bytes from 98.137.246.7: seq=25 ttl=44 time=97.185 ms
64 bytes from 98.137.246.7: seq=26 ttl=44 time=95.653 ms
64 bytes from 98.137.246.7: seq=27 ttl=44 time=96.786 ms
64 bytes from 98.137.246.7: seq=28 ttl=44 time=97.472 ms
64 bytes from 98.137.246.7: seq=29 ttl=44 time=96.565 ms
64 bytes from 98.137.246.7: seq=30 ttl=44 time=96.016 ms
64 bytes from 98.137.246.7: seq=73 ttl=44 time=1032.209 ms
64 bytes from 98.137.246.7: seq=74 ttl=44 time=97.084 ms
64 bytes from 98.137.246.7: seq=75 ttl=44 time=95.420 ms
64 bytes from 98.137.246.7: seq=76 ttl=44 time=101.712 ms
64 bytes from 98.137.246.7: seq=77 ttl=44 time=96.096 ms
64 bytes from 98.137.246.7: seq=78 ttl=44 time=97.080 ms
64 bytes from 98.137.246.7: seq=79 ttl=44 time=100.372 ms
64 bytes from 98.137.246.7: seq=80 ttl=44 time=96.438 ms
64 bytes from 98.137.246.7: seq=81 ttl=44 time=98.292 ms
64 bytes from 98.137.246.7: seq=82 ttl=44 time=102.709 ms
64 bytes from 98.137.246.7: seq=124 ttl=44 time=971.308 ms
64 bytes from 98.137.246.7: seq=125 ttl=44 time=99.012 ms
64 bytes from 98.137.246.7: seq=126 ttl=44 time=96.369 ms
64 bytes from 98.137.246.7: seq=127 ttl=44 time=96.283 ms
64 bytes from 98.137.246.7: seq=128 ttl=44 time=99.077 ms
64 bytes from 98.137.246.7: seq=129 ttl=44 time=96.350 ms
64 bytes from 98.137.246.7: seq=130 ttl=44 time=96.962 ms
64 bytes from 98.137.246.7: seq=131 ttl=44 time=101.488 ms
64 bytes from 98.137.246.7: seq=132 ttl=44 time=96.484 ms
64 bytes from 98.137.246.7: seq=133 ttl=44 time=96.660 ms
^C
--- yahoo.com ping statistics ---
166 packets transmitted, 31 packets received, 81% packet loss
round-trip min/avg/max = 95.420/246.763/2005.585 ms

If I connect my laptop directly to the parent router, and ping from the laptop, it is 100% consistent. I am a little more that concerned the router is somehow dead!

Any suggestions?

I see no problem?

  • Is this the problem?
  • Do you have the packet loss with the directly-connected machine?
  • Is web actual web browsing having an issue?

the very first ping time is over one second for 8.8.8.8 and nearly 2 seconds for yahoo.com (in reality each was closer to a minute)
there are two in the middle for around 1 second (again, significantly more by clock time)
81% packet loss is not very good either

I am not sure what/where the problem is, but I am unable to update any of the software on the router because opkg times out and fails

If I connect around the router, everything works fine 100% of the time and I have no browsing issues.

That looks terrible... How is this device connected to the main router? And how was it configured?

Also how does pinging the router from your PC do?

1 Like

I have a cable modem connected to an openwrt router (working fine). It is connected to a 24 port switch, that is connected to another 8 port switch that the bad openwrt router is connected to via its WAN.
I can connect to a LAN port of the bad router with my laptop or I can connect to the 8 port switch with my laptop.
When I connect to the 8 port switch with my laptop and ping anywhere, I get great results.
When I connect to the good router and ping anywhere, I get great results.
When I connect to a LAN port on the bad router and ping as shown above, I get the results shown.
Pinging from my laptop to the bad router is 100%
Pinging from the bad router to the laptop is 100%
Trying to find the IP address of the bad router (from the router itself) I tried:
wget http://ipecho.net/plain -O - -q
When it finally was able to connect, it returned nothing - so I don't know the WAN address of the bad router and cannot ping to it from the WAN side.

That's, likely, a managed switch?

For the sake of testing, did you try connecting the bad router directly to the modem and see if it shows the same problem?

They are all dumb switches.

I finally had some time alone so I could switch out the routers. The "bad?" router works fine when connected directly to the cable modem. I was able to opkg update with no issues (but when I tried installing luci, there was a conflict - but that's fodder for another thread...)
I am now looking at all of the cables in my equation and testing the ports...

This is so strange... I have buzzed out the cables with a tester and they are fine. I have three other routers that I have configured (not that I'm an expert by any stretch, but I have been down this road before) and they all have worked as I thought they would. I am ultimately using the routers as access points (everything connecting to their LAN ports, ignoring the WAN port) but I need to be able to configure them and this is how I have done it in the past:


     CABLE MODEM
          |
          |
       wan port
      GOOD ROUTER
       lan port
          |
          |
       lan port
        SWITCH
       lan port
          |
          |
       lan port
        SWITCH
       lan port
         | |________
         |          |
     wan port       |
    BAD ROUTER      |
     lan port       |
         |          |
         |          |
   LAPTOP ___or ____|

I have tried different combinations of cables but I always get the same results.

I was looking at the firewall config file on the bad router and see that WAN ping response is on (I guess its always on by default)

config rule                                     
        option name             Allow-Ping
        option src              wan             
        option proto            icmp      
        option icmp_type        echo-request
        option family           ipv4        
        option target           ACCEPT

And yet, I cannot ping it from the WAN side of the bad router (I just realized that I could find it by hostname in the good router's client list and got its IP address from there.)

Which IP you try to ping from the WAN side? WAN IP or LAN IP?

I tried to ping the WAN IP of the bad router from the WAN side of the bad router (can you ping the LAN side IP from the WAN side?)

That's with the WAN interface set to static, and you are connecting to it directly? Or was it a dynamic?

If you allow that, yes.

At this point, the bad router has completely stock openwrt on it, so I assume that the WAN side is DHCP-assigned (I am not assigning an address to it.) . I am connecting to it via a dumb switch.

Are you sure? I think not, because of the nat.

Have you tried to ping from the bad router the good router? How are that results?

Remember, the bad router is a completely clean openwrt instance (at least it should be at this point).

Pinging from the bad router to good is a problem for me because the good router has the same LAN IP address as the bad router's LAN address (192.168.1.1) So if I ping from bad to good, I will be pinging myself.

To be clear, and perhaps get everyone's point-of-view:

  • Router2 doesn't work when plugged into Switch2
  • We now call this "bad router"
  • We plug into Switch1, OK
  • We plug into port on Router1, OK
  • Maybe Switch2 has the issue?

IMHO, the router has been 50% ruled out already, except for the switch ports.
Have we ruled out hardware before doing all these internal pings?

  1. Are these devices grounded?
  2. Are they on DC power by chance (without AC adapter)?
  3. Do they operate on a frequency other than 2.4 or 5.4 GHz?
  4. Do they have a Underwriters Laboratories (or similar) inspection for their electronic parts?
  5. Do other devices have issues on Switch2?
1 Like

This breaks anything leaving the "bad router," not just pings. It's default route (gateway to the Internet) is also 192.168.1.1 which is ambiguous.

You have to have LAN and WAN IP subnets that don't overlap. So change the LAN on the "bad router."

1 Like

What? Really? Do you have any idea what you are doing?

OK...disregard my hardware post...you do realize the issue with this, correct?

This completely explains why you have 81% packet loss when connected two switches down from a device with the same IP.

Fix this.

Soooo, I changed /etc/network to look like this:

.
.
.
config interface 'lan'
        option ipaddr '192.168.10.1'
.
.
.

and everything is working like a charm...

Which confuses me a bit... I assumed that the (no longer) bad router is creating its own subnet that shouldn't get nat'ed because it is in the 192.168.X.X group... At least I haven't had this problem in the past anyway.

Can you please explain why this is not the case?