Contributed by jose on from the wireless dept.
> Add an option to use software WEP now that we have a software decrypt > function. Can be useful for cards that only support 40-bit WEP or > where the card firmware lacks weak IVs avoidance. Prism/Symbol only. > In the future this will be expanded to support proposed WEP replacements. > Based on code from Jamison Adcock. (millert@)While no one likes WEP much (in favor of IPsec or other proven cryptosystems), there are some environments which still rely on it. Hence, you have to support it. As such, this addition comes in handy to improve those environments as best as possible.
(Comments are closed)
By hettb () htb@subdimension.com on mailto:htb@subdimension.com
By Anonymous Coward () on
When are the errata page going to be updated?
By Anonymous Coward () on
I know it seems pretty stupid - but there is actually a use for it; and higher end (professional/"enterprise") access points from both Cabletron/Enterasys (Roamabout) and Cisco offer this functionality. It's the one thing that I found lacking in building an OpenBSD based host AP.
As far as where this comes in useful - there are potentially a few places, but the one that has been most prominent in my experience is where a company has been using 802.11b without WEP, and then wants to tightening things down slightly - just straight out enabling WEP can cause headaches for migration purposes. Especially if the company has multiple branches with employees who travel between them with their laptops, if you don't switch all the sites at once. Since the average corporate user doesn't have a clue about their computers (even something as simple as adding a WEP key) - this tends to be a manual switchover process per wireless device that needs to be undertaken by the IT staff, usually not super quickly. However, the ability to run the AP's with and without WEP simultaneously allows for a smooth migration so that the majority of users can be cutover to using WEP, and then doing a firm cutover date on the AP's, after which you only have the remaining stragglers that IT can then deal with without exhausting resources.
Currently the host-ap mode does allow for WEP and non-WEP clients to associate to the base station if you configure it appropriately - but it will only _pass_ WEP traffic, the non-WEP clients are left out in the cold. It would definitely add greater flexibility to the host AP mode if WEP & non-WEP traffic could be passed in hostAP mode (perhaps if someone got really imaginative, there could be WEP & non-WEP type interfaces in such a case, and one could filter traffic more liberally dependant on the case?).
WEP might be easily breakable - but I sort of envision it to be more like a switch vs. a hub. Sure you can poison the ARP cache of a switch in many cases, but it's just an additional hassle that many people aren't going to bother with. In the case of wardrivers, becoming a target with a bit more work involved is even more appealing since there are so many open AP's around - the average wardriver will just move on. You still need to worry about the dedicated crook, but that's always going to be a concern, and you should be taking additional measures (IPSec will help a lot more in such cases) to thwart such efforts in the long run. However, reducing one's attractiveness to the casual user is going to deflect a large bulk of potential assailants, and as such better WEP support is a welcome addition.
Thanks again OpenBSD!