**NEW** Advanced Search Options

We recently added advanced search options to make it easier to locate posts on the community.
More information can be found at Advanced Search Options

Welcome to the Community!

If you are looking for something specific, please use the search bar to check if someone else has asked or answered the same question before posting a new question. Check out our Community Instructions for other FAQ's.

Spectrum RAC2V1K Askey wireless router 802.11b/g/n ERP protection tsunami

HT_GreenfieldHT_Greenfield Posts: 4 ✭✭
edited May 13 in Internet 2020 Archive Oct 31, 2020

This is intended for 802.11 PHY geeks & I’m hopeful the right specialists at Spectrum & Askey somehow pick up on this as well. 

Subject: Spectrum RAC2V1K Askey wireless router 2.4 GHz 802.11b/g/n ERP protection tsunami

Among the several dozen 802.11b/g/n BSS’s within range of my mine, 3 of them are of the subject product. 

All 3 are the only 3 in “g/n” “mode” (versus b/g/n.)

All 3 are the only 3 with the “Non-ERP Station(s) Present” flag set. (Thus, of course, is ERP Protection also set.)

They move around, channel-wise, independently of each other as time goes by but these indications persist. 

All of the BSS’s that overlap (including partially) these Askey BSS’s & detect their “Non-ERP Station(s) Present,” in turn, set ERP Protection. 

In addition to that, some AP makes makes/models will set ERP Protection even if they overlap another BSS that has ERP Protection set even if “Non-ERP Station(s) Present” isn’t set. (The standard affords some regimental leeway for vendors to play it extra-safe & many do.) Thus are these 3 Askey’s causing a persistent domino-effect tsunami of ERP Protection across most of the BSS’s in my 802.11b/g/n PHY neighborhood. 

The probe responses show that the “g/n” “mode” of the Askey’s eliminates support for non-ERP rates. This of course only applies to data frames as non-ERP-rate management & control frames are mandatory and non-ERP-rate control frames are indeed the very essence of ERP Protection. 

I don't believe even one, much less all 3, of these Askey BSS's actually has any non-ERP (802.11b) devices associated. That standard was superseded by g in 2003!

My theory: the “g/n” “mode” of this product doesn’t just prevent non-ERP devices from associating; it furthermore completely ignores non-ERP data frames. The standard doesn’t allow this without also remedying the increased potential for contentious interference it facilitates. Thus the requisite persistent “assumption” that one or more non-ERP devices are associated which ERP & HT data transmissions need protection against. 

Such regimen is a hold-over from auld land syne. The ONLY way it saves more air time THAN IT COSTS is if there were a LOT of non-ERP (802.11b) devices still around that would otherwise associate. If you would just leave it in b/g/n mode, then it would only use ERP Protection if/when a non-ERP (802.11b) device was actually associated (in the first place) & that would be never (in the second place.) The bottom line is a significant airtime cost for these Askey BSS’s & all overlapping BSS’s & a lot of BSS’s that overlap those! 

Most makes & models don’t even have the g/n versus b/g/n modal option &, of all of the ones I’ve seen that do, the subject product is the only one I know of that implements it this way. It would be very sweet if Askey & Spectrum could push a firmware update to remedy this problem. Can any 802.11 PHY eggheads out there with one of these Askey’s confirm or deny any of this?

Accepted Answers

  • HT_GreenfieldHT_Greenfield Posts: 4 ✭✭
    Nov 02, 2020 Accepted Answer

    Allow me to restate the case for whatever it’s worth & whomever it might be worth something to, & close it. 

    It concerns the 2.4-GHz 802.11b/g/n PHY of the Spectrum RAC2V1K Askey 802.11ac Wave 2 wireless router.

    There are 3 of these Askey routers operating in my “Wi-Fi neighborhood.” The 1st one showed up about a year ago. Then eventually another. And now a 3rd one as of about a month ago. Of the several dozen BSS’s in my 2.4-GHz neighborhood, all 3 of these are the only ones in “g/n” “mode” & all 3 are the only ones with “Non-ERP Station(s) Present”. These indications have persisted since day one, in each case, even as they move around, channel-wise, independently of each other as time goes by. 

    “Non-ERP Station(s) Present” elicits ERP Protection on these Askey BSS’s as well as overlapping BSS’s regardless of make/model. The domino effect is simply the nature of the ERP Protection standard. But I’m skeptical that any of these Askey BSS’s actually has any non-ERP stations associated, as such would have to be 16 or 17 years old. 

    ERP protection is never a bad thing. It’s just that the cost outweighs the benefit when there aren’t actually any non-ERP or non-HT devices around, in which case it’s a net payload throughput hit. All of the BSS’s within range used to fly sans ERP Protection & most of them also sans any HT Protection. Now, of course, most of them are working with ERP protection as stated.

    While I’m skeptical that the Askey BSS’s actually have any non-ERP stations associated, I realize that they actually could & that there could be a good reason for it. 

  • HT_GreenfieldHT_Greenfield Posts: 4 ✭✭
    Nov 11, 2020 Accepted Answer

    Recent developments & further analysis indicate that the most logical albeit improbable explanation is that there are one or more non-ERP AP’s or STA’s on the air sending out management frames that are out of my range but are directly causing the Askey AP’s & at least one other AP to set ERP Use_Protection. The Askey’s are also setting NonERP_Present even though no non-ERP STA’s are associated. This in turn causes some BSS’s that are co-channel with the Askeys (but not any that are partially overlapping) to also set Use_Protection. 

    The only problem is the IEEE 802.11 standard guidance for ERP protection, specifically the conditions by which NonERP_Present may (but doesn’t have to) be set coupled with how Use_Protection may (but doesn’t have to) be set when a co-channel BSS has NonERP_Present set. Not as helpful these days as it may have been circa 2003-2009.


  • Lake802Lake802 Posts: 96 ✭✭✭✭
    Oct 31, 2020

    Greetings HT - your ERP question is interesting but is unclear from your original post what if any service impact you are experiencing ie slow performance/packetloss etc.

    There are a bunch of helpful folks on these forums that might be a tad more inclined to help if you refrain from the colorful pejoratives ie geek/egghead etc .

    Most recent models of routers do have a toggle mode for the wifi bands they support. The askey and similar models let you choose wifimode of G, mixed G and N or N only. If most of your wifi clients are newer , changing to N only can be helpful in some circumstances.

    Its unlikely that Spectrum, Askey or any manufacturers will be releasing firmware updates to specifically address ERP beacon issues for 802.11b products from circa 2013 ish. Many corporations have long ago purged any remaining 802.11b devices from their networks. There could easily be some older 802.11b residential device in the area that registers on a few of the local wifi AP's but nothing that would trigger a protection tsunami as described.

    As more folks upgrade to 802.11ac/Wifi6 and the newer Wifi6E - there will still be backwards compatibility to some extent but the 802.11b beacon ERP will become even more irrelevant as the wifi technology further improves.

  • HT_GreenfieldHT_Greenfield Posts: 4 ✭✭
    Nov 02, 2020

    Correction: I erroneously used the word "associated" where I should have used "present." Non-ERP stations shouldn't be able to associate with any BSS in "g/n" "mode."

This discussion has been closed.