Problem: As soon as I modify the bridging table in order to route the wl1.1 through br1, I'm unable to connect to wl1.1
Goal: use my OpenVPN client only when connected to a specific WLAN
What I've done so far:
- OpenVPN client setup was easily accomplished: in status -> OpenVPN, it shows I'm correctly connected
Client: CONNECTED SUCCESS
Local Address: 10.8.0.21
Remote Address: 10.8.0.21
So far everything works, all my traffic gets redirected through the VPN
- Setup a VAP (Virtual Access Point) on my Virtual Interface wl1.1 (SSID wl1.1) and configured with the correct settings: I can correctly connect to it without any issue
- I create a new bridge br1, to which I assign the IP 192.168.2.1/24
- Under Multiple DHCP Server, I add a new DHCP server and associate it to the br1 interface
Interface br1: IP 192.168.2.1/255.255.255.0
So far, everything still works with the wl1.1 interface still routed through br0
As soon as I modify the bridging table in order to route the wl1.1 through br1, I'm unable to connect to wl1.1
If I try to connect via my Win 10 laptop, I see the following error events:
Wireless security failed.
Network Adapter: Intel(R) Dual Band Wireless-AC 8260
Interface GUID: {beb2e2a8-6992-4f4d-86a7-30ac54da844d}
Local MAC Address: [my MAC Address]
Network SSID: wl1.1
BSS Type: Infrastructure
Peer MAC Address: 3E:37:86:FD:9F:9B
Reason: Dynamic key exchange did not succeed within configured time
Error: 0x0
WLAN AutoConfig service failed to connect to a wireless network.
Network Adapter: Intel(R) Dual Band Wireless-AC 8260
Interface GUID: {beb2e2a8-6992-4f4d-86a7-30ac54da844d}
Connection Mode: Manual connection with a profile
Profile Name: wl1.1
SSID: wl1.1
BSS Type: Infrastructure
Failure Reason:The specific network is not available.
RSSI: -49
This database may not have up-to-date information and may even recommend a build which might cause issues. As such, you should check the device specific forum (Broadcom, Atheros, MediaTek, etc.) first before flashing any build recommended in this database. There you will find build specific topics that discuss any issues with a particular build/release. For more up-to-date firmware files, please visit the firmware faq.
I've upgraded to kernel-panic69 to the firmware DD-WRT v3.0-r43516 std (06/25/20) as you suggested, but it still doesn't work.
I must admit I haven't reset the router after upgrading to this last version, it might be worth a try. I guess I can save my configuration and the re-apply it after resetting, correct?
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Wed Jul 01, 2020 19:42 Post subject:
There is no point to restoring to what you saved just before the reset. That just undoes the reset and leaves you where you started.
You most likely have a configuration error somewhere and are going to have to work through entering and testing things a step at a time.
Have a look at https://wiki.dd-wrt.com/wiki/index.php/Guest_WiFi_%2B_abuse_control_for_beginners with an eye to using an unbridged VAP rather than creating and using that second bridge. This guide is rather out of date though, so I suggest only reading through the DHCPd section and making a mental note that DHCPd is gone now in dd-wrt. DHCP is now instead handled by DNSMasq, but the setup steps are the same. And note that Net Isolation as discussed assumes that you have only a main network br0 and this one new guest network. It's a bit more involved if you have more networks (subnets) than these two.
I'm not familiar myself with R7000 specifics, but I do know that it's a popular dd-wrt router, so I assume people who know will speak up if there are router-specific things you should know. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Joined: 08 May 2018 Posts: 14223 Location: Texas, USA
Posted: Wed Jul 01, 2020 19:49 Post subject:
Sorry, I completely glazed over the bridged VAP issue in the process of the usual response to 40559. The following information may be helpful for you. Whichever magic voodoo works will have to be saved in your startup script in Administration->Commands->"Save Startup". If you already have something there, you will need to click "Edit" and add, preferably at the top of your startup script.
Quote:
• VAPs not working at boot fixed for unbridged VAPs with r40564:40566. Workaround startup command:
sleep 10;stopservice nas;stopservice wlconf;startservice wlconf;startservice nas (there are a few alternatives: search)
I've the feeling that they are not too stable though, so every times I make also a trivial change to the wireless settings (e.g.: the SSID), it doesn't work anymore. In that case, a reboot is needed.
As it wasn't a configuration error, it was really hard to understand what the problem was. I'm still unsure what the glitch is, but at least this workaround works.
Thanks again kernel-panic69!
P.s.:
For those interested, don't forget to add the Policy Based Routing to the VPN service if you want just some subnet to routed via the VPN.
Essentially Asus RT-AC68U E1 (though revision matters not) a Broadcom SoC, Ive been experiencing wifi disconnections to all connected clients on a wl1.1 VAP when I click apply for any reason, or even if theres no reason at all, merely clicking apply just to see the bug rear its head is enough.
So not fun, when I have to test work Im doing for DD_WRT themes and ppl are using the wifi and suddenly the only choice is to run the restart interfaces commands via ssh, else none will reconnect of its own accord.
Joined: 08 May 2018 Posts: 14223 Location: Texas, USA
Posted: Thu Sep 23, 2021 1:37 Post subject:
You need a non-production test device; I saw your reply just now. Anything I test patches on or bug-check is never on a device people connect to. But I understand how much of a pain in the a$$ this is - and was NOT aware of the larger picture when I made that comment. There have been people who don't understand what happens when they click "Apply" and they report issues that may be invalid. Last time I looked at wlconf and all the associated code, I got cross-eyed. I would have to agree, though, that it would be great if this bug were fixed completely. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Thu Sep 23, 2021 7:55 Post subject:
kernel-panic69 wrote:
You need a non-production test device; I saw your reply just now. Anything I test patches on or bug-check is never on a device people connect to. But I understand how much of a pain in the a$$ this is - and was NOT aware of the larger picture when I made that comment. There have been people who don't understand what happens when they click "Apply" and they report issues that may be invalid. Last time I looked at wlconf and all the associated code, I got cross-eyed. I would have to agree, though, that it would be great if this bug were fixed completely.
I have a much older router (buffalo_wzr-hp-g300nh) that suffers from other issues, upgrades only via TFTP (else was a softbrick) which is a pita in itself. The other issue is recently, these furry terrorists aka cat(s) knocked it down from where it was stored and it cracked the case/mobo, its now dead, until I get the patience to try repair it. (I have a even older 2MB flash model but thats a non starter for this type of work).
So only choice is, production on the Asus RT-AC68U. On a personal note, I haven't has much paid work as I'de like due to COVID, even remote work has decreased considerably. I would buy a non Broadcom SoC router, cause lets face it, Broadcom sucks at FLOSS and by extension Projects like dd-wrt are limited.
But on a more ontopic note:
Im not a fresh off the boat novice, I am fully aware how dd-wrt works for the most part.
As for this issue with clicking apply and VAP clients cant reconnect until interfaces are restarted.
I see that dd-wrt does a wland daemon restart (amongst other things) on clicking apply, but this is the important part.
But for VAPS this doesn't seem to be enough, even if its technically correct procedure and (assuming) the source code is correct (and bug free'ish).
I have to try ask/beg BS if he'd mind adding some exception to the source where as to ensure the interfaces are forced to re-initialize both on boot and after clicking apply as a workaround to this issue pretty much what the command line seems to work.
Also rebooting works, because its set to run the command on startup, else it wouldn't work either.
Joined: 08 May 2018 Posts: 14223 Location: Texas, USA
Posted: Thu Sep 23, 2021 12:28 Post subject:
Funny you mention that model Buffalo; I just snagged one off eBay to possibly swap out with another test device. To be quire honest IRT this bug, it's Broadcom, and that isn't always where the focus is at in DD-WRT development. One thing I am grateful for is that I didn't lose much due to COVID, but there was definitely a slight hiccup. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
