So I got a bridged hostapd AP server working with a MT7612U chipset

[Thimbles809]

But I have a problem.

I have an Alfa AWUS36ACM and it works brilliantly in "hw_mode=a", pulling the limits of my cable modem plan at about 250 to 300 mbs, which is what I get when wired.
But I need to have a 2.4 ghz network to support some older devices that can't hit 5 ghz. When I put the Alfa in "hw_mode=g", it pulls 50 to 60 mbs.

I've tried tweaking many hostapd.conf parameters but it's just not working, and I've set up a realtek 8812bu in g mode and it's pulling about 100mbs using morrownr's driver:
https://github.com/morrownr/88x2bu-20210702

but I would like to use the Alfa at full capacity on the 2.4ghz spectrum. Is this a hardware limit, or am I just not invoking the right hostapd.conf spell?

Running on 64 bit raspberry os on a 8gig Raspi4.

[Thimbles809]

So I just dropped the 2g version of the hostapd.conf listed here:
https://github.com/morrownr/USB-WiFi/blob/main/home/AP_Mode/Bridged_Wireless_Access_Point.md
on my AP - uncommenting the section devoted to the mt7612u and I got 60mbs.

The same file, changing the interface to the Realtek 8812bu and eliminating the unsupported [GF] flag with that chipset, generates 108 mbs. So it looks like this is a hardware issue or a driver issue for the Alfa, which is a shame. :(

Unless anyone else knows how to get the Alfa to perform 2g better, I'm stumped and stuck,

[morrownr]

Hi @Thimbles809

Let me throw some ideas out, then we can see about optimizing things if that is what you want to do.

I have a RasPi4B w/4gb RAM. To say that I have worn it out testing and building the Bridged Wireless Access Point guide is an understatement. Here are some observations:

• Some things just work better at some jobs. It really is that simple. My approach is try it and see what you get.
• My experience with the Alfa ACM is that it is excellent as a 5 GHz AP.
• My experience is that adapters based the rtl8812bu chipset are best kept in USB2 mode due to issues with the RasPi4B.

So, given two adapters, the ACM and one based on the 8812bu, I would use the ACM as the 5 GHz AP and the 8812bu as the 2.4 GHz AP in the dual band setup. You are pretty much optimizing the capabilities of the PI and those two adapters with that setup.

To do any tweaking, I would need to look at your hostapd.coonf files.

[Thimbles809]

That's the thing. I spent the majority of my time on this project getting the network bridge interface to work properly with the remote dhcp server and, by the time I finished getting the AP to work properly, I just wanted to drop a hostapd.conf file that had been tuned to the mt7612.

And that's how I found your tutorial on making a bridged ap with the 5g and 2g confs. 😑 So it's basically those files that powered my setup and the changes I made since made no difference to the 2.4 gz performance.
So I reverted them back.

But now I got an extra Alfa on order because I thought its performance on the 5g band was so great and the Realtek was just my stop gap until the Alfa came in.

Lesson learned, the $$$ way. Is there a better 2.4ghz suited adapter currently on the market? Even the Realtek, complements to the driver author, seems capped at 2/3rds the 2.4g spec.

[Thimbles809]

So I've tried adjusting supported rates and basic rates to see if that would bump it any higher. Nothing budged.
This is my output from the 2g conf file running sudo hostapd interactively:
"Configuration file: /etc/hostapd/2-4hostapd.conf
AlfaWlan0: interface state UNINITIALIZED->COUNTRY_UPDATE
AlfaWlan0: interface state COUNTRY_UPDATE->HT_SCAN
20/40 MHz operation not permitted on channel pri=1 sec=5 based on overlapping BSSes
Using interface AlfaWlan0 with hwaddr XX:XX:XX:XX:XX:XX and ssid "2-4Test"
AlfaWlan0: interface state HT_SCAN->ENABLED
AlfaWlan0: AP-ENABLED
#phone connecting here#
AlfaWlan0: STA XX:XX:XX:XX:XX:XX IEEE 802.11: authenticated
AlfaWlan0: STA XX:XX:XX:XX:XX:XX IEEE 802.11: associated (aid 1)
AlfaWlan0: AP-STA-CONNECTED XX:XX:XX:XX:XX:XX
AlfaWlan0: STA XX:XX:XX:XX:XX:XX RADIUS: starting accounting session 8C92B5E5046E2C08
AlfaWlan0: STA XX:XX:XX:XX:XX:XX WPA: pairwise key handshake completed (RSN)

---

PS> The AlfaWlan0 name comes from a /etc/udev/rules.d/10.network.rules file I made to stop the OS from flipping my two wlan usb interfaces when I plugged or unplugged an extra usb device and rebooted. Spent a few minutes trying to figure why my wlan1 interface was down and wlan2 was up until I realized that they were 'hostapd' each other's conf files. Good Times.

[morrownr]

That's the thing. I spent the majority of my time on this project getting the network bridge interface to work properly with the remote dhcp server and, by the time I finished getting the AP to work properly, I just wanted to drop a hostapd.conf file that had been tuned to the mt7612.

I get that. It can take a while to really understand how all this networking stuff works, hostapd is powerful but it takes time to learn. One of these days when you think about setting up WiFi 6, it gets more complicated. WiFi 6e is even more complicated.

Is there a better 2.4ghz suited adapter currently on the market?

The best 2.4 GHz adapter depends on what you are doing and what the need is.

Twice last year I had individuals looking for adapters to support the IoT setup they were building in their house. What they needed was an adapter that could handle 32-64 connections, long range and 24/7/365 stability. There was no need to big throughput because the devices just don't need it and only 2.4 GHz was needed. The Realtek drivers that I am aware of limit out at about 32 connections so they were ruled out. I did some testing and the adapter at the top of the list was the Panda PAU08. The users bought one to test and, in both cases, they were very pleased. That adapter has very long range and will cover a large home. The in-kernel driver is rock solid. It could do a link rate of about 72 Mb/s with a throughput of about 30 Mb/s... basic 20 MHz channel width 2.4 GHz band wifi.

If I need long range with 2.4 GHz, the Panda works well or my personnel favorite is the Alfa ACHM. It costs more than the Panda but the range that little mighty mite adapter has is really something. If you are looking for big throughput, we might look somewhere else but it depends on your local situation. Generally speaking, I stick to 20 MHz channel width because going to 40 can actually slow things down depending on your local traffic. If you live out in the country away from other APs, sure use 40 MHz channel width and you can get more throughput. Were you running 20 or 40 MHz channel width? Do you have other APs in the area? Have you tested to see what channels provide the best throughput?

Even the Realtek, complements to the driver author, seems capped at 2/3rds the 2.4g spec.

I know the author. He tries to take care of that driver but back to topic.

WiFi is a sharing technology. So that I don't bore you, here is a link that provides some good info:

https://metis.fi/en/2017/10/txpower/

Nick

[Thimbles809]

"I know the author. He tries to take care of that driver but back to topic."
;)
Back on topic, the other thought I had was that the 802.11n total transfer rate tops out at 150mbs. The AWUS036ACM adapter had 3rx and 3tx antennas. Could the adapter be reserving transfer capacity, at about 50mbs - give or take, so it can assign capacity to the other sets of antenna and service other clients in AP mode?
I'm going to run a simultaneous test and report results.

[Thimbles809]

:/ Simultaneous clients running speedtest show one client hitting 28.23 and the other hitting 17.11. Yup. It's not reserving 2g capacity, it just doesn't seem to have it.

"The best 2.4 GHz adapter depends on what you are doing and what the need is."

I need my family to stop complaining that the internet is slow or that the signal has dropped in their rooms. :)
What the house used to run was an 10/100 moca network that received internet served by an old linksys running tomato firmware.
I updated that to a raspberry DDNS DHCP server last year and kept the old tomato running the wifi. Then the cable plan got bumped to 300 mbs and, a couple of screen beams later:
https://www.amazon.ca/Actiontec-MoCA-Network-Adapter-Ethernet/dp/B088KV2YYL/ref=sr_1_1
suddenly the tomato was the bottleneck.
Now, wifi 5 and 6 wise, the devices that can run it are pleased with more internet than they know what to do with. It's just the 2.4 g band limited devices that vex me.

[Thimbles809]

Update. I got my second AWUS36ACM and, though I was getting 802.11g speeds, I decided to go with an in-kernel driven card.

And I learned something from doing so.

It turns out my area is quite congested on the 2.4ghz band and I thought the sub par speeds might be related to being forced into a 20mhz wide channel.

So to test, I compiled a hostapd patch that forces a 40mhz channel:

https://github.com/d2r2/upstream-hostapd-force-ht40-mode-patch

and did some test runs in user mode (I didn't make install). I verified my SSID was 40mhz wide with this:

https://play.google.com/store/apps/details?id=com.farproc.wifi.analyzer&hl=en

And my findings were the channel width made no difference. The Alfa pushes the 2.4 band at the speed it wants to push it - WRT54G speed.

So I sucked it up an decided to take a fresh 2g file from the bridged AP section and just focus on making it secure for the devices that use it and will use it slowly.

And what I found then was that A) my daughters beloved tablet did not support wpa2.
B) the devices that do, suddenly have 70-80mbs down 65-75mbs up.

Here's my hostapd file:
AlfaWlan1-hostapd.conf.txt
Now my plan is, I might have to expand house coverage by setting up another AP with the second Alfa and run the 2.4ghz with these cheapo adapters they're clearing out here:
https://www.pishop.ca/product/TEMP_11
But for now, it seems I got something working securely and doing the best it can within a 20mhz channel range in the 2.4ghz spectrum on the Alfa.
But I do have some concerns about how the realtek was handling the wpa low supported devices. I'll have to see how my RealTek hostapd configuration was letting on legacy devices without, it appears, supporting the proper encryption.

[morrownr]

I need my family to stop complaining that the internet is slow or that the signal has dropped in their rooms. :)

Now, wifi 5 and 6 wise, the devices that can run it are pleased with more internet than they know what to do with. It's just the 2.4 g band limited devices that vex me.

And I thought I was going to be able to relax this evening.

It turns out my area is quite congested on the 2.4ghz band and I thought the sub par speeds might be related to being forced into a 20mhz wide channel.

Please allow me to wax poetic...

I've been using Linux since 1994 and wifi since the beginning. My experience with the 2.4 GHz band tells me...

• you should only use 40 Mhz wide if you live way out in the country away from any 2.4 band signals. You can actually slow things down in a congested area by trying 40 MHz. I always lock 20 MHz in my wifi router/AP for the 2.4 band . It can push plenty of data for most uses. Our 2.4 GHz serves 2 FHD streaming TV's and the smartphones and the IoT stuff. Not a problem.
• where we currently live, we have congestion in the 2.4 band. Channels 1 and 6 are badly congested. Channel 11 has limited congestion so that is what we use.
• it is my experience that there is almost always one 2.4 GHz channel that is best to use. You have to find it. All 3 channels will be at different levels of congestion. You have to find the best one.
• only use channels 1, 6 or 11. Others will overlap and you will get congestion from 2 directions.

So, job number one is to find the least congested of channels 1, 6 or 11. Then we can look at others things.

Nick

[Thimbles809]

So after going over the wifi analyzer, it appears my best channel is 8 and I get just under 90mbs on it. I've removed all the 40 mhz ht_capab's so there are no complaints at startup about how our wifi toilet is clogged and we can only support 20mhz. ACS, I assume, is still not working since it returns "ACS: Unable to collect survey data" whenever I try to use it and it seems I'm not alone.

So it appears that on the Alfa, having the setting "wpa_key_mgmt=WPA-PSK" limits the wifi to under 54mbs despite setting everything else to 802.11n and enabling all the extensions. I've found reference to this problem here:
https://superuser.com/questions/678899/wireless-ac-adapter-indicates-max-speed-is-54mbps-when-connected-to-wireless-ac
By using "WPA-PSK-SHA256 = WPA2-Personal using SHA256"
https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
it inadvertently forced my 2g configuration to use WPA2 which boosted the speed to 802.11n. Yay.

[morrownr]

after going over the wifi analyzer, it appears my best channel is 8

Then use channel 6. Your options are 1, 6 and 11. Seriously.

ACS, I assume, is still not working since it returns "ACS: Unable to collect survey data" whenever I try to use it and it seems I'm not alone.

You don't want ACS. Set a fixed channel.

So it appears that on the Alfa, having the setting "wpa_key_mgmt=WPA-PSK" limits the wifi to under 54mbs

You need to copy and paste your hostapd.conf that you are using for 2.4 Ghz. Let me help you. Something is wrong.

[Thimbles809]

I posted it above as a link, but we'll try it this way. fingers crossed

# /etc/hostapd/hostapd-2g.conf
# Documentation: https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
# 2022-08-08

# SSID
ssid=ANSSID
# PASSPHRASE
wpa_passphrase=APASSWORD
# Band: a = 5g (a/n/ac), g = 2g (b/g/n)
hw_mode=g
# Channel
channel=6
# Country code
country_code=CA

# Bridge interface
bridge=br0
# WiFi interface
interface=AlfaWlan1

# nl80211 is used with all Linux mac80211 (in-kernel) and modern Realtek drivers
driver=nl80211
ctrl_interface=/var/run/AlfaWlan1-hostapd
ctrl_interface_group=0

beacon_int=100
dtim_period=2
max_num_sta=32
rts_threshold=2347
fragm_threshold=2346
#send_probe_response=1

# security
# auth_algs=3 is required for WPA3-SAE and WPA3-SAE Transition mode
auth_algs=3
macaddr_acl=0
ignore_broadcast_ssid=0
wpa=2
# WPA2-AES
#wpa_key_mgmt=WPA-PSK
# WPA3-SAE
wpa_key_mgmt=SAE WPA-PSK-SHA256
#wpa_group_rekey=1800
wpa_pairwise=CCMP TKIP
rsn_pairwise=GCMP-256 CCMP
# ieee80211w=2 is required for WPA3-SAE
ieee80211w=2
# If parameter is not set, 19 is the default value.
#sae_groups=19 20 21 25 26
#sae_require_mfp=1
# If parameter is not 9 set, 5 is the default value.
#sae_anti_clogging_threshold=10
# IEEE 802.11n
ieee80211n=1
wmm_enabled=1
#
# Note: Only one ht_capab= line should be active. The content of these lines is
# determined by the capabilities of your adapter.
#
# generic 20 MHz setting
#ht_capab=[SHORT-GI-20]
#
# generic 40 MHz setting
#ht_capab=[HT40+][HT40-][SHORT-GI-20][SHORT-GI-40]
#
# RasPi4B internal wifi
#ht_capab=[HT40+][HT40-][SHORT-GI-20][SHORT-GI-40][DSSS_CCK-40]
#
# rt5370 - rt3070
#ht_capab=[HT40+][HT40-][GF][SHORT-GI-20][SHORT-GI-40][RX-STBC1]
#
# ar9271
#ht_capab=[HT40+][HT40-][SHORT-GI-20][SHORT-GI-40][RX-STBC1][DSSS_CCK-40]
#
# mt7612u - mt7610u
ht_capab=[GF][SHORT-GI-20]
#
# rtl8812au - rtl8811au - rtl8812bu - rtl8811cu
#ht_capab=[HT40+][HT40-][SHORT-GI-20][SHORT-GI-40][MAX-AMSDU-7935]
# rtl8814au
#ht_capab=[LDPC][HT40+][HT40-][SHORT-GI-20][SHORT-GI-40][MAX-AMSDU-7935][DSSS_CCK-40]

# End of hostapd-2g.conf

Thanks for your patience on this. I know it's hard showing rookies how to work the ropes... and I hate being the rookie.

[morrownr]

The only changes that I would make if it were my system are the following. The reason is that many older devices just can't handle WPA3 on 2.4 band.

auth_algs=1
wpa_key_mgmt=WPA-PSK
wpa_pairwise=CCMP
#rsn_pairwise=GCMP-256 CCMP
#ieee80211w=2

Thanks for your patience on this. I know it's hard showing rookies how to work the ropes... and I hate being the rookie.

I enjoy it.

Let me switch out adapters on my Pi4B so as check what kind of throughput I can get.

[morrownr]

Here is the iperf3 result when I used a Alfa ACM 7612u adapter on my Pi4B:
Note: Channel 6 is congested here but not too bad.

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  11.0 MBytes  92.6 Mbits/sec    0    495 KBytes       
[  5]   1.00-2.00   sec  9.67 MBytes  81.1 Mbits/sec    0    667 KBytes       
[  5]   2.00-3.00   sec  10.0 MBytes  83.9 Mbits/sec    0    864 KBytes       
[  5]   3.00-4.00   sec  8.75 MBytes  73.4 Mbits/sec    0    932 KBytes       
[  5]   4.00-5.00   sec  8.75 MBytes  73.4 Mbits/sec    0   1.02 MBytes       
[  5]   5.00-6.00   sec  10.0 MBytes  83.9 Mbits/sec    0   1.02 MBytes       
[  5]   6.00-7.00   sec  8.75 MBytes  73.4 Mbits/sec    0   1.15 MBytes       
[  5]   7.00-8.00   sec  8.75 MBytes  73.4 Mbits/sec    0   1.15 MBytes       
[  5]   8.00-9.00   sec  10.0 MBytes  83.9 Mbits/sec    0   1.15 MBytes       
[  5]   9.00-10.00  sec  8.75 MBytes  73.4 Mbits/sec    0   1.15 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  94.5 MBytes  79.2 Mbits/sec    0             sender
[  5]   0.00-10.06  sec  91.2 MBytes  76.1 Mbits/sec                  receiver

Below is the .conf file I used for the above. I cut all of the comments and spaces to make it more readable.

ssid=myPI-2g
wpa_passphrase=myPW
hw_mode=g
channel=6
country_code=US
ieee80211d=1
bridge=br0
interface=wlan0
driver=nl80211
auth_algs=3
macaddr_acl=0
ignore_broadcast_ssid=0
wpa=2
wpa_pairwise=CCMP CCMP-256
wpa_key_mgmt=WPA-PSK
ieee80211n=1
wmm_enabled=1
ht_capab=[SHORT-GI-20]

[morrownr]

I decided to do a test with the adapter in a USB2 port so as to show you that USB2 does just fine with the 2.4 band. In other words, there is no need to use a USB3 port for the 2.4 GHz band. iperf3 result:

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  12.7 MBytes   106 Mbits/sec    0    571 KBytes       
[  5]   1.00-2.00   sec  9.98 MBytes  83.7 Mbits/sec    0    691 KBytes       
[  5]   2.00-3.00   sec  8.75 MBytes  73.4 Mbits/sec    0    691 KBytes       
[  5]   3.00-4.00   sec  7.50 MBytes  62.9 Mbits/sec    0    737 KBytes       
[  5]   4.00-5.00   sec  8.75 MBytes  73.4 Mbits/sec    0    737 KBytes       
[  5]   5.00-6.00   sec  11.2 MBytes  94.4 Mbits/sec    0    892 KBytes       
[  5]   6.00-7.00   sec  11.2 MBytes  94.4 Mbits/sec    0    940 KBytes       
[  5]   7.00-8.00   sec  10.0 MBytes  83.9 Mbits/sec    0   1.09 MBytes       
[  5]   8.00-9.00   sec  8.75 MBytes  73.4 Mbits/sec    0   1.09 MBytes       
[  5]   9.00-10.00  sec  10.0 MBytes  83.9 Mbits/sec    0   1.14 MBytes       

[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  98.9 MBytes  83.0 Mbits/sec    0             sender
[  5]   0.00-10.03  sec  95.8 MBytes  80.1 Mbits/sec                  receiver

It turns out that it seemed to give consistently higher results in a USB2 port. Don't ask.

Something else to keep in mind:

The placement of the antennas is extremely important for AP mode. You may have to try different locations to determine what gives the best results but in general:

• at least eye level. Higher than the clients is good.
• at least 1 foot away from any walls.
• consider what is between the antennas and the clients. Concrete walls, electrical wiring and other similar things can hurt.
• an extension cable can help with placement.

Don't underestimate location of the antennas as an issue for setting up an AP.

[Thimbles809]

Work and IRL activities really cut into my 2.4g network tunning hobby this week so sorry for the delay.
I tried the file with your changes and it didn't make a significant dent on my side, me being beside the antenna which is mounted high on a bookshelf. I just got the rt5730's and I'll be unpacking them and setting them up to serve the 2.4 band and using the Alfa's to do 5 g on multiple AP's with a cat6 cable on the back end.

What I can say is that the usb2 improvement may be related to my experience with the pi and its usb port placement. I had a pocket keyboard to control a pi dlna server and the keyboard started glitching really bad when I switched from sd cards to USB3 ssd drives. I thought the keyboard was broken until I stumbled on this:

https://www.usb.org/sites/default/files/327216.pdf

The keyboard glitch was solved by a 3ft male to female usb cable. I don't know if that might be the reason why you're seeing performance loss when plugging a 2.4g emitter into a usb3 port, but boy was I getting mad at my misbehaving keyboard until I found out it was a dongle proximity problem.

[Thimbles809]

Wow. Wow. I'm just insert explodey head here. That pishop link with the cheap rt5370's? Turns out they sent me cheap RealTek 8188EU's. To get one of them working in AP mode, I had to git clone a driver and then downgrade the encryption to the barest in order for hostapd not to fail with the cryptic error "Failed to set beacon parameters".
And even when it's working, it's dumping heaps of junk into my syslog.

Honestly. insert mad "$%^" face here* I've had good experiences with pishop as a vendor in the past, but this is a major screw up.

[morrownr]

@Thimbles809

Even my head exploded.

While you cool down, we can have a discussion. I've had good luck with the below on Pi's.

https://www.amazon.com/dp/B07S6B5X76

Here is a new adapter I just posted in the In-Kernel list today:

https://www.amazon.com/Panda-Wireless-PAU0B-Adapter-Antenna/dp/B08NPX2X4Z/ref=cm_cr_arp_d_product_top?ie=UTF8

Look at that high gain antenna. It is getting good reviews.

[Thimbles809]

The red adapter would look real thematic here in Canada, if amazon and panda made them available in canada :(
The closest item on the amazon.ca website is sad trombone music
https://www.amazon.ca/Panda-Wireless-PAU0A-AC600-Adapter/dp/B07C9TYDR4
So I committed myself to making two 5gz AP's with a 100ft cat6 cable as the backend and the same SSID to allow roaming in the house.
How is it working you ask? Fantastic but I probably could have gotten away with 75 ft of ethernet.

Better too much than too little, I say.

I do have a minor hiccup with the 5gz channel selection. the first AP is set at 36 and has an 80mhz width. I tried to set it to 40, using "vht_oper_chwidth=0", but that failed with "Could not set channel for kernel driver".

For the second AP, I attempted to keep the channels from overlapping and there seems to be a lot of channels reserved for radar detection or are just disabled 149 to 165 seem available, but every channel assignment leads to a downgrade from the requested 80mhz width to 20mhz. Not a big deal because I get just over 100 mbs down with that 20mhz width, which is about half the performance of the 80mhz, but no one but me is measuring that if the youtubes and netflixes work seamlessly.

I currently have the channel of the second AP at 165, since that is the most unoccupied band. I'd like to get every AP matched up on different channels with about 40mhz width and the spirits won't let me.

On another note, while learning how to set up multiple interfaces to run hostapd on multiple bands I learned (what I've heard) is the proper way of configuring systemd to start hostapd with multiple configuration files.
"cp /lib/systemd/system/hostapd.service /etc/systemd/system/hostapd.service
add your multiple files to the /etc/systemd/system/hostapd.service file on the ExecStart line"
Now I have neighbors who are sensitive to sources of radio around them. So I wanted to turn the radio down on my AP's at startup. So what I did was I created an ExecStartPost line and stuck the command "iwconfig AlfaWlan0 txpower 10" on it
It appears to work, but I don't know if it's the right way. shrug However, if it isn't the wrong way, it might be a useful technique for people using hostapd around sensitive equipment and who want to reduce their interference from their wifi.

[morrownr]

On another note, while learning how to set up multiple interfaces to run hostapd on multiple bands I learned (what I've heard) is the proper way of configuring systemd to start hostapd with multiple configuration files.
"cp /lib/systemd/system/hostapd.service /etc/systemd/system/hostapd.service
add your multiple files to the /etc/systemd/system/hostapd.service file on the ExecStart line"
Now I have neighbors who are sensitive to sources of radio around them. So I wanted to turn the radio down on my AP's at startup. So what I did was I created an ExecStartPost line and stuck the command "iwconfig AlfaWlan0 txpower 10" on it
It appears to work, but I don't know if it's the right way. shrug

https://github.com/morrownr/USB-WiFi

If you go to item 9 on the USB-WiFi main menu (see link above), the document gives very specific setup instructions for the above. It is widely tested and works well. The document is a long read but it is hard to include the needed information in a short document.

For the second AP, I attempted to keep the channels from overlapping and there seems to be a lot of channels reserved for radar detection or are just disabled 149 to 165 seem available, but every channel assignment leads to a downgrade from the requested 80mhz width to 20mhz. Not a big deal because I get just over 100 mbs down with that 20mhz width, which is about half the performance of the 80mhz, but no one but me is measuring that if the youtubes and netflixes work seamlessly.

When using hostapd, often, when you want to make a change, you have to move several settings at the same time for it to work. You can post your hostapd.conf along with a short description of what you are trying to and I can point out any issues.

[Thimbles809]

Man. If I had found this tutorial last month, would have been so helpful.

But I went a different route on the bridging by setting up the bridge and interfaces in files in the interfaces.d directory. And this process gave me insight into what the bridge tends to do (which is why it took me so long to get the bridgework done right).

The bridge tends to take the MAC address of the last interface it absorbs and, because our hostapd added wireless is the last interface to join the bridge, it captures the MAC address of the wireless.

And then it requests an ip address from your DHCP server for that address. angry face %^&$%@$!

So I went through the steps just now on the tutorial and I got to here:
[Match]
Name=br0

[Network]
DHCP=yes
#Address=192.168.1.100/24
#Gateway=192.168.1.1
#DNS=8.8.8.8

did the reboot, and got locked out of my AP.
Turns out br0 had assigned itself my Alfa's MAC again and got a ip associated with it I couldn't connect to. The ethernet interface over which the bridge communicates with the DHCP server had the ip I wanted assigned but the unfaithful bridge had moved on at that point.

Home network wrecker.

What I found worked was tying down the bridge to the interface it uses to talk to the dhcp server. In the interfaces.d/br0 file, I did this by:
auto br0
iface br0 inet dhcp
hwaddress ether <mac address of dhcp talking interface>
bridge_ports eth0

Using your method, I had to do this in the 30-config-bridge-br0.network:
[Match]
Name=br0
[Link]
MACAddress=<mac address of dhcp talking interface>
[Network]
DHCP=yes
#Address=192.168.1.100/24
#Gateway=192.168.1.1
#DNS=8.8.8.8

Which got everything working again. Sorry for turning this thread into a pain in the ass, but the good news is my site is making progress thumbs up emojis

[morrownr]

Man. If I had found this tutorial last month, would have been so helpful.

I knew I should have bought an ad for the Super Bowl.

But I went a different route on the bridging by setting up the bridge and interfaces in files in the interfaces.d directory.

There are a lot of different ways to set this up. The setup you see in the guide was developed over time as it falls into what I call a 24/7/365 setup. It is extremely stable.

Using your method, I had to do this in the 30-config-bridge-br0.network:

[Match]
Name=br0
[Link]
MACAddress=<mac address of dhcp talking interface>
[Network]
DHCP=yes
#Address=192.168.1.100/24
#Gateway=192.168.1.1
#DNS=8.8.8.8

What I use to stick things is:

[Match]
Name=br0

[Network]
#DHCP=yes
Address=192.168.1.104/24
Gateway=192.168.1.1
DNS=8.8.8.8

What I found worked was tying down the bridge to the...

You have a hybrid setup so I need to be quiet or I will mess you up. If you do see any problems, a format c: might be in order. It takes less time to start from a fresh burn than you think. I have the guide setup so that you can cut and paste.

Sorry for turning this thread into a pain in the ass...

No problem. Things that are a pain in the ass are what I do. It is for educational purposes. If you see any improvements that can be made to the guide, let me know.

@morrownr

[Thimbles809]

We're at the end of a very long day.

So I did it from scratch, format c: if you will, and over the howls of my family only having one working AP to rely on, I pulled it all together.

Here's what I came up with.

1. when you enable the systemd-networkd the bridges act different. They generate their own MAC and it seems consistent because it appears to be based on:
   https://wiki.archlinux.org/title/systemd-networkd
   systemd-networkd assigns a MAC address generated based on the interface name and the machine ID to the bridge.
This may cause connection issues, for example in case of routing based on MAC filtering.
To circumvent such problems you may assign a MAC address to your bridge, probably the same as your physical device, adding the line MACAddress=xx:xx:xx:xx:xx:xx in the NetDev section above.

What that enables you to do is to assign an IP from your DHCP server to the br0 macaddress, which will allow you to connect any ethernet (or maybe even a wifi) interface to the DHCP server and even rotate them, which I have done. I still like the idea of explicitly tying the bridge to a MAC in case a name change breaks your DHCP setup.

I spent a a lot of time trying to diagnose why I kept getting garbage ipv6 addresses from avahi and dhcpcd. Turns out if you are running a ipv4 home network, you better tell your interfaces.
[Match]
Name=br0
[Network]
DHCP=ipv4
IPv6AcceptRA=no
LinkLocalAddressing=no
#Address=192.168.1.100/24
#Gateway=192.168.1.1
#DNS=8.8.8.8

The ethernet interfaces seem to follow br0's lead, because they're all joined first and then config'ed, but wifi gets added later and so it needed it's own coaxing.
31-config-wlan0.network
[Match]
Name=wlan0
[Network]
DHCP=ipv4
IPv6AcceptRA=no
LinkLocalAddressing=no

And then there was my clever service file which was not clever when I converted to systemd-networkd. Don't put quotes in your ExecStartPost command and it's good form to explicitly define your root level invocations.
Do it right and you'll see something like this in your systemctl status messages
ExecStartPost=/sbin/iwconfig wlan0 txpower 10 (code=exited, status=0/SUCCESS)
Do it wrong and hostapd won't start :(

Oh, and I put into dhcpcd.conf:
interface br0
ipv4only

Calling it a day.

[morrownr]

Whew! It is going to take some time for me to digest the above.

ExecStartPost=/sbin/iwconfig wlan0 txpower 10 (code=exited, status=0/SUCCESS)

Recommend you discontinue the use of iwconfig as it has been depreciated and is no longer maintained.

I see you re using MAC addresses to do certain things. I can't do that as I am constantly changing out adapters to test when users have problems.

Keep me posted and make sure the family has good wifi. Happy wife, happy life!

[Thimbles809]

You can use the generated MAC to set up a host on the dhcp server in the dhcpd.conf file. Then you can explicitly link the generated MAC to your bridge so that changes in machine ID or system's pick of interface don't mess up your host definition.

This was why the bridge was grinding my gears before, because it would get the MAC from the interface that I had used to set up dhcp, and then it would take another MAC from another interface and pull another ip from the dhcp pool. Then I didn't know which ip to ssh to because dhcp was confused.
Now we have one MAC to rule them all, one MAC to find them, one MAC for all the interfaces and in darkness bind them! Hooray!

[Thimbles809]

New non iwconfig command:
ExecStartPost=/sbin/iw dev wlan0 set txpower fixed 1000

I figure the power level should be fixed rather than "auto" or "limit" because the AP should be broadcasting at a consistent rate. The power argument for iw is 100 times more granular than iwconfig, so 1000 translates to 10dbm, verified by the 'iw dev' command
phy#0
Interface wlan0
ifindex 6
wdev 0x1
addr 00:11:22:33:44:55
ssid Muted-Effect
type AP
channel 165 (5825 MHz), width: 20 MHz, center1: 5825 MHz
txpower 10.00 dBm
multicast TXQ:
qsz-byt qsz-pkt flows drops marks overlmt hashcol tx-bytes tx-packets
0 0 72 0 0 0 0 13134 76

[Thimbles809]

So I cloned my original AP, renamed it, configured it for the interfaces on the secondary ap, took out the hard coded MACAdress, and systemd networkd generated the exact same MAC for a similarly named interface on a different computer.
Which, of course, messed up my ddns and dhcp for a time.
So I grabbed two unique mac's from McDonalds a MACaddress generator and dropped them in as a link in each ap's 30-config file. Now my ddns, dhcp, and host config's are shaking hands like little John and the sheriff of Nottingham.
https://youtu.be/y-uZrjVD3fo?t=2m3s
There's more sanding to do, but I'm pleased with this.

[Thimbles809]

I recently upgraded.
https://www.walmart.ca/en/ip/Mymisisa-COMFAST-CF-WU785AC-1300M-WiFi-Adapter-USB-3-0-4-Antennas-Wireless-Receiver/1ARE3FBBU27S

My search for a working adapter solution from amazon was a fail and I'm not brave enough to put my credentials in alibaba's hands, but it seems that some alibaba resellers are setting up shop in canada under the walmart banner and 35 bucks canadian for an MT7612 chipset with 4 antennas is too sweet to pass up.
So now I got the alfa's running the 2.4 ghz spectrum and the comfast's running the 5 ghz with the hope that the extra set of antennas provides extra connectivity for clients? shrug I'm not sure if it works that way, but I'm going with it for now.

What I did note was that, if you are going to be like me and not use a static address for your wifi bridges, it was important to put an edit in /etc/dhcpcd.conf (the dhcp client config file)

This is what I have:
denyinterfaces eth0 enx* wlx*
interface br0
ipv4
dhcp
ipv4only
noipv4ll
noipv6
Then I had to edit the file I use to enforce my policy of all interfaces getting their interface info from br0 that I made in /etc/systemd/network/31-config-br0-interfaces.network
[Match]
#2.4ghz
Name=wlxde53f2545543
#5ghz
Name=wlxa3d917fb7d33
#network backend
Name=eth0

[Network]
DHCP=no
IPv6AcceptRA=no
LinkLocalAddressing=no

This gives you an output upon reboot of:
yeahwifibabyyeah :~ $ ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.3 netmask 255.255.255.0 broadcast 192.168.1.255
ether a9:07:b7:be:69:5e txqueuelen 1000 (Ethernet)
RX packets 329350 bytes 233767493 (222.9 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 51980 bytes 3195452 (3.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 59:a9:b0:7e:0c:f2 txqueuelen 1000 (Ethernet)
RX packets 7337664 bytes 8148367882 (7.5 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 2638965 bytes 602314478 (574.4 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 68 bytes 6271 (6.1 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 68 bytes 6271 (6.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlxde53f2545543: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether de:53:f2:54:55:43 txqueuelen 1000 (Ethernet)
RX packets 902202 bytes 492568768 (469.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 1887375 bytes 1842851069 (1.7 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

wlxa3d917fb7d33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether a3:d9:17:fb:7d:33 txqueuelen 1000 (Ethernet)
RX packets 1878514 bytes 323285692 (308.3 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 5789932 bytes 6493456357 (6.0 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
(all hostnames and MAC addresses have been changed to protect the innocent)

Using iperf3, a meter away from the AP, I'm getting:
Connecting to host yeahwifibabyyeah, port 5201
[ 4] local 192.168.1.185 port 52245 connected to 192.168.1.3 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 36.8 MBytes 307 Mbits/sec
[ 4] 1.00-2.00 sec 40.0 MBytes 336 Mbits/sec
[ 4] 2.00-3.00 sec 38.5 MBytes 323 Mbits/sec
[ 4] 3.00-4.08 sec 38.8 MBytes 302 Mbits/sec
[ 4] 4.08-5.00 sec 37.2 MBytes 339 Mbits/sec
[ 4] 5.00-6.00 sec 41.0 MBytes 344 Mbits/sec
[ 4] 6.00-7.00 sec 38.5 MBytes 323 Mbits/sec
[ 4] 7.00-8.00 sec 39.5 MBytes 332 Mbits/sec
[ 4] 8.00-9.00 sec 37.0 MBytes 310 Mbits/sec
[ 4] 9.00-10.00 sec 39.6 MBytes 333 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.00 sec 387 MBytes 325 Mbits/sec sender
[ 4] 0.00-10.00 sec 387 MBytes 325 Mbits/sec receiver

iperf Done.

on the 5ghz spec and
Connecting to host yeahwifibabyyeah, port 5201
[ 4] local 192.168.1.185 port 52392 connected to 192.168.1.3 port 5201
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.01 sec 6.38 MBytes 52.9 Mbits/sec
[ 4] 1.01-2.01 sec 5.62 MBytes 47.4 Mbits/sec
[ 4] 2.01-3.00 sec 5.75 MBytes 48.4 Mbits/sec
[ 4] 3.00-4.00 sec 5.75 MBytes 48.2 Mbits/sec
[ 4] 4.00-5.00 sec 5.00 MBytes 42.1 Mbits/sec
[ 4] 5.00-6.00 sec 5.12 MBytes 42.9 Mbits/sec
[ 4] 6.00-7.00 sec 4.75 MBytes 39.8 Mbits/sec
[ 4] 7.00-8.00 sec 2.25 MBytes 18.9 Mbits/sec
[ 4] 8.00-9.01 sec 2.12 MBytes 17.7 Mbits/sec
[ 4] 9.01-10.01 sec 2.00 MBytes 16.7 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 44.8 MBytes 37.5 Mbits/sec sender
[ 4] 0.00-10.01 sec 44.7 MBytes 37.5 Mbits/sec receiver

iperf Done.
on the 2.4ghz spec.

The hostapd 2g file is vanilla bridged hostapd with a canadian touch:
# /etc/hostapd/hostapd-2g.conf
# Documentation: https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
# 2022-08-08

#** SSID
ssid=YeahWifiBaby2.4
# PASSPHRASE
wpa_passphrase=DoIMakeYouHorny1234
# Band: a = 5g (a/n/ac), g = 2g (b/g/n)
hw_mode=g
# Channel
channel=6
# Country code
country_code=CA

# Bridge interface
bridge=br0
# WiFi interface
#alfa
interface=wlxde53f2545543
#comfast
#interface=wlxa3d917fb7d33

# nl80211 is used with all Linux mac80211 (in-kernel) and modern Realtek drivers
driver=nl80211
#alfa
ctrl_interface=/var/run/wlxde53f2545543-hostapd
#comfast
#ctrl_interface=/var/run/wlxa3d917fb7d33-hostapd
ctrl_interface_group=0
**vanilla stuff snipped here**
# security
# auth_algs=3 is required for WPA3-SAE and WPA3-SAE Transition mode
auth_algs=1
macaddr_acl=0
ignore_broadcast_ssid=0
wpa=2
wpa_pairwise=CCMP
# WPA2-AES
wpa_key_mgmt=WPA-PSK
rsn_pairwise=CCMP
**vanilla stuff snipped here**
# IEEE 802.11n
ieee80211n=1
wmm_enabled=1
#
# Note: Only one ht_capab= line should be active. The content of these lines is
# determined by the capabilities of your adapter.
#
**vanilla stuff snipped here**
# mt7612u - mt7610u
ht_capab=[HT40+][HT40-][GF][SHORT-GI-20][SHORT-GI-40]
# End of hostapd-2g.conf

On the isc-dhcp / ddns server side of things, we still get multiple request behavior from the wifi AP's as indicated in the server's syslog:

Mar 26 00:36:41 dr-evil dhcpd[1109]: DHCPREQUEST for 192.168.1.3 from a9:07:b7:be:69:5e via eth1
Mar 26 00:36:41 dr-evil dhcpd[1109]: DHCPACK on 192.168.1.3 to a9:07:b7:be:69:5e via eth1
Mar 26 00:37:44 dr-evil dhcpd[1109]: DHCPREQUEST for 192.168.1.3 from a9:07:b7:be:69:5e via eth1
Mar 26 00:37:44 dr-evil dhcpd[1109]: DHCPACK on 192.168.1.3 to a9:07:b7:be:69:5e via eth1
Mar 26 00:38:48 dr-evil dhcpd[1109]: DHCPREQUEST for 192.168.1.3 from a9:07:b7:be:69:5e via eth1
Mar 26 00:38:48 dr-evil dhcpd[1109]: DHCPACK on 192.168.1.3 to a9:07:b7:be:69:5e via eth1
Mar 26 00:39:53 dr-evil dhcpd[1109]: DHCPREQUEST for 192.168.1.3 from a9:07:b7:be:69:5e via eth1
Mar 26 00:39:53 dr-evil dhcpd[1109]: DHCPACK on 192.168.1.3 to a9:07:b7:be:69:5e via eth1
Mar 26 00:40:57 dr-evil dhcpd[1109]: DHCPREQUEST for 192.168.1.3 from a9:07:b7:be:69:5e via eth1
Mar 26 00:40:57 dr-evil dhcpd[1109]: DHCPACK on 192.168.1.3 to a9:07:b7:be:69:5e via eth1
Mar 26 00:42:01 dr-evil dhcpd[1109]: DHCPREQUEST for 192.168.1.3 from a9:07:b7:be:69:5e via eth1
Mar 26 00:42:01 dr-evil dhcpd[1109]: DHCPACK on 192.168.1.3 to a9:07:b7:be:69:5e via eth1
Mar 26 00:43:04 dr-evil dhcpd[1109]: DHCPREQUEST for 192.168.1.3 from a9:07:b7:be:69:5e via eth1
Mar 26 00:43:04 dr-evil dhcpd[1109]: DHCPACK on 192.168.1.3 to a9:07:b7:be:69:5e via eth1
Mar 26 00:44:07 dr-evil dhcpd[1109]: DHCPREQUEST for 192.168.1.3 from a9:07:b7:be:69:5e via eth1
Mar 26 00:44:07 dr-evil dhcpd[1109]: DHCPACK on 192.168.1.3 to a9:07:b7:be:69:5e via eth1
Mar 26 00:45:12 dr-evil dhcpd[1109]: DHCPREQUEST for 192.168.1.3 from a9:07:b7:be:69:5e via eth1
Mar 26 00:45:12 dr-evil dhcpd[1109]: DHCPACK on 192.168.1.3 to a9:07:b7:be:69:5e via eth1

And indications of the same on the bridged AP's syslog:
Mar 26 00:36:41 yeahwifibabyyeah dhcpcd[459]: br0: sending REQUEST (xid 0x5df77679), next in 63.1 seconds
Mar 26 00:37:44 yeahwifibabyyeah dhcpcd[459]: br0: sending REQUEST (xid 0x5df77679), next in 64.2 seconds
Mar 26 00:38:48 yeahwifibabyyeah dhcpcd[459]: br0: sending REQUEST (xid 0x5df77679), next in 64.5 seconds
Mar 26 00:39:53 yeahwifibabyyeah dhcpcd[459]: br0: sending REQUEST (xid 0x5df77679), next in 64.5 seconds
Mar 26 00:40:57 yeahwifibabyyeah dhcpcd[459]: br0: sending REQUEST (xid 0x5df77679), next in 63.8 seconds
Mar 26 00:42:01 yeahwifibabyyeah dhcpcd[459]: br0: sending REQUEST (xid 0x5df77679), next in 63.0 seconds
Mar 26 00:43:04 yeahwifibabyyeah dhcpcd[459]: br0: sending REQUEST (xid 0x5df77679), next in 63.3 seconds
Mar 26 00:44:07 yeahwifibabyyeah dhcpcd[459]: br0: sending REQUEST (xid 0x5df77679), next in 64.5 seconds
Mar 26 00:45:12 yeahwifibabyyeah dhcpcd[459]: br0: sending REQUEST (xid 0x5df77679), next in 65.0 seconds

but I've set the lease expire, in /etc/dhcp/dhcpd.conf to 7200 seconds so that my syslog traffic is manageable:
default-lease-time 7200;
max-lease-time 14400;

Anyways, I know that's a lot more to digest so I'll leave it at that.
Cheers.

[Thimbles809]

I may have come to a solution to the multiple request problem that has been plaguing my syslog all this time.
First
sudo cp /usr/lib/systemd/system/dhcpcd.service /etc/systemd/system/dhcpcd.service

We're going to use this file to hook into our dhcp client process.
Then
sudo nano /etc/systemd/system/dhcpcd.service

We're going to change this line:
ExecStart=/usr/sbin/dhcpcd -b -q
(the -b means background the process immediately, which allows it to continue forking. The -q means be quiet and don't spit out informative messages unless there's an error)

and change it to:
ExecStart=/usr/sbin/dhcpcd --waitip=4 -d
(the --waitip doesn't put the process in background until it gets a ipv4 value; --waitip=6 would wait on an ipv6 value. -d gives valuable debug messages)

Suddenly my requests to router have dropped to two per renewal - I still can't get the system not to make two simultaneous dhcpcd instances. Better than what it was though.

[morrownr]

@Thimbles809

I'm not ignoring you. My lab is shut down and I am moving. I can probably be back in business in a week or two. Let me know how it is going then.

[Thimbles809]

No problem. I have news, I have made progress.

[Thimbles809]

Ahem. I prematurely declared victory over the dhcpcd dragon with my:
ExecStart=/usr/sbin/dhcpcd --waitip=4 -d
work, because the sessions overnight still spawned a dozen dhcpcd requests and the dhcpd server logged a dozen packs which resembles the sheriff of notingham and little john conversation I referenced earlier:
https://youtu.be/y-uZrjVD3fo?t=2m3s
Annoying.
Nothing I did to dhcpcd seemed to solve the problem... until I remembered something from back in my computer class days when our comp prof assigned us a forking process lab to be done on a production server.
https://en.wikipedia.org/wiki/Fork_bomb
There were a lot of angry letters from the sys admin that day.
So looking at the dhcpcd service file, it starts a dhcpcd process which forks of the systemd process and sends a return code.
But underneath it says:
Restart=always
What that means is laid out here:
https://www.freedesktop.org/software/systemd/man/systemd.service.html#Restart=
That is an invitation for a fork bomb.
I changed it to the recommended on-failure
Setting this to on-failure is the recommended choice for long-running services, in order to increase reliability by attempting automatic recovery from errors. For services that shall be able to terminate on their own choice (and avoid immediate restarting), on-abnormal is an alternative choice.

My logs have gone from this:
Mar 31 22:23:53 yeahwifibabyyeah dhcpcd[665]: br0: renewing lease of 192.168.1.100
Mar 31 22:23:53 yeahwifibabyyeah dhcpcd[665]: br0: sending REQUEST (xid 0x604f1f09), next in 4.1 seconds
Mar 31 22:23:57 yeahwifibabyyeah dhcpcd[665]: br0: sending REQUEST (xid 0x604f1f09), next in 8.5 seconds
Mar 31 22:24:06 yeahwifibabyyeah dhcpcd[665]: br0: sending REQUEST (xid 0x604f1f09), next in 15.1 seconds
Mar 31 22:24:21 yeahwifibabyyeah dhcpcd[665]: br0: sending REQUEST (xid 0x604f1f09), next in 31.3 seconds
Mar 31 22:24:52 yeahwifibabyyeah dhcpcd[665]: br0: sending REQUEST (xid 0x604f1f09), next in 63.5 seconds
Mar 31 22:25:56 yeahwifibabyyeah dhcpcd[665]: br0: sending REQUEST (xid 0x604f1f09), next in 64.6 seconds
Mar 31 22:27:00 yeahwifibabyyeah dhcpcd[665]: br0: sending REQUEST (xid 0x604f1f09), next in 64.2 seconds
Mar 31 22:28:04 yeahwifibabyyeah dhcpcd[665]: br0: sending REQUEST (xid 0x604f1f09), next in 64.8 seconds
Mar 31 22:29:09 yeahwifibabyyeah dhcpcd[665]: br0: sending REQUEST (xid 0x604f1f09), next in 64.9 seconds
....many more times
Mar 31 23:04:59 yeahwifibabyyeah dhcpcd[665]: br0: failed to renew DHCP, rebinding
Mar 31 23:04:59 yeahwifibabyyeah dhcpcd[665]: br0: expire in 823 seconds
Mar 31 23:04:59 yeahwifibabyyeah dhcpcd[665]: br0: sending REQUEST (xid 0x604f1f09), next in 4.6 seconds
Mar 31 23:04:59 yeahwifibabyyeah dhcpcd[665]: br0: acknowledged 192.168.1.100 from 192.168.1.1
Mar 31 23:04:59 yeahwifibabyyeah dhcpcd[665]: br0: leased 192.168.1.100 for 6584 seconds
Mar 31 23:04:59 yeahwifibabyyeah dhcpcd[665]: br0: renew in 3292 seconds, rebind in 5761 seconds
Mar 31 23:04:59 yeahwifibabyyeah dhcpcd[665]: br0: writing lease '/var/lib/dhcpcd/br0.lease'
Mar 31 23:04:59 yeahwifibabyyeah dhcpcd[665]: br0: adding IP address 192.168.1.100/24 broadcast 192.168.1.255
Mar 31 23:04:59 yeahwifibabyyeah dhcpcd[665]: br0: ARP announcing 192.168.1.100 (1 of 2), next in 2.0 seconds
Mar 31 23:04:59 yeahwifibabyyeah dhcpcd[665]: br0: executing '/lib/dhcpcd/dhcpcd-run-hooks' REBIND
Mar 31 23:05:01 yeahwifibabyyeah dhcpcd[665]: br0: ARP announcing 192.168.1.100 (2 of 2)

to

Apr 1 01:29:48 yeahwifibabyyeah dhcpcd[6039]: br0: renewing lease of 192.168.1.100
Apr 1 01:29:48 yeahwifibabyyeah dhcpcd[6039]: br0: sending REQUEST (xid 0xfcaa93c7), next in 3.6 seconds
Apr 1 01:29:48 yeahwifibabyyeah dhcpcd[6039]: br0: acknowledged 192.168.1.100 from 192.168.1.1
Apr 1 01:29:48 yeahwifibabyyeah dhcpcd[6039]: br0: leased 192.168.1.100 for 7200 seconds
Apr 1 01:29:48 yeahwifibabyyeah dhcpcd[6039]: br0: renew in 3600 seconds, rebind in 6300 seconds
Apr 1 01:29:48 yeahwifibabyyeah dhcpcd[6039]: br0: writing lease '/var/lib/dhcpcd/br0.lease'
Apr 1 01:29:48 yeahwifibabyyeah dhcpcd[6039]: br0: adding IP address 192.168.1.100/24 broadcast 192.168.1.255
Apr 1 01:29:48 yeahwifibabyyeah dhcpcd[6039]: br0: ARP announcing 192.168.1.100 (1 of 2), next in 2.0 seconds
Apr 1 01:29:48 yeahwifibabyyeah dhcpcd[6039]: br0: executing '/lib/dhcpcd/dhcpcd-run-hooks' RENEW
Apr 1 01:29:50 yeahwifibabyyeah dhcpcd[6039]: br0: ARP announcing 192.168.1.100 (2 of 2)

I honestly don't know if all other raspberry pi dhcpcd clients are doing this and it's just the obsessive compulsive bridged AP folks that checked our logs compulsively enough to notice, but this is the behavior that's configured in the /usr/lib/systemd/system/dhcpcd.service file and, I think, it's bad. No other dhcp client on my network spams like this except systemd-networkd configured raspberry pi's.

[Thimbles809]

this is my current dhcpcd.service file:
[Unit]
Description=DHCP Client Daemon
Wants=network.target
Before=network-online.target
Documentation=man:dhcpcd(8)

[Service]
Type=forking
ExecStart=/usr/sbin/dhcpcd --waitip=4 -d
Restart=on-failure
RestartSec=4
The RestartSec setting gives it a 4 second time delay on failure in case the failure is a sync issue and dr-evil needs to catch up.

[Install]
WantedBy=multi-user.target

[Thimbles809]

You know what I hate? Being right until something proves me horribly wrong and that is what rebooting my APs did. Mass dhcpcd requests were back, which tells me that it's something at startup to do with dhcpcd ad I suspect it has something to do with the dhcpcd-run-hooks NOCARRIER message I see logged, but who cares.

According to man systemd.service you can use no as a Restart= flag.
As in no forking multiple dhcpcd requests and flogging my poor dhcp server to death on AP reboot.
dhcpcd appears to work fine without requiring a restart argument since its behavior is to regularly poll for a server anyways and go to sleep until its next poll.
Sorry about the premature announcements of success; progress is made through trial and error and this project has been a trial rife with errors.

[morrownr]

I know what you mean. The AP guide on the Main Menu here is something I worked on for a long time until I had a setup that would provide 24/7/365 stability and fast connections. It is fun and you learn a lot while doing it.

Right now I am having problems with the hostapd.conf for WiFi6 that I have on the Main Menu. It seems to work well until the AP sits overnight and then nopackets. The connection is there but no packets. Trying to figure out what is causing this.

[Thimbles809]

So once again, I don't know if it's a dhcpcd bug or what, but the mass poll behavior returns no matter what flags I set for dhcpcd, given enough time.
And once it starts, it's persistent.
So it has gone beyond my ability to fix using my knowledge of dhcpcd...
but I luckily have knowledge of crontab.
By running:
sudo crontab -e
I was able to insert this line into the root crontab:
45 * * * * sudo /bin/systemctl stop dhcpcd && sudo /bin/systemctl start dhcpcd
which stops and starts the dhcpcd daemon at quarter to the hour and a simliar line starts my other AP's dhcpcd at quarter after. Any dhcpcd error behavior gets wiped on refresh. It's a kludge, but until someone with better understanding can offer better understanding of what is happening, I have to rely on it... and I've been relying on it without noticeable problems for a week and a bit now, but I'm going to try and pester the poor person who develops dhcpcd to see if he can offer a better solution.
EDIT
Created thread here:
NetworkConfiguration/dhcpcd#194
/EDIT