Unable to connect to outside internet with Dumb AP coniguration

I did the steps step by step and ended up with the same results, in both the web interface, uci syntax, and editing the files directly. This time in particular I've gone the route of doing it via ssh. I'll put my new config files here:

[/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 device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.200.254'
        option netmask '255.255.255.0'
        option gateway '192.168.200.1'
        option broadcast '192.168.200.255'
        list dns '8.8.8.8'
[/etc/config/wireless]
config wifi-device 'radio0'
        option type 'mac80211'
        option path 'platform/18000000.wmac'
        option channel '1'
        option band '2g'
        option htmode 'HT20'
        option disabled '0'
        option country 'US'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'OpenWrt TEST'
        option encryption 'none'
[Radio 1 omitted as we're just testing on 2.4GHz until this works]
[/etc/config/dhcp]
config dnsmasq
        option domainneeded '1'
        option boguspriv '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_protection '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'

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

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'
[Commands run]
[Yes, there is redundancy here, I just wanted to cover all of my bases]

uci set dhcp.lan.ignore=1
uci commit dhcp
/etc/init.d/dnsmasq disable

uci set dhcp.lan.dhcpv6=disabled
uci set dhcp.lan.ra=disabled
uci commit
/etc/init.d/odhcpd disable

/etc/init.d/firewall disable

[Rebooted AP]

Still, Wi-Fi devices will not connect to the internet. They do get DHCP leases from the pfSense router and they do access other devices on the network yet do not access the internet. Also, devices plugged into the switch port on the router do (as expected) connect to the internet and grab their DHCP leases as expected.
To sanity check I configured my very old dd-wrt router in a similar access point configuration and plugged it into the LAN, and noticed that devices connected could connect to the internet and also still grabbed IP addresses in the 100+ range of this subnet.
Finally, DHCP has been modified to exclude a range of addresses to allow for static IPs of the routers temporarily, so no overlap conditions will exist.

Thank you all again for your help, I really do appreciate your time, patience, and feedback as I try to get this working, I'm learning a lot

Remove everything except ignore means ending up with this:

config dhcp 'lan'
    option interface 'lan'
    option ignore '1'

The option interface has to stay so it knows which interface to ignore. At least change dhcpv4 to disabled, since leaving it in is a conflict with ignore.

Try removing broadcast from the lan interface definition. It is not required and is actually auto generated based on the IP address and subnet mask. (the value you have is correct, and it shouldn't cause problems, but still not necessary and recommend removing just in case).

What do your wifi clients get as their router/gateway address via DHCP?

Have you tried an outbound ping test on the wifi clients?

  • 192.168.200.254 (AP)
  • 192.168.200.1 (router/gateway)
  • 8.8.8.8 (google DNS server by IP)
  • google.com (direct ping with a domain name)

Can confirm the same issue with the Belkin RT3200 on my side on a similar network setup.

I'm using an OPNSense firewall device with two dumb APs (Netgear WNDR3800 and ZyXEL NBG6817) without any issue so far. OpenWRT is up to date on all devices.

Adding the RT3200 as dumb AP to the setup, no wireless traffic is being forwarded to the lan bridge. Traffic via ethernet ports is working without any noticable issue.

I've noticed that the old devices make use of an ethernet switch, configurable in the network tab. Whereas the RT3200 is using dedicated LAN switch Ports (lan1-lan4) and has no such configuration tab in luci. I'm in the process of understanding the DSA approach regarding switch configuration and the DSA conversion guide

Maybe this hint helps to find a solution to this issue.

Glad I'm not going crazy, thank you for the sanity check! I did notice that when I'm connected to the RT3200 wirelessly I can still communicate with other devices on LAN that aren't connected to the RT3200 or the built-in switch/LANs. What would that imply for Wireless internet access?

So... I'm not insane. Seems to be the only thread about pfSense/OPNsense and Linksys E8450/Belkin RT3200 setup issues. This took me ~8 days to troubleshoot this issue - trying to set up a dumb AP on a recently bought Linksys E8450 router behind an OPNsense 21.1.9 firewall build with a bridged LAN setup (OPNsense firmware to be soon updated next month).

--

Symptoms:

  • Linksys E8450 directly connected to the OPNsense box would take over a minute to connect to the Internet. Though, the worst was ~10 minutes when connected to an older router served a Wireless Ethernet Bridge, lol. Cannot exactly install packages through the web, yet machines connected to the Linksys E8450 switch are perfectly fine. Bonus: even through the router served as a Wireless Ethernet Bridge.
    • unless I installed the ip-full package through opkg and manually added ip neigh replace 192.168.1.1 lladdr '00:11:22:33:44:55' nud permanent dev br-lan to /etc/rc.local!
  • Windows WLAN clients would authenticate, grab an IP address, but not connect to the Internet.
    • Manually added the OPNsense MAC address via Powershell to my main Windows laptop as a test. Now I have an Internet connection on that Windows laptop.
      • Get-NetAdapter
      • NewNetNeighbor -InterfaceIndex [num] -IPAddress '192.168.1.1' -LinkLayerAddress '001122334455' -State Permanent
      • Get-NetNeighbor -InterfaceIndex [num] -IPAddress 192.168.1.1
  • Linux WLAN clients would generally authenticate, but would take up to 5 minutes to connect to the Internet. Least problematic.
  • Android WLAN clients are odd.
    • My current phone (Motorola G Stylus 2022) would rapidly connect then disconnect, then it would eventually say Connected and stay there. After that, I have Internet access. This would go on for up to about 15 minutes, average.
    • Have an old Motorola Atrix HD phone that would authenticate (though I had to deselect Avoid poor connections to troubleshoot), but very rarely establish a connection to the Internet.
    • An RCA phone (cannot exactly remember the model, likely G2) was relatively fine, however, though it took up to a minute to connect to the Internet.
    • Mom's OnePlus 7 Pro would rapidly connect, disconnect, then fall back to the primary 5GHz WLAN SSID in the house.

I was originally running 22.03.2 when I first set it up, then 22.03.3, looked over my configuration multiple times, troubleshot the setup, then a snapshot version (Jan 6, Jan 7), then back to 22.03.3. More configuration checks. More troubleshooting.

--

Some notes:

  • Weird quirk when leaving DHCP on (ignore interface unchecked, Dynamic DHCP checked) eventually has DHCP WLAN clients grabbing the OpenWrt router's IP as gateway and DNS, despite the fact you set the gateway and DNS to your main firewall's IP address. Yes, the Internet works in that state for those WLAN clients as well.
    • Disabling DHCP and setting gateway and DNS to your pfSense/OPNsense firewall's IP address, however, results in practially non-functional Internet access for WLAN clients.
  • If you're wondering if static IP WLAN clients receive Internet access, then you would be wrong. My main Windows laptop is actually set as a static IP and even it needed the NetNeighbor workaround.
  • Hooked up my main Windows laptop to the Linksys E8450 via Ethernet and ran Wireshark. That's when I discovered the WLAN clients weren't exactly getting the OPNsense firewall's ARP responses, but the OPNsense firewall was getting theirs.

Then, I searched for the earliest version available on the OpenWrt downloads server... I installed OpenWrt 22.03.0-rc1 and everything worked well from there. Removed the workarounds from the OpenWrt router and my main Windows laptop after that. Wondering when it first stopped working for this setup, I installed 22.03.0-rc4 on the router... welp, dumb AP setup doesn't work on that version, either, so I rolled it back to rc1.

Running very well on 22.03.0-rc1 for 3.5 days now. Am planning to buy a second one, as I already deployed a third of the wireless network to the E8450 for a testing phase, so no further troubleshooting from me until then.

I return; this edge case (issue) actually seems to have been introduced in OpenWrt 22.03.0-rc2 rather than rc4 for this router and pfSense/OPNsense setup!

I had to compile that particular release candidate (for obvious reasons) just for testing purposes.

Eventually obtained a Belkin RT3200 router that is to serve as a wireless bridge to the Linksys E8450 I obtained even earlier. Converted to UBI layout, flashed 22.03.3, set it up just like the Linksys E8450 dumb AP setup that has been running for 12 days (would've been 16 days, but I relocated it to the main area). Of course, same issues persist as in my previous post. Then flashed 22.03.0-rc1 to the Belkin unit, and the dumb AP setup works as intended.

But...

Backstory of Linksys WRT54G-TM

I also have an old Linksys WRT54G-TM router that I got off eBay years ago that was specified to be in bricked condition due to a bad flash (thankfully the CFE was still present), and brought it back to life via JTAG. After that, I ran an old build of DD-WRT just for the SD card mod, then a custom build of TomatoUSB for the same reason. Eventually ran FreshTomato on it to have old Nintendo DS consoles connect to WAN because the SD card novelty wore off.

Back in December 2021, I flashed OpenWrt 21.02.1 on the router, went, "Yeah, that's a bit slow..." messed with it for a bit anyway, and set it aside until December 2022, for which I flashed 22.03.2 on it, then set it aside again. On January 2023, I finally flashed 22.03.3 on the ancient Linksys WRT54G-TM router... and set it aside again.

Today, I finally set it up as a dumb AP with the same settings as my Linksys E8450 and Belkin RT3200 routers, and it works flawlessly (though slow, shocker). Basically, the WRT54G-TM part pretty much adds to martinlauer's statement that other dumb AP setups are working fine with OPNsense.

I also have a somewhat older Netgear R7000 running as an AP, but-- that runs FreshTomato, and it was going to be replaced with the Linksys E8450... and repurposed as a backup router.

--

The configuration is as follows (not entirely cleaned up yet; WDS enabled for Linksys E8450 only):

/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 device
	option name 'br-lan'
	option type 'bridge'
	list ports 'lan1'
	list ports 'lan2'
	list ports 'lan3'
	list ports 'lan4'
	list ports 'wan'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option netmask '255.255.255.0'
	option ipaddr '192.168.1.5'
	option gateway '192.168.1.1'
	list dns '192.168.1.1'
	option delegate '0'

config interface 'lan6'
	option proto 'dhcpv6'
	option force_link '1'
	option reqaddress 'try'
	option device '@lan'
	option reqprefix 'no'
/etc/config/wireless
config wifi-device 'radio0'
	option type 'mac80211'
	option path 'platform/18000000.wmac'
	option band '2g'
	option cell_density '0'
	option country 'US'
	option htmode 'HT40'
	option channel 'auto'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt-2G'
	option encryption 'psk2+ccmp'
	option key 'wpa2pass'

config wifi-device 'radio1'
	option type 'mac80211'
	option path '1a143000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
	option band '5g'
	option htmode 'HE80'
	option cell_density '0'
	option country 'US'
	option channel '153'
	option he_su_beamformee '1'
	option he_bss_color '8'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'OpenWrt-5G'
	option encryption 'psk2+ccmp'
	option key 'wpa2pass'
	option wds '1'
/etc/config/dhcp
config dnsmasq
	option localise_queries '1'
	option expandhosts '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option ednspacket_max '1232'
	option rebind_protection '0'
	option logqueries '1'
	option domainneeded '1'
	option localservice '1'
	list interface 'br-lan'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	option ignore '1'
	option dynamicdhcp '0'

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

YES, VIDICATION!!

I have a pfSense appliance as router and a Netgear WAX206 + EX6120 (both Mediatek devices) which behave much the same way with Android and iOS devices. I thought I was losing my mind after searching for anything that came close to what I was experiencing...

Funny detail: I started experiencing this issue with the deployment of DAWN/802.11r/k to have clients moved to the closest AP for the best WiFi experience possible. So I initially blamed these modifications and reverted everything to try and dumb it down again. The only thing I did not do was revert the OpenWRT version I was using to the older one (19 something) and the problems remained but mostly for iOS devices, though sometimes the Android devices would join the fray...

I am thinking of trying to enable the OpenWRT firewall and filtering out all ARP traffic over the bridge. Did anyone try this?

Reverted the EX6120 to 21.02.5 and the problems seem gone on that device.

I am going to upgrade this device step by step to see where it breaks, I am going to take it easy though, I have had more then enough issues with WiFi so far.

For the EX6120 there is another issue I discovered, the WiFi drivers get replaced or mangled in the latest version (22.03.x as well as any snapshot) of openwrt, which causes the wifi to stop working after only a couple connects. The AP just disapears from the air, until I reboot it. This is something I am trying to debug a bit for more information which I will be putting in a seperate bug report on GitHub.

@dajakerboss and @AmiSapphire are you still experiencing this issue? If so, can you try to enable ProxyARP on your WLAN Advanced settings and report back how it works after that?

I think that may have fixed the issue for me on my WAX206...

I also have this at start-up. If the ProxyARP did not help on the WLAN as a stand alone solution, add this to the /etc/rc.local and reboot the AP:

for device in `ls /proc/sys/net/ipv4/conf/*/proxy_arp | awk -F'/' '{print $7}'`; do 
  sysctl -w net.ipv4.conf.$device.proxy_arp=1;
  sysctl -w net.ipv4.conf.$device.proxy_arp_pvlan=1;
done
1 Like

Yeah, the power is out (Michigan ice storm), so I won't be able to test this right away. On a portable generator for mostly running essentials.

I'll keep a note of this for when the power returns (probably a few days at most).

Edit: The power is actually back on and the original setup is fully operational! However, I will test this tomorrow at 5AM EST.

1 Like

I have upgraded the EX6120 back up to 22.03.3 applying my 'fix/workaround'.

I have reinstated all features and it is working like a charm again. 802.11v/k/r with DAWN. Sweet!

please link to it in the post, so it's easier to find.

1 Like

done, thanks for the pointer! :relieved:

2 Likes

As I mentioned in the comment to the issue filed here, the workaround actually works on 22.03.3, after some initial quirks regarding DNS handling. :slightly_smiling_face:

2 Likes

Cool! I'm happy you where able to reproduce the results.

Now I need to dumb it down, disable the script and reboot, see if the problem returns even with the ProxyARP setting turned ON in the WLAN settings. If that keeps it fixed, the Dumb AP guide needs an update :smiley:

I want to thank y'all so much for helping me out with this - I really thought I was clueless throughout all this and not that it was a niche bug that only recently cropped up. Since I haven't been able to get the materials together to get the AP wired up for serial I haven't been able to get stock firmware re-flashed either so this is a welcome fix for what's already installed. Spending more time with Arch+systemd and pfSense I'm starting to better understand what's working in the background as well, which helps a lot :sweat_smile:

I'm gonna go ahead and mark this as resolved since the temporary fix is here, try out the fix when I can, and watch the github for further updates!

@dajakerboss just to complete the story here some more, can you please tell us what else you have in your network?

pfSense/OPNsense/Linux router? Any special configurations towards your LAN from the router?

If anyone somehow runs into this thread and not the Github issue first: the suspect commit has been found! Reverting the commit and building 22.03.3 as a test afterwards works for a dumb AP as intended (like in 22.03.0-rc1). This connectivity issue (ARP/broadcast issue) shows up in pfSense and OPNsense bridged LAN setups, but those are not as common in general, so this went pretty much unnoticed until recently.

Issue in question:
Github Issue #11942

Commits in question:
kernel 5.15 - kernel: fix corrupted padding on small packets with mt753x dsa
kernel 5.10 - kernel: fix corrupted padding on small packets with mt753x dsa

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