Wifi connects; no connectivity

Greetings,
I've had a minor issue on my OpenWRT device that was odd but didn't bother me so I've kinda ignored it for some time. Recently I upgraded my tablet to Android 12 and now I'm about to go stark raving mad. :laugh:

What's the issue? Every once in a while (like once or twice a week across four devices), I connect to the wireless and get a DHCP IP...but absolutely no routing at all. I can't ping anything on the network. I can't ping the OpenWRT device. I mean...it's just nothing! I'm connected to the wireless. If I use another device, I can see that it communitcated to get a DHCP IP. By every metric I know about, it looks like a successful connection. But the device can't ping nor be pinged from others on the network even though it says it's connected. It's weird.

However, since the upgrade to Android 12, my tablet... It's about all it does. I have to simply let it sit and keep re-negotiating (sometimes for as long as three hours!!) before it connects in a way that allows it to talk to the network/internet. Android simply says that it is connected but has no internet (with a ! over the wifi symbol.)

For a (probably too long) detailed look at my setup, here's the discussion where I got help with setting up VLANs on my network. Including a diagram of what I set out to achieve.

The short of it is this. My hardware is an Archer C7 1750. My primary network that the family uses is VLAN 4. I try really hard not to break that network since the family uses it. To my knowledge, there is no issue at all on this network. My personal playground network is VLAN5. Attached to VLAN5 is a guest interface that has DHCP. This interface is the one with the troubles. This guest network was originally set up to provide internet only access to friends/family but because I've separated out VLAN5 for my playground and this network is on VLAN5 already I tend to use it with all my devices too.

I'd like to upgrade my other Android devices but there's no way I can deal with this issue happening on all of them. I need to get it fixed.
(also, if anyone spots why I have issues routing from the guest to VLAN4 I'd appreciate it though that's a small matter. If I attach to VLAN5, traffic is sent to the switch to route to VLAN4 which is exactly what I want, but while on the guest network, traffic hits the OpenWRT device then attempts to route to VLAN4 and that obviously fails. I don't know why it does that... everything else is sent to VLAN5. :shrug:)

But I've now been poking at this config for far too long and I'd greatly appreciate a second pair of eyes. Any errors or oddities someone spot, I'd be grateful for opinions on how to improve. Especially if in my tweaking I've made bad choices.

Thank you!

cat /etc/config/dhcp

config dnsmasq
	option domainneeded '1'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option localservice '1'
	option ednspacket_max '1232'
	list server '10.0.5.103'
	option noresolv '1'
	option nohosts '1'

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

config dhcp 'guest'
	option interface 'guest'
	option start '100'
	option limit '15'
	option leasetime '1h'
	option netmask '255.255.255.0'
	list dhcp_option '6,10.0.5.103'
	list ra_flags 'none'

cat /etc/config/network

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 'fdd0:fe45:0c99::/48'

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

config device
	option name 'eth0.2'
	option macaddr 'd8:07:b6:74:13:d5'

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

config device
	option type '8021q'
	option ifname 'eth0'
	option vid '4'
	option name 'eth0.4'
	option ipv6 '0'

config interface 'vlan4'
	option proto 'static'
	option netmask '255.255.255.0'
	option device 'br-vlan4'
	list dns '10.0.5.103'      #Author note. Not a mistake. This is the DNS for everyone.
	option ipaddr '10.0.4.102'

config switch_vlan
	option device 'switch0'
	option vlan '3'
	option vid '4'
	option ports '0t 1t 2 3'

config device
	option type 'bridge'
	option name 'br-vlan4'
	list ports 'eth0.4'

config device
	option type '8021q'
	option ifname 'eth0'
	option vid '5'
	option name 'eth0.5'
	option ipv6 '0'

config interface 'vlan5'
	option proto 'static'
	option netmask '255.255.255.0'
	option device 'br-vlan5'
	option ipaddr '10.0.5.102'
	list dns '10.0.5.103'
	option gateway '10.0.5.1'

config device
	option type 'bridge'
	option name 'br-vlan5'
	list ports 'eth0.5'

config switch_vlan
	option device 'switch0'
	option vlan '4'
	option vid '5'
	option ports '0t 1t 4 5'

config interface 'guest'
	option proto 'static'
	option ipaddr '10.0.3.1'
	option netmask '255.255.255.0'
	list dns '10.0.5.103'
	option delegate '0'
	option device 'br-guest'

config device
	option type 'bridge'
	option name 'br-guest'

cat /etc/config/firewall

config defaults
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option synflood_protect '1'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

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

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option name 'Support-UDP-Traceroute'
	option src 'wan'
	option dest_port '33434:33689'
	option proto 'udp'
	option family 'ipv4'
	option target 'REJECT'
	option enabled 'false'

config include
	option path '/etc/firewall.user'

config zone 'guest'
	option name 'guest'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	list network 'guest'

config forwarding 'guest_wan'
	option src 'guest'
	option dest 'vlan5'

config rule 'guest_dns'
	option name 'Allow-DNS-Guest'
	option src 'guest'
	option dest_port '53'
	option proto 'tcp udp'
	option target 'ACCEPT'

config rule 'guest_dhcp'
	option name 'Allow-DHCP-Guest'
	option src 'guest'
	option dest_port '67-68'
	option family 'ipv4'
	option target 'ACCEPT'

config zone
	option name 'vlan5'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'vlan5'
	option masq '1'

What is the purpose of VLAN4 on this router? It doesn't seem to be doing anything useful -- I'd recommend removing it (unless it is being used for a wifi SSID -- and if that is the case, I'd recommend changing the interface to proto none (unmanaged).

Since it seems that your upstream router already handles VLANs, you'll probably be best served by actually using that upstream router to setup the guest network.

But...

Your guest network only has a DHCP pool size of 15, so if you have as many devices, you'll run out of IP addresses to hand out to your guest devices.

Also, you've got the preferred DNS server here via option 6, so remove it from the guest network interface definition.

Have you tested pings to 10.0.5.103 from your guest network? Although it is allowed by the firewall configuration you've shown, you need to make sure the connection is actually working.

Have you tested pings to the internet via IP such as 8.8.8.8? It is possible that there is an issue with DNS resolution but not routing.

Greetings,
Thanks for the response.

VLAN4 is for the family. And I forgot to post the wireless bit. (see below) The reason I left it there was so that I could access the OpenWRT device when I'm on the family network (wouldn't be the first time I did some crazy experiment and completely broke VLAN5 :sweat_smile: Though it has been a while.)

Yeah, I keep the DHCP pool tiny because I don't have a lot of people over very often.

As for the preferred DNS option, if I don't specify it then there is no DNS at all. 10.0.5.103 is the DNS for /everyone/. It is accessible from every network and it works from every network.

When things connect properly, I can ping everything including 8.8.8.8. But when it gets into its weird funky state, I can't ping /anything/. It's really odd that the device shows connected but it really isn't. And right now it is still very intermittent and I can't even come close to replicating it on any of my other devices with any repeatable frequency EXCEPT for this Android 12 which apparently is super sensitive to whatever is going on.

Thanks for the suggestions!

cat /etc/config/wireless

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'pci0000:00/0000:00:00.0'
	option channel '36'
	option band '5g'
	option htmode 'VHT80'
	option cell_density '0'
	option country 'US'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option mode 'ap'
	option encryption 'psk2'
	option network 'vlan4'
	option ssid 'Family'
	option key 'Passremoved'
	option disabled '1'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/ahb/18100000.wmac'
	option channel '1'
	option band '2g'
	option htmode 'HT20'
	option cell_density '0'
	option country 'US'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option mode 'ap'
	option encryption 'psk2'
	option ssid 'Guest_n'
	option key 'Passremoved'
	option network 'guest'

config wifi-iface 'wifinet2'
	option device 'radio0'
	option mode 'ap'
	option ssid 'Guest'
	option encryption 'psk2'
	option key 'Passremoved'
	option network 'guest'

config wifi-iface 'wifinet3'
	option device 'radio1'
	option mode 'ap'
	option ssid 'OpenWrt'
	option encryption 'psk2'
	option key 'TestTest'
	option network 'vlan5'
	option disabled '1'

I stand by my suggestion to make VLAN 4 unmanaged (proto none) in the network configuration. Since the main router already provides connectivity for VLAN 5, you can simply address it via the address on VLAN5 (10.0.5.102) -- if you wish to have the ability to connect to that when you're on VLAN 4, just make sure your main router is configured to allow inter-VLAN routing.

Remove the DNS entry from the guest network stanza -- it doesn't serve any purpose there. The DHCP option 6 will handle the DNS advertisement for the client devices, and the OpenWrt router will use the DNS server you've specified in the upstream network configuration (i.e. VLAN 5's DNS).

Increase your DHCP pool size to ensure that it is not causing the issue. Constraining it doesn't really serve a practical purpose here.

Try those things and then see if you experience the issue again.

Thanks for the suggestions. I do think I've found the problem and it's embarrassingly stupid. But first...

For some reason I can't get SSH nor LUCI to work on VLAN5... I must have a firewall directive or something blocking somewhere but I'm not sure where. So for the moment, I haven't set VLAN4 to unmanaged.

I did remove the DNS entry from the guest network stanza. I've not yet increased the DHCP pool size because when I looked at the logs the max devices I've had on it in the last few weeks was seven. :smiley:

So what was the problem? Well... Early July-ish, a friend did a bunch of upgrades and was throwing out old gear. Turns out he had the same model C7 Archer I have. He gave his old one to me. I figured I'd keep it as a backup in case mine kicked the bucket. I ported over all the configs and gave it different IP's.... then life got busy and I kinda forgot about it... so it was just chillin in the "to get around to one day" project space. Now, VLAN4 - working perfectly. I suppose it was providing better coverage to that part of the house? :man_shrugging: However, VLAN 5? "Network not detected."

So here's my current theory. Other devices are being more forgiving when they see the same SSID from two devices and are auto-magically deciding "Hey, this AP is responding so I'm going to use it!". Whenever they start communicating, get an IP, and for-whatever-reason then jump to the bad AP that's when I get those funky "It's connected but I can't ping it or do anything on the network moments." As for Android 12, I'm thinking it's either trying to do something "to protect me" by recognizing there are multiple AP's with the same SSID but one of them is bad so it just freaks out and won't connect at all OR it's just super sensitive to the bad SSID and can't determine which to connect to thus deciding to peeve off the end user by not providing any actual information about why it's being stubborn.

For the moment, I've simply unplugged that AP. Maybe later tonight/this week I can attempt to get the VLAN 5 working correctly on it. Now that I know VLAN4 was working well as a second AP coverage point, I think I might as well move them around to give better coverage and use both of them. Why not? :laughing:

Sorry for taking up peoples time with me being dumb and leaving half-finished projects laying around... I was seriously stumped looking at a puzzle with a large missing piece trying to figure out where I'd gone wrong. :laughing:

I couldn't let this go and had to poke at it. Turn the AP back on... immediately start having issues with Android 12 again. Did a diff between the two AP's on a bunch of files and updated the forgotten AP to proper values - lo and behold that fixed the issue with VLAN5! :confetti_ball: Now I can't replicate the problem at all with Android 12. So the issue is very much looking like it was a broken rogue AP.

Just for grins, I changed the second AP to be on different frequencies for all the wifi networks on the second AP to not clash with each other and I'm going to see what "breaks" now. I expect the VLAN 4 & 5 networks to switch properly between the AP's but not holding out much hope for the "Guest network" as each of the AP's has it's own independent DHCP but I really don't care and if it does become a problem I can simply disable Guest network on the backup AP. :person_shrugging:

Again, sorry for taking up time with a forgotten-project-fail...

This will be on your main router -- not C7 with OpenWrt.

It's not about 'tolerance' but more about which AP it happened to connect to -- if the rogue AP was misconfigured and doesn't have proper connectivity, it was probably a matter of chance if the devices connected to the right AP or not. Depending on the OS, the lack of connectivity may or may not be reported, but you would probably have noticed connectivity issues... but those devices may have by chance, always connected to the properly configured AP. Or maybe they silently dropped the connection and tried again and then connected to the right AP.

Yes, done properly, it can be great to have multiple APs providing coverage for all the desired networks.

Neighboring APs should always be set to different channels, otherwise it is effectively noise/interference and will degrade the wifi performance. If you have something break as a result of changing frequencies, it is likely that there is some other issue entirely.

At this point, the second C7 should actually be configured as a dumb AP. You can trunk the guest network from the 'main' C7 (which is not your main router). This will prevent issues around the guest network.

But, I'll also return to something I said earlier -- the guest network should be handled by your main router and then both C7 devices should actually be dumb APs with respect to the guest network. In fact, there is little reason to make either of the C7 devices operate as routers unless you are using them learn/experiment/test routing related things and/or learning OpenWrt in general.

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