summaryrefslogtreecommitdiffstats
path: root/sys/i386/isa/if_wi.c
Commit message (Collapse)AuthorAgeFilesLines
* As suggested by phk, unconditionalize BPF support in these drivers. Sincewpaul1999-09-231-9/+0
| | | | | | | there are stubs compiled into the kernel if BPF support is not enabled, there aren't any problems with unresolved symbols. The modules in /modules are compiled with BPF support enabled anyway, so the most this will do is bloat GENERIC a little.
* $Id$ -> $FreeBSD$peter1999-08-281-2/+2
|
* Clean up after removing sys/eventhandler.h from sys/systm.h at the lastmsmith1999-08-211-2/+3
| | | | | minute. This should cover all of the missed cases (and should let LINT build again).
* Implement a new generic mechanism for attaching handler functions tomsmith1999-08-211-6/+7
| | | | | | | | | | | | | events, in order to pave the way for removing a number of the ad-hoc implementations currently in use. Retire the at_shutdown family of functions and replace them with new event handler lists. Rework kern_shutdown.c to take greater advantage of the use of event handlers. Reviewed by: green
* Rename bpfilter to bpf.des1999-07-061-7/+7
|
* Patch the WaveLAN/IEEE driver to detect and reject oversized receivedwpaul1999-07-041-2/+19
| | | | | | | | | | | frames (or just insane received packet lengths generated due to errors reading from the NIC's internal buffers). Anything too large to fit safely into an mbuf cluster buffer is discarded and an error logged. I have not observed this problem with my own cards, but on user has reported it and adding the sanity test seems reasonable in any case. Problem noted and patch provided by: Per Andersson <per@cdg.chalmers.se>
* Small optimization: use wi_seek() in wi_read_record() and wi_write_record()wpaul1999-06-061-27/+9
| | | | | instead of frobbing the buffer access path registers directly. Saves a few lines of duplicated code.
* - Fix up some comments in if_wi.c (no code changes)wpaul1999-05-221-9/+9
| | | | | | | - Mention that the 6Mbps turbo adapters are supported in HARDWARE.TXT and RELNOTES.TXT and the wi.4 man page - Mention turbo adapters in the wicontrol.8 man page and provide a complete table of available transmit speed settings
* Add support to wicontrol(8) and wi(4) for enabling and configuringwpaul1999-05-071-2/+16
| | | | | | | power management. This will only work on newer firmware revisions; older firmware will silently ignore the attempts to turn power management on. Patches supplied by: Brad Karp <karp@eecs.harvard.edu>
* Modify wicontrol(8) and wi(4) to allow setting the frequency of thewpaul1999-05-061-2/+23
| | | | | | | WaveLAN's radio modem. The default is whatever the NIC uses since NICs sold in different countries may default to different frequencies. (The Lose95/LoseNT software doesn't let you select the channel so it's probably not really meant to be changed.)
* Add device driver support for the Lucent WaveLAN/IEEE 802.11 PCMCIAwpaul1999-05-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | adapter (and some workalikes). Also add man pages and a wicontrol utility to manipulate some of the card parameters. This driver was written using information gleaned from the Lucent HCF Light library, though it does not use any of the HCF Light code itself, mainly because it's contaminated by the GPL (but also because it's pretty gross). The HCF Light lacks certain featurs from the full (but proprietary) HCF library, including 802.11 frame encapsulation support, however it has just enough register information about the Hermes chip to allow someone with enough spare time and energy to implement a proper driver. (I would have prefered getting my hands on the Hermes manual, but that's proprietary too. For those who are wondering, the Linux driver uses the proprietary HCF library, but it's provided in object code form only.) Note that I do not have access to a WavePOINT access point, so I have only been able to test ad-hoc mode. The wicontrol utility can turn on BSS mode, but I don't know for certain that the NIC will associate with an access point correctly. Testers are encouraged to send their results to me so that I can find out if I screwed up or not.
* Add device driver support for the Lucent WaveLAN/IEEE 802.11 wirelesswpaul1999-05-051-0/+1315
network adapters. These are all PCMCIA devices (the ISA version is a PCMCIA to ISA bridge with a PCMCIA card plugged into it). Also add a wicontrol utility to read and write some of the card's parameters. Note: I do not have access to a WavePOINT access point, so I have only been able to test this driver in ad-hoc (point to point) mode. The wicontrol utility allows programming the desired service set name (SSID) and enabling BSS mode, but I can't tell for sure if it works (I know the card switches modes, but I can't verify that it joins a service set correctly). This driver was written using information gleaned from the Lucent HCF Light library, which is an API library designed to simplify driver development for devices based on the Lucent Hermes chip. Unfortunately, the HCF Light is missing certain features (like 802.11 frame encapsulation!) which are available only in the proprietary complete HCF code, which is not available to the public. This driver uses none of the HCF Light code: it's very ugly and contaminated by the GPL. IP and ARP packets are encapsulated as 802.11 frames, everything else is encapsulated as 802.3. (It would be easier to just get the Hermes programming manual, but that's not publically available either. For those who are wondering, the Linux WaveLAN/IEEE driver uses the proprietary HCF code, which is provided in object code form only. So much for supporting open source sofware.) Multicast filter support is implemented, however it appears that the filter doesn't work: programming in one IP mutlicast group enables them all.
OpenPOWER on IntegriCloud