Android developer options reports strange home router acess point errors
when in client bridge (repeater) mode as shown in this screenshot below:
<https://i.postimg.cc/BQyYWpj3/devopt-verbose-wifi-log.jpg>

Does having one router joining a wireless client bridge on the home router
disable that home router access point from being a normal access point?

Or, could it simply be that there's a hardware failure in my router AP?
[Note the 5GHz home router AP does not exhibit this 2.4GHz failure mode.]

Downstairs is a home router with 2G & 5G access points which worked fine.
Upstairs, I have a desktop Windows 10 PC with only Ethernet (no Wi-Fi).

I flashed a Linksys WRT54Gv8.1 with "dd-wrt v24 RC-7 (03/19/08_) micro".
I set up that Linksys WRT54Gv8.1 dd-wrt in "wireless client bridge mode".
I joined the dd-wrt router to the Netgear home router 2GHz access point.

Note: At some point I changed the "Wireless Client Bridge" to a "Bridge
Repeater" which simply made the client bridge _also_ a wireless repeater.

That works fine to connect a Windows 10 PC Ethernet port to the dd-wrt
which itself is joined to the Netgear LAN WI-Fi AP as a w/l client bridge.

However, after that, other devices (e.g., cellphone, iPad, other computers,
etc.) no longer connect to the home router 2G access point - but - they can
connect to the home router 5G access point (so the home router is working).

Note: If I turn on Android Developer options, and then I turn on Networking
"Enable Wi-Fi Verbose Logging", that reports upon connecting this:
"NETWORK_SELECTION_DISABLED_AUTHENTICATION_FAILURE=2" whereas when
I connect to the 5G AP of the same home router, Android reports
"Connected / standard = 4rssi = -34 score =60 tx = 1.4 rx=0.6, etc."

Can I assume, from that datum, that once the spare router connects to a
home router AP as a wireless client bridge, this connection disables the
home router access point from connecting to anything else in normal mode?

Or could it possibly be that the home router access point is just bad?
--
Posted out of the goodness of my heart to disseminate useful information
which, in this case, is to find the answer to the networking question.

Andy Burnelli wrote:

> Does having one router joining a wireless client bridge on the home router
> disable that home router access point from being a normal access point?

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?]

Andy Burns wrote:

>> Does having one router joining a wireless client bridge on the home router
>> disable that home router access point from being a normal access point?
>
> 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.)

<https://i.postimg.cc/44VBVjtB/wirelessbridge01.jpg> dd-wrt client bridge
<https://i.postimg.cc/k5Hfvmfh/wirelessbridge02.jpg> dd-wrt bridge repeater
<https://i.postimg.cc/65xbPBwk/wirelessbridge03.jpg> run site survey & join
<https://i.postimg.cc/L5KDGVdt/wirelessbridge04.jpg> 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).
<https://i.postimg.cc/XJChDCPr/spare-access-points.jpg>

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.
<https://duckduckgo.com/&q=NETWORK_SELECTION_DISABLED_AUTHENTICATION_FAILURE>

It seems, like many networking issues, there are multiple error causes.
<https://forum.xda-developers.com/t/wifi-problem-in-oreo-network-selection-disabled-association-rejection.3800632/>

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*
<https://appuals.com/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)
--
Posted out of the goodness of my heart to disseminate useful information
which, in this case, is to respond to Andy's helpful bridge comments.

Andy Burnelli wrote:

> <https://i.postimg.cc/44VBVjtB/wirelessbridge01.jpg> dd-wrt client bridge
> <https://i.postimg.cc/k5Hfvmfh/wirelessbridge02.jpg> dd-wrt bridge repeater
> <https://i.postimg.cc/65xbPBwk/wirelessbridge03.jpg> run site survey & join
> <https://i.postimg.cc/L5KDGVdt/wirelessbridge04.jpg> both SSIDs now work!

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.
<https://i.postimg.cc/SKvK2ccJ/wirelessbridge05.jpg> Windows elegance
--
Posted out of the goodness of my heart to disseminate useful information
which, in this case, is to describe some of the networking magic going on.

> Can I assume, from that datum, that once the spare router connects to a
> home router AP as a wireless client bridge, this connection disables the
> home router access point from connecting to anything else in normal mode?
>
> Or could it possibly be that the home router access point is just bad?

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:
<https://wiki.dd-wrt.com/wiki/index.php/Client_Bridge>
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.
<https://openwrt.org/toh/hwdata/netgear/netgear_wndr3400_v2>
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:
<https://wiki.dd-wrt.com/wiki/index.php/Repeater_Bridge>

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.
<http://en.techinfodepot.shoutwiki.com/wiki/Netgear_WNDR3400v2>
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.
--
Posted out of the goodness of my heart to disseminate useful information
which, in this case, is to supply a summary solution so that the next
person with this problem may find this solution in the permanent Usenet
archives, which, since immense detail is provided, may help them solve the
problem far sooner, easier, and more efficiently, than it took me & you.