Linux wireless vendor support and regulatory compliance

Enhancing vendor relationship

Distributions and Linux wireless developers would like to see vendor support for FOSS drivers for their wireless chipsets. Up until now only a few wireless chipset vendors have committed time and effort into working together with wireless developers in the community in providing sane drivers for proper kernel inclusion and support. Most vendors though have either demonstrated no interest at all to support FOSS drivers, have not been responsive to inquiries on support, or have proceeded in providing proprietary solutions for their drivers based on advice from third parties which usually results in preventing us to incorporate their drivers into the kernel. For the second wireless summit we have attempted to reach out to as many wireless vendors as possible so we can properly address their concerns in providing FOSS drivers.

Addressing vendor concerns

Based on discussions and conference calls before and after the summit it is clear now that the main vendor concern over supporting FOSS drivers has been to provide a mechanism to enforce regulatory compliance to satisfy their own and their hardware vendors (OEMs like Dell, HP, IBM) legal department's concerns over legal liability. Additional concerns have been that a FOSS driver may force hardware vendors to certify their platforms under new Software Defined Radio regulations. Additionally, also that the FCC is only one of the many regulatory agencies vendors take into consideration for certifying devices – the major vendor's geographies of interest are governed under the FCC, ETSI and MKK. Vendors explained their concerns over getting devices certified under FCC SDR regulations is the extended length that this process would take – a month compared to a couple of weeks under FCC Part 15. The most problematic regulatory agencies vendors have to deal with are those of Singapore and Taiwan. Although a FOSS driver approach may be acceptable under the FCC, Singapore's and Taiwan's regulatory agencies may prevent the vendors from supporting devices under the same FOSS driver. Vendors need to provide driver solutions which meet legal criteria on all of their geographies of interest.

Technical difficulties on solutions

The obvious solution to all of these vendor concerns in providing support for FOSS drivers is to provide restrictions in hardware based on geography but it has been argued by vendors that this proves to be economically unfeasible. Likewise, this would also create a problem for some users wanting to roam outside of their geography using the same wireless hardware. Current vagueness under FCC Part 15 rules have allowed vendors to move forward with supporting proprietary driver solutions for management and enforcement of regulatory restrictions. Although security through obscurity is ultimately not a great security model it is one which some vendors rely on, even for Linux proprietary drivers, as it has satisfied their and their customers' legal departments. Alternative solutions to the problem has been to incorporate regulatory restrictions on the microcode of the wireless device, which does allow for a complete FOSS driver, but this approach is looked down upon by vendors as it confines the vendors to smaller amount of space available for development on the microcode.

Moving forward

Our options to gain vendor support for wireless devices where regulatory restrictions are enforced on the driver are to pivot ourselves on similar practical tendencies of security through obscurity or to validate a new approach under current legislation to set precedent for vendors to follow. Although FCC part 15 rules, under which all current popular WLAN devices are certified under in the US, really are software and operating agnostic we can try to set precedent for vendors in supporting FOSS drivers by obtaining FCC certification on certain platforms with Linux with our own built in software regulatory compliance. We can certify platforms with wireless devices either under FCC part 15 rules or FCC SDR. Since vendors have expressed concerns over the implication of certifying one of their devices under SDR we can try to aim for certification under FCC part 15 rules first. If FCC part 15 certification fails we can consider obtaining certification under SDR. Certification under SDR requires technical security means of verifying that the driver and firmware are valid before the device can operate. It is unclear exactly what is meant by this and some vendors have expressed concerns that the outcome of going down the SDR route may actually be unfavorable toward FOSS. Ultimately clearing this issue up should allow us to obtain proper vendor support for FOSS drivers where regulatory enforcement is kept in software. In the meantime we should be able to gain vendor support for FOSS drivers for all wireless devices where regulatory compliance is kept in the microcode (with a freely redistributable license on the firmware). In the meantime, to gain vendor support for a FOSS driver for wireless devices where regulatory compliance is kept in the driver, we can rely on the vendor on providing FOSS drivers with HAL solution for regulatory enforcement.