Proxim Orinoco 8494 Chipset



Trademarks ORiNOCO® and Proxim are registered trademarks, and the Proxim logo is a trademark, of Proxim Wireless Corporation. Click Close when you are finished. 12 ORiNOCO USB-9100 802.11a/b/g/n/ac Adapter User Guide Specifications ORiNOCO USB-9100 Specifications Chipset –RTL8812AU Host Interface Complies with USB Revision 3.0 Radio.

Proxim Orinoco 8494 Chipset

UNII-2E band in Proxim 8494 adapter

11 posts by 3 authors in: Forums > CWDP & CWAP - Enterprise Wi-Fi Design & Analysis
Last Post: July 14, 2015:

Proxim Orinoco 8494 Chipset Usb

Proxim Orinoco 8494 Chipset
  • 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. Hiren bootable cd iso. 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.

  • One Proxim 8494 US USB wireless adapter. This item was pulled from a working environment and is in good condition overall. Item may have cosmetic defects. The wireless chipset in this unit is made by ORiNOCO. This item has been tested and is working. You will receive one Proxim 8494 US USB wireless adapter. No other items or accessories are.
  • 5 results for proxim orinoco 8494. Save this search. Shipping to 98052: Items in search results. Proxim 8494-WD Wireless ORiNOCO 802.11 A/B/G/N USB Adapter Dual Band 2.4 /5 Ghz. C $169.14; or Best Offer +C $18.16 shipping; From United States; Customs services and international tracking provided.

Proxim Orinoco 8494 Chipset Driver

Partner BenefitsWirelessGoldPlatinum
Annual Revenue Attainment RequirementN/A$75,000$150,000
Primary Distributor of ChoiceYYY
SALES DRIVERS
Partner Rebate-YY
Channel Instant RebatesYYY
Partner Exclusive Incentive ProgramsYYY
Project Registration
  • Deal Protection from competing Proxim VARs for the same project.
  • No Minimum Revenue required to receive dedicated support from Proxim Regional Sales Management (RSM) and System Engineer (SE) teams.
  • A minimum of MSRP $15,000 in project value is required to be considered for pricing discounts.
Leads-YY
MARKETING SUPPORT
MDF (proposal based)-YY
Demo Kit - 60% Off on hardwareYYY
Access to Partner ExtranetYYY
Partner NewsletterYYY
Joint Press ReleasesYYY
TRAINING AND TECHNICAL SUPPORT
Educational WebinarsYYY
On-site Sales TrainingYYY
Fee Based Priority Repair ProgramYYY
Number of Proxim Certified Engineers-12