Forum

Seeing something strange where this band remains disabled on my Proxim adapters.

Confirmed via various flavours of linux. 'iw get reg' shows the 'AU' reg domain, where 2E is enabled.

'iw phy' shows my laptop's inbuilt adapter is enabled for DFS on that band, but the proxim (Ekahau branded) show disabled and can not detect an AP on channel 100 for example.

Any ideas? The datasheet (https://wikidevi.com/files/datasheets/proxim/ORiNOCO%20802%2011%20abgn%20USB%20Adapter%20Datasheet.pdf) suggests the band is supported 'subject to regulatory restrictions'. 

Presumably it was never FCC certified in that band.

I would also assume custom firmware.

I remember there are 2x Proxim adapters the USA-version  8494 and a  WorldWide version 8494,

(the Proxim, Ekahau and Ubiquity SR-71 make use of the same chipset).  Maybe you can try in Linux,

the OTUS driver (or there is a newer version I remember, forgot the name...).

We are having the same issues with other adapters:

(e.g  Cisco Linksys WUSB600N v1  and v2   (using different drivers, different IEEE 802.11d / Regulatory domains, etc.)

in inSSIDer for example they are all grey-ed out and people cannot use this to connect to APs configured at these channels.

and did not figured out how to get  UNII-2, 2E to work.

(when you click on the adapter properties of the dongle, you can see all the regulatory domains and channel configuration,

other options do not work)

Maybe to do the IEEE 802.11h  (TPC / DFS ?) 

See also this good website of Mike Albano -->  clients.mikealbano.com

Ok, looks like the problem is the linux driver itself (carl9170), can find channel 100 in Windows on a different machine. Will look for that OTUS driver. 

Looking in ekahau, only channels 14, 120, 124, 128 are greyed out. This is just the AU domain. In the adapter properties I don't get any channel details, although you can specify an ad hoc channel - the list understandably excludes the DFS channels. So far I'm not seeing anyway to see hardware channel support under Windows.

Under linux it seems to be a case of hardware+driver+reg is visible but not hardware alone.

Look for German versions.   They sometimes support more channels.

Hi Ben, 

That's the correct one the "carl9170" is replacing the OTUS driver  (and the AR9170 driver).

>> See history --> https://wireless.wiki.kernel.org/en/users/drivers/carl9170#history

Same like in normal traffic we have good and bad drivers....:-)

This is another wireless "driver" issue we see over the last year of customers attending classes:

Not sure in USA,  but what I see in APAC is that most Dell laptops get shipped with the wrong driver

(or they do it on purpose, but it limits the built-in card to 65 Mbps only (1 Spatial stream),  after upgrading

the drivers the customers can use 130 Mbps data rate (2x spatial streams).  For both the Intel and Broadcom ones.

Re: Howard:  I was not aware of the German drivers/channels (will check that in the weekend), 

but for Japan  (IEEE 802.11j), there are more channels available as

well (14 channels in 2.4 GHz,  and  4.9 GHz - 5 GHz),  but that is not allowed when you use them in another country.

(there are actually 2x regulations / standards for Japan,  you can see these on the enterprise level APs,

checking the power output regulations, typically done via the command line interface).

Interesting..

So I'm working off the latest kali linux distro and fedora 14(?). Pretty sure it's the same carl driver in both cases.

The reg domain (iw reg get) correctly shows UNII-2E enabled, but definitely every channel in that band is stuck in disbled, so must be a driver problem.

*sigh* I suppose I should open a bug :)

As different regulatory domains release new compliance standards, not every manufacturers firmware or drivers are in sync with them.    In addition, and as I'm sure you know, not all products get sold in their intended market.   

I only mention Germany, as I have seen some gear from there either ahead or behind other countries, and therefore sometimes more useful.   TUV Rheinland might dispute that however.  There are undoubtedly worse cases.

Other countries, including China and Brazil, are flexing their muscles in the compliance arena.   The costs and headaches for getting compliance certifications in these countries have increased enormously in the last several years.   It's not unheard of spending $300k for a combination of safety and radio certs, for a brand new product, with only a short list of countries.   

You might find firmware from some countries to either not allow newer channels, or are lenient on DFS channel controls.  This is despite the fact that its own rules have been in effect for a year or more.   Obviously, there is a holdup, of some kind, somewhere.

I've heard it said that international customs and compliance bodies were (literally) started by extortionists and pirates.   It feels like some countries have not shed that legacy.  

Hi Ben,

Let me know if the carl9170 driver has been fixed, that would be interesting.  Also for 1x vendor what we see in the classes

is when we configure the AP in the DFS channel, that they will change back automatically to the range 36-48  (and stick to 36

most cases and creating CCI). We have not figured out yet what is causing it  (as it happens at different locations/countries,

my guess is that it is software bug, something is triggering it, or maybe it relates to what you are seeing not to be able to use

those channels?)

Hi Howard,

Exactly it is a big headache for product vendors to get the "type approvals" for each country.

(costs a lot of money), e.g. VietNam and Indonesia are also not so easy compared to other countries

For products shipped into Indonesia you cannot change the country code (IEEE 802.11d/regulatory domain)

it need to be fixed. 

Also maybe the DFS relates to TPC (Transmit Power Control)  (IEEE 802.11k),

e.g. Hong-Kong and Australia  Access Points (APs) can have TX-power up to 500mW  

(and probably for dongles as well as it are Transmitters) . What you see happening

in the region is that some people (system integrators) have this knowledge and they change the country code to implement it at full power

(e.g. in a hotel, to cover 3x rooms, to save on the number of APs to be deployed,  no matter what kind of side-effect

it has  (like hidden nodes,  power imbalance between clients and AP,   larger RF coverage areas, etc. etc. etc.)

Then if an issue happens at the customer site and they call support, then the vendor service support comes in and

they see the other country code settings and are "fixing" it back to the regulatory domain for that country .... :-) 

you can fill in what happens after that at the customer side.  

No response from linux wireless..

I have a stable working setup with Windows now so will focus on that. The trick is finding the right adapter,  but as you've noted even there there can be some inconsistencies and anomalies.

I have two different adapters, same chipset, same driver it seems (windows reports same version number and same options in adapter properties), but very different behaviour. I suspect vendors take a reference driver from the chipset manufacturerer and make small modifications - some do it better than others.