[CLOSED] Vs 22.03 keeps missing the gateway

Installing and Using OpenWrt
1

The strange thing I'm seeing is that the router running 22.03 keeps losing it's gateway.
Why it's strange is that I have three sessions open to the router.

One is pinging my LAN firewall (192.168.1.1), another pinging the providers modem/gateway (192.168.0.1) and another pinging 4.2.2.2.

I watch as the first two stop being reachable while the 4.2.2.2 continues being reachable.
On the other hand, at times I also see all three no longer pinging.

This is only happening on the device running 22.03. I've been monitoring another one running 18.6 and it's not doing that. I did notice that the routers are the same, gl.inet mt300n v2 and one has br-wan while the other has br-lan for network configuration. I assume names aren't an issue.

Very unusual, not sure how to diagnose this so looking for thoughts.

2

well, let's start with the configuration of the 22.03 device that seems to be dropping its gateway...

Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
grafik
Remember to redact passwords, MAC addresses and any public IP addresses you may have:

cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
2 Likes
3
  • Also, is this the same device where you're attempting to remove new fw4/nft to install/use deprecated iptables on 22.03?
  • How long are these ping tests (do they happen to fail after ~6 hours)?
1 Like
4

Now, please, keep in mind that I've been changing the network files repeatedly in trying to solve this mystery so what ever I share is simply the current version.

There is no /etc/config/firewall file now that I've removed that package
Disregard the wireless stuff. I was just playing around with the device being an AP and wifi client.
My tests are being done over the wired interface only.

Correct, it's the same device. I've got a few of these which made it nice to test going from one version to another. I've been testing 23.03.3 but once I get things working, I'll probably upgrade to the latest.

The ping tests are constant. I have three ssh sessions open and can clearly see when something stops pinging. I noticed this because I did the same with an 18.x.x version next to it and it never missed a thing so I know there aren't any network issues. I've also done the same from a Linux machine and some others on the network to make sure. This is only happening on this 23.x.x device.

At one point, I had a little script sending an email so I'd know exactly when this was happening and it's
not uniform, 6;11,6;12,6;17,6;32,6;40,6;45, etc.

Is it possible it's just the latest ping tool that has a problem? Unlikely but I noticed that when pings stop, if I jump into yet another sh session and ping something like 4.2.2.2, then the pings start up again in the other three windows.

# cat network

config interface 'loopback'
    option device 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config device
    option name 'br-lan'
    option type 'bridge'
    list ports 'eth0.1'
    list ports 'eth0.2'

config interface 'lan'
    option device 'br-lan'
    option proto 'dhcp'
    option ip6assign '60'
    option ifname 'br-lan wlan0'

config interface 'wan'
    option device 'eth0.2'
    option proto 'dhcp'
    option metric '10'
    option ifname 'wlan0'

config interface 'wwan'
    option device 'radio0'
    option proto 'none'
    option metric '30'

config interface 'wlan'
    option device 'radio0'
    option proto 'none'
    option metric '40'


config wifi-device 'radio0'
    option type 'mac80211'
    option channel '1'
    option hwmode '11g'
    option path 'platform/10300000.wmac'
    option htmode 'HT20'
    option disabled '0'

config wifi-iface 'ap'
    option device 'radio0'
    option mode 'ap'
    option network 'lan'
    option ssid 'xxx'
    option encryption 'psk2'
    option key 'xxx'
    option disassoc_low_ack '0'
    option disabled '1'

config wifi-iface 'sta'
    option device 'radio0'
    option network 'wwan'
    option mode 'sta'
    option ssid 'gst2'
    option encryption 'psk2'
    option key 'xxx'
    option disassoc_low_ack '0'
    option disabled '1'

# cat dhcp

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option domain 'lan'
        option dhcpv4 'server'
        option dhcpv6 'server'
        option ra 'server'
        option ra_slaac '1'
        list ra_flags 'managed-config'
        list ra_flags 'other-config'

config odhcpd 'odhcpd'
        option maindhcp '1'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'
5

I will try something else right now. I'll connect it directly to my providers modem and see what happens.
Update: No different, keeps doing the same.

6

Is the issue with devices you're pinging or the device you're sending the ping(s) from?

7

As mentioned in my post, it's from the openwrt 23.x.x device. This is not happening on other openwrt devices, only this one. I tested by upgrading another router to the same version and it does the same. My older versions, 18.x.x do not have the issue.

The problem is more than likely how I've configured the router or there is something broken in one of the packages or something related. I truly do not know which is why I decided to post.

BTW, I'm now logging all of these failed pings and will generate a report after a while then post it.

8

There are several questions that this raises...
First and foremost, ifname is deprecated in most situations. So how did this syntax get here?
Then, why is wlan0 included there? wlan references do not belong in the network file at all anyway, but this method of specifying multiple interfaces is not valid in 22.03.

So, this leads me to the next set of questions:

  1. What version of OpenWrt are you using -- is it official or from another maintainer?
    --> let's see the ouput of ubus call system board

  2. If it is official OpenWrt (i.e. downloaded directly from the openwrt.org site), have you restored an older configuration? Or kept settings? If so, from what version? Or, did you ediit these by hand?

2 Likes
9

It's the official 23.03.3 but I've used image builder to make my own with less packages that I don't need.

I initially got the settings from the default 22.03.3 built off the openwrt downloads site.
It was this one I believe;

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd17:78ff:5e34::/48'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'eth0.1'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option device 'eth0.2'
        option proto 'dhcp'

config interface 'wan6'
        option device 'eth0.2'
        option proto 'dhcpv6'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option ports '1 6t'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '0 6t'

I started changing things mainly to test. I don't know enough about the settings to know what mine should really look like if 'option ifname 'br-lan wlan0' is no good. I probably copied that some some post I found. I wanted to have ap and cli wireless options too.

I've been having a heck of a time trying to figure out why this is happening.

21:08:30.135583 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
21:08:30.135723 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
21:08:30.135990 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
21:08:30.141471 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
21:08:30.142411 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
21:08:30.142970 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46

I ran a bunch of ping tests but they aren't all that useful.

10

You should probably reset to defaults and configure from there.

What specific configuration details do you need to setup that would be different than the defaults? We can help make sure it's all set correctly.

11

That's doable but I don't know enough about these configurations to handle them. That's why I was looking on the net to configure the network and wireless files but there's so much old info out there, you never know what's good or bad.

12

The config I'm looking for just lets me do different things like using the wired or wireless interface or setting it up as an access point. I also use the vpn to reach work related things.

The one I shared but working, is my objective :).

13

Let's start with a more basic approach -- please describe your desired result. For example, if you want a trusted LAN + guest network + IoT network with isolation between them, that's a pretty common use case. We'd need to know what you plan to do in terms of wireless vs wired and such, but we really just need to know your goals and we can work from there.

1 Like
14

My goals were explained I thought. I don't care to have a guest network, it's just for me to test wireless devices now and then. I could use it as an access point. I also need to use wireless as a client sometimes when I'm testing something and just want to blast traffic on the wifi.
The vpn was explained, it's to get to a work vpn.

The config I show works for all of these things but obviously, there's something wrong with it.

15

The more precisely you can lay out your requirements/goals/use-case, the better.

Is this your description of those goals?

For the wired/wireless interface, that would basically just be a dumb AP.

Adding a VPN means you need to perform routing... so for that, you'd need to create an additional network that would be routed using the VPN. Setup your VPN, then create a new network that is associated with a bridge if you plan to use ethernet + wifi, or more than one radio on wifi (i.e. 2.4 and 5G). There's more to do, but this is the basics.

Start with the dumb AP and make sure that works reliably... then if it does, we can add the VPN.

16

Sorry if I'm not being clear, I am trying but I'm not terribly knowledgeable about this aspect.
Everything actually works perfectly on the router except for this loss of either lan gateway or the providers modem gateway.

The files I shared, other than not being correctly built, are what I'd like to keep/have as a final configuration.

The current configuration allows me to use the router as a wired client or a wireless client or as an access point. I have the vpn tunnel open to my work and all these things are working well.
I don't really notice any problems but what ever is causing these ping drops means there is something that is causing an inefficiency and that would be nice to fix. I'm also curious what might be the cause of that.

Based on what's been said, it's likely because of the way I have my network and wireless files configured and probably not something else in terms of packages, etc.

17

It's very odd. I have a non stop ping going to 4.2.2.2 and it constantly makes it while pinging the two local devices keeps missing. I would not find this strange if other devices on the lan were seeing this but they aren't, only this 23.03 router is.

p# tcpdump -i br-lan host 192.168.1.1 or host 192.168.0.1 or host 4.2.2.2 | grep exceeded
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), capture size 262144 bytes
15:05:00.679823 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:05:00.679932 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:05:00.679966 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:05:00.685314 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:05:00.686104 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:05:00.686542 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:05:30.684745 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:05:30.685494 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:05:30.685602 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:06:30.698670 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:06:30.698800 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:06:30.699076 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:06:30.704705 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:06:30.705416 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:06:30.705883 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:07:00.706075 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:07:00.706206 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:07:00.706476 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:07:00.712429 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:07:00.713120 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:07:00.713584 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:00.720161 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:00.720269 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:00.720303 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:00.726149 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:00.726590 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:00.727056 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:30.725296 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:30.725429 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:30.725707 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:30.731330 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:30.732264 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:08:30.732738 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:00.731887 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:00.731994 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:00.732029 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:00.737687 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:00.738082 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:00.738564 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:30.737211 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:30.737345 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:30.737627 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:30.744081 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:30.744581 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:09:30.745014 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:10:30.756453 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:10:30.756584 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:10:30.756868 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:10:30.763879 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:10:30.764629 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:10:30.765038 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:00.759875 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:00.760234 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:00.760322 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:00.769926 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:00.770045 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:00.770079 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:30.761355 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:30.761486 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:30.761767 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:30.767230 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:30.768135 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:11:30.768632 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:12:00.770913 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:12:00.771021 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:12:00.771054 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
15:12:00.776698 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:12:00.777267 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:12:00.777985 IP 192.168.0.1 > enagent: ICMP time exceeded in-transit, length 46
15:12:30.778470 IP 192.168.1.1 > enagent: ICMP time exceeded in-transit, length 46
18

This is a very different error message than you originally described (i.e. "missing gateway").

Who are these 2 hosts?

(BTW you can use -n so tcpdump shows the IP).

EDIT: To be clear:

  • "time exceeded in-transit" usually denotes some routing loop; but your config is fairly basic
  • You have not told us what device has the IP of 192.168.0.1 - I assume it's an upstream router?
19

When I started talking about this, I was looking for ways to find out what is happening so I can using pings. I then fired up tcpdump to get this information. As I said in my original post, I'm looking for ideas on how to find and solve the problem so trying different things.

I shared that info in my first comment, above.
I'm not sure where 'enagent' is coming from.
The 192.168.1.1 is my local LAN firewall and the 192.168.0.1 is the providers modem.

20

Correct... it is your configuration that is almost certainly the problem.

These are generally different use cases that require different configurations that are usually mutually exclusive. Specifically, the wired/wireless client and dumb access point modes are fundamentally distinct modes of operation, as one involves routing, the other is switching. And one will have a DHCP server enabled, while the other must have it disabled (in the vast majority of cases)

And then a VPN can work on either situation, but cannot operate purely as a dumb AP -- you must (usually) have a different subnet relative to the uplink in order for hosts to route to the VPN.

Can all of these scenarios be achieved on a single device -- yes, but it's far more complicated. So select one use case that you really want and go with that. Don't try to make this do evertything.

1 Like