Android developer options reports strange home router acess point errors when in client bridge (repeater) mode

I've never used bridge mode, but always assumed that the SSID you set up for bridging, should only have the 'partner' bridge device for point-to-point, not any client devices.

[or multiple bridge partners, if your device supports point-to-multipoint?]

Thanks Andy for trying to help out as only one in thousands on Usenet are purposefully helpful people who spend the time to try to help the others.

I think I may have figured it out after running a few hours of tests today. (Networking always confuses me because I have no book learning on the topic; all my networking is empirical tests such as those I ran today shown below.)

dd-wrt client bridge dd-wrt bridge repeater run site survey & join both SSIDs now work!

Thanks Andy for your always helpful advice. Last night I spent hours trying to figure this out, and I still haven't figured it out, but I think the home Netgear N router simply has a "bad" 2.4GHz as strange as that sounds.

But I'm not sure yet... as I spent a few hours this morning running tests.

To your point of bridge mode SSID's, I am no good at networking so I only know what works when I experiment. When I connect the PC Ethernet port by Cat5 to to the dd-wrt (WRT54G) router, mainly I perform three dd-wrt setup steps to connect the dd-wrt wirelessly to the home router SSID, namely:

1. I set the dd-wrt to "wireless client bridge" mode
2. I run a dd-wrt "site survey" and "join" the 2.4GHz home router SSID
3. I duplicate the 2.4Ghz home router SSID's authentication stuff

That bridges PC Ethernet via the dd-wrt router to the home router 2.4GHz SSID, but it wouldn't allow my phone to connect to the same access point.

But then I ran a _different_ test and got completely different results!

What I did was bridge to a _different_ 2.4GHz SSID in my home (I have plenty as can be seen by this photo - so I just added a 2.4GHz Rocket).

Then I tried to connect my phone to _that_ (already bridged) access point. It worked!

It even worked when I slightly modified the dd-wrt to change the "Wireless Client Bridge" mode to a wireless "Bridge Repeater", which simply adds the ability for devices to connect to that same bridge, wirelessly, in addition to the PC connected to that bridge via its RJ45 Ethernet port & CAT5 cable.

Hmmm.... That makes no sense...

What I've tentatively concluded, for now, is that there's something 'wrong' with my 2.4GHz access point inside the Netgear N router.

Here's what is working at the moment (and what I'm using to send this): a. The upstairs PC RJ45 is wired to one of the four dd-wrt LAN ports b. A Rocket M2 is wired to one of the downstairs Netgear router LAN ports c. The upstairs dd-wrt is set to "wireless bridge repeater" mode d. The upstairs dd-wrt ran a "site survey" & "joined" the Rocket M2 SSID e. And I typed the duplicate SSID credentials into the upstairs dd-wrt

That does three things which didn't happen with the Netgear 2.4GHz SSID.

1. The upstairs PC gets its Internet over that Rocket M2 client bridge
2. The phone can now also connect wireelessly to that same Rocket M2 SSID
3. In addition, the upstairs dd-wrt makes its own SSID available to Wi-Fi

This means that everything works as you'd want it to work, which is that even though the downstairs Rocket M2 access point is connected to the upstairs dd-wrt as a client bridge, the phone can also connect to that Rocket M2 SSID at the same time.

Meanwhile, upstairs I have a new access point that I never had before, which is that the dd-wrt set up in "wireless bridge repeater" mode, additionally, as a bonus, acts as a Wi-Fi access point for the phone.

That most of this failed with the Netgear 2.4GHz router, I think means that there's just "something wrong" with that 2.4GHz radio.

BTW, it was hugely useful to set my Android 12 "Developer options" to "Enable Wi-Fi Verbose Logging" because I would never have seen the error message of "NETWORK_SELECTION_DISABLED_AUTHENTICATION_FAILURE=2" otherwise.

The #2 seems to be simply an incremental counter of how many times the phone tries to reconnect and gets the same error, so we can ignore that.

A search shows it's a common error message found on Android phones.

It seems, like many networking issues, there are multiple error causes.

While there are many such errors, most people never figure it out, but this one suggestion made me think of a workaround - which - surprisingly worked! *How to Fix WiFi Authentication Error Occurred on Android*

Following that suggestion that it's simply an error in the SSID or password or encryption setup, I removed the password and encryption from the downstairs Netgear 2.4GHz access point.

Wouldn't you know it, everything worked after I did that! Huh? Makes no sense (I've checked the configuration many many times!)

My experimental results this morning show that without any encryption, I _can_ connect the upstairs dd-wrt wireless client bridge/repeater to the downstairs 2.4GHz access point and I can connect a phone also to it.

But the instant I add security, I can't. It's crazy.

That makes no sense. Anyway, I think the answer to the original question is this:

Q: Can you wirelessly bridge to a router AP & still use that router AP for other wireless devices to connect wirelessly to that bridged AP? A: Yes.

In fact, not only can you bridge to that downstairs router's AP and still use that downstairs router's AP for other devices to connect wirelessly to (such as a phone), but the upstairs dd-wrt bridge itself can act as yet _another_ access point for wireless devices to connect to.

It's the best of all worlds when it works. a. You convert a PC with only Ethernet, to a powerful Wi-Fi connection b. At the same time, you can use the Netgear router AP for other devices c. And, at the same time, you add a new AP to the dd-wrt for other devices

It's perfect! (when it works)

UPDATE:

It's great to share the fruits of the efforts of the entire network team.

The finesse of using the Windows' killswitches allows the computer to reboot without connecting to the Internet after doing so, until and unless the user flips the killswitch toggle. a. C:\Windows\System32\schtasks.exe /run /TN "task nettoggle" b. c:\data\sys\batch\nettoggle.bat

This is accomplished by Windows 'magic' integrating the task scheduler, the taskbar, specific red/green off/on changeable icons, and basic batch files.

@echo off REM nettoggle.bat by Zaidy036 20210207 on alt.comp.os.windows-10 set defgw=192.168.1.1 set "ip=" for /f "tokens=2,3 delims={,}" %%a in ('"WMIC NICConfig where IPEnabled="True" get DefaultIPGateway /value | find "I" "') do if not defined ip set ip=%%~a IF "%ip%"=="%defgw%" ( %comspec% /c %windir%\system32\route.exe delete 0.0.0.0 %defgw%) ELSE ( %comspec% /c %windir%\system32\route.exe add 0.0.0.0 mask 0.0.0.0 %defgw%) exit

For the benefit of those on Windows who wish for a perfectly seamless integration with Ethernet, Wi-Fi, Android, and yes, even killswitches, I made this screenshot just now of the Windows portion of the setup.

Windows elegance

SOLVED! (maybe)

Moral: (perhaps) *Don't buy a home router that uses a Broadcom chipset!*

Details: As you know, I really hate when I don't understand a computer problem. It bothers me even when the workaround works fine. Because, to me, the problem shouldn't have existed in the first place.

That's just my nature (which is why I solve almost all computer problems). Often, with your help!

The situation above was a case where it seemed the instant I created a "wired client bridge" between the upstairs Window desktop with only Ethernet to the downstairs WNDR3400 v2 2.4GHz access point, that 2.4 GHZ access point stopped connecting to other wireless clients only when encryption was involved.

What seemed odd (to me anyway) was the clue that the downstairs WNDR3400 v2

2.4GHz access point connected to other wireless clients if I turned the encryption off, and, what also seemed odd (to me anyway) was that the 5GHz access point was unaffected.

This inability to use encryption on the 2.4GHz access point only was also seen when I flipped the switch in the upstairs dd-wrt wireless client bridge (aka "client bridge" in dd-wrt) to convert it to a "wireless client bridge repeater" (aka "repeater bridge" in dd-wrt).

That seemed so odd to me that the 2.4GHz encryption would stop working, but everything else worked, that one of the Occam's Razor options was simply that it was "broken", but that just didn't seem logical to me, which is why I asked this question in the first place (to get down to what's going on!).

Digging into the problem on the dd-wrt web site, I found this reference:

Which says in the "Client Bridge (Broadcom)" section, the following: "Broadcom ARM: dhd driver models (e.g. AC5300 routers) cannot support "client bridge" nor nor "repeater bridge" modes since the Broadcom driver is controlled by wireless firmware internal to the Broadcom chipset. This makes it impossible to implement fake bridge modes, and is not fixable in dd-wrt. While "client bridge" & "repeater bridge" modes can sometimes work without encryption, there is no guarantee nor official support. The driver will usually crash when in these "client bridge or "repeater bridge" modes. If "client bridge" or "repeater bridge" will not work on your hardware, use "Client" mode instead, where the primary and secondary routers must be on separate subnets, and NAT is used between them.

I wasn't sure which chipset the downstairs WNDR3400 v2 router contained, but when I looked it up, it does contain a Broadcom chipset apparently.

CPU: Broadcom BCM5357 Switch: Broadcom BCM5325 WLAN Hardware: Broadcom BCM5358UB0, Broadcom BCM43236

I'm not yet totally sure, but the seemingly strange oddity that only the encryption was broken, and, only when in client bridge or repeater bridge connections, was what stuck out to me as an oddity of the first order.

Since I switched the dd-wrt from being a wireless client bridge to a wireless repeater bridge (so as to make further use of the upstairs access point for wireless devices such as a cellphone or iPad), the oddity of the

2.4GHz access point's encryption no longer working continued unabated.

Looking up the details for the "wireless repeater bridge", I found this:

The first suggestion didn't apply to me, but might apply to others: "To use dd-wrt "client bridge repeater" mode, your primary router must be able to support encryption that works with DD-WRT (use WPA2-AES, not TKIP)." That's useful to know that TKIP won't work; but I was using WPA2-AES.

The next suggestion seemed more down the line of what I was seeing: "Broadcom dhd driver models (e.g. AC5300 routers) cannot support wireless repeater bridge (nor wireless client bridge) modes since the Broadcom dhd driver is controlled by wireless firmware internal to the chipset. This makes it impossible to implement fake bridge modes, and is not fixable. While it can sometimes work without encryption, there is no guarantee nor official support."

One issue is I don't really know what a "dhd" driver is, nor if the Netgear WNDR3400 v2 router contains it, but the first quest is to figure out what "DHD" stands for, which apparently is: "Broadcom Dongle Host Driver (DHD)"

Now I have to figure out if the Netgear WNDR3400v2 implements dhd.

Where I haven't confirmed if the router implements DHD or not yet.

In summary, the issue that struck me as an oddity of the encryption no longer working for an access point when it's connected in a wireless client bridge mode "may" be simply due to the substandard Broadcom DHD drivers since that type of oddity is known to occur elsewhere.

The future solution may be to never buy a router made using Broadcom chipsets, but a statement that severe would need a lot more research to say that for sure - so - for now - take it as an advisory only.