d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7c1968ad82
freebsd-dev/sys/dev/if_ndis/if_ndis.c

2456 lines
60 KiB
C
Raw Normal View History

Start each of the license/copyright comments with /*-, minor shuffle of lines
2005-01-06 01:43:34 +00:00
/*-
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
* Copyright (c) 2003
* Bill Paul <wpaul@windriver.com>. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
* 3. All advertising materials mentioning features or use of this software
* must display the following acknowledgement:
* This product includes software developed by Bill Paul.
* 4. Neither the name of the author nor the names of any co-contributors
* may be used to endorse or promote products derived from this software
* without specific prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY Bill Paul AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL Bill Paul OR THE VOICES IN HIS HEAD
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
* INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
* CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
* ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
* THE POSSIBILITY OF SUCH DAMAGE.
*/
#include <sys/cdefs.h>
__FBSDID("$FreeBSD$");
#include "opt_bdg.h"
#include <sys/param.h>
#include <sys/systm.h>
#include <sys/sockio.h>
#include <sys/mbuf.h>
#include <sys/malloc.h>
#include <sys/kernel.h>
#include <sys/socket.h>
#include <sys/queue.h>
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
#include <sys/module.h>
When you call MiniportInitialize() for an 802.11 driver, it will at some point result in a status event being triggered (it should be a link down event: the Microsoft driver design guide says you should generate one when the NIC is initialized). Some drivers generate the event during MiniportInitialize(), such that by the time MiniportInitialize() completes, the NIC is ready to go. But some drivers, in particular the ones for Atheros wireless NICs, don't generate the event until after a device interrupt occurs at some point after MiniportInitialize() has completed. The gotcha is that you have to wait until the link status event occurs one way or the other before you try to fiddle with any settings (ssid, channel, etc...). For the drivers that set the event sycnhronously this isn't a problem, but for the others we have to pause after calling ndis_init_nic() and wait for the event to arrive before continuing. Failing to wait can cause big trouble: on my SMP system, calling ndis_setstate_80211() after ndis_init_nic() completes, but _before_ the link event arrives, will lock up or reset the system. What we do now is check to see if a link event arrived while ndis_init_nic() was running, and if it didn't we msleep() until it does. Along the way, I discovered a few other problems: - Defered procedure calls run at PASSIVE_LEVEL, not DISPATCH_LEVEL. ntoskrnl_run_dpc() has been fixed accordingly. (I read the documentation wrong.) - Similarly, the NDIS interrupt handler, which is essentially a DPC, also doesn't need to run at DISPATCH_LEVEL. ndis_intrtask() has been fixed accordingly. - MiniportQueryInformation() and MiniportSetInformation() run at DISPATCH_LEVEL, and each request must complete before another can be submitted. ndis_get_info() and ndis_set_info() have been fixed accordingly. - Turned the sleep lock that guards the NDIS thread job list into a spin lock. We never do anything with this lock held except manage the job list (no other locks are held), so it's safe to do this, and it's possible that ndis_sched() and ndis_unsched() can be called from DISPATCH_LEVEL, so using a sleep lock here is semantically incorrect. Also updated subr_witness.c to add the lock to the order list.
2005-03-07 03:05:31 +00:00
#include <sys/proc.h>
Take advantage of the dev sysctl tree. Approved by: wpaul
2004-06-04 22:24:46 +00:00
#if __FreeBSD_version < 502113
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
#include <sys/sysctl.h>
Take advantage of the dev sysctl tree. Approved by: wpaul
2004-06-04 22:24:46 +00:00
#endif
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
#include <net/if.h>
#include <net/if_arp.h>
#include <net/ethernet.h>
#include <net/if_dl.h>
#include <net/if_media.h>
Link state change notification of ethernet media to the routing socket. o The ndis_ticktask() function updates the ifi_link_state field and calls rt_ifmsg() to notify listeners on the routing socket. Approved by: wpaul
2004-05-06 13:17:02 +00:00
#include <net/route.h>
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
#include <net/bpf.h>
#include <machine/bus_memio.h>
#include <machine/bus_pio.h>
#include <machine/bus.h>
#include <machine/resource.h>
#include <sys/bus.h>
#include <sys/rman.h>
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
#include <net80211/ieee80211_var.h>
#include <net80211/ieee80211_ioctl.h>
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
#include <dev/wi/if_wavelan_ieee.h>
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
#include <dev/pci/pcireg.h>
#include <dev/pci/pcivar.h>
#include <compat/ndis/pe_var.h>
#include <compat/ndis/resource_var.h>
Implement support for single packet sends. The Intel Centrino driver that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
2004-02-03 07:39:23 +00:00
#include <compat/ndis/ntoskrnl_var.h>
Add some minor changes related to PCMCIA attribute memory mapping (which I apparently forgot to commit earlier). Acquire NDIS_LOCK() in ndis_linksts_done().
2004-08-01 06:42:44 +00:00
#include <compat/ndis/hal_var.h>
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
#include <compat/ndis/ndis_var.h>
#include <compat/ndis/cfg_var.h>
#include <dev/if_ndis/if_ndisvar.h>
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
#define NDIS_IMAGE
#define NDIS_REGVALS
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
#include "ndis_driver_data.h"
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
int ndis_attach (device_t);
int ndis_detach (device_t);
int ndis_suspend (device_t);
int ndis_resume (device_t);
void ndis_shutdown (device_t);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
int ndisdrv_modevent (module_t, int, void *);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
static __stdcall void ndis_txeof (ndis_handle,
ndis_packet *, ndis_status);
static __stdcall void ndis_rxeof (ndis_handle,
ndis_packet **, uint32_t);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
static __stdcall void ndis_linksts (ndis_handle,
ndis_status, void *, uint32_t);
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
static __stdcall void ndis_linksts_done (ndis_handle);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
/* We need to wrap these functions for amd64. */
static funcptr ndis_txeof_wrap;
static funcptr ndis_rxeof_wrap;
static funcptr ndis_linksts_wrap;
static funcptr ndis_linksts_done_wrap;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
static void ndis_intr (void *);
static void ndis_tick (void *);
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
static void ndis_ticktask (void *);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
static void ndis_start (struct ifnet *);
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
static void ndis_starttask (void *);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
static int ndis_ioctl (struct ifnet *, u_long, caddr_t);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
static int ndis_wi_ioctl_get (struct ifnet *, u_long, caddr_t);
static int ndis_wi_ioctl_set (struct ifnet *, u_long, caddr_t);
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
static int ndis_80211_ioctl_get (struct ifnet *, u_long, caddr_t);
static int ndis_80211_ioctl_set (struct ifnet *, u_long, caddr_t);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
static void ndis_init (void *);
static void ndis_stop (struct ndis_softc *);
static void ndis_watchdog (struct ifnet *);
static int ndis_ifmedia_upd (struct ifnet *);
static void ndis_ifmedia_sts (struct ifnet *, struct ifmediareq *);
The ndis_wlan_bssid_ex structure we retrieve in ndis_get_assoc() is variable length, so we should not be trying to copy it into a fixed length buffer, especially one on the stack. malloc() a buffer of the right size and return a pointer to that instead. Fixes a crash I discovered when testing whe a Cisco AP in infrastructure mode, which returns several information elements that make the ndis_wlan_bssid_ex structure larger than expected.
2004-03-24 05:35:03 +00:00
static int ndis_get_assoc (struct ndis_softc *, ndis_wlan_bssid_ex **);
Add support for TCP/IP checksum offload. No, really.
2004-01-22 02:36:34 +00:00
static int ndis_probe_offload (struct ndis_softc *);
static int ndis_set_offload (struct ndis_softc *);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
static void ndis_getstate_80211 (struct ndis_softc *);
static void ndis_setstate_80211 (struct ndis_softc *);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
static void ndis_media_status (struct ifnet *, struct ifmediareq *);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
static void ndis_setmulti (struct ndis_softc *);
static void ndis_map_sclist (void *, bus_dma_segment_t *,
int, bus_size_t, int);
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
static int ndisdrv_loaded = 0;
/*
* This routine should call windrv_load() once for each driver
* image. This will do the relocation and dynalinking for the
* image, and create a Windows driver object which will be
* saved in our driver database.
*/
int
ndisdrv_modevent(mod, cmd, arg)
module_t mod;
int cmd;
void *arg;
{
int error = 0;
switch (cmd) {
case MOD_LOAD:
ndisdrv_loaded++;
if (ndisdrv_loaded > 1)
break;
windrv_load(mod, (vm_offset_t)drv_data, 0);
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
windrv_wrap((funcptr)ndis_rxeof, &ndis_rxeof_wrap);
windrv_wrap((funcptr)ndis_txeof, &ndis_txeof_wrap);
windrv_wrap((funcptr)ndis_linksts, &ndis_linksts_wrap);
windrv_wrap((funcptr)ndis_linksts_done,
&ndis_linksts_done_wrap);
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
break;
case MOD_UNLOAD:
ndisdrv_loaded--;
if (ndisdrv_loaded > 0)
break;
windrv_unload(mod, (vm_offset_t)drv_data, 0);
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
windrv_unwrap(ndis_rxeof_wrap);
windrv_unwrap(ndis_txeof_wrap);
windrv_unwrap(ndis_linksts_wrap);
windrv_unwrap(ndis_linksts_done_wrap);
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
break;
case MOD_SHUTDOWN:
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
windrv_unwrap(ndis_rxeof_wrap);
windrv_unwrap(ndis_txeof_wrap);
windrv_unwrap(ndis_linksts_wrap);
windrv_unwrap(ndis_linksts_done_wrap);
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
break;
default:
error = EINVAL;
break;
}
return (error);
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/*
* Program the 64-bit multicast hash filter.
*/
static void
ndis_setmulti(sc)
struct ndis_softc *sc;
{
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
struct ifnet *ifp;
struct ifmultiaddr *ifma;
int len, mclistsz, error;
uint8_t *mclist;
ifp = &sc->arpcom.ac_if;
Fix two problems: - In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags used for shared memory allocations with a lowaddr of 0x3E7FFFFF. This forces the buffers to be mapped to physical/bus addresses within the first 1GB of physical memory. It seems that at least one card (Linksys Instant Wireless PCI V2.7) depends on this behavior. I don't know if this is a hardware restriction, or if the NDIS driver for this card is truncating the addresses itself, but using physical/bus addresses beyong the 1GB limit causes initialization failures. - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in if_ndis.c to test whether the device has been initialized rather than checking for the presence of the IFF_UP flag in if_flags. While debugging the previous problem, I noticed that bringing up the device would always produce failures from ndis_setmulti(). It turns out that the following steps now occur during device initialization: - IFF_UP flag is set in if_flags - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) - ifp->if_ioctl() called with SIOCADDMULTI - ifp->if_ioctl() called with SIOCADDMULTI (again) - ifp->if_ioctl() called with SIOCADDMULTI (yet again) - ifp->if_ioctl() called with SIOCSIFFLAGS Setting the receive filter and multicast filters can only be done when the underlying NDIS driver has been initialized, which is done by ifp->if_init(). However, we don't call ifp->if_init() until ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been set. It appears that now, the network stack tries to add multicast addresses to interface's filter before those steps occur. Normally, ndis_setmulti() would trap this condition by checking for the IFF_UP flag, but the network code has in fact set this flag already, so ndis_setmulti() is fooled into thinking the interface has been initialized when it really hasn't. It turns out this is usually harmless because the ifp->if_init() routine (in this case ndis_init()) will set up the multicast filter when it initializes the hardware anyway, and the underlying routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC haven't been initialized yet, but you end up spurious error messages on the console all the time. Something tells me this new behavior isn't really correct. I think the intention was to fix it so that ifp->if_init() is only called once when we ifconfig an interface up, but the end result seems a little bogus: the change of the IFF_UP flag should be propagated down to the driver before calling any other ioctl() that might actually require the hardware to be up and running.
2004-07-07 17:46:30 +00:00
if (!NDIS_INITIALIZED(sc))
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
return;
if (ifp->if_flags & IFF_ALLMULTI || ifp->if_flags & IFF_PROMISC) {
sc->ndis_filter |= NDIS_PACKET_TYPE_ALL_MULTICAST;
len = sizeof(sc->ndis_filter);
error = ndis_set_info(sc, OID_GEN_CURRENT_PACKET_FILTER,
&sc->ndis_filter, &len);
if (error)
device_printf (sc->ndis_dev,
"set filter failed: %d\n", error);
return;
}
Add missing cprd_flags member to partial resource structure in resource_var.h. In kern_ndis.c:ndis_convert_res(), fill in the cprd_flags and cprd_sharedisp fields as best we can. In if_ndis.c:ndis_setmulti(), don't bother updating the multicast filter if our multicast address list is empty. Add some missing updates to ndis_var.h and ntoskrnl_var.h that I forgot to check in when I added the KeDpc stuff.
2004-03-29 02:15:29 +00:00
if (TAILQ_EMPTY(&ifp->if_multiaddrs))
return;
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
len = sizeof(mclistsz);
ndis_get_info(sc, OID_802_3_MAXIMUM_LIST_SIZE, &mclistsz, &len);
Use the M_BZERO flag with malloc() in a couple of places.
2004-01-27 03:14:59 +00:00
mclist = malloc(ETHER_ADDR_LEN * mclistsz, M_TEMP, M_NOWAIT|M_ZERO);
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
if (mclist == NULL) {
sc->ndis_filter |= NDIS_PACKET_TYPE_ALL_MULTICAST;
goto out;
}
sc->ndis_filter |= NDIS_PACKET_TYPE_MULTICAST;
len = 0;
TAILQ_FOREACH(ifma, &ifp->if_multiaddrs, ifma_link) {
if (ifma->ifma_addr->sa_family != AF_LINK)
continue;
bcopy(LLADDR((struct sockaddr_dl *)ifma->ifma_addr),
mclist + (ETHER_ADDR_LEN * len), ETHER_ADDR_LEN);
len++;
if (len > mclistsz) {
sc->ndis_filter |= NDIS_PACKET_TYPE_ALL_MULTICAST;
sc->ndis_filter &= ~NDIS_PACKET_TYPE_MULTICAST;
goto out;
}
}
len = len * ETHER_ADDR_LEN;
error = ndis_set_info(sc, OID_802_3_MULTICAST_LIST, mclist, &len);
if (error) {
device_printf (sc->ndis_dev, "set mclist failed: %d\n", error);
sc->ndis_filter |= NDIS_PACKET_TYPE_ALL_MULTICAST;
sc->ndis_filter &= ~NDIS_PACKET_TYPE_MULTICAST;
}
out:
free(mclist, M_TEMP);
len = sizeof(sc->ndis_filter);
error = ndis_set_info(sc, OID_GEN_CURRENT_PACKET_FILTER,
&sc->ndis_filter, &len);
if (error)
device_printf (sc->ndis_dev, "set filter failed: %d\n", error);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return;
}
Add support for TCP/IP checksum offload. No, really.
2004-01-22 02:36:34 +00:00
static int
ndis_set_offload(sc)
struct ndis_softc *sc;
{
ndis_task_offload *nto;
ndis_task_offload_hdr *ntoh;
ndis_task_tcpip_csum *nttc;
struct ifnet *ifp;
int len, error;
ifp = &sc->arpcom.ac_if;
Fix two problems: - In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags used for shared memory allocations with a lowaddr of 0x3E7FFFFF. This forces the buffers to be mapped to physical/bus addresses within the first 1GB of physical memory. It seems that at least one card (Linksys Instant Wireless PCI V2.7) depends on this behavior. I don't know if this is a hardware restriction, or if the NDIS driver for this card is truncating the addresses itself, but using physical/bus addresses beyong the 1GB limit causes initialization failures. - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in if_ndis.c to test whether the device has been initialized rather than checking for the presence of the IFF_UP flag in if_flags. While debugging the previous problem, I noticed that bringing up the device would always produce failures from ndis_setmulti(). It turns out that the following steps now occur during device initialization: - IFF_UP flag is set in if_flags - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) - ifp->if_ioctl() called with SIOCADDMULTI - ifp->if_ioctl() called with SIOCADDMULTI (again) - ifp->if_ioctl() called with SIOCADDMULTI (yet again) - ifp->if_ioctl() called with SIOCSIFFLAGS Setting the receive filter and multicast filters can only be done when the underlying NDIS driver has been initialized, which is done by ifp->if_init(). However, we don't call ifp->if_init() until ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been set. It appears that now, the network stack tries to add multicast addresses to interface's filter before those steps occur. Normally, ndis_setmulti() would trap this condition by checking for the IFF_UP flag, but the network code has in fact set this flag already, so ndis_setmulti() is fooled into thinking the interface has been initialized when it really hasn't. It turns out this is usually harmless because the ifp->if_init() routine (in this case ndis_init()) will set up the multicast filter when it initializes the hardware anyway, and the underlying routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC haven't been initialized yet, but you end up spurious error messages on the console all the time. Something tells me this new behavior isn't really correct. I think the intention was to fix it so that ifp->if_init() is only called once when we ifconfig an interface up, but the end result seems a little bogus: the change of the IFF_UP flag should be propagated down to the driver before calling any other ioctl() that might actually require the hardware to be up and running.
2004-07-07 17:46:30 +00:00
if (!NDIS_INITIALIZED(sc))
Add support for TCP/IP checksum offload. No, really.
2004-01-22 02:36:34 +00:00
return(EINVAL);
/* See if there's anything to set. */
error = ndis_probe_offload(sc);
if (error)
return(error);
if (sc->ndis_hwassist == 0 && ifp->if_capabilities == 0)
return(0);
len = sizeof(ndis_task_offload_hdr) + sizeof(ndis_task_offload) +
sizeof(ndis_task_tcpip_csum);
ntoh = malloc(len, M_TEMP, M_NOWAIT|M_ZERO);
if (ntoh == NULL)
return(ENOMEM);
ntoh->ntoh_vers = NDIS_TASK_OFFLOAD_VERSION;
ntoh->ntoh_len = sizeof(ndis_task_offload_hdr);
ntoh->ntoh_offset_firsttask = sizeof(ndis_task_offload_hdr);
ntoh->ntoh_encapfmt.nef_encaphdrlen = sizeof(struct ether_header);
ntoh->ntoh_encapfmt.nef_encap = NDIS_ENCAP_IEEE802_3;
ntoh->ntoh_encapfmt.nef_flags = NDIS_ENCAPFLAG_FIXEDHDRLEN;
nto = (ndis_task_offload *)((char *)ntoh +
ntoh->ntoh_offset_firsttask);
nto->nto_vers = NDIS_TASK_OFFLOAD_VERSION;
nto->nto_len = sizeof(ndis_task_offload);
nto->nto_task = NDIS_TASK_TCPIP_CSUM;
nto->nto_offset_nexttask = 0;
nto->nto_taskbuflen = sizeof(ndis_task_tcpip_csum);
nttc = (ndis_task_tcpip_csum *)nto->nto_taskbuf;
if (ifp->if_capenable & IFCAP_TXCSUM)
nttc->nttc_v4tx = sc->ndis_v4tx;
if (ifp->if_capenable & IFCAP_RXCSUM)
nttc->nttc_v4rx = sc->ndis_v4rx;
error = ndis_set_info(sc, OID_TCP_TASK_OFFLOAD, ntoh, &len);
free(ntoh, M_TEMP);
return(error);
}
static int
ndis_probe_offload(sc)
struct ndis_softc *sc;
{
ndis_task_offload *nto;
ndis_task_offload_hdr *ntoh;
ndis_task_tcpip_csum *nttc = NULL;
struct ifnet *ifp;
int len, error, dummy;
ifp = &sc->arpcom.ac_if;
len = sizeof(dummy);
error = ndis_get_info(sc, OID_TCP_TASK_OFFLOAD, &dummy, &len);
if (error != ENOSPC)
return(error);
ntoh = malloc(len, M_TEMP, M_NOWAIT|M_ZERO);
if (ntoh == NULL)
return(ENOMEM);
ntoh->ntoh_vers = NDIS_TASK_OFFLOAD_VERSION;
ntoh->ntoh_len = sizeof(ndis_task_offload_hdr);
ntoh->ntoh_encapfmt.nef_encaphdrlen = sizeof(struct ether_header);
ntoh->ntoh_encapfmt.nef_encap = NDIS_ENCAP_IEEE802_3;
ntoh->ntoh_encapfmt.nef_flags = NDIS_ENCAPFLAG_FIXEDHDRLEN;
error = ndis_get_info(sc, OID_TCP_TASK_OFFLOAD, ntoh, &len);
if (error) {
free(ntoh, M_TEMP);
return(error);
}
if (ntoh->ntoh_vers != NDIS_TASK_OFFLOAD_VERSION) {
free(ntoh, M_TEMP);
return(EINVAL);
}
nto = (ndis_task_offload *)((char *)ntoh +
ntoh->ntoh_offset_firsttask);
while (1) {
switch (nto->nto_task) {
case NDIS_TASK_TCPIP_CSUM:
nttc = (ndis_task_tcpip_csum *)nto->nto_taskbuf;
break;
/* Don't handle these yet. */
case NDIS_TASK_IPSEC:
case NDIS_TASK_TCP_LARGESEND:
default:
break;
}
if (nto->nto_offset_nexttask == 0)
break;
nto = (ndis_task_offload *)((char *)nto +
nto->nto_offset_nexttask);
}
if (nttc == NULL) {
free(ntoh, M_TEMP);
return(ENOENT);
}
sc->ndis_v4tx = nttc->nttc_v4tx;
sc->ndis_v4rx = nttc->nttc_v4rx;
if (nttc->nttc_v4tx & NDIS_TCPSUM_FLAGS_IP_CSUM)
sc->ndis_hwassist |= CSUM_IP;
if (nttc->nttc_v4tx & NDIS_TCPSUM_FLAGS_TCP_CSUM)
sc->ndis_hwassist |= CSUM_TCP;
if (nttc->nttc_v4tx & NDIS_TCPSUM_FLAGS_UDP_CSUM)
sc->ndis_hwassist |= CSUM_UDP;
if (sc->ndis_hwassist)
ifp->if_capabilities |= IFCAP_TXCSUM;
if (nttc->nttc_v4rx & NDIS_TCPSUM_FLAGS_IP_CSUM)
ifp->if_capabilities |= IFCAP_RXCSUM;
if (nttc->nttc_v4rx & NDIS_TCPSUM_FLAGS_TCP_CSUM)
ifp->if_capabilities |= IFCAP_RXCSUM;
if (nttc->nttc_v4rx & NDIS_TCPSUM_FLAGS_UDP_CSUM)
ifp->if_capabilities |= IFCAP_RXCSUM;
free(ntoh, M_TEMP);
return(0);
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/*
* Attach the interface. Allocate softc structures, do ifmedia
* setup and ethernet/BPF attach.
*/
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
int
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
ndis_attach(dev)
device_t dev;
{
u_char eaddr[ETHER_ADDR_LEN];
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
struct ndis_softc *sc;
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
driver_object *drv;
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
driver_object *pdrv;
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
device_object *pdo;
In if_ndis.c:ndis_attach(), temporarily set the IFF_UP flag while calling the haltfunc. If an interrupt is triggered by the init or halt func, the IFF_UP flag must be set in order for us to be able to service it. In kern_ndis.c: implement a handler for NdisMSendResourcesAvailable() (currently does nothing since we don't really need it). In subr_ndis.c: - Correct ndis_init_string() and ndis_unicode_to_ansi(), which were both horribly broken. - Implement NdisImmediateReadPciSlotInformation() and NdisImmediateWritePciSlotInformation(). - Implement NdisBufferLength(). - Work around my first confirmed NDIS driver bug. The SMC 9462 gigE driver (natsemi 83820-based copper) incorrectly creates a spinlock in its DriverEntry() routine and then destroys it in its MiniportHalt() handler. This is wrong: spinlocks should be created in MiniportInit(). In a Windows environment, this is often not a problem because DriverEntry()/MiniportInit() are called once when the system boots and MiniportHalt() or the shutdown handler is called when the system halts. With this stuff in place, this driver now seems to work: ndis0: <SMC EZ Card 1000> port 0xe000-0xe0ff mem 0xda000000-0xda000fff irq 10 at device 9.0 on pci0 ndis0: assign PCI resources... ndis_open_file("FLASH9.hex", 18446744073709551615) ndis0: Ethernet address: 00:04:e2:0e:d3:f0
2004-01-03 13:20:30 +00:00
struct ifnet *ifp = NULL;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
void *img;
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
int error = 0, len;
int i;
Deal with the duplicate sysctl leaf problem. A .inf file may contain definitions for more than one device (usually differentiated by the PCI subvendor/subdevice ID). Each device also has its own tree of registry keys. In some cases, each device has the same keys, but sometimes each device has a unique tree but with overlap. Originally, I just had ndiscvt(8) dump out all the keys it could find, and we would try to apply them to every device we could find. Now, each key has an index number that matches it to a device in the device ID list. This lets us create just the keys that apply to a particular device. I also added an extra field to the device list to hold the subvendor and subdevice ID. Some devices are generic, i.e. there is no subsystem definition. If we have a device that doesn't match a specific subsystem value and we have a generic entry, we use the generic entry.
2003-12-18 03:51:21 +00:00
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sc = device_get_softc(dev);
Continue my efforts to imitate Windows as closely as possible by attempting to duplicate Windows spinlocks. Windows spinlocks differ from FreeBSD spinlocks in the way they block preemption. FreeBSD spinlocks use critical_enter(), which masks off _all_ interrupts. This prevents any other threads from being scheduled, but it also prevents ISRs from running. In Windows, preemption is achieved by raising the processor IRQL to DISPATCH_LEVEL, which prevents other threads from preempting you, but does _not_ prevent device ISRs from running. (This is essentially what Solaris calls dispatcher locks.) The Windows spinlock itself (kspin_lock) is just an integer value which is atomically set when you acquire the lock and atomically cleared when you release it. FreeBSD doesn't have IRQ levels, so we have to cheat a little by using thread priorities: normal thread priority is PASSIVE_LEVEL, lowest interrupt thread priority is DISPATCH_LEVEL, highest thread priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL matter to us. The immediate benefit of all this is that I no longer have to rely on a mutex pool. Now, I'm sure many people will be seized by the urge to criticize me for doing an end run around our own spinlock implementation, but it makes more sense to do it this way. Well, it does to me anyway. Overview of the changes: - Properly implement hal_lock(), hal_unlock(), hal_irql(), hal_raise_irql() and hal_lower_irql() so that they more closely resemble their Windows counterparts. The IRQL is determined by thread priority. - Make ntoskrnl_lock_dpc() and ntoskrnl_unlock_dpc() do what they do in Windows, which is to atomically set/clear the lock value. These routines are designed to be called from DISPATCH_LEVEL, and are actually half of the work involved in acquiring/releasing spinlocks. - Add FASTCALL1(), FASTCALL2() and FASTCALL3() macros/wrappers that allow us to call a _fastcall function in spite of the fact that our version of gcc doesn't support __attribute__((__fastcall__)) yet. The macros take 1, 2 or 3 arguments, respectively. We need to call hal_lock(), hal_unlock() etc... ourselves, but can't really invoke the function directly. I could have just made the underlying functions native routines and put _fastcall wrappers around them for the benefit of Windows binaries, but that would create needless bloat. - Remove ndis_mtxpool and all references to it. We don't need it anymore. - Re-implement the NdisSpinLock routines so that they use hal_lock() and friends like they do in Windows. - Use the new spinlock methods for handling lookaside lists and linked list updates in place of the mutex locks that were there before. - Remove mutex locking from ndis_isr() and ndis_intrhand() since they're already called with ndis_intrmtx held in if_ndis.c. - Put ndis_destroy_lock() code under explicit #ifdef notdef/#endif. It turns out there are some drivers which stupidly free the memory in which their spinlocks reside before calling ndis_destroy_lock() on them (touch-after-free bug). The ADMtek wireless driver is guilty of this faux pas. (Why this doesn't clobber Windows I have no idea.) - Make NdisDprAcquireSpinLock() and NdisDprReleaseSpinLock() into real functions instead of aliasing them to NdisAcaquireSpinLock() and NdisReleaseSpinLock(). The Dpr routines use KeAcquireSpinLockAtDpcLevel() level and KeReleaseSpinLockFromDpcLevel(), which acquires the lock without twiddling the IRQL. - In ndis_linksts_done(), do _not_ call ndis_80211_getstate(). Some drivers may call the status/status done callbacks as the result of setting an OID: ndis_80211_getstate() gets OIDs, which means we might cause the driver to recursively access some of its internal structures unexpectedly. The ndis_ticktask() routine will call ndis_80211_getstate() for us eventually anyway. - Fix the channel setting code a little in ndis_80211_setstate(), and initialize the channel to IEEE80211_CHAN_ANYC. (The Microsoft spec says you're not supposed to twiddle the channel in BSS mode; I may need to enforce this later.) This fixes the problems I was having with the ADMtek adm8211 driver: we were setting the channel to a non-standard default, which would cause it to fail to associate in BSS mode. - Use hal_raise_irql() to raise our IRQL to DISPATCH_LEVEL when calling certain miniport routines, per the Microsoft documentation. I think that's everything. Hopefully, other than fixing the ADMtek driver, there should be no apparent change in behavior.
2004-04-14 07:48:03 +00:00
mtx_init(&sc->ndis_mtx, "ndis softc lock",
MTX_NETWORK_LOCK, MTX_DEF);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
/*
Set up the interrupt earlier in ndis_attach(), because calling the driver's initfunc may cause an interrupt to be generated. This avoids the occasional 'stray irqXXX' messages on load.
2003-12-23 18:41:34 +00:00
* Hook interrupt early, since calling the driver's
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
* init routine may trigger an interrupt. Note that
* we don't need to do any explicit interrupt setup
* for USB.
Set up the interrupt earlier in ndis_attach(), because calling the driver's initfunc may cause an interrupt to be generated. This avoids the occasional 'stray irqXXX' messages on load.
2003-12-23 18:41:34 +00:00
*/
- Fix some compiler warnings in subr_pe.c - Add explicit cardbus attachment in if_ndis.c - Clean up after moving bus_setup_intr() in ndis_attach(). - When setting an ssid, program an empty ssid as a 1-byte string with a single 0 byte. The Microsoft documentation says this is how you're supposed to tell the NIC to attach to 'any' ssid. - Keep trace of callout handles for timers externally from the ndis_miniport_timer structs, and run through and clobber them all after invoking the haltfunc just in case the driver left one running. (We need to make sure all timers are cancelled on driver unload.) - Handle the 'cancelled' argument in ndis_cancel_timer() correctly.
2003-12-24 21:21:18 +00:00
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
if (sc->ndis_iftype == PCMCIABus || sc->ndis_iftype == PCIBus) {
error = bus_setup_intr(dev, sc->ndis_irq,
INTR_TYPE_NET | INTR_MPSAFE,
ndis_intr, sc, &sc->ndis_intrhand);
Set up the interrupt earlier in ndis_attach(), because calling the driver's initfunc may cause an interrupt to be generated. This avoids the occasional 'stray irqXXX' messages on load.
2003-12-23 18:41:34 +00:00
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
if (error) {
device_printf(dev, "couldn't set up irq\n");
goto fail;
}
Set up the interrupt earlier in ndis_attach(), because calling the driver's initfunc may cause an interrupt to be generated. This avoids the occasional 'stray irqXXX' messages on load.
2003-12-23 18:41:34 +00:00
}
Add some minor changes related to PCMCIA attribute memory mapping (which I apparently forgot to commit earlier). Acquire NDIS_LOCK() in ndis_linksts_done().
2004-08-01 06:42:44 +00:00
if (sc->ndis_iftype == PCMCIABus) {
error = ndis_alloc_amem(sc);
if (error) {
device_printf(dev, "failed to allocate "
"attribute memory\n");
goto fail;
}
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sc->ndis_regvals = ndis_regvals;
Deal with the duplicate sysctl leaf problem. A .inf file may contain definitions for more than one device (usually differentiated by the PCI subvendor/subdevice ID). Each device also has its own tree of registry keys. In some cases, each device has the same keys, but sometimes each device has a unique tree but with overlap. Originally, I just had ndiscvt(8) dump out all the keys it could find, and we would try to apply them to every device we could find. Now, each key has an index number that matches it to a device in the device ID list. This lets us create just the keys that apply to a particular device. I also added an extra field to the device list to hold the subvendor and subdevice ID. Some devices are generic, i.e. there is no subsystem definition. If we have a device that doesn't match a specific subsystem value and we have a generic entry, we use the generic entry.
2003-12-18 03:51:21 +00:00
Take advantage of the dev sysctl tree. Approved by: wpaul
2004-06-04 22:24:46 +00:00
#if __FreeBSD_version < 502113
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sysctl_ctx_init(&sc->ndis_ctx);
Take advantage of the dev sysctl tree. Approved by: wpaul
2004-06-04 22:24:46 +00:00
#endif
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/* Create sysctl registry nodes */
ndis_create_sysctls(sc);
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
/* Find the PDO for this device instance. */
if (sc->ndis_iftype == PCIBus)
Use 0 instead if NULL for vm_offset_t argument to windrv_lookup() to silence compiler warnings.
2005-02-28 16:47:54 +00:00
pdrv = windrv_lookup(0, "PCI Bus");
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
else if (sc->ndis_iftype == PCMCIABus)
Use 0 instead if NULL for vm_offset_t argument to windrv_lookup() to silence compiler warnings.
2005-02-28 16:47:54 +00:00
pdrv = windrv_lookup(0, "PCCARD Bus");
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
else
Use 0 instead if NULL for vm_offset_t argument to windrv_lookup() to silence compiler warnings.
2005-02-28 16:47:54 +00:00
pdrv = windrv_lookup(0, "USB Bus");
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
pdo = windrv_find_pdo(pdrv, dev);
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
/*
* Create a new functional device object for this
* device. This is what creates the miniport block
* for this device instance.
*/
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
img = drv_data;
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
drv = windrv_lookup((vm_offset_t)img, NULL);
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
if (NdisAddDevice(drv, pdo) != STATUS_SUCCESS) {
device_printf(dev, "failed to create FDO!\n");
error = ENXIO;
goto fail;
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
In ndis_attach(), report the NDIS API level that the Windows miniport driver was compiled with. Remove debug printf from ndis_assicn_pcirsc(). It doesn't serve much purpose. Implement NdisMIndicateStatus() and NdisMIndicateStatusComplete() as functions in subr_ndis.c. In NDIS 4.0, they were functions. In NDIS 5.0 and later, they're just macros. Allocate a few extra packets/buffers beyond what the driver asks for since sometimes it seems they can lie about how many they really need, and some extra stupid ones don't check to see if NdisAllocatePacket() and/or NdisAllocateBuffer() actually succeed.
2004-01-04 03:00:21 +00:00
/* Tell the user what version of the API the driver is using. */
device_printf(dev, "NDIS API version: %d.%d\n",
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
sc->ndis_chars->nmc_version_major,
sc->ndis_chars->nmc_version_minor);
In ndis_attach(), report the NDIS API level that the Windows miniport driver was compiled with. Remove debug printf from ndis_assicn_pcirsc(). It doesn't serve much purpose. Implement NdisMIndicateStatus() and NdisMIndicateStatusComplete() as functions in subr_ndis.c. In NDIS 4.0, they were functions. In NDIS 5.0 and later, they're just macros. Allocate a few extra packets/buffers beyond what the driver asks for since sometimes it seems they can lie about how many they really need, and some extra stupid ones don't check to see if NdisAllocatePacket() and/or NdisAllocateBuffer() actually succeed.
2004-01-04 03:00:21 +00:00
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/* Do resource conversion. */
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
if (sc->ndis_iftype == PCMCIABus || sc->ndis_iftype == PCIBus)
ndis_convert_res(sc);
Apparently, the probe routine in if_ndis_usb.c can be called twice for a given device in some circumstances, so move the PDO creation to the attach routine so we don't end up creating two PDOs. Also, when we skip the call to ndis_convert_res() in if_ndis.c:ndis_attach(), initialize sc->ndis_block->nmb_rlist to NULL. We don't explicitly zero the miniport block, so this will make sure ndis_unload_driver() does the right thing.
2005-02-24 22:54:15 +00:00
else
sc->ndis_block->nmb_rlist = NULL;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/* Install our RX and TX interrupt handlers. */
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
sc->ndis_block->nmb_senddone_func = ndis_txeof_wrap;
sc->ndis_block->nmb_pktind_func = ndis_rxeof_wrap;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/* Call driver's init routine. */
if (ndis_init_nic(sc)) {
Clean up ndiscvt a bit (leaving out the -i flag didn't work) and add copyrights to the inf parser files. Add a -n flag to ndiscvt to allow the user to override the default device name of NDIS devices. Instead of "ndis0, ndis1, etc..." you can have "foo0, foo1, etc..." This allows you to have more than one kind of NDIS device in the kernel at the same time. Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c and subr_ndis.c. Create UMA zones for ndis_packet and ndis_buffer structs allocated on transmit. The zones are created and destroyed in the modevent handler in kern_ndis.c. printf() and UMA changes submitted by green@freebsd.org
2004-01-02 04:31:06 +00:00
device_printf (dev, "init handler failed\n");
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
error = ENXIO;
goto fail;
}
/*
* Get station address from the driver.
*/
len = sizeof(eaddr);
ndis_get_info(sc, OID_802_3_CURRENT_ADDRESS, &eaddr, &len);
bcopy(eaddr, (char *)&sc->arpcom.ac_enaddr, ETHER_ADDR_LEN);
/*
Minor cleanups: - Fix typo in comment - Remember to free() sc->ndis_txarray on detach - Remember to do an ifmedia_removeall() for ethernet devices
2004-08-03 17:00:39 +00:00
* Figure out if we're allowed to use multipacket sends
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
* with this driver, and if so, how many.
*/
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
if (sc->ndis_chars->nmc_sendsingle_func &&
sc->ndis_chars->nmc_sendmulti_func == NULL) {
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sc->ndis_maxpkts = 1;
Implement support for single packet sends. The Intel Centrino driver that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
2004-02-03 07:39:23 +00:00
} else {
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
len = sizeof(sc->ndis_maxpkts);
ndis_get_info(sc, OID_GEN_MAXIMUM_SEND_PACKETS,
&sc->ndis_maxpkts, &len);
}
Implement support for single packet sends. The Intel Centrino driver that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
2004-02-03 07:39:23 +00:00
sc->ndis_txarray = malloc(sizeof(ndis_packet *) *
sc->ndis_maxpkts, M_DEVBUF, M_NOWAIT|M_ZERO);
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
/* Allocate a pool of ndis_packets for TX encapsulation. */
NdisAllocatePacketPool(&i, &sc->ndis_txpool,
sc->ndis_maxpkts, PROTOCOL_RESERVED_SIZE_IN_PACKET);
if (i != NDIS_STATUS_SUCCESS) {
sc->ndis_txpool = NULL;
device_printf(dev, "failed to allocate TX packet pool");
error = ENOMEM;
goto fail;
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sc->ndis_txpending = sc->ndis_maxpkts;
sc->ndis_oidcnt = 0;
/* Get supported oid list. */
ndis_get_supported_oids(sc, &sc->ndis_oids, &sc->ndis_oidcnt);
/* If the NDIS module requested scatter/gather, init maps. */
if (sc->ndis_sc)
ndis_init_dma(sc);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
/*
Use the OID_802_11_CONFIGURATION OID when deciding if the underlying driver is for an 802.11 device or not. At least one driver I have does not support the OID_802_11_NETWORK_TYPES_SUPPORTED OID. Also, for now, don't do anything special in the ndis_suspend() method. I originally wanted to shut down the NIC but leave the IFF_UP flag alone since technically the interface is meant to remain up, but an interrupt may be delivered to the ISR on suspend, and if this happens while the NIC is halted, we will crash, since none of the miniport driver methods will function. This needs to be dealt with properly later, but for now this prevents a panic, and the resume method properly re-inits the NIC.
2004-02-01 21:35:15 +00:00
* See if the OID_802_11_CONFIGURATION OID is
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
* supported by this driver. If it is, then this an 802.11
* wireless driver, and we should set up media for wireless.
*/
for (i = 0; i < sc->ndis_oidcnt; i++) {
Use the OID_802_11_CONFIGURATION OID when deciding if the underlying driver is for an 802.11 device or not. At least one driver I have does not support the OID_802_11_NETWORK_TYPES_SUPPORTED OID. Also, for now, don't do anything special in the ndis_suspend() method. I originally wanted to shut down the NIC but leave the IFF_UP flag alone since technically the interface is meant to remain up, but an interrupt may be delivered to the ISR on suspend, and if this happens while the NIC is halted, we will crash, since none of the miniport driver methods will function. This needs to be dealt with properly later, but for now this prevents a panic, and the resume method properly re-inits the NIC.
2004-02-01 21:35:15 +00:00
if (sc->ndis_oids[i] == OID_802_11_CONFIGURATION) {
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
sc->ndis_80211++;
break;
}
}
Add support for TCP/IP checksum offload. No, really.
2004-01-22 02:36:34 +00:00
/* Check for task offload support. */
ndis_probe_offload(sc);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
ifp = &sc->arpcom.ac_if;
ifp->if_softc = sc;
if_initname(ifp, device_get_name(dev), device_get_unit(dev));
ifp->if_mtu = ETHERMTU;
ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST;
ifp->if_ioctl = ndis_ioctl;
ifp->if_start = ndis_start;
ifp->if_watchdog = ndis_watchdog;
ifp->if_init = ndis_init;
ifp->if_baudrate = 10000000;
Second part of ALTQ driver modifications, covering: an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4) Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/ Tested by: Vaidas Damosevicius (an, ath, wi) Roman Divacky (vr) Submitted by: yongari (hme)
2004-08-01 23:58:04 +00:00
#if __FreeBSD_version < 502114
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
ifp->if_snd.ifq_maxlen = 50;
Second part of ALTQ driver modifications, covering: an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4) Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/ Tested by: Vaidas Damosevicius (an, ath, wi) Roman Divacky (vr) Submitted by: yongari (hme)
2004-08-01 23:58:04 +00:00
#else
IFQ_SET_MAXLEN(&ifp->if_snd, 50);
ifp->if_snd.ifq_drv_maxlen = 25;
IFQ_SET_READY(&ifp->if_snd);
#endif
Add support for TCP/IP checksum offload. No, really.
2004-01-22 02:36:34 +00:00
ifp->if_capenable = ifp->if_capabilities;
ifp->if_hwassist = sc->ndis_hwassist;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
/* Do media setup */
if (sc->ndis_80211) {
Fix compilation and correct mapping from struct ifnet to struct ieee80211com after net80211 import. Submitted by: Tor Egge
2004-12-10 00:59:27 +00:00
struct ieee80211com *ic = (void *)&sc->ic;
Unbreak the Intel 2100 Centrino wireless driver (and probably others): - In subr_ndis.c, my_strcasecmp() actually behaved like my_strncasecmp(): we really need it to behave like the former, not the latter. (It was falsely matching "RadioEnable", which defaults to 1 with "RadioEnableHW" which the driver creates itself and to 0, because we were using strlen("RadioEnable") as the length to test. This caused the radio to always be turned off. :( ) - In if_ndis.c, only set IEEE80211_CHAN_A for channels if we actually set any IEEE80211_MODE_11A rates. (ieee80211_attach() will "helpfully" add IEEE80211_MODE_11A to ic_modecaps for you if you initialize any 802.11a channels. This caused "ndis0: 11a rates:" to erroneously be displayed during driver load.) - Also in if_ndis.c, when using TESTSETRATE() to add in any missing 802.11b rates, remember to OR the rates with IEEE80211_RATE_BASIC, otherwise comparing against existing basic rates won't match. (1, 2, 5.5 and 11Mbps are basic rates, according to the 802.11b spec.) This erroneously cause 11Mbps to be added to the 11b rate list twice.
2004-06-04 04:43:36 +00:00
ndis_80211_rates_ex rates;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
struct ndis_80211_nettype_list *ntl;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
uint32_t arg;
int r;
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
ic->ic_ifp = ifp;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
ic->ic_phytype = IEEE80211_T_DS;
ic->ic_opmode = IEEE80211_M_STA;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
ic->ic_caps = IEEE80211_C_IBSS;
ic->ic_state = IEEE80211_S_ASSOC;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
ic->ic_modecaps = (1<<IEEE80211_MODE_AUTO);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
len = 0;
r = ndis_get_info(sc, OID_802_11_NETWORK_TYPES_SUPPORTED,
NULL, &len);
if (r != ENOSPC)
goto nonettypes;
Use the M_BZERO flag with malloc() in a couple of places.
2004-01-27 03:14:59 +00:00
ntl = malloc(len, M_DEVBUF, M_WAITOK|M_ZERO);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
r = ndis_get_info(sc, OID_802_11_NETWORK_TYPES_SUPPORTED,
ntl, &len);
if (r != 0) {
free(ntl, M_DEVBUF);
goto nonettypes;
}
for (i = 0; i < ntl->ntl_items; i++) {
switch (ntl->ntl_type[i]) {
case NDIS_80211_NETTYPE_11FH:
case NDIS_80211_NETTYPE_11DS:
ic->ic_modecaps |= (1<<IEEE80211_MODE_11B);
break;
case NDIS_80211_NETTYPE_11OFDM5:
ic->ic_modecaps |= (1<<IEEE80211_MODE_11A);
break;
case NDIS_80211_NETTYPE_11OFDM24:
ic->ic_modecaps |= (1<<IEEE80211_MODE_11G);
break;
default:
break;
}
}
free(ntl, M_DEVBUF);
nonettypes:
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
len = sizeof(rates);
bzero((char *)&rates, len);
r = ndis_get_info(sc, OID_802_11_SUPPORTED_RATES,
(void *)rates, &len);
if (r)
Clean up ndiscvt a bit (leaving out the -i flag didn't work) and add copyrights to the inf parser files. Add a -n flag to ndiscvt to allow the user to override the default device name of NDIS devices. Instead of "ndis0, ndis1, etc..." you can have "foo0, foo1, etc..." This allows you to have more than one kind of NDIS device in the kernel at the same time. Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c and subr_ndis.c. Create UMA zones for ndis_packet and ndis_buffer structs allocated on transmit. The zones are created and destroyed in the modevent handler in kern_ndis.c. printf() and UMA changes submitted by green@freebsd.org
2004-01-02 04:31:06 +00:00
device_printf (dev, "get rates failed: 0x%x\n", r);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
/*
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
* Since the supported rates only up to 8 can be supported,
* if this is not 802.11b we're just going to be faking it
* all up to heck.
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
*/
- The MiniportReset() function can return NDIS_STATUS_PENDING, in which case we should wait for the resetdone handler to be called before returning. - When providing resources via ndis_query_resources(), uses the computed rsclen when using bcopy() to copy out the resource data rather than the caller-supplied buffer length. - Avoid using ndis_reset_nic() in if_ndis.c unless we really need to reset the NIC because of a problem. - Allow interrupts to be fielded during ndis_attach(), at least as far as allowing ndis_isr() and ndis_intrhand() to run. - Use ndis_80211_rates_ex when probing for supported rates. Technically, this isn't supposed to work since, although Microsoft added the extended rate structure with the NDIS 5.1 update, the spec still says that the OID_802_11_SUPPORTED_RATES OID uses ndis_80211_rates. In spite of this, it appears some drivers use it anyway. - When adding in our guessed rates, check to see if they already exist so that we avoid any duplicates. - Add a printf() to ndis_open_file() that alerts the user when a driver attempts to open a file under /compat/ndis. With these changes, I can get the driver for the SMC 2802W 54g PCI card to load and run. This board uses a Prism54G chip. Note that in order for this driver to work, you must place the supplied smc2802w.arm firmware image under /compat/ndis. (The firmware is not resident on the device.) Note that this should also allow the 3Com 3CRWE154G72 card to work as well; as far as I can tell, these cards also use a Prism54G chip.
2004-04-05 08:26:52 +00:00
#define TESTSETRATE(x, y) \
do { \
int i; \
for (i = 0; i < ic->ic_sup_rates[x].rs_nrates; i++) { \
if (ic->ic_sup_rates[x].rs_rates[i] == (y)) \
break; \
} \
if (i == ic->ic_sup_rates[x].rs_nrates) { \
ic->ic_sup_rates[x].rs_rates[i] = (y); \
ic->ic_sup_rates[x].rs_nrates++; \
} \
} while (0)
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
#define SETRATE(x, y) \
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
ic->ic_sup_rates[x].rs_rates[ic->ic_sup_rates[x].rs_nrates] = (y)
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
#define INCRATE(x) \
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
ic->ic_sup_rates[x].rs_nrates++
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
ic->ic_curmode = IEEE80211_MODE_AUTO;
if (ic->ic_modecaps & (1<<IEEE80211_MODE_11A))
ic->ic_sup_rates[IEEE80211_MODE_11A].rs_nrates = 0;
if (ic->ic_modecaps & (1<<IEEE80211_MODE_11B))
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
ic->ic_sup_rates[IEEE80211_MODE_11B].rs_nrates = 0;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
if (ic->ic_modecaps & (1<<IEEE80211_MODE_11G))
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
ic->ic_sup_rates[IEEE80211_MODE_11G].rs_nrates = 0;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
for (i = 0; i < len; i++) {
switch (rates[i] & IEEE80211_RATE_VAL) {
case 2:
case 4:
case 11:
case 10:
case 22:
if (!(ic->ic_modecaps &
(1<<IEEE80211_MODE_11B))) {
/* Lazy-init 802.11b. */
ic->ic_modecaps |=
(1<<IEEE80211_MODE_11B);
ic->ic_sup_rates[IEEE80211_MODE_11B].
rs_nrates = 0;
}
SETRATE(IEEE80211_MODE_11B, rates[i]);
INCRATE(IEEE80211_MODE_11B);
break;
default:
if (ic->ic_modecaps & (1<<IEEE80211_MODE_11A)) {
SETRATE(IEEE80211_MODE_11A, rates[i]);
INCRATE(IEEE80211_MODE_11A);
}
if (ic->ic_modecaps & (1<<IEEE80211_MODE_11G)) {
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
SETRATE(IEEE80211_MODE_11G, rates[i]);
INCRATE(IEEE80211_MODE_11G);
}
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
break;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
}
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
}
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
/*
* If the hardware supports 802.11g, it most
* likely supports 802.11b and all of the
* 802.11b and 802.11g speeds, so maybe we can
* just cheat here. Just how in the heck do
* we detect turbo modes, though?
*/
In subr_ndis.c, when searching for keys in our make-pretend registry, make the key name matching case-insensitive. There are some drivers and .inf files that have mismatched cases, e.g. the driver will look for "AdhocBand" whereas the .inf file specifies a registry key to be created called "AdHocBand." The mismatch is probably a typo that went undetected (so much for QA), but since Windows seems to be case-insensitive, we should be too. In if_ndis.c, initialize rates and channels correctly so that specify frequences correctly when trying to set channels in the 5Ghz band, and so that 802.11b rates show up for some a/b/g cards (which otherwise appear to have no 802.11b modes). Also, when setting OID_802_11_CONFIGURATION in ndis_80211_setstate(), provide default values for the beacon interval, ATIM window and dwelltime. The Atheros "Aries" driver will crash if you try to select ad-hoc mode and leave the beacon interval set to 0: it blindly uses this value and does a division by 0 in the interrupt handler, causing an integer divide trap.
2004-05-29 06:41:17 +00:00
if (ic->ic_modecaps & (1<<IEEE80211_MODE_11B)) {
Unbreak the Intel 2100 Centrino wireless driver (and probably others): - In subr_ndis.c, my_strcasecmp() actually behaved like my_strncasecmp(): we really need it to behave like the former, not the latter. (It was falsely matching "RadioEnable", which defaults to 1 with "RadioEnableHW" which the driver creates itself and to 0, because we were using strlen("RadioEnable") as the length to test. This caused the radio to always be turned off. :( ) - In if_ndis.c, only set IEEE80211_CHAN_A for channels if we actually set any IEEE80211_MODE_11A rates. (ieee80211_attach() will "helpfully" add IEEE80211_MODE_11A to ic_modecaps for you if you initialize any 802.11a channels. This caused "ndis0: 11a rates:" to erroneously be displayed during driver load.) - Also in if_ndis.c, when using TESTSETRATE() to add in any missing 802.11b rates, remember to OR the rates with IEEE80211_RATE_BASIC, otherwise comparing against existing basic rates won't match. (1, 2, 5.5 and 11Mbps are basic rates, according to the 802.11b spec.) This erroneously cause 11Mbps to be added to the 11b rate list twice.
2004-06-04 04:43:36 +00:00
TESTSETRATE(IEEE80211_MODE_11B,
IEEE80211_RATE_BASIC|2);
TESTSETRATE(IEEE80211_MODE_11B,
IEEE80211_RATE_BASIC|4);
TESTSETRATE(IEEE80211_MODE_11B,
IEEE80211_RATE_BASIC|11);
TESTSETRATE(IEEE80211_MODE_11B,
IEEE80211_RATE_BASIC|22);
In subr_ndis.c, when searching for keys in our make-pretend registry, make the key name matching case-insensitive. There are some drivers and .inf files that have mismatched cases, e.g. the driver will look for "AdhocBand" whereas the .inf file specifies a registry key to be created called "AdHocBand." The mismatch is probably a typo that went undetected (so much for QA), but since Windows seems to be case-insensitive, we should be too. In if_ndis.c, initialize rates and channels correctly so that specify frequences correctly when trying to set channels in the 5Ghz band, and so that 802.11b rates show up for some a/b/g cards (which otherwise appear to have no 802.11b modes). Also, when setting OID_802_11_CONFIGURATION in ndis_80211_setstate(), provide default values for the beacon interval, ATIM window and dwelltime. The Atheros "Aries" driver will crash if you try to select ad-hoc mode and leave the beacon interval set to 0: it blindly uses this value and does a division by 0 in the interrupt handler, causing an integer divide trap.
2004-05-29 06:41:17 +00:00
}
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
if (ic->ic_modecaps & (1<<IEEE80211_MODE_11G)) {
- The MiniportReset() function can return NDIS_STATUS_PENDING, in which case we should wait for the resetdone handler to be called before returning. - When providing resources via ndis_query_resources(), uses the computed rsclen when using bcopy() to copy out the resource data rather than the caller-supplied buffer length. - Avoid using ndis_reset_nic() in if_ndis.c unless we really need to reset the NIC because of a problem. - Allow interrupts to be fielded during ndis_attach(), at least as far as allowing ndis_isr() and ndis_intrhand() to run. - Use ndis_80211_rates_ex when probing for supported rates. Technically, this isn't supposed to work since, although Microsoft added the extended rate structure with the NDIS 5.1 update, the spec still says that the OID_802_11_SUPPORTED_RATES OID uses ndis_80211_rates. In spite of this, it appears some drivers use it anyway. - When adding in our guessed rates, check to see if they already exist so that we avoid any duplicates. - Add a printf() to ndis_open_file() that alerts the user when a driver attempts to open a file under /compat/ndis. With these changes, I can get the driver for the SMC 2802W 54g PCI card to load and run. This board uses a Prism54G chip. Note that in order for this driver to work, you must place the supplied smc2802w.arm firmware image under /compat/ndis. (The firmware is not resident on the device.) Note that this should also allow the 3Com 3CRWE154G72 card to work as well; as far as I can tell, these cards also use a Prism54G chip.
2004-04-05 08:26:52 +00:00
TESTSETRATE(IEEE80211_MODE_11G, 47);
TESTSETRATE(IEEE80211_MODE_11G, 72);
TESTSETRATE(IEEE80211_MODE_11G, 96);
TESTSETRATE(IEEE80211_MODE_11G, 108);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
}
if (ic->ic_modecaps & (1<<IEEE80211_MODE_11A)) {
- The MiniportReset() function can return NDIS_STATUS_PENDING, in which case we should wait for the resetdone handler to be called before returning. - When providing resources via ndis_query_resources(), uses the computed rsclen when using bcopy() to copy out the resource data rather than the caller-supplied buffer length. - Avoid using ndis_reset_nic() in if_ndis.c unless we really need to reset the NIC because of a problem. - Allow interrupts to be fielded during ndis_attach(), at least as far as allowing ndis_isr() and ndis_intrhand() to run. - Use ndis_80211_rates_ex when probing for supported rates. Technically, this isn't supposed to work since, although Microsoft added the extended rate structure with the NDIS 5.1 update, the spec still says that the OID_802_11_SUPPORTED_RATES OID uses ndis_80211_rates. In spite of this, it appears some drivers use it anyway. - When adding in our guessed rates, check to see if they already exist so that we avoid any duplicates. - Add a printf() to ndis_open_file() that alerts the user when a driver attempts to open a file under /compat/ndis. With these changes, I can get the driver for the SMC 2802W 54g PCI card to load and run. This board uses a Prism54G chip. Note that in order for this driver to work, you must place the supplied smc2802w.arm firmware image under /compat/ndis. (The firmware is not resident on the device.) Note that this should also allow the 3Com 3CRWE154G72 card to work as well; as far as I can tell, these cards also use a Prism54G chip.
2004-04-05 08:26:52 +00:00
TESTSETRATE(IEEE80211_MODE_11A, 47);
TESTSETRATE(IEEE80211_MODE_11A, 72);
TESTSETRATE(IEEE80211_MODE_11A, 96);
TESTSETRATE(IEEE80211_MODE_11A, 108);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
}
#undef SETRATE
#undef INCRATE
Re-do the handling of ndis_buffers. The NDIS_BUFFER structure is supposed to be opaque to the driver, however it is exposed through several macros which expect certain behavior. In my original implementation, I used the mappedsystemva member of the structure to hold a pointer to the buffer and bytecount to hold the length. It turns out you must use the startva pointer to point to the page containing the start of the buffer and set byteoffset to the offset within the page where the buffer starts. So, for a buffer with address 'baseva,' startva is baseva & ~(PAGE_SIZE -1) and byteoffset is baseva & (PAGE_SIZE -1). We have to maintain this convention everywhere that ndis_buffers are used. Fortunately, Microsoft defines some macros for initializing and manipulating NDIS_BUFFER structures in ntddk.h. I adapted some of them for use here and used them where appropriate. This fixes the discrepancy I observed between how RX'ed packet sizes were being reported in the Broadcom wireless driver and the sample ethernet drivers that I've tested. This should also help the Intel Centrino wireless driver work. Also try to properly initialize the 802.11 BSS and IBSS channels. (Sadly, the channel value is meaningless since there's no way in the existing NDIS API to get/set the channel, but this should take care of any 'invalid channel (NULL)' messages printed on the console.
2003-12-23 04:08:22 +00:00
/*
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
* Taking yet more guesses here.
Re-do the handling of ndis_buffers. The NDIS_BUFFER structure is supposed to be opaque to the driver, however it is exposed through several macros which expect certain behavior. In my original implementation, I used the mappedsystemva member of the structure to hold a pointer to the buffer and bytecount to hold the length. It turns out you must use the startva pointer to point to the page containing the start of the buffer and set byteoffset to the offset within the page where the buffer starts. So, for a buffer with address 'baseva,' startva is baseva & ~(PAGE_SIZE -1) and byteoffset is baseva & (PAGE_SIZE -1). We have to maintain this convention everywhere that ndis_buffers are used. Fortunately, Microsoft defines some macros for initializing and manipulating NDIS_BUFFER structures in ntddk.h. I adapted some of them for use here and used them where appropriate. This fixes the discrepancy I observed between how RX'ed packet sizes were being reported in the Broadcom wireless driver and the sample ethernet drivers that I've tested. This should also help the Intel Centrino wireless driver work. Also try to properly initialize the 802.11 BSS and IBSS channels. (Sadly, the channel value is meaningless since there's no way in the existing NDIS API to get/set the channel, but this should take care of any 'invalid channel (NULL)' messages printed on the console.
2003-12-23 04:08:22 +00:00
*/
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
for (i = 1; i < IEEE80211_CHAN_MAX; i++) {
int chanflag = 0;
if (ic->ic_sup_rates[IEEE80211_MODE_11G].rs_nrates)
chanflag |= IEEE80211_CHAN_G;
if (i <= 14)
chanflag |= IEEE80211_CHAN_B;
Unbreak the Intel 2100 Centrino wireless driver (and probably others): - In subr_ndis.c, my_strcasecmp() actually behaved like my_strncasecmp(): we really need it to behave like the former, not the latter. (It was falsely matching "RadioEnable", which defaults to 1 with "RadioEnableHW" which the driver creates itself and to 0, because we were using strlen("RadioEnable") as the length to test. This caused the radio to always be turned off. :( ) - In if_ndis.c, only set IEEE80211_CHAN_A for channels if we actually set any IEEE80211_MODE_11A rates. (ieee80211_attach() will "helpfully" add IEEE80211_MODE_11A to ic_modecaps for you if you initialize any 802.11a channels. This caused "ndis0: 11a rates:" to erroneously be displayed during driver load.) - Also in if_ndis.c, when using TESTSETRATE() to add in any missing 802.11b rates, remember to OR the rates with IEEE80211_RATE_BASIC, otherwise comparing against existing basic rates won't match. (1, 2, 5.5 and 11Mbps are basic rates, according to the 802.11b spec.) This erroneously cause 11Mbps to be added to the 11b rate list twice.
2004-06-04 04:43:36 +00:00
if (ic->ic_sup_rates[IEEE80211_MODE_11A].rs_nrates &&
i > 14)
In subr_ndis.c, when searching for keys in our make-pretend registry, make the key name matching case-insensitive. There are some drivers and .inf files that have mismatched cases, e.g. the driver will look for "AdhocBand" whereas the .inf file specifies a registry key to be created called "AdHocBand." The mismatch is probably a typo that went undetected (so much for QA), but since Windows seems to be case-insensitive, we should be too. In if_ndis.c, initialize rates and channels correctly so that specify frequences correctly when trying to set channels in the 5Ghz band, and so that 802.11b rates show up for some a/b/g cards (which otherwise appear to have no 802.11b modes). Also, when setting OID_802_11_CONFIGURATION in ndis_80211_setstate(), provide default values for the beacon interval, ATIM window and dwelltime. The Atheros "Aries" driver will crash if you try to select ad-hoc mode and leave the beacon interval set to 0: it blindly uses this value and does a division by 0 in the interrupt handler, causing an integer divide trap.
2004-05-29 06:41:17 +00:00
chanflag = IEEE80211_CHAN_A;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
if (chanflag == 0)
break;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
ic->ic_channels[i].ic_freq =
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
ieee80211_ieee2mhz(i, chanflag);
ic->ic_channels[i].ic_flags = chanflag;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
}
Re-do the handling of ndis_buffers. The NDIS_BUFFER structure is supposed to be opaque to the driver, however it is exposed through several macros which expect certain behavior. In my original implementation, I used the mappedsystemva member of the structure to hold a pointer to the buffer and bytecount to hold the length. It turns out you must use the startva pointer to point to the page containing the start of the buffer and set byteoffset to the offset within the page where the buffer starts. So, for a buffer with address 'baseva,' startva is baseva & ~(PAGE_SIZE -1) and byteoffset is baseva & (PAGE_SIZE -1). We have to maintain this convention everywhere that ndis_buffers are used. Fortunately, Microsoft defines some macros for initializing and manipulating NDIS_BUFFER structures in ntddk.h. I adapted some of them for use here and used them where appropriate. This fixes the discrepancy I observed between how RX'ed packet sizes were being reported in the Broadcom wireless driver and the sample ethernet drivers that I've tested. This should also help the Intel Centrino wireless driver work. Also try to properly initialize the 802.11 BSS and IBSS channels. (Sadly, the channel value is meaningless since there's no way in the existing NDIS API to get/set the channel, but this should take care of any 'invalid channel (NULL)' messages printed on the console.
2003-12-23 04:08:22 +00:00
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
i = sizeof(arg);
r = ndis_get_info(sc, OID_802_11_WEP_STATUS, &arg, &i);
if (arg != NDIS_80211_WEPSTAT_NOTSUPPORTED)
ic->ic_caps |= IEEE80211_C_WEP;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
i = sizeof(arg);
r = ndis_get_info(sc, OID_802_11_POWER_MODE, &arg, &i);
if (r == 0)
ic->ic_caps |= IEEE80211_C_PMGT;
bcopy(eaddr, &ic->ic_myaddr, sizeof(eaddr));
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
ieee80211_ifattach(ic);
ieee80211_media_init(ic, ieee80211_media_change,
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
ndis_media_status);
Continue my efforts to imitate Windows as closely as possible by attempting to duplicate Windows spinlocks. Windows spinlocks differ from FreeBSD spinlocks in the way they block preemption. FreeBSD spinlocks use critical_enter(), which masks off _all_ interrupts. This prevents any other threads from being scheduled, but it also prevents ISRs from running. In Windows, preemption is achieved by raising the processor IRQL to DISPATCH_LEVEL, which prevents other threads from preempting you, but does _not_ prevent device ISRs from running. (This is essentially what Solaris calls dispatcher locks.) The Windows spinlock itself (kspin_lock) is just an integer value which is atomically set when you acquire the lock and atomically cleared when you release it. FreeBSD doesn't have IRQ levels, so we have to cheat a little by using thread priorities: normal thread priority is PASSIVE_LEVEL, lowest interrupt thread priority is DISPATCH_LEVEL, highest thread priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL matter to us. The immediate benefit of all this is that I no longer have to rely on a mutex pool. Now, I'm sure many people will be seized by the urge to criticize me for doing an end run around our own spinlock implementation, but it makes more sense to do it this way. Well, it does to me anyway. Overview of the changes: - Properly implement hal_lock(), hal_unlock(), hal_irql(), hal_raise_irql() and hal_lower_irql() so that they more closely resemble their Windows counterparts. The IRQL is determined by thread priority. - Make ntoskrnl_lock_dpc() and ntoskrnl_unlock_dpc() do what they do in Windows, which is to atomically set/clear the lock value. These routines are designed to be called from DISPATCH_LEVEL, and are actually half of the work involved in acquiring/releasing spinlocks. - Add FASTCALL1(), FASTCALL2() and FASTCALL3() macros/wrappers that allow us to call a _fastcall function in spite of the fact that our version of gcc doesn't support __attribute__((__fastcall__)) yet. The macros take 1, 2 or 3 arguments, respectively. We need to call hal_lock(), hal_unlock() etc... ourselves, but can't really invoke the function directly. I could have just made the underlying functions native routines and put _fastcall wrappers around them for the benefit of Windows binaries, but that would create needless bloat. - Remove ndis_mtxpool and all references to it. We don't need it anymore. - Re-implement the NdisSpinLock routines so that they use hal_lock() and friends like they do in Windows. - Use the new spinlock methods for handling lookaside lists and linked list updates in place of the mutex locks that were there before. - Remove mutex locking from ndis_isr() and ndis_intrhand() since they're already called with ndis_intrmtx held in if_ndis.c. - Put ndis_destroy_lock() code under explicit #ifdef notdef/#endif. It turns out there are some drivers which stupidly free the memory in which their spinlocks reside before calling ndis_destroy_lock() on them (touch-after-free bug). The ADMtek wireless driver is guilty of this faux pas. (Why this doesn't clobber Windows I have no idea.) - Make NdisDprAcquireSpinLock() and NdisDprReleaseSpinLock() into real functions instead of aliasing them to NdisAcaquireSpinLock() and NdisReleaseSpinLock(). The Dpr routines use KeAcquireSpinLockAtDpcLevel() level and KeReleaseSpinLockFromDpcLevel(), which acquires the lock without twiddling the IRQL. - In ndis_linksts_done(), do _not_ call ndis_80211_getstate(). Some drivers may call the status/status done callbacks as the result of setting an OID: ndis_80211_getstate() gets OIDs, which means we might cause the driver to recursively access some of its internal structures unexpectedly. The ndis_ticktask() routine will call ndis_80211_getstate() for us eventually anyway. - Fix the channel setting code a little in ndis_80211_setstate(), and initialize the channel to IEEE80211_CHAN_ANYC. (The Microsoft spec says you're not supposed to twiddle the channel in BSS mode; I may need to enforce this later.) This fixes the problems I was having with the ADMtek adm8211 driver: we were setting the channel to a non-standard default, which would cause it to fail to associate in BSS mode. - Use hal_raise_irql() to raise our IRQL to DISPATCH_LEVEL when calling certain miniport routines, per the Microsoft documentation. I think that's everything. Hopefully, other than fixing the ADMtek driver, there should be no apparent change in behavior.
2004-04-14 07:48:03 +00:00
ic->ic_ibss_chan = IEEE80211_CHAN_ANYC;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
ic->ic_bss->ni_chan = ic->ic_ibss_chan;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
} else {
ifmedia_init(&sc->ifmedia, IFM_IMASK, ndis_ifmedia_upd,
ndis_ifmedia_sts);
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_10_T, 0, NULL);
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_10_T|IFM_FDX, 0, NULL);
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_100_TX, 0, NULL);
ifmedia_add(&sc->ifmedia,
IFM_ETHER|IFM_100_TX|IFM_FDX, 0, NULL);
ifmedia_add(&sc->ifmedia, IFM_ETHER|IFM_AUTO, 0, NULL);
ifmedia_set(&sc->ifmedia, IFM_ETHER|IFM_AUTO);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
ether_ifattach(ifp, eaddr);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
}
/* Override the status handler so we can detect link changes. */
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
sc->ndis_block->nmb_status_func = ndis_linksts_wrap;
sc->ndis_block->nmb_statusdone_func = ndis_linksts_done_wrap;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
fail:
if (error)
ndis_detach(dev);
- The MiniportReset() function can return NDIS_STATUS_PENDING, in which case we should wait for the resetdone handler to be called before returning. - When providing resources via ndis_query_resources(), uses the computed rsclen when using bcopy() to copy out the resource data rather than the caller-supplied buffer length. - Avoid using ndis_reset_nic() in if_ndis.c unless we really need to reset the NIC because of a problem. - Allow interrupts to be fielded during ndis_attach(), at least as far as allowing ndis_isr() and ndis_intrhand() to run. - Use ndis_80211_rates_ex when probing for supported rates. Technically, this isn't supposed to work since, although Microsoft added the extended rate structure with the NDIS 5.1 update, the spec still says that the OID_802_11_SUPPORTED_RATES OID uses ndis_80211_rates. In spite of this, it appears some drivers use it anyway. - When adding in our guessed rates, check to see if they already exist so that we avoid any duplicates. - Add a printf() to ndis_open_file() that alerts the user when a driver attempts to open a file under /compat/ndis. With these changes, I can get the driver for the SMC 2802W 54g PCI card to load and run. This board uses a Prism54G chip. Note that in order for this driver to work, you must place the supplied smc2802w.arm firmware image under /compat/ndis. (The firmware is not resident on the device.) Note that this should also allow the 3Com 3CRWE154G72 card to work as well; as far as I can tell, these cards also use a Prism54G chip.
2004-04-05 08:26:52 +00:00
else
- Add pe_get_message() and pe_get_messagetable() for processing the RT_MESSAGETABLE resources that some driver binaries have. This allows us to print error messages in ndis_syslog(). - Correct the implementation of InterlockedIncrement() and InterlockedDecrement() -- they return uint32_t, not void. - Correct the declarations of the 64-bit arithmetic shift routines in subr_ntoskrnl.c (_allshr, allshl, etc...). These do not follow the _stdcall convention: instead, they appear to be __attribute__((regparm(3)). - Change the implementation of KeInitializeSpinLock(). There is no complementary KeFreeSpinLock() function, so creating a new mutex on each call to KeInitializeSpinLock() leaks resources when a driver is unloaded. For now, KeInitializeSpinLock() returns a handle to the ntoskrnl interlock mutex. - Use a driver's MiniportDisableInterrupt() and MiniportEnableInterrupt() routines if they exist. I'm not sure if I'm doing this right yet, but at the very least this shouldn't break any currently working drivers, and it makes the Intel PRO/1000 driver work. - In ndis_register_intr(), save some state that might be needed later, and save a pointer to the driver's interrupt structure in the ndis_miniport_block. - Save a pointer to the driver image for use by ndis_syslog() when it calls pe_get_message().
2004-01-06 07:09:26 +00:00
/* We're done talking to the NIC for now; halt it. */
ndis_halt_nic(sc);
- In ndis_intr(), don't do any interrupt processing if the IFF_UP flag isn't set. - In ndis_attach(), halt the NIC before exiting the routine. Calling ndis_init() will bring it up again, and we don't want it running (and potentially generating interrupts) until we're ready to deal with it.
2003-12-25 09:44:49 +00:00
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return(error);
}
/*
* Shutdown hardware and free up resources. This can be called any
* time after the mutex has been initialized. It is called in both
* the error case in attach and the normal detach case so it needs
* to be careful about only freeing resources that have actually been
* allocated.
*/
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
int
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
ndis_detach(dev)
device_t dev;
{
Re-do the handling of ndis_buffers. The NDIS_BUFFER structure is supposed to be opaque to the driver, however it is exposed through several macros which expect certain behavior. In my original implementation, I used the mappedsystemva member of the structure to hold a pointer to the buffer and bytecount to hold the length. It turns out you must use the startva pointer to point to the page containing the start of the buffer and set byteoffset to the offset within the page where the buffer starts. So, for a buffer with address 'baseva,' startva is baseva & ~(PAGE_SIZE -1) and byteoffset is baseva & (PAGE_SIZE -1). We have to maintain this convention everywhere that ndis_buffers are used. Fortunately, Microsoft defines some macros for initializing and manipulating NDIS_BUFFER structures in ntddk.h. I adapted some of them for use here and used them where appropriate. This fixes the discrepancy I observed between how RX'ed packet sizes were being reported in the Broadcom wireless driver and the sample ethernet drivers that I've tested. This should also help the Intel Centrino wireless driver work. Also try to properly initialize the 802.11 BSS and IBSS channels. (Sadly, the channel value is meaningless since there's no way in the existing NDIS API to get/set the channel, but this should take care of any 'invalid channel (NULL)' messages printed on the console.
2003-12-23 04:08:22 +00:00
struct ndis_softc *sc;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
struct ifnet *ifp;
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
driver_object *drv;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sc = device_get_softc(dev);
Correct KASSERT()s that check for initialization of mutexes in ndis_detach(), which are different now that I'm not using mutex pools anymore. Noticed by: des
2004-04-23 17:15:14 +00:00
KASSERT(mtx_initialized(&sc->ndis_mtx),
Correct KASSERT() in ndis_destroy(): ndis_mtx is a pointer now. Also add KASSERT() for ndis_intrmtx().
2004-01-25 00:13:07 +00:00
("ndis mutex not initialized"));
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
NDIS_LOCK(sc);
ifp = &sc->arpcom.ac_if;
- In ndis_intr(), don't do any interrupt processing if the IFF_UP flag isn't set. - In ndis_attach(), halt the NIC before exiting the routine. Calling ndis_init() will bring it up again, and we don't want it running (and potentially generating interrupts) until we're ready to deal with it.
2003-12-25 09:44:49 +00:00
ifp->if_flags &= ~IFF_UP;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
if (device_is_attached(dev)) {
NDIS_UNLOCK(sc);
ndis_stop(sc);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
if (sc->ndis_80211)
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
ieee80211_ifdetach(&sc->ic);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
else
ether_ifdetach(ifp);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
} else
NDIS_UNLOCK(sc);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
bus_generic_detach(dev);
if (sc->ndis_intrhand)
bus_teardown_intr(dev, sc->ndis_irq, sc->ndis_intrhand);
if (sc->ndis_irq)
bus_release_resource(dev, SYS_RES_IRQ, 0, sc->ndis_irq);
if (sc->ndis_res_io)
bus_release_resource(dev, SYS_RES_IOPORT,
sc->ndis_io_rid, sc->ndis_res_io);
if (sc->ndis_res_mem)
bus_release_resource(dev, SYS_RES_MEMORY,
sc->ndis_mem_rid, sc->ndis_res_mem);
Rework resource allocation. Replace the "feel around like a blind man" method with something a little more intelligent: use BUS_GET_RESOURCE_LIST() to run through all resources allocated to us and map them as needed. This way we know exactly what resources need to be mapped and what their RIDs are without having to guess. This simplifies both ndis_attach() and ndis_convert_res(), and eliminates the unfriendly "ndisX: couldn't map <foo>" messages that are sometimes emitted during driver load.
2003-12-29 23:51:59 +00:00
if (sc->ndis_res_altmem)
bus_release_resource(dev, SYS_RES_MEMORY,
sc->ndis_altmem_rid, sc->ndis_res_altmem);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Add some minor changes related to PCMCIA attribute memory mapping (which I apparently forgot to commit earlier). Acquire NDIS_LOCK() in ndis_linksts_done().
2004-08-01 06:42:44 +00:00
if (sc->ndis_iftype == PCMCIABus)
ndis_free_amem(sc);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
if (sc->ndis_sc)
ndis_destroy_dma(sc);
Minor cleanups: - Fix typo in comment - Remember to free() sc->ndis_txarray on detach - Remember to do an ifmedia_removeall() for ethernet devices
2004-08-03 17:00:39 +00:00
if (sc->ndis_txarray)
free(sc->ndis_txarray, M_DEVBUF);
if (!sc->ndis_80211)
ifmedia_removeall(&sc->ifmedia);
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
if (sc->ndis_txpool != NULL)
NdisFreePacketPool(sc->ndis_txpool);
Fix compilation and correct mapping from struct ifnet to struct ieee80211com after net80211 import. Submitted by: Tor Egge
2004-12-10 00:59:27 +00:00
ndis_unload_driver(sc);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
/* Destroy the PDO for this device. */
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
if (sc->ndis_iftype == PCIBus)
Use 0 instead if NULL for vm_offset_t argument to windrv_lookup() to silence compiler warnings.
2005-02-28 16:47:54 +00:00
drv = windrv_lookup(0, "PCI Bus");
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
else if (sc->ndis_iftype == PCMCIABus)
Use 0 instead if NULL for vm_offset_t argument to windrv_lookup() to silence compiler warnings.
2005-02-28 16:47:54 +00:00
drv = windrv_lookup(0, "PCCARD Bus");
- Correct one aspect of the driver_object/device_object/IRP framework: when we create a PDO, the driver_object associated with it is that of the parent driver, not the driver we're trying to attach. For example, if we attach a PCI device, the PDO we pass to the NdisAddDevice() function should contain a pointer to fake_pci_driver, not to the NDIS driver itself. For PCI or PCMCIA devices this doesn't matter because the child never needs to talk to the parent bus driver, but for USB, the child needs to be able to send IRPs to the parent USB bus driver, and for that to work the parent USB bus driver has to be hung off the PDO. This involves modifying windrv_lookup() so that we can search for bus drivers by name, if necessary. Our fake bus drivers attach themselves as "PCI Bus," "PCCARD Bus" and "USB Bus," so we can search for them using those names. The individual attachment stubs now create and attach PDOs to the parent bus drivers instead of hanging them off the NDIS driver's object, and in if_ndis.c, we now search for the correct driver object depending on the bus type, and use that to find the correct PDO. With this fix, I can get my sample USB ethernet driver to deliver an IRP to my fake parent USB bus driver's dispatch routines. - Add stub modules for USB support: subr_usbd.c, usbd_var.h and if_ndis_usb.c. The subr_usbd.c module is hooked up the build but currently doesn't do very much. It provides the stub USB parent driver object and a dispatch routine for IRM_MJ_INTERNAL_DEVICE_CONTROL. The only exported function at the moment is USBD_GetUSBDIVersion(). The if_ndis_usb.c stub compiles, but is not hooked up to the build yet. I'm putting these here so I can keep them under source code control as I flesh them out.
2005-02-24 21:49:14 +00:00
else
Use 0 instead if NULL for vm_offset_t argument to windrv_lookup() to silence compiler warnings.
2005-02-28 16:47:54 +00:00
drv = windrv_lookup(0, "USB Bus");
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
if (drv == NULL)
panic("couldn't find driver object");
windrv_destroy_pdo(drv, dev);
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
if (sc->ndis_iftype == PCIBus)
bus_dma_tag_destroy(sc->ndis_parent_tag);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Take advantage of the dev sysctl tree. Approved by: wpaul
2004-06-04 22:24:46 +00:00
#if __FreeBSD_version < 502113
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sysctl_ctx_free(&sc->ndis_ctx);
Take advantage of the dev sysctl tree. Approved by: wpaul
2004-06-04 22:24:46 +00:00
#endif
Minor cleanups: - Fix typo in comment - Remember to free() sc->ndis_txarray on detach - Remember to do an ifmedia_removeall() for ethernet devices
2004-08-03 17:00:39 +00:00
Continue my efforts to imitate Windows as closely as possible by attempting to duplicate Windows spinlocks. Windows spinlocks differ from FreeBSD spinlocks in the way they block preemption. FreeBSD spinlocks use critical_enter(), which masks off _all_ interrupts. This prevents any other threads from being scheduled, but it also prevents ISRs from running. In Windows, preemption is achieved by raising the processor IRQL to DISPATCH_LEVEL, which prevents other threads from preempting you, but does _not_ prevent device ISRs from running. (This is essentially what Solaris calls dispatcher locks.) The Windows spinlock itself (kspin_lock) is just an integer value which is atomically set when you acquire the lock and atomically cleared when you release it. FreeBSD doesn't have IRQ levels, so we have to cheat a little by using thread priorities: normal thread priority is PASSIVE_LEVEL, lowest interrupt thread priority is DISPATCH_LEVEL, highest thread priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL matter to us. The immediate benefit of all this is that I no longer have to rely on a mutex pool. Now, I'm sure many people will be seized by the urge to criticize me for doing an end run around our own spinlock implementation, but it makes more sense to do it this way. Well, it does to me anyway. Overview of the changes: - Properly implement hal_lock(), hal_unlock(), hal_irql(), hal_raise_irql() and hal_lower_irql() so that they more closely resemble their Windows counterparts. The IRQL is determined by thread priority. - Make ntoskrnl_lock_dpc() and ntoskrnl_unlock_dpc() do what they do in Windows, which is to atomically set/clear the lock value. These routines are designed to be called from DISPATCH_LEVEL, and are actually half of the work involved in acquiring/releasing spinlocks. - Add FASTCALL1(), FASTCALL2() and FASTCALL3() macros/wrappers that allow us to call a _fastcall function in spite of the fact that our version of gcc doesn't support __attribute__((__fastcall__)) yet. The macros take 1, 2 or 3 arguments, respectively. We need to call hal_lock(), hal_unlock() etc... ourselves, but can't really invoke the function directly. I could have just made the underlying functions native routines and put _fastcall wrappers around them for the benefit of Windows binaries, but that would create needless bloat. - Remove ndis_mtxpool and all references to it. We don't need it anymore. - Re-implement the NdisSpinLock routines so that they use hal_lock() and friends like they do in Windows. - Use the new spinlock methods for handling lookaside lists and linked list updates in place of the mutex locks that were there before. - Remove mutex locking from ndis_isr() and ndis_intrhand() since they're already called with ndis_intrmtx held in if_ndis.c. - Put ndis_destroy_lock() code under explicit #ifdef notdef/#endif. It turns out there are some drivers which stupidly free the memory in which their spinlocks reside before calling ndis_destroy_lock() on them (touch-after-free bug). The ADMtek wireless driver is guilty of this faux pas. (Why this doesn't clobber Windows I have no idea.) - Make NdisDprAcquireSpinLock() and NdisDprReleaseSpinLock() into real functions instead of aliasing them to NdisAcaquireSpinLock() and NdisReleaseSpinLock(). The Dpr routines use KeAcquireSpinLockAtDpcLevel() level and KeReleaseSpinLockFromDpcLevel(), which acquires the lock without twiddling the IRQL. - In ndis_linksts_done(), do _not_ call ndis_80211_getstate(). Some drivers may call the status/status done callbacks as the result of setting an OID: ndis_80211_getstate() gets OIDs, which means we might cause the driver to recursively access some of its internal structures unexpectedly. The ndis_ticktask() routine will call ndis_80211_getstate() for us eventually anyway. - Fix the channel setting code a little in ndis_80211_setstate(), and initialize the channel to IEEE80211_CHAN_ANYC. (The Microsoft spec says you're not supposed to twiddle the channel in BSS mode; I may need to enforce this later.) This fixes the problems I was having with the ADMtek adm8211 driver: we were setting the channel to a non-standard default, which would cause it to fail to associate in BSS mode. - Use hal_raise_irql() to raise our IRQL to DISPATCH_LEVEL when calling certain miniport routines, per the Microsoft documentation. I think that's everything. Hopefully, other than fixing the ADMtek driver, there should be no apparent change in behavior.
2004-04-14 07:48:03 +00:00
mtx_destroy(&sc->ndis_mtx);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return(0);
}
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
int
Add suspend and resume methods. I'm not certain this work correctly since I can't easily test them on my laptop right now, but they should do the right thing.
2004-01-22 03:00:59 +00:00
ndis_suspend(dev)
device_t dev;
{
struct ndis_softc *sc;
struct ifnet *ifp;
sc = device_get_softc(dev);
ifp = &sc->arpcom.ac_if;
Use the OID_802_11_CONFIGURATION OID when deciding if the underlying driver is for an 802.11 device or not. At least one driver I have does not support the OID_802_11_NETWORK_TYPES_SUPPORTED OID. Also, for now, don't do anything special in the ndis_suspend() method. I originally wanted to shut down the NIC but leave the IFF_UP flag alone since technically the interface is meant to remain up, but an interrupt may be delivered to the ISR on suspend, and if this happens while the NIC is halted, we will crash, since none of the miniport driver methods will function. This needs to be dealt with properly later, but for now this prevents a panic, and the resume method properly re-inits the NIC.
2004-02-01 21:35:15 +00:00
#ifdef notdef
Fix two problems: - In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags used for shared memory allocations with a lowaddr of 0x3E7FFFFF. This forces the buffers to be mapped to physical/bus addresses within the first 1GB of physical memory. It seems that at least one card (Linksys Instant Wireless PCI V2.7) depends on this behavior. I don't know if this is a hardware restriction, or if the NDIS driver for this card is truncating the addresses itself, but using physical/bus addresses beyong the 1GB limit causes initialization failures. - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in if_ndis.c to test whether the device has been initialized rather than checking for the presence of the IFF_UP flag in if_flags. While debugging the previous problem, I noticed that bringing up the device would always produce failures from ndis_setmulti(). It turns out that the following steps now occur during device initialization: - IFF_UP flag is set in if_flags - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) - ifp->if_ioctl() called with SIOCADDMULTI - ifp->if_ioctl() called with SIOCADDMULTI (again) - ifp->if_ioctl() called with SIOCADDMULTI (yet again) - ifp->if_ioctl() called with SIOCSIFFLAGS Setting the receive filter and multicast filters can only be done when the underlying NDIS driver has been initialized, which is done by ifp->if_init(). However, we don't call ifp->if_init() until ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been set. It appears that now, the network stack tries to add multicast addresses to interface's filter before those steps occur. Normally, ndis_setmulti() would trap this condition by checking for the IFF_UP flag, but the network code has in fact set this flag already, so ndis_setmulti() is fooled into thinking the interface has been initialized when it really hasn't. It turns out this is usually harmless because the ifp->if_init() routine (in this case ndis_init()) will set up the multicast filter when it initializes the hardware anyway, and the underlying routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC haven't been initialized yet, but you end up spurious error messages on the console all the time. Something tells me this new behavior isn't really correct. I think the intention was to fix it so that ifp->if_init() is only called once when we ifconfig an interface up, but the end result seems a little bogus: the change of the IFF_UP flag should be propagated down to the driver before calling any other ioctl() that might actually require the hardware to be up and running.
2004-07-07 17:46:30 +00:00
if (NDIS_INITIALIZED(sc))
Add suspend and resume methods. I'm not certain this work correctly since I can't easily test them on my laptop right now, but they should do the right thing.
2004-01-22 03:00:59 +00:00
ndis_stop(sc);
Use the OID_802_11_CONFIGURATION OID when deciding if the underlying driver is for an 802.11 device or not. At least one driver I have does not support the OID_802_11_NETWORK_TYPES_SUPPORTED OID. Also, for now, don't do anything special in the ndis_suspend() method. I originally wanted to shut down the NIC but leave the IFF_UP flag alone since technically the interface is meant to remain up, but an interrupt may be delivered to the ISR on suspend, and if this happens while the NIC is halted, we will crash, since none of the miniport driver methods will function. This needs to be dealt with properly later, but for now this prevents a panic, and the resume method properly re-inits the NIC.
2004-02-01 21:35:15 +00:00
#endif
Add suspend and resume methods. I'm not certain this work correctly since I can't easily test them on my laptop right now, but they should do the right thing.
2004-01-22 03:00:59 +00:00
return(0);
}
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
int
Add suspend and resume methods. I'm not certain this work correctly since I can't easily test them on my laptop right now, but they should do the right thing.
2004-01-22 03:00:59 +00:00
ndis_resume(dev)
device_t dev;
{
struct ndis_softc *sc;
struct ifnet *ifp;
sc = device_get_softc(dev);
ifp = &sc->arpcom.ac_if;
Fix two problems: - In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags used for shared memory allocations with a lowaddr of 0x3E7FFFFF. This forces the buffers to be mapped to physical/bus addresses within the first 1GB of physical memory. It seems that at least one card (Linksys Instant Wireless PCI V2.7) depends on this behavior. I don't know if this is a hardware restriction, or if the NDIS driver for this card is truncating the addresses itself, but using physical/bus addresses beyong the 1GB limit causes initialization failures. - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in if_ndis.c to test whether the device has been initialized rather than checking for the presence of the IFF_UP flag in if_flags. While debugging the previous problem, I noticed that bringing up the device would always produce failures from ndis_setmulti(). It turns out that the following steps now occur during device initialization: - IFF_UP flag is set in if_flags - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) - ifp->if_ioctl() called with SIOCADDMULTI - ifp->if_ioctl() called with SIOCADDMULTI (again) - ifp->if_ioctl() called with SIOCADDMULTI (yet again) - ifp->if_ioctl() called with SIOCSIFFLAGS Setting the receive filter and multicast filters can only be done when the underlying NDIS driver has been initialized, which is done by ifp->if_init(). However, we don't call ifp->if_init() until ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been set. It appears that now, the network stack tries to add multicast addresses to interface's filter before those steps occur. Normally, ndis_setmulti() would trap this condition by checking for the IFF_UP flag, but the network code has in fact set this flag already, so ndis_setmulti() is fooled into thinking the interface has been initialized when it really hasn't. It turns out this is usually harmless because the ifp->if_init() routine (in this case ndis_init()) will set up the multicast filter when it initializes the hardware anyway, and the underlying routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC haven't been initialized yet, but you end up spurious error messages on the console all the time. Something tells me this new behavior isn't really correct. I think the intention was to fix it so that ifp->if_init() is only called once when we ifconfig an interface up, but the end result seems a little bogus: the change of the IFF_UP flag should be propagated down to the driver before calling any other ioctl() that might actually require the hardware to be up and running.
2004-07-07 17:46:30 +00:00
if (NDIS_INITIALIZED(sc))
Add suspend and resume methods. I'm not certain this work correctly since I can't easily test them on my laptop right now, but they should do the right thing.
2004-01-22 03:00:59 +00:00
ndis_init(sc);
return(0);
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/*
* A frame has been uploaded: pass the resulting mbuf chain up to
* the higher level protocols.
Attempt to handle the status field in the ndis_packet oob area correctly. For received packets, an status of NDIS_STATUS_RESOURCES means we need to copy the packet data and return the ndis_packet to the driver immediatel. NDIS_STATUS_SUCCESS means we get to hold onto the packet, but we have to set the status to NDIS_STATUS_PENDING so the driver knows we're going to hang onto it for a while. For transmit packets, NDIS_STATUS_PENDING means the driver will asynchronously return the packet to us via the ndis_txeof() routine, and NDIS_STATUS_SUCCESS means the driver sent the frame, and NDIS (i.e. the OS) retains ownership of the packet and can free it right away.
2003-12-26 07:01:05 +00:00
*
* When handling received NDIS packets, the 'status' field in the
* out-of-band portion of the ndis_packet has special meaning. In the
* most common case, the underlying NDIS driver will set this field
* to NDIS_STATUS_SUCCESS, which indicates that it's ok for us to
* take posession of it. We then change the status field to
* NDIS_STATUS_PENDING to tell the driver that we now own the packet,
* and that we will return it at some point in the future via the
* return packet handler.
*
* If the driver hands us a packet with a status of NDIS_STATUS_RESOURCES,
* this means the driver is running out of packet/buffer resources and
* wants to maintain ownership of the packet. In this case, we have to
* copy the packet data into local storage and let the driver keep the
* packet.
Fix the problem with the Cisco Aironet 340 PCMCIA card. Most newer drivers for Windows are deserialized miniports. Such drivers maintain their own queues and do their own locking. This particular driver is not deserialized though, and we need special support to handle it correctly. Typically, in the ndis_rxeof() handler, we pass all incoming packets directly to (*ifp->if_input)(). This in turn may cause another thread to run and preempt us, and the packet may actually be processed and then released before we even exit the ndis_rxeof() routine. The problem with this is that releasing a packet calls the ndis_return_packet() function, which hands the packet and its buffers back to the driver. Calling ndis_return_packet() before ndis_rxeof() returns will screw up the driver's internal queues since, not being deserialized, it does no locking. To avoid this problem, if we detect a serialized driver (by checking the attribute flags passed to NdisSetAttributesEx(), we use an alternate ndis_rxeof() handler, ndis_rxeof_serial(), which puts the call to (*ifp->if_input)() on the NDIS SWI work queue. This guarantees the packet won't be processed until after ndis_rxeof_serial() returns. Note that another approach is to always copy the packet data into another mbuf and just let the driver retain ownership of the ndis_packet structure (ndis_return_packet() never needs to be called in this case). I'm not sure which method is faster.
2004-03-11 09:40:00 +00:00
*/
__stdcall static void
Fix the problems people have been having with the Intel 2100B Centrino wireless ever since I added the new spinlock code. Previously, I added a special ndis_rxeof_serial() function to insure that when we receive a packet, we never end up calling the MiniportReturnPacket() routine until after the receive handler has finished. I set things up so that ndis_rxeof_serial() would only be used for serialized miniports since they depend on this property. Well, it turns out deserialized miniports depend on a similar property: you can't let MiniportReturnPacket() be called from the same context as the receive handler at all. The 2100B driver happens to use a single spinlock for all of its synchronization, and it tries to acquire it both while in MiniportHandleInterrupt() and in MiniportReturnPacket(), so if we call MiniportReturnPacket() from the MiniportHandleInterrupt() context, we will end up trying to acquire the spinlock recursively, which you can't do. To fix this, I made the ndis_rxeof_serial() handler the default. An alternate solution would be to make ndis_return_packet() submit the call to MiniportReturnPacket() to the NDIS task queue thread. I may do that in the future, after I've tested things a bit more.
2004-04-21 02:29:28 +00:00
ndis_rxeof(adapter, packets, pktcnt)
Fix the problem with the Cisco Aironet 340 PCMCIA card. Most newer drivers for Windows are deserialized miniports. Such drivers maintain their own queues and do their own locking. This particular driver is not deserialized though, and we need special support to handle it correctly. Typically, in the ndis_rxeof() handler, we pass all incoming packets directly to (*ifp->if_input)(). This in turn may cause another thread to run and preempt us, and the packet may actually be processed and then released before we even exit the ndis_rxeof() routine. The problem with this is that releasing a packet calls the ndis_return_packet() function, which hands the packet and its buffers back to the driver. Calling ndis_return_packet() before ndis_rxeof() returns will screw up the driver's internal queues since, not being deserialized, it does no locking. To avoid this problem, if we detect a serialized driver (by checking the attribute flags passed to NdisSetAttributesEx(), we use an alternate ndis_rxeof() handler, ndis_rxeof_serial(), which puts the call to (*ifp->if_input)() on the NDIS SWI work queue. This guarantees the packet won't be processed until after ndis_rxeof_serial() returns. Note that another approach is to always copy the packet data into another mbuf and just let the driver retain ownership of the ndis_packet structure (ndis_return_packet() never needs to be called in this case). I'm not sure which method is faster.
2004-03-11 09:40:00 +00:00
ndis_handle adapter;
ndis_packet **packets;
uint32_t pktcnt;
{
struct ndis_softc *sc;
ndis_miniport_block *block;
ndis_packet *p;
uint32_t s;
ndis_tcpip_csum *csum;
struct ifnet *ifp;
struct mbuf *m0, *m;
int i;
block = (ndis_miniport_block *)adapter;
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
sc = device_get_softc(block->nmb_physdeviceobj->do_devext);
ifp = &sc->arpcom.ac_if;
Fix the problem with the Cisco Aironet 340 PCMCIA card. Most newer drivers for Windows are deserialized miniports. Such drivers maintain their own queues and do their own locking. This particular driver is not deserialized though, and we need special support to handle it correctly. Typically, in the ndis_rxeof() handler, we pass all incoming packets directly to (*ifp->if_input)(). This in turn may cause another thread to run and preempt us, and the packet may actually be processed and then released before we even exit the ndis_rxeof() routine. The problem with this is that releasing a packet calls the ndis_return_packet() function, which hands the packet and its buffers back to the driver. Calling ndis_return_packet() before ndis_rxeof() returns will screw up the driver's internal queues since, not being deserialized, it does no locking. To avoid this problem, if we detect a serialized driver (by checking the attribute flags passed to NdisSetAttributesEx(), we use an alternate ndis_rxeof() handler, ndis_rxeof_serial(), which puts the call to (*ifp->if_input)() on the NDIS SWI work queue. This guarantees the packet won't be processed until after ndis_rxeof_serial() returns. Note that another approach is to always copy the packet data into another mbuf and just let the driver retain ownership of the ndis_packet structure (ndis_return_packet() never needs to be called in this case). I'm not sure which method is faster.
2004-03-11 09:40:00 +00:00
for (i = 0; i < pktcnt; i++) {
p = packets[i];
/* Stash the softc here so ptom can use it. */
p->np_softc = sc;
if (ndis_ptom(&m0, p)) {
device_printf (sc->ndis_dev, "ptom failed\n");
if (p->np_oob.npo_status == NDIS_STATUS_SUCCESS)
ndis_return_packet(sc, p);
} else {
if (p->np_oob.npo_status == NDIS_STATUS_RESOURCES) {
m = m_dup(m0, M_DONTWAIT);
/*
* NOTE: we want to destroy the mbuf here, but
* we don't actually want to return it to the
* driver via the return packet handler. By
* bumping np_refcnt, we can prevent the
* ndis_return_packet() routine from actually
* doing anything.
*/
p->np_refcnt++;
m_freem(m0);
if (m == NULL)
ifp->if_ierrors++;
else
m0 = m;
} else
p->np_oob.npo_status = NDIS_STATUS_PENDING;
m0->m_pkthdr.rcvif = ifp;
Ok, _really_ fix the Intel 2100B Centrino deadlock problems this time. (I hope.) My original instinct to make ndis_return_packet() asynchronous was correct. Making ndis_rxeof() submit packets to the stack asynchronously fixes one recursive spinlock acquisition, but it's also possible for it to happen via the ndis_txeof() path too. So: - In if_ndis.c, revert ndis_rxeof() to its old behavior (and don't bother putting ndis_rxeof_serial() back since we don't need it anymore). - In kern_ndis.c, make ndis_return_packet() submit the call to the MiniportReturnPacket() function to the "ndis swi" thread so that it always happens in another context no matter who calls it.
2004-04-22 07:08:39 +00:00
ifp->if_ipackets++;
Fix the problem with the Cisco Aironet 340 PCMCIA card. Most newer drivers for Windows are deserialized miniports. Such drivers maintain their own queues and do their own locking. This particular driver is not deserialized though, and we need special support to handle it correctly. Typically, in the ndis_rxeof() handler, we pass all incoming packets directly to (*ifp->if_input)(). This in turn may cause another thread to run and preempt us, and the packet may actually be processed and then released before we even exit the ndis_rxeof() routine. The problem with this is that releasing a packet calls the ndis_return_packet() function, which hands the packet and its buffers back to the driver. Calling ndis_return_packet() before ndis_rxeof() returns will screw up the driver's internal queues since, not being deserialized, it does no locking. To avoid this problem, if we detect a serialized driver (by checking the attribute flags passed to NdisSetAttributesEx(), we use an alternate ndis_rxeof() handler, ndis_rxeof_serial(), which puts the call to (*ifp->if_input)() on the NDIS SWI work queue. This guarantees the packet won't be processed until after ndis_rxeof_serial() returns. Note that another approach is to always copy the packet data into another mbuf and just let the driver retain ownership of the ndis_packet structure (ndis_return_packet() never needs to be called in this case). I'm not sure which method is faster.
2004-03-11 09:40:00 +00:00
/* Deal with checksum offload. */
if (ifp->if_capenable & IFCAP_RXCSUM &&
p->np_ext.npe_info[ndis_tcpipcsum_info] != NULL) {
s = (uintptr_t)
p->np_ext.npe_info[ndis_tcpipcsum_info];
csum = (ndis_tcpip_csum *)&s;
if (csum->u.ntc_rxflags &
NDIS_RXCSUM_IP_PASSED)
m0->m_pkthdr.csum_flags |=
CSUM_IP_CHECKED|CSUM_IP_VALID;
if (csum->u.ntc_rxflags &
(NDIS_RXCSUM_TCP_PASSED |
NDIS_RXCSUM_UDP_PASSED)) {
m0->m_pkthdr.csum_flags |=
CSUM_DATA_VALID|CSUM_PSEUDO_HDR;
m0->m_pkthdr.csum_data = 0xFFFF;
}
}
Ok, _really_ fix the Intel 2100B Centrino deadlock problems this time. (I hope.) My original instinct to make ndis_return_packet() asynchronous was correct. Making ndis_rxeof() submit packets to the stack asynchronously fixes one recursive spinlock acquisition, but it's also possible for it to happen via the ndis_txeof() path too. So: - In if_ndis.c, revert ndis_rxeof() to its old behavior (and don't bother putting ndis_rxeof_serial() back since we don't need it anymore). - In kern_ndis.c, make ndis_return_packet() submit the call to the MiniportReturnPacket() function to the "ndis swi" thread so that it always happens in another context no matter who calls it.
2004-04-22 07:08:39 +00:00
(*ifp->if_input)(ifp, m0);
Fix the problem with the Cisco Aironet 340 PCMCIA card. Most newer drivers for Windows are deserialized miniports. Such drivers maintain their own queues and do their own locking. This particular driver is not deserialized though, and we need special support to handle it correctly. Typically, in the ndis_rxeof() handler, we pass all incoming packets directly to (*ifp->if_input)(). This in turn may cause another thread to run and preempt us, and the packet may actually be processed and then released before we even exit the ndis_rxeof() routine. The problem with this is that releasing a packet calls the ndis_return_packet() function, which hands the packet and its buffers back to the driver. Calling ndis_return_packet() before ndis_rxeof() returns will screw up the driver's internal queues since, not being deserialized, it does no locking. To avoid this problem, if we detect a serialized driver (by checking the attribute flags passed to NdisSetAttributesEx(), we use an alternate ndis_rxeof() handler, ndis_rxeof_serial(), which puts the call to (*ifp->if_input)() on the NDIS SWI work queue. This guarantees the packet won't be processed until after ndis_rxeof_serial() returns. Note that another approach is to always copy the packet data into another mbuf and just let the driver retain ownership of the ndis_packet structure (ndis_return_packet() never needs to be called in this case). I'm not sure which method is faster.
2004-03-11 09:40:00 +00:00
}
}
return;
}
Ok, _really_ fix the Intel 2100B Centrino deadlock problems this time. (I hope.) My original instinct to make ndis_return_packet() asynchronous was correct. Making ndis_rxeof() submit packets to the stack asynchronously fixes one recursive spinlock acquisition, but it's also possible for it to happen via the ndis_txeof() path too. So: - In if_ndis.c, revert ndis_rxeof() to its old behavior (and don't bother putting ndis_rxeof_serial() back since we don't need it anymore). - In kern_ndis.c, make ndis_return_packet() submit the call to the MiniportReturnPacket() function to the "ndis swi" thread so that it always happens in another context no matter who calls it.
2004-04-22 07:08:39 +00:00
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/*
* A frame was downloaded to the chip. It's safe for us to clean up
* the list buffers.
*/
__stdcall static void
ndis_txeof(adapter, packet, status)
ndis_handle adapter;
ndis_packet *packet;
ndis_status status;
{
struct ndis_softc *sc;
ndis_miniport_block *block;
struct ifnet *ifp;
int idx;
Rework mbuf<->ndis_packet/ndis_packet<->mbuf translation a little to make it more robust. This should fix problems with crashes under heavy traffic loads that have been reported. Also add a 'query done' callback handler to satisfy the e100bex.sys sample Intel driver.
2003-12-14 21:31:32 +00:00
struct mbuf *m;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
block = (ndis_miniport_block *)adapter;
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
sc = device_get_softc(block->nmb_physdeviceobj->do_devext);
ifp = &sc->arpcom.ac_if;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Avoid using any of the ndis_packet/ndis_packet_private fields for mbuf<->packet housekeeping. Instead, add a couple of extra fields to the end of ndis_packet. These should be invisible to the Windows driver module. This also lets me get rid of a little bit of evil from ndis_ptom() (frobbing of the ext_buf field instead of relying on the MEXTADD() macro).
2003-12-25 06:04:40 +00:00
m = packet->np_m0;
idx = packet->np_txidx;
Rework mbuf<->ndis_packet/ndis_packet<->mbuf translation a little to make it more robust. This should fix problems with crashes under heavy traffic loads that have been reported. Also add a 'query done' callback handler to satisfy the e100bex.sys sample Intel driver.
2003-12-14 21:31:32 +00:00
if (sc->ndis_sc)
bus_dmamap_unload(sc->ndis_ttag, sc->ndis_tmaps[idx]);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
ndis_free_packet(packet);
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
m_freem(m);
NDIS_LOCK(sc);
Rework mbuf<->ndis_packet/ndis_packet<->mbuf translation a little to make it more robust. This should fix problems with crashes under heavy traffic loads that have been reported. Also add a 'query done' callback handler to satisfy the e100bex.sys sample Intel driver.
2003-12-14 21:31:32 +00:00
sc->ndis_txarray[idx] = NULL;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sc->ndis_txpending++;
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
if (status == NDIS_STATUS_SUCCESS)
ifp->if_opackets++;
else
ifp->if_oerrors++;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
ifp->if_timer = 0;
ifp->if_flags &= ~IFF_OACTIVE;
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
NDIS_UNLOCK(sc);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
ndis_sched(ndis_starttask, ifp, NDIS_TASKQUEUE);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return;
}
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
__stdcall static void
ndis_linksts(adapter, status, sbuf, slen)
ndis_handle adapter;
ndis_status status;
void *sbuf;
uint32_t slen;
{
ndis_miniport_block *block;
When you call MiniportInitialize() for an 802.11 driver, it will at some point result in a status event being triggered (it should be a link down event: the Microsoft driver design guide says you should generate one when the NIC is initialized). Some drivers generate the event during MiniportInitialize(), such that by the time MiniportInitialize() completes, the NIC is ready to go. But some drivers, in particular the ones for Atheros wireless NICs, don't generate the event until after a device interrupt occurs at some point after MiniportInitialize() has completed. The gotcha is that you have to wait until the link status event occurs one way or the other before you try to fiddle with any settings (ssid, channel, etc...). For the drivers that set the event sycnhronously this isn't a problem, but for the others we have to pause after calling ndis_init_nic() and wait for the event to arrive before continuing. Failing to wait can cause big trouble: on my SMP system, calling ndis_setstate_80211() after ndis_init_nic() completes, but _before_ the link event arrives, will lock up or reset the system. What we do now is check to see if a link event arrived while ndis_init_nic() was running, and if it didn't we msleep() until it does. Along the way, I discovered a few other problems: - Defered procedure calls run at PASSIVE_LEVEL, not DISPATCH_LEVEL. ntoskrnl_run_dpc() has been fixed accordingly. (I read the documentation wrong.) - Similarly, the NDIS interrupt handler, which is essentially a DPC, also doesn't need to run at DISPATCH_LEVEL. ndis_intrtask() has been fixed accordingly. - MiniportQueryInformation() and MiniportSetInformation() run at DISPATCH_LEVEL, and each request must complete before another can be submitted. ndis_get_info() and ndis_set_info() have been fixed accordingly. - Turned the sleep lock that guards the NDIS thread job list into a spin lock. We never do anything with this lock held except manage the job list (no other locks are held), so it's safe to do this, and it's possible that ndis_sched() and ndis_unsched() can be called from DISPATCH_LEVEL, so using a sleep lock here is semantically incorrect. Also updated subr_witness.c to add the lock to the order list.
2005-03-07 03:05:31 +00:00
struct ndis_softc *sc;
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
block = adapter;
When you call MiniportInitialize() for an 802.11 driver, it will at some point result in a status event being triggered (it should be a link down event: the Microsoft driver design guide says you should generate one when the NIC is initialized). Some drivers generate the event during MiniportInitialize(), such that by the time MiniportInitialize() completes, the NIC is ready to go. But some drivers, in particular the ones for Atheros wireless NICs, don't generate the event until after a device interrupt occurs at some point after MiniportInitialize() has completed. The gotcha is that you have to wait until the link status event occurs one way or the other before you try to fiddle with any settings (ssid, channel, etc...). For the drivers that set the event sycnhronously this isn't a problem, but for the others we have to pause after calling ndis_init_nic() and wait for the event to arrive before continuing. Failing to wait can cause big trouble: on my SMP system, calling ndis_setstate_80211() after ndis_init_nic() completes, but _before_ the link event arrives, will lock up or reset the system. What we do now is check to see if a link event arrived while ndis_init_nic() was running, and if it didn't we msleep() until it does. Along the way, I discovered a few other problems: - Defered procedure calls run at PASSIVE_LEVEL, not DISPATCH_LEVEL. ntoskrnl_run_dpc() has been fixed accordingly. (I read the documentation wrong.) - Similarly, the NDIS interrupt handler, which is essentially a DPC, also doesn't need to run at DISPATCH_LEVEL. ndis_intrtask() has been fixed accordingly. - MiniportQueryInformation() and MiniportSetInformation() run at DISPATCH_LEVEL, and each request must complete before another can be submitted. ndis_get_info() and ndis_set_info() have been fixed accordingly. - Turned the sleep lock that guards the NDIS thread job list into a spin lock. We never do anything with this lock held except manage the job list (no other locks are held), so it's safe to do this, and it's possible that ndis_sched() and ndis_unsched() can be called from DISPATCH_LEVEL, so using a sleep lock here is semantically incorrect. Also updated subr_witness.c to add the lock to the order list.
2005-03-07 03:05:31 +00:00
sc = device_get_softc(block->nmb_physdeviceobj->do_devext);
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
block->nmb_getstat = status;
return;
}
__stdcall static void
ndis_linksts_done(adapter)
ndis_handle adapter;
{
ndis_miniport_block *block;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
struct ndis_softc *sc;
struct ifnet *ifp;
block = adapter;
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
sc = device_get_softc(block->nmb_physdeviceobj->do_devext);
ifp = &sc->arpcom.ac_if;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
if (!NDIS_INITIALIZED(sc))
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
return;
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
switch (block->nmb_getstat) {
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
case NDIS_STATUS_MEDIA_CONNECT:
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
ndis_sched(ndis_ticktask, sc, NDIS_TASKQUEUE);
ndis_sched(ndis_starttask, ifp, NDIS_TASKQUEUE);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
break;
case NDIS_STATUS_MEDIA_DISCONNECT:
Fix another Intel 2200BG bug: don't schedule ndis_ticktask() on media disconnect events if the link wasn't even up yet.
2004-03-21 00:06:56 +00:00
if (sc->ndis_link)
ndis_sched(ndis_ticktask, sc, NDIS_TASKQUEUE);
When you call MiniportInitialize() for an 802.11 driver, it will at some point result in a status event being triggered (it should be a link down event: the Microsoft driver design guide says you should generate one when the NIC is initialized). Some drivers generate the event during MiniportInitialize(), such that by the time MiniportInitialize() completes, the NIC is ready to go. But some drivers, in particular the ones for Atheros wireless NICs, don't generate the event until after a device interrupt occurs at some point after MiniportInitialize() has completed. The gotcha is that you have to wait until the link status event occurs one way or the other before you try to fiddle with any settings (ssid, channel, etc...). For the drivers that set the event sycnhronously this isn't a problem, but for the others we have to pause after calling ndis_init_nic() and wait for the event to arrive before continuing. Failing to wait can cause big trouble: on my SMP system, calling ndis_setstate_80211() after ndis_init_nic() completes, but _before_ the link event arrives, will lock up or reset the system. What we do now is check to see if a link event arrived while ndis_init_nic() was running, and if it didn't we msleep() until it does. Along the way, I discovered a few other problems: - Defered procedure calls run at PASSIVE_LEVEL, not DISPATCH_LEVEL. ntoskrnl_run_dpc() has been fixed accordingly. (I read the documentation wrong.) - Similarly, the NDIS interrupt handler, which is essentially a DPC, also doesn't need to run at DISPATCH_LEVEL. ndis_intrtask() has been fixed accordingly. - MiniportQueryInformation() and MiniportSetInformation() run at DISPATCH_LEVEL, and each request must complete before another can be submitted. ndis_get_info() and ndis_set_info() have been fixed accordingly. - Turned the sleep lock that guards the NDIS thread job list into a spin lock. We never do anything with this lock held except manage the job list (no other locks are held), so it's safe to do this, and it's possible that ndis_sched() and ndis_unsched() can be called from DISPATCH_LEVEL, so using a sleep lock here is semantically incorrect. Also updated subr_witness.c to add the lock to the order list.
2005-03-07 03:05:31 +00:00
else {
if (sc->ndis_80211)
wakeup(&block->nmb_getstat);
}
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
break;
default:
break;
}
Modify if_ndis.c so that the MiniportISR function runs in ndis_intr() and MiniportHandleInterrupt() is fired off later via a task queue in ndis_intrtask(). This more accurately follows the NDIS interrupt handling model, where the ISR does a minimal amount of work in interrupt context and the handler is defered and run at a lower priority. Create a separate ndis_intrmtx mutex just for the guarding the ISR. Modify NdisSynchronizeWithInterrupt() to aquire the ndis_intrmtx mutex before invoking the synchronized procedure. (The purpose of this function is to provide mutual exclusion for code that shares variables with the ISR.) Modify NdisMRegisterInterrupt() to save a pointer to the miniport block in the ndis_miniport_interrupt structure so that NdisSynchronizeWithInterrupt() can grab it later and derive ndis_intrmtx from it.
2004-01-04 21:22:25 +00:00
return;
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
static void
ndis_intr(arg)
void *arg;
{
Re-do the handling of ndis_buffers. The NDIS_BUFFER structure is supposed to be opaque to the driver, however it is exposed through several macros which expect certain behavior. In my original implementation, I used the mappedsystemva member of the structure to hold a pointer to the buffer and bytecount to hold the length. It turns out you must use the startva pointer to point to the page containing the start of the buffer and set byteoffset to the offset within the page where the buffer starts. So, for a buffer with address 'baseva,' startva is baseva & ~(PAGE_SIZE -1) and byteoffset is baseva & (PAGE_SIZE -1). We have to maintain this convention everywhere that ndis_buffers are used. Fortunately, Microsoft defines some macros for initializing and manipulating NDIS_BUFFER structures in ntddk.h. I adapted some of them for use here and used them where appropriate. This fixes the discrepancy I observed between how RX'ed packet sizes were being reported in the Broadcom wireless driver and the sample ethernet drivers that I've tested. This should also help the Intel Centrino wireless driver work. Also try to properly initialize the 802.11 BSS and IBSS channels. (Sadly, the channel value is meaningless since there's no way in the existing NDIS API to get/set the channel, but this should take care of any 'invalid channel (NULL)' messages printed on the console.
2003-12-23 04:08:22 +00:00
struct ndis_softc *sc;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
struct ifnet *ifp;
int is_our_intr = 0;
int call_isr = 0;
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
uint8_t irql;
ndis_miniport_interrupt *intr;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sc = arg;
ifp = &sc->arpcom.ac_if;
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
intr = sc->ndis_block->nmb_interrupt;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
if (sc->ndis_block->nmb_miniportadapterctx == NULL)
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return;
- In ndis_intr(), don't do any interrupt processing if the IFF_UP flag isn't set. - In ndis_attach(), halt the NIC before exiting the routine. Calling ndis_init() will bring it up again, and we don't want it running (and potentially generating interrupts) until we're ready to deal with it.
2003-12-25 09:44:49 +00:00
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
KeAcquireSpinLock(&intr->ni_dpccountlock, &irql);
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
if (sc->ndis_block->nmb_interrupt->ni_isrreq == TRUE)
- Add pe_get_message() and pe_get_messagetable() for processing the RT_MESSAGETABLE resources that some driver binaries have. This allows us to print error messages in ndis_syslog(). - Correct the implementation of InterlockedIncrement() and InterlockedDecrement() -- they return uint32_t, not void. - Correct the declarations of the 64-bit arithmetic shift routines in subr_ntoskrnl.c (_allshr, allshl, etc...). These do not follow the _stdcall convention: instead, they appear to be __attribute__((regparm(3)). - Change the implementation of KeInitializeSpinLock(). There is no complementary KeFreeSpinLock() function, so creating a new mutex on each call to KeInitializeSpinLock() leaks resources when a driver is unloaded. For now, KeInitializeSpinLock() returns a handle to the ntoskrnl interlock mutex. - Use a driver's MiniportDisableInterrupt() and MiniportEnableInterrupt() routines if they exist. I'm not sure if I'm doing this right yet, but at the very least this shouldn't break any currently working drivers, and it makes the Intel PRO/1000 driver work. - In ndis_register_intr(), save some state that might be needed later, and save a pointer to the driver's interrupt structure in the ndis_miniport_block. - Save a pointer to the driver image for use by ndis_syslog() when it calls pe_get_message().
2004-01-06 07:09:26 +00:00
ndis_isr(sc, &is_our_intr, &call_isr);
else {
ndis_disable_intr(sc);
call_isr = 1;
}
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
KeReleaseSpinLock(&intr->ni_dpccountlock, irql);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
- The MiniportReset() function can return NDIS_STATUS_PENDING, in which case we should wait for the resetdone handler to be called before returning. - When providing resources via ndis_query_resources(), uses the computed rsclen when using bcopy() to copy out the resource data rather than the caller-supplied buffer length. - Avoid using ndis_reset_nic() in if_ndis.c unless we really need to reset the NIC because of a problem. - Allow interrupts to be fielded during ndis_attach(), at least as far as allowing ndis_isr() and ndis_intrhand() to run. - Use ndis_80211_rates_ex when probing for supported rates. Technically, this isn't supposed to work since, although Microsoft added the extended rate structure with the NDIS 5.1 update, the spec still says that the OID_802_11_SUPPORTED_RATES OID uses ndis_80211_rates. In spite of this, it appears some drivers use it anyway. - When adding in our guessed rates, check to see if they already exist so that we avoid any duplicates. - Add a printf() to ndis_open_file() that alerts the user when a driver attempts to open a file under /compat/ndis. With these changes, I can get the driver for the SMC 2802W 54g PCI card to load and run. This board uses a Prism54G chip. Note that in order for this driver to work, you must place the supplied smc2802w.arm firmware image under /compat/ndis. (The firmware is not resident on the device.) Note that this should also allow the 3Com 3CRWE154G72 card to work as well; as far as I can tell, these cards also use a Prism54G chip.
2004-04-05 08:26:52 +00:00
if ((is_our_intr || call_isr))
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
IoRequestDpc(sc->ndis_block->nmb_deviceobj, NULL, sc);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return;
}
static void
ndis_tick(xsc)
void *xsc;
Correct the definition of the ndis_miniport_interrupt structure: the ni_dpccountlock member is an ndis_kspin_lock, not an ndis_spin_lock (the latter is too big). Run if_ndis.c:ndis_tick() via taskqueue_schedule(). Also run ndis_start() via taskqueue in certain circumstances. Using these tweaks, I can now get the Broadcom BCM5701 NDIS driver to load and run. Unfortunately, the version I have seems to suffer from the same bug as the SMC 83820 driver, which is that it creates a spinlock during its DriverEntry() routine. I'm still debating the right way to deal with this.
2004-01-08 10:44:37 +00:00
{
struct ndis_softc *sc;
Small timer cleanups: - Use the dh_inserted member of the dispatch header in the Windows timer structure to indicate that the timer has been "inserted into the timer queue" (i.e. armed via timeout()). Use this as the value to return to the caller in KeCancelTimer(). Previously, I was using callout_pending(), but you can't use that with timeout()/untimeout() without creating a potential race condition. - Make ntoskrnl_init_timer() just a wrapper around ntoskrnl_init_timer_ex() (reduces some code duplication). - Drop Giant when entering if_ndis.c:ndis_tick() and subr_ntorkrnl.c:ntoskrnl_timercall(). At the moment, I'm forced to use system callwheel via timeout()/untimeout() to handle timers rather than the callout API (struct callout is too big to fit inside the Windows struct KTIMER, so I'm kind of hosed). Unfortunately, all the callouts in the callwhere are not marked as MPSAFE, so when one of them fires, it implicitly acquires Giant before invoking the callback routine (and releases it when it returns). I don't need to hold Giant, but there's no way to stop the callout code from acquiring it as long as I'm using timeout()/untimeout(), so for now we cheat by just dropping Giant right away (and re-acquiring it right before the routine returns so keep the callout code happy). At some point, I will need to solve this better, but for now this should be a suitable workaround.
2004-04-30 20:51:55 +00:00
mtx_unlock(&Giant);
Correct the definition of the ndis_miniport_interrupt structure: the ni_dpccountlock member is an ndis_kspin_lock, not an ndis_spin_lock (the latter is too big). Run if_ndis.c:ndis_tick() via taskqueue_schedule(). Also run ndis_start() via taskqueue in certain circumstances. Using these tweaks, I can now get the Broadcom BCM5701 NDIS driver to load and run. Unfortunately, the version I have seems to suffer from the same bug as the SMC 83820 driver, which is that it creates a spinlock during its DriverEntry() routine. I'm still debating the right way to deal with this.
2004-01-08 10:44:37 +00:00
sc = xsc;
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
ndis_sched(ndis_ticktask, sc, NDIS_TASKQUEUE);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
sc->ndis_stat_ch = timeout(ndis_tick, sc, hz *
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
sc->ndis_block->nmb_checkforhangsecs);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
Small timer cleanups: - Use the dh_inserted member of the dispatch header in the Windows timer structure to indicate that the timer has been "inserted into the timer queue" (i.e. armed via timeout()). Use this as the value to return to the caller in KeCancelTimer(). Previously, I was using callout_pending(), but you can't use that with timeout()/untimeout() without creating a potential race condition. - Make ntoskrnl_init_timer() just a wrapper around ntoskrnl_init_timer_ex() (reduces some code duplication). - Drop Giant when entering if_ndis.c:ndis_tick() and subr_ntorkrnl.c:ntoskrnl_timercall(). At the moment, I'm forced to use system callwheel via timeout()/untimeout() to handle timers rather than the callout API (struct callout is too big to fit inside the Windows struct KTIMER, so I'm kind of hosed). Unfortunately, all the callouts in the callwhere are not marked as MPSAFE, so when one of them fires, it implicitly acquires Giant before invoking the callback routine (and releases it when it returns). I don't need to hold Giant, but there's no way to stop the callout code from acquiring it as long as I'm using timeout()/untimeout(), so for now we cheat by just dropping Giant right away (and re-acquiring it right before the routine returns so keep the callout code happy). At some point, I will need to solve this better, but for now this should be a suitable workaround.
2004-04-30 20:51:55 +00:00
mtx_lock(&Giant);
return;
Correct the definition of the ndis_miniport_interrupt structure: the ni_dpccountlock member is an ndis_kspin_lock, not an ndis_spin_lock (the latter is too big). Run if_ndis.c:ndis_tick() via taskqueue_schedule(). Also run ndis_start() via taskqueue in certain circumstances. Using these tweaks, I can now get the Broadcom BCM5701 NDIS driver to load and run. Unfortunately, the version I have seems to suffer from the same bug as the SMC 83820 driver, which is that it creates a spinlock during its DriverEntry() routine. I'm still debating the right way to deal with this.
2004-01-08 10:44:37 +00:00
}
static void
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
ndis_ticktask(xsc)
Correct the definition of the ndis_miniport_interrupt structure: the ni_dpccountlock member is an ndis_kspin_lock, not an ndis_spin_lock (the latter is too big). Run if_ndis.c:ndis_tick() via taskqueue_schedule(). Also run ndis_start() via taskqueue in certain circumstances. Using these tweaks, I can now get the Broadcom BCM5701 NDIS driver to load and run. Unfortunately, the version I have seems to suffer from the same bug as the SMC 83820 driver, which is that it creates a spinlock during its DriverEntry() routine. I'm still debating the right way to deal with this.
2004-01-08 10:44:37 +00:00
void *xsc;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
{
Re-do the handling of ndis_buffers. The NDIS_BUFFER structure is supposed to be opaque to the driver, however it is exposed through several macros which expect certain behavior. In my original implementation, I used the mappedsystemva member of the structure to hold a pointer to the buffer and bytecount to hold the length. It turns out you must use the startva pointer to point to the page containing the start of the buffer and set byteoffset to the offset within the page where the buffer starts. So, for a buffer with address 'baseva,' startva is baseva & ~(PAGE_SIZE -1) and byteoffset is baseva & (PAGE_SIZE -1). We have to maintain this convention everywhere that ndis_buffers are used. Fortunately, Microsoft defines some macros for initializing and manipulating NDIS_BUFFER structures in ntddk.h. I adapted some of them for use here and used them where appropriate. This fixes the discrepancy I observed between how RX'ed packet sizes were being reported in the Broadcom wireless driver and the sample ethernet drivers that I've tested. This should also help the Intel Centrino wireless driver work. Also try to properly initialize the 802.11 BSS and IBSS channels. (Sadly, the channel value is meaningless since there's no way in the existing NDIS API to get/set the channel, but this should take care of any 'invalid channel (NULL)' messages printed on the console.
2003-12-23 04:08:22 +00:00
struct ndis_softc *sc;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
__stdcall ndis_checkforhang_handler hangfunc;
uint8_t rval;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
ndis_media_state linkstate;
int error, len;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sc = xsc;
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
hangfunc = sc->ndis_chars->nmc_checkhang_func;
- The MiniportReset() function can return NDIS_STATUS_PENDING, in which case we should wait for the resetdone handler to be called before returning. - When providing resources via ndis_query_resources(), uses the computed rsclen when using bcopy() to copy out the resource data rather than the caller-supplied buffer length. - Avoid using ndis_reset_nic() in if_ndis.c unless we really need to reset the NIC because of a problem. - Allow interrupts to be fielded during ndis_attach(), at least as far as allowing ndis_isr() and ndis_intrhand() to run. - Use ndis_80211_rates_ex when probing for supported rates. Technically, this isn't supposed to work since, although Microsoft added the extended rate structure with the NDIS 5.1 update, the spec still says that the OID_802_11_SUPPORTED_RATES OID uses ndis_80211_rates. In spite of this, it appears some drivers use it anyway. - When adding in our guessed rates, check to see if they already exist so that we avoid any duplicates. - Add a printf() to ndis_open_file() that alerts the user when a driver attempts to open a file under /compat/ndis. With these changes, I can get the driver for the SMC 2802W 54g PCI card to load and run. This board uses a Prism54G chip. Note that in order for this driver to work, you must place the supplied smc2802w.arm firmware image under /compat/ndis. (The firmware is not resident on the device.) Note that this should also allow the 3Com 3CRWE154G72 card to work as well; as far as I can tell, these cards also use a Prism54G chip.
2004-04-05 08:26:52 +00:00
if (hangfunc != NULL) {
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
rval = MSCALL1(hangfunc,
sc->ndis_block->nmb_miniportadapterctx);
- The MiniportReset() function can return NDIS_STATUS_PENDING, in which case we should wait for the resetdone handler to be called before returning. - When providing resources via ndis_query_resources(), uses the computed rsclen when using bcopy() to copy out the resource data rather than the caller-supplied buffer length. - Avoid using ndis_reset_nic() in if_ndis.c unless we really need to reset the NIC because of a problem. - Allow interrupts to be fielded during ndis_attach(), at least as far as allowing ndis_isr() and ndis_intrhand() to run. - Use ndis_80211_rates_ex when probing for supported rates. Technically, this isn't supposed to work since, although Microsoft added the extended rate structure with the NDIS 5.1 update, the spec still says that the OID_802_11_SUPPORTED_RATES OID uses ndis_80211_rates. In spite of this, it appears some drivers use it anyway. - When adding in our guessed rates, check to see if they already exist so that we avoid any duplicates. - Add a printf() to ndis_open_file() that alerts the user when a driver attempts to open a file under /compat/ndis. With these changes, I can get the driver for the SMC 2802W 54g PCI card to load and run. This board uses a Prism54G chip. Note that in order for this driver to work, you must place the supplied smc2802w.arm firmware image under /compat/ndis. (The firmware is not resident on the device.) Note that this should also allow the 3Com 3CRWE154G72 card to work as well; as far as I can tell, these cards also use a Prism54G chip.
2004-04-05 08:26:52 +00:00
if (rval == TRUE) {
ndis_reset_nic(sc);
return;
}
}
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
len = sizeof(linkstate);
error = ndis_get_info(sc, OID_GEN_MEDIA_CONNECT_STATUS,
(void *)&linkstate, &len);
- subr_ntoskrnl.c: improve the _fastcall hack based on suggestions from peter and jhb: use __volatile__ to prevent gcc from possibly reordering code, use a null inline instruction instead of a no-op movl (I would have done this myself if I knew it was allowed) and combine two register assignments into a single asm statement. - if_ndis.c: set the NDIS_STATUS_PENDING flag on all outgoing packets in ndis_start(), make the resource allocation code a little smarter about how it selects the altmem range, correct a lock order reversal in ndis_tick().
2003-12-31 04:12:57 +00:00
NDIS_LOCK(sc);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
if (sc->ndis_link == 0 && linkstate == nmc_connected) {
device_printf(sc->ndis_dev, "link up\n");
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
sc->ndis_link = 1;
Don't hold NDIS_LOCK() around call to ndis_getstate_80211() since it may block on ndis_get_info().
2004-02-07 23:52:58 +00:00
NDIS_UNLOCK(sc);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
if (sc->ndis_80211)
ndis_getstate_80211(sc);
Don't hold NDIS_LOCK() around call to ndis_getstate_80211() since it may block on ndis_get_info().
2004-02-07 23:52:58 +00:00
NDIS_LOCK(sc);
Restore source code compatibility with 5.2-RELEASE.
2004-05-12 15:58:42 +00:00
#ifdef LINK_STATE_UP
Link state change notification of ethernet media to the routing socket. o The ndis_ticktask() function updates the ifi_link_state field and calls rt_ifmsg() to notify listeners on the routing socket. Approved by: wpaul
2004-05-06 13:17:02 +00:00
sc->arpcom.ac_if.if_link_state = LINK_STATE_UP;
rt_ifmsg(&(sc->arpcom.ac_if));
Restore source code compatibility with 5.2-RELEASE.
2004-05-12 15:58:42 +00:00
#endif /* LINK_STATE_UP */
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
}
if (sc->ndis_link == 1 && linkstate == nmc_disconnected) {
device_printf(sc->ndis_dev, "link down\n");
sc->ndis_link = 0;
Restore source code compatibility with 5.2-RELEASE.
2004-05-12 15:58:42 +00:00
#ifdef LINK_STATE_DOWN
Link state change notification of ethernet media to the routing socket. o The ndis_ticktask() function updates the ifi_link_state field and calls rt_ifmsg() to notify listeners on the routing socket. Approved by: wpaul
2004-05-06 13:17:02 +00:00
sc->arpcom.ac_if.if_link_state = LINK_STATE_DOWN;
rt_ifmsg(&(sc->arpcom.ac_if));
Restore source code compatibility with 5.2-RELEASE.
2004-05-12 15:58:42 +00:00
#endif /* LINK_STATE_DOWN */
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
}
NDIS_UNLOCK(sc);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return;
}
static void
ndis_map_sclist(arg, segs, nseg, mapsize, error)
void *arg;
bus_dma_segment_t *segs;
int nseg;
bus_size_t mapsize;
int error;
{
struct ndis_sc_list *sclist;
int i;
if (error || arg == NULL)
return;
sclist = arg;
sclist->nsl_frags = nseg;
for (i = 0; i < nseg; i++) {
sclist->nsl_elements[i].nse_addr.np_quad = segs[i].ds_addr;
sclist->nsl_elements[i].nse_len = segs[i].ds_len;
}
return;
}
Correct the definition of the ndis_miniport_interrupt structure: the ni_dpccountlock member is an ndis_kspin_lock, not an ndis_spin_lock (the latter is too big). Run if_ndis.c:ndis_tick() via taskqueue_schedule(). Also run ndis_start() via taskqueue in certain circumstances. Using these tweaks, I can now get the Broadcom BCM5701 NDIS driver to load and run. Unfortunately, the version I have seems to suffer from the same bug as the SMC 83820 driver, which is that it creates a spinlock during its DriverEntry() routine. I'm still debating the right way to deal with this.
2004-01-08 10:44:37 +00:00
static void
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
ndis_starttask(arg)
Correct the definition of the ndis_miniport_interrupt structure: the ni_dpccountlock member is an ndis_kspin_lock, not an ndis_spin_lock (the latter is too big). Run if_ndis.c:ndis_tick() via taskqueue_schedule(). Also run ndis_start() via taskqueue in certain circumstances. Using these tweaks, I can now get the Broadcom BCM5701 NDIS driver to load and run. Unfortunately, the version I have seems to suffer from the same bug as the SMC 83820 driver, which is that it creates a spinlock during its DriverEntry() routine. I'm still debating the right way to deal with this.
2004-01-08 10:44:37 +00:00
void *arg;
{
struct ifnet *ifp;
ifp = arg;
Second part of ALTQ driver modifications, covering: an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4) Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/ Tested by: Vaidas Damosevicius (an, ath, wi) Roman Divacky (vr) Submitted by: yongari (hme)
2004-08-01 23:58:04 +00:00
#if __FreeBSD_version < 502114
Correct the definition of the ndis_miniport_interrupt structure: the ni_dpccountlock member is an ndis_kspin_lock, not an ndis_spin_lock (the latter is too big). Run if_ndis.c:ndis_tick() via taskqueue_schedule(). Also run ndis_start() via taskqueue in certain circumstances. Using these tweaks, I can now get the Broadcom BCM5701 NDIS driver to load and run. Unfortunately, the version I have seems to suffer from the same bug as the SMC 83820 driver, which is that it creates a spinlock during its DriverEntry() routine. I'm still debating the right way to deal with this.
2004-01-08 10:44:37 +00:00
if (ifp->if_snd.ifq_head != NULL)
Second part of ALTQ driver modifications, covering: an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4) Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/ Tested by: Vaidas Damosevicius (an, ath, wi) Roman Divacky (vr) Submitted by: yongari (hme)
2004-08-01 23:58:04 +00:00
#else
if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
#endif
Correct the definition of the ndis_miniport_interrupt structure: the ni_dpccountlock member is an ndis_kspin_lock, not an ndis_spin_lock (the latter is too big). Run if_ndis.c:ndis_tick() via taskqueue_schedule(). Also run ndis_start() via taskqueue in certain circumstances. Using these tweaks, I can now get the Broadcom BCM5701 NDIS driver to load and run. Unfortunately, the version I have seems to suffer from the same bug as the SMC 83820 driver, which is that it creates a spinlock during its DriverEntry() routine. I'm still debating the right way to deal with this.
2004-01-08 10:44:37 +00:00
ndis_start(ifp);
return;
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/*
* Main transmit routine. To make NDIS drivers happy, we need to
* transform mbuf chains into NDIS packets and feed them to the
* send packet routines. Most drivers allow you to send several
* packets at once (up to the maxpkts limit). Unfortunately, rather
* that accepting them in the form of a linked list, they expect
* a contiguous array of pointers to packets.
*
* For those drivers which use the NDIS scatter/gather DMA mechanism,
* we need to perform busdma work here. Those that use map registers
* will do the mapping themselves on a buffer by buffer basis.
*/
static void
ndis_start(ifp)
struct ifnet *ifp;
{
struct ndis_softc *sc;
struct mbuf *m = NULL;
ndis_packet **p0 = NULL, *p = NULL;
Add support for TCP/IP checksum offload. No, really.
2004-01-22 02:36:34 +00:00
ndis_tcpip_csum *csum;
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
int pcnt = 0, status;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sc = ifp->if_softc;
Silence irritating watchdog timeout messages: if we call ndis_send_packets() but there's no link yet, we get an immediate callback to ndis_txeof(), which clears if_timer. But ndis_start() sets if_timer right after the call to ndis_send_packets(). Set if_timer before calling ndis_send_packets(). Also fix mutex locking to prevent ndis_txeof() from running in the middle of ndis_start().
2003-12-14 22:47:01 +00:00
NDIS_LOCK(sc);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
if (!sc->ndis_link || ifp->if_flags & IFF_OACTIVE) {
NDIS_UNLOCK(sc);
return;
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
p0 = &sc->ndis_txarray[sc->ndis_txidx];
while(sc->ndis_txpending) {
Second part of ALTQ driver modifications, covering: an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4) Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/ Tested by: Vaidas Damosevicius (an, ath, wi) Roman Divacky (vr) Submitted by: yongari (hme)
2004-08-01 23:58:04 +00:00
#if __FreeBSD_version < 502114
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
IF_DEQUEUE(&ifp->if_snd, m);
Second part of ALTQ driver modifications, covering: an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4) Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/ Tested by: Vaidas Damosevicius (an, ath, wi) Roman Divacky (vr) Submitted by: yongari (hme)
2004-08-01 23:58:04 +00:00
#else
IFQ_DRV_DEQUEUE(&ifp->if_snd, m);
#endif
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
if (m == NULL)
break;
Add support for Windows/x86-64 binaries to Project Evil. Ville-Pertti Keinonen (will at exomi dot comohmygodnospampleasekthx) deserves a big thanks for submitting initial patches to make it work. I have mangled his contributions appropriately. The main gotcha with Windows/x86-64 is that Microsoft uses a different calling convention than everyone else. The standard ABI requires using 6 registers for argument passing, with other arguments on the stack. Microsoft uses only 4 registers, and requires the caller to leave room on the stack for the register arguments incase the callee needs to spill them. Unlike x86, where Microsoft uses a mix of _cdecl, _stdcall and _fastcall, all routines on Windows/x86-64 uses the same convention. This unfortunately means that all the functions we export to the driver require an intermediate translation wrapper. Similarly, we have to wrap all calls back into the driver binary itself. The original patches provided macros to wrap every single routine at compile time, providing a secondary jump table with a customized wrapper for each exported routine. I decided to use a different approach: the call wrapper for each function is created from a template at runtime, and the routine to jump to is patched into the wrapper as it is created. The subr_pe module has been modified to patch in the wrapped function instead of the original. (On x86, the wrapping routine is a no-op.) There are some minor API differences that had to be accounted for: - KeAcquireSpinLock() is a real function on amd64, not a macro wrapper around KfAcquireSpinLock() - NdisFreeBuffer() is actually IoFreeMdl(). I had to change the whole NDIS_BUFFER API a bit to accomodate this. Bugs fixed along the way: - IoAllocateMdl() always returned NULL - kern_windrv.c:windrv_unload() wasn't releasing private driver object extensions correctly (found thanks to memguard) This has only been tested with the driver for the Broadcom 802.11g chipset, which was the only Windows/x86-64 driver I could find.
2005-02-16 05:41:18 +00:00
NdisAllocatePacket(&status,
&sc->ndis_txarray[sc->ndis_txidx], sc->ndis_txpool);
if (status != NDIS_STATUS_SUCCESS)
break;
Rework mbuf<->ndis_packet/ndis_packet<->mbuf translation a little to make it more robust. This should fix problems with crashes under heavy traffic loads that have been reported. Also add a 'query done' callback handler to satisfy the e100bex.sys sample Intel driver.
2003-12-14 21:31:32 +00:00
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
if (ndis_mtop(m, &sc->ndis_txarray[sc->ndis_txidx])) {
Second part of ALTQ driver modifications, covering: an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4) Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/ Tested by: Vaidas Damosevicius (an, ath, wi) Roman Divacky (vr) Submitted by: yongari (hme)
2004-08-01 23:58:04 +00:00
#if __FreeBSD_version >= 502114
IFQ_DRV_PREPEND(&ifp->if_snd, m);
#endif
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
NDIS_UNLOCK(sc);
Second part of ALTQ driver modifications, covering: an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4) Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/ Tested by: Vaidas Damosevicius (an, ath, wi) Roman Divacky (vr) Submitted by: yongari (hme)
2004-08-01 23:58:04 +00:00
#if __FreeBSD_version < 502114
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
IF_PREPEND(&ifp->if_snd, m);
Second part of ALTQ driver modifications, covering: an(4), ath(4), hme(4), ndis(4), vr(4) and wi(4) Please help testing: http://people.freebsd.org/~mlaier/ALTQ_driver/ Tested by: Vaidas Damosevicius (an, ath, wi) Roman Divacky (vr) Submitted by: yongari (hme)
2004-08-01 23:58:04 +00:00
#endif
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return;
}
/*
* Save pointer to original mbuf
* so we can free it later.
*/
- subr_ntoskrnl.c: improve the _fastcall hack based on suggestions from peter and jhb: use __volatile__ to prevent gcc from possibly reordering code, use a null inline instruction instead of a no-op movl (I would have done this myself if I knew it was allowed) and combine two register assignments into a single asm statement. - if_ndis.c: set the NDIS_STATUS_PENDING flag on all outgoing packets in ndis_start(), make the resource allocation code a little smarter about how it selects the altmem range, correct a lock order reversal in ndis_tick().
2003-12-31 04:12:57 +00:00
p = sc->ndis_txarray[sc->ndis_txidx];
p->np_txidx = sc->ndis_txidx;
p->np_m0 = m;
p->np_oob.npo_status = NDIS_STATUS_PENDING;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/*
* Do scatter/gather processing, if driver requested it.
*/
if (sc->ndis_sc) {
bus_dmamap_load_mbuf(sc->ndis_ttag,
sc->ndis_tmaps[sc->ndis_txidx], m,
ndis_map_sclist, &p->np_sclist, BUS_DMA_NOWAIT);
bus_dmamap_sync(sc->ndis_ttag,
sc->ndis_tmaps[sc->ndis_txidx],
BUS_DMASYNC_PREREAD);
p->np_ext.npe_info[ndis_sclist_info] = &p->np_sclist;
}
Add support for TCP/IP checksum offload. No, really.
2004-01-22 02:36:34 +00:00
/* Handle checksum offload. */
if (ifp->if_capenable & IFCAP_TXCSUM &&
m->m_pkthdr.csum_flags) {
csum = (ndis_tcpip_csum *)
&p->np_ext.npe_info[ndis_tcpipcsum_info];
csum->u.ntc_txflags = NDIS_TXCSUM_DO_IPV4;
if (m->m_pkthdr.csum_flags & CSUM_IP)
csum->u.ntc_txflags |= NDIS_TXCSUM_DO_IP;
if (m->m_pkthdr.csum_flags & CSUM_TCP)
csum->u.ntc_txflags |= NDIS_TXCSUM_DO_TCP;
if (m->m_pkthdr.csum_flags & CSUM_UDP)
csum->u.ntc_txflags |= NDIS_TXCSUM_DO_UDP;
p->np_private.npp_flags = NDIS_PROTOCOL_ID_TCP_IP;
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
NDIS_INC(sc);
sc->ndis_txpending--;
pcnt++;
/*
* If there's a BPF listener, bounce a copy of this frame
* to him.
*/
BPF_MTAP(ifp, m);
/*
* The array that p0 points to must appear contiguous,
* so we must not wrap past the end of sc->ndis_txarray[].
* If it looks like we're about to wrap, break out here
* so the this batch of packets can be transmitted, then
* wait for txeof to ask us to send the rest.
*/
if (sc->ndis_txidx == 0)
break;
}
Drop the NDIS lock before returning from ndis_start(). PR: i386/72795 Submitted by: Frank Mayhar <frank@exit.com> MFC in: 3 days
2004-10-18 21:33:56 +00:00
if (pcnt == 0) {
NDIS_UNLOCK(sc);
Fix sis, bfe and ndis in the same way dc was fixed: Do not tell the hardware to send when there were no packets enqueued. Found and reviewed by: green MFC after: 1 days
2004-10-08 16:14:42 +00:00
return;
Drop the NDIS lock before returning from ndis_start(). PR: i386/72795 Submitted by: Frank Mayhar <frank@exit.com> MFC in: 3 days
2004-10-18 21:33:56 +00:00
}
Fix sis, bfe and ndis in the same way dc was fixed: Do not tell the hardware to send when there were no packets enqueued. Found and reviewed by: green MFC after: 1 days
2004-10-08 16:14:42 +00:00
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
if (sc->ndis_txpending == 0)
ifp->if_flags |= IFF_OACTIVE;
/*
* Set a timeout in case the chip goes out to lunch.
*/
ifp->if_timer = 5;
Silence irritating watchdog timeout messages: if we call ndis_send_packets() but there's no link yet, we get an immediate callback to ndis_txeof(), which clears if_timer. But ndis_start() sets if_timer right after the call to ndis_send_packets(). Set if_timer before calling ndis_send_packets(). Also fix mutex locking to prevent ndis_txeof() from running in the middle of ndis_start().
2003-12-14 22:47:01 +00:00
NDIS_UNLOCK(sc);
Implement support for single packet sends. The Intel Centrino driver that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
2004-02-03 07:39:23 +00:00
if (sc->ndis_maxpkts == 1)
ndis_send_packet(sc, p);
else
ndis_send_packets(sc, p0, pcnt);
Silence irritating watchdog timeout messages: if we call ndis_send_packets() but there's no link yet, we get an immediate callback to ndis_txeof(), which clears if_timer. But ndis_start() sets if_timer right after the call to ndis_send_packets(). Set if_timer before calling ndis_send_packets(). Also fix mutex locking to prevent ndis_txeof() from running in the middle of ndis_start().
2003-12-14 22:47:01 +00:00
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return;
}
static void
ndis_init(xsc)
void *xsc;
{
struct ndis_softc *sc = xsc;
struct ifnet *ifp = &sc->arpcom.ac_if;
int i, error;
Add a kludge to avoid having ndis_init() called needlessly by dhclient on an SIOCSIFADDR (by way of brain damage in net80211). Also, avoid trying to set NDIS_80211_AUTHMODE_AUTO since the Microsoft documentation I have recommends not using it, and the Centrino driver seems to dislike being told to use it.
2004-01-27 07:57:42 +00:00
/*
* Avoid reintializing the link unnecessarily.
* This should be dealt with in a better way by
* fixing the upper layer modules so they don't
* call ifp->if_init() quite as often.
*/
if (sc->ndis_link && sc->ndis_skip)
return;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/*
* Cancel pending I/O and free all RX/TX buffers.
*/
ndis_stop(sc);
Add yet more bulletproofing. This is to guard against the case that ndis_init_nic() works one during attach, but fails later. Many things will blow up if ndis_init_nic() fails and we aren't careful.
2004-02-11 21:53:40 +00:00
if (ndis_init_nic(sc))
return;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/* Init our MAC address */
/* Program the packet filter */
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
sc->ndis_filter = NDIS_PACKET_TYPE_DIRECTED;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
if (ifp->if_flags & IFF_BROADCAST)
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
sc->ndis_filter |= NDIS_PACKET_TYPE_BROADCAST;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
if (ifp->if_flags & IFF_PROMISC)
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
sc->ndis_filter |= NDIS_PACKET_TYPE_PROMISCUOUS;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
i = sizeof(sc->ndis_filter);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
error = ndis_set_info(sc, OID_GEN_CURRENT_PACKET_FILTER,
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
&sc->ndis_filter, &i);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
if (error)
Clean up ndiscvt a bit (leaving out the -i flag didn't work) and add copyrights to the inf parser files. Add a -n flag to ndiscvt to allow the user to override the default device name of NDIS devices. Instead of "ndis0, ndis1, etc..." you can have "foo0, foo1, etc..." This allows you to have more than one kind of NDIS device in the kernel at the same time. Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c and subr_ndis.c. Create UMA zones for ndis_packet and ndis_buffer structs allocated on transmit. The zones are created and destroyed in the modevent handler in kern_ndis.c. printf() and UMA changes submitted by green@freebsd.org
2004-01-02 04:31:06 +00:00
device_printf (sc->ndis_dev, "set filter failed: %d\n", error);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
/*
* Program the multicast filter, if necessary.
*/
ndis_setmulti(sc);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
Add support for TCP/IP checksum offload. No, really.
2004-01-22 02:36:34 +00:00
/* Setup task offload. */
ndis_set_offload(sc);
/* Enable interrupts. */
- Add pe_get_message() and pe_get_messagetable() for processing the RT_MESSAGETABLE resources that some driver binaries have. This allows us to print error messages in ndis_syslog(). - Correct the implementation of InterlockedIncrement() and InterlockedDecrement() -- they return uint32_t, not void. - Correct the declarations of the 64-bit arithmetic shift routines in subr_ntoskrnl.c (_allshr, allshl, etc...). These do not follow the _stdcall convention: instead, they appear to be __attribute__((regparm(3)). - Change the implementation of KeInitializeSpinLock(). There is no complementary KeFreeSpinLock() function, so creating a new mutex on each call to KeInitializeSpinLock() leaks resources when a driver is unloaded. For now, KeInitializeSpinLock() returns a handle to the ntoskrnl interlock mutex. - Use a driver's MiniportDisableInterrupt() and MiniportEnableInterrupt() routines if they exist. I'm not sure if I'm doing this right yet, but at the very least this shouldn't break any currently working drivers, and it makes the Intel PRO/1000 driver work. - In ndis_register_intr(), save some state that might be needed later, and save a pointer to the driver's interrupt structure in the ndis_miniport_block. - Save a pointer to the driver image for use by ndis_syslog() when it calls pe_get_message().
2004-01-06 07:09:26 +00:00
ndis_enable_intr(sc);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
if (sc->ndis_80211)
ndis_setstate_80211(sc);
Rework mbuf<->ndis_packet/ndis_packet<->mbuf translation a little to make it more robust. This should fix problems with crashes under heavy traffic loads that have been reported. Also add a 'query done' callback handler to satisfy the e100bex.sys sample Intel driver.
2003-12-14 21:31:32 +00:00
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
NDIS_LOCK(sc);
sc->ndis_txidx = 0;
sc->ndis_txpending = sc->ndis_maxpkts;
sc->ndis_link = 0;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
ifp->if_flags |= IFF_RUNNING;
ifp->if_flags &= ~IFF_OACTIVE;
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
NDIS_UNLOCK(sc);
- Add pe_get_message() and pe_get_messagetable() for processing the RT_MESSAGETABLE resources that some driver binaries have. This allows us to print error messages in ndis_syslog(). - Correct the implementation of InterlockedIncrement() and InterlockedDecrement() -- they return uint32_t, not void. - Correct the declarations of the 64-bit arithmetic shift routines in subr_ntoskrnl.c (_allshr, allshl, etc...). These do not follow the _stdcall convention: instead, they appear to be __attribute__((regparm(3)). - Change the implementation of KeInitializeSpinLock(). There is no complementary KeFreeSpinLock() function, so creating a new mutex on each call to KeInitializeSpinLock() leaks resources when a driver is unloaded. For now, KeInitializeSpinLock() returns a handle to the ntoskrnl interlock mutex. - Use a driver's MiniportDisableInterrupt() and MiniportEnableInterrupt() routines if they exist. I'm not sure if I'm doing this right yet, but at the very least this shouldn't break any currently working drivers, and it makes the Intel PRO/1000 driver work. - In ndis_register_intr(), save some state that might be needed later, and save a pointer to the driver's interrupt structure in the ndis_miniport_block. - Save a pointer to the driver image for use by ndis_syslog() when it calls pe_get_message().
2004-01-06 07:09:26 +00:00
/*
* Some drivers don't set this value. The NDIS spec says
Recently I realized that the ADMtek 8211 driver wasn't working correctly (NIC would claim to establish a link with an ad-hoc net but it couldn't send/receive packets). It turns out that every time the checkforhang handler was called by ndis_ticktask(), the driver would generate a new media connect event. The NDIS spec says the checkforhang handler is called "approximately every 2 seconds" but using exactly 2 seconds seems too fast. Using 3 seconds makes it happy again, so we'll go with that for now.
2004-03-23 19:51:17 +00:00
* the default checkforhang timeout is "approximately 2
* seconds." We use 3 seconds, because it seems for some
* drivers, exactly 2 seconds is too fast.
- Add pe_get_message() and pe_get_messagetable() for processing the RT_MESSAGETABLE resources that some driver binaries have. This allows us to print error messages in ndis_syslog(). - Correct the implementation of InterlockedIncrement() and InterlockedDecrement() -- they return uint32_t, not void. - Correct the declarations of the 64-bit arithmetic shift routines in subr_ntoskrnl.c (_allshr, allshl, etc...). These do not follow the _stdcall convention: instead, they appear to be __attribute__((regparm(3)). - Change the implementation of KeInitializeSpinLock(). There is no complementary KeFreeSpinLock() function, so creating a new mutex on each call to KeInitializeSpinLock() leaks resources when a driver is unloaded. For now, KeInitializeSpinLock() returns a handle to the ntoskrnl interlock mutex. - Use a driver's MiniportDisableInterrupt() and MiniportEnableInterrupt() routines if they exist. I'm not sure if I'm doing this right yet, but at the very least this shouldn't break any currently working drivers, and it makes the Intel PRO/1000 driver work. - In ndis_register_intr(), save some state that might be needed later, and save a pointer to the driver's interrupt structure in the ndis_miniport_block. - Save a pointer to the driver image for use by ndis_syslog() when it calls pe_get_message().
2004-01-06 07:09:26 +00:00
*/
Correct the definition of the ndis_miniport_interrupt structure: the ni_dpccountlock member is an ndis_kspin_lock, not an ndis_spin_lock (the latter is too big). Run if_ndis.c:ndis_tick() via taskqueue_schedule(). Also run ndis_start() via taskqueue in certain circumstances. Using these tweaks, I can now get the Broadcom BCM5701 NDIS driver to load and run. Unfortunately, the version I have seems to suffer from the same bug as the SMC 83820 driver, which is that it creates a spinlock during its DriverEntry() routine. I'm still debating the right way to deal with this.
2004-01-08 10:44:37 +00:00
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
if (sc->ndis_block->nmb_checkforhangsecs == 0)
sc->ndis_block->nmb_checkforhangsecs = 3;
- Add pe_get_message() and pe_get_messagetable() for processing the RT_MESSAGETABLE resources that some driver binaries have. This allows us to print error messages in ndis_syslog(). - Correct the implementation of InterlockedIncrement() and InterlockedDecrement() -- they return uint32_t, not void. - Correct the declarations of the 64-bit arithmetic shift routines in subr_ntoskrnl.c (_allshr, allshl, etc...). These do not follow the _stdcall convention: instead, they appear to be __attribute__((regparm(3)). - Change the implementation of KeInitializeSpinLock(). There is no complementary KeFreeSpinLock() function, so creating a new mutex on each call to KeInitializeSpinLock() leaks resources when a driver is unloaded. For now, KeInitializeSpinLock() returns a handle to the ntoskrnl interlock mutex. - Use a driver's MiniportDisableInterrupt() and MiniportEnableInterrupt() routines if they exist. I'm not sure if I'm doing this right yet, but at the very least this shouldn't break any currently working drivers, and it makes the Intel PRO/1000 driver work. - In ndis_register_intr(), save some state that might be needed later, and save a pointer to the driver's interrupt structure in the ndis_miniport_block. - Save a pointer to the driver image for use by ndis_syslog() when it calls pe_get_message().
2004-01-06 07:09:26 +00:00
Correct the definition of the ndis_miniport_interrupt structure: the ni_dpccountlock member is an ndis_kspin_lock, not an ndis_spin_lock (the latter is too big). Run if_ndis.c:ndis_tick() via taskqueue_schedule(). Also run ndis_start() via taskqueue in certain circumstances. Using these tweaks, I can now get the Broadcom BCM5701 NDIS driver to load and run. Unfortunately, the version I have seems to suffer from the same bug as the SMC 83820 driver, which is that it creates a spinlock during its DriverEntry() routine. I'm still debating the right way to deal with this.
2004-01-08 10:44:37 +00:00
sc->ndis_stat_ch = timeout(ndis_tick, sc,
Next step on the road to IRPs: create and use an imitation of the Windows DRIVER_OBJECT and DEVICE_OBJECT mechanism so that we can simulate driver stacking. In Windows, each loaded driver image is attached to a DRIVER_OBJECT structure. Windows uses the registry to match up a given vendor/device ID combination with a corresponding DRIVER_OBJECT. When a driver image is first loaded, its DriverEntry() routine is invoked, which sets up the AddDevice() function pointer in the DRIVER_OBJECT and creates a dispatch table (based on IRP major codes). When a Windows bus driver detects a new device, it creates a Physical Device Object (PDO) for it. This is a DEVICE_OBJECT structure, with semantics analagous to that of a device_t in FreeBSD. The Windows PNP manager will invoke the driver's AddDevice() function and pass it pointers to the DRIVER_OBJECT and the PDO. The AddDevice() function then creates a new DRIVER_OBJECT structure of its own. This is known as the Functional Device Object (FDO) and corresponds roughly to a private softc instance. The driver uses IoAttachDeviceToDeviceStack() to add this device object to the driver stack for this PDO. Subsequent drivers (called filter drivers in Windows-speak) can be loaded which add themselves to the stack. When someone issues an IRP to a device, it travel along the stack passing through several possible filter drivers until it reaches the functional driver (which actually knows how to talk to the hardware) at which point it will be completed. This is how Windows achieves driver layering. Project Evil now simulates most of this. if_ndis now has a modevent handler which will use MOD_LOAD and MOD_UNLOAD events to drive the creation and destruction of DRIVER_OBJECTs. (The load event also does the relocation/dynalinking of the image.) We don't have a registry, so the DRIVER_OBJECTS are stored in a linked list for now. Eventually, the list entry will contain the vendor/device ID list extracted from the .INF file. When ndis_probe() is called and detectes a supported device, it will create a PDO for the device instance and attach it to the DRIVER_OBJECT just as in Windows. ndis_attach() will then call our NdisAddDevice() handler to create the FDO. The NDIS miniport block is now a device extension hung off the FDO, just as it is in Windows. The miniport characteristics table is now an extension hung off the DRIVER_OBJECT as well (the characteristics are the same for all devices handled by a given driver, so they don't need to be per-instance.) We also do an IoAttachDeviceToDeviceStack() to put the FDO on the stack for the PDO. There are a couple of fake bus drivers created for the PCI and pccard buses. Eventually, there will be one for USB, which will actually accept USB IRP.s Things should still work just as before, only now we do things in the proper order and maintain the correct framework to support passing IRPs between drivers. Various changes: - corrected the comments about IRQL handling in subr_hal.c to more accurately reflect reality - update ndiscvt to make the drv_data symbol in ndis_driver_data.h a global so that if_ndis_pci.o and/or if_ndis_pccard.o can see it. - Obtain the softc pointer from the miniport block by referencing the PDO rather than a private pointer of our own (nmb_ifp is no longer used) - implement IoAttachDeviceToDeviceStack(), IoDetachDevice(), IoGetAttachedDevice(), IoAllocateDriverObjectExtension(), IoGetDriverObjectExtension(), IoCreateDevice(), IoDeleteDevice(), IoAllocateIrp(), IoReuseIrp(), IoMakeAssociatedIrp(), IoFreeIrp(), IoInitializeIrp() - fix a few mistakes in the driver_object and device_object definitions - add a new module, kern_windrv.c, to handle the driver registration and relocation/dynalinkign duties (which don't really belong in kern_ndis.c). - made ndis_block and ndis_chars in the ndis_softc stucture pointers and modified all references to it - fixed NdisMRegisterMiniport() and NdisInitializeWrapper() so they work correctly with the new driver_object mechanism - changed ndis_attach() to call NdisAddDevice() instead of ndis_load_driver() (which is now deprecated) - used ExAllocatePoolWithTag()/ExFreePool() in lookaside list routines instead of kludged up alloc/free routines - added kern_windrv.c to sys/modules/ndis/Makefile and files.i386.
2005-02-08 17:23:25 +00:00
hz * sc->ndis_block->nmb_checkforhangsecs);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return;
}
/*
* Set media options.
*/
static int
ndis_ifmedia_upd(ifp)
struct ifnet *ifp;
{
struct ndis_softc *sc;
sc = ifp->if_softc;
Fix two problems: - In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags used for shared memory allocations with a lowaddr of 0x3E7FFFFF. This forces the buffers to be mapped to physical/bus addresses within the first 1GB of physical memory. It seems that at least one card (Linksys Instant Wireless PCI V2.7) depends on this behavior. I don't know if this is a hardware restriction, or if the NDIS driver for this card is truncating the addresses itself, but using physical/bus addresses beyong the 1GB limit causes initialization failures. - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in if_ndis.c to test whether the device has been initialized rather than checking for the presence of the IFF_UP flag in if_flags. While debugging the previous problem, I noticed that bringing up the device would always produce failures from ndis_setmulti(). It turns out that the following steps now occur during device initialization: - IFF_UP flag is set in if_flags - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) - ifp->if_ioctl() called with SIOCADDMULTI - ifp->if_ioctl() called with SIOCADDMULTI (again) - ifp->if_ioctl() called with SIOCADDMULTI (yet again) - ifp->if_ioctl() called with SIOCSIFFLAGS Setting the receive filter and multicast filters can only be done when the underlying NDIS driver has been initialized, which is done by ifp->if_init(). However, we don't call ifp->if_init() until ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been set. It appears that now, the network stack tries to add multicast addresses to interface's filter before those steps occur. Normally, ndis_setmulti() would trap this condition by checking for the IFF_UP flag, but the network code has in fact set this flag already, so ndis_setmulti() is fooled into thinking the interface has been initialized when it really hasn't. It turns out this is usually harmless because the ifp->if_init() routine (in this case ndis_init()) will set up the multicast filter when it initializes the hardware anyway, and the underlying routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC haven't been initialized yet, but you end up spurious error messages on the console all the time. Something tells me this new behavior isn't really correct. I think the intention was to fix it so that ifp->if_init() is only called once when we ifconfig an interface up, but the end result seems a little bogus: the change of the IFF_UP flag should be propagated down to the driver before calling any other ioctl() that might actually require the hardware to be up and running.
2004-07-07 17:46:30 +00:00
if (NDIS_INITIALIZED(sc))
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
ndis_init(sc);
return(0);
}
/*
* Report current media status.
*/
static void
ndis_ifmedia_sts(ifp, ifmr)
struct ifnet *ifp;
struct ifmediareq *ifmr;
{
struct ndis_softc *sc;
uint32_t media_info;
ndis_media_state linkstate;
int error, len;
Back out the last batch of changes until I have a chance to properly evaluate them. Whatever they're meant to do, they're doing it wrong. Also: - Clean up last bits of NULL fallout in subr_pe - Don't let ndis_ifmedia_sts() do anything if the IFF_UP flag isn't set - Implement NdisSystemProcessorCount() and NdisQueryMapRegisterCount().
2003-12-26 03:31:34 +00:00
ifmr->ifm_status = IFM_AVALID;
ifmr->ifm_active = IFM_ETHER;
Fix two problems: - In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags used for shared memory allocations with a lowaddr of 0x3E7FFFFF. This forces the buffers to be mapped to physical/bus addresses within the first 1GB of physical memory. It seems that at least one card (Linksys Instant Wireless PCI V2.7) depends on this behavior. I don't know if this is a hardware restriction, or if the NDIS driver for this card is truncating the addresses itself, but using physical/bus addresses beyong the 1GB limit causes initialization failures. - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in if_ndis.c to test whether the device has been initialized rather than checking for the presence of the IFF_UP flag in if_flags. While debugging the previous problem, I noticed that bringing up the device would always produce failures from ndis_setmulti(). It turns out that the following steps now occur during device initialization: - IFF_UP flag is set in if_flags - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) - ifp->if_ioctl() called with SIOCADDMULTI - ifp->if_ioctl() called with SIOCADDMULTI (again) - ifp->if_ioctl() called with SIOCADDMULTI (yet again) - ifp->if_ioctl() called with SIOCSIFFLAGS Setting the receive filter and multicast filters can only be done when the underlying NDIS driver has been initialized, which is done by ifp->if_init(). However, we don't call ifp->if_init() until ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been set. It appears that now, the network stack tries to add multicast addresses to interface's filter before those steps occur. Normally, ndis_setmulti() would trap this condition by checking for the IFF_UP flag, but the network code has in fact set this flag already, so ndis_setmulti() is fooled into thinking the interface has been initialized when it really hasn't. It turns out this is usually harmless because the ifp->if_init() routine (in this case ndis_init()) will set up the multicast filter when it initializes the hardware anyway, and the underlying routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC haven't been initialized yet, but you end up spurious error messages on the console all the time. Something tells me this new behavior isn't really correct. I think the intention was to fix it so that ifp->if_init() is only called once when we ifconfig an interface up, but the end result seems a little bogus: the change of the IFF_UP flag should be propagated down to the driver before calling any other ioctl() that might actually require the hardware to be up and running.
2004-07-07 17:46:30 +00:00
sc = ifp->if_softc;
Back out the last batch of changes until I have a chance to properly evaluate them. Whatever they're meant to do, they're doing it wrong. Also: - Clean up last bits of NULL fallout in subr_pe - Don't let ndis_ifmedia_sts() do anything if the IFF_UP flag isn't set - Implement NdisSystemProcessorCount() and NdisQueryMapRegisterCount().
2003-12-26 03:31:34 +00:00
Fix two problems: - In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags used for shared memory allocations with a lowaddr of 0x3E7FFFFF. This forces the buffers to be mapped to physical/bus addresses within the first 1GB of physical memory. It seems that at least one card (Linksys Instant Wireless PCI V2.7) depends on this behavior. I don't know if this is a hardware restriction, or if the NDIS driver for this card is truncating the addresses itself, but using physical/bus addresses beyong the 1GB limit causes initialization failures. - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in if_ndis.c to test whether the device has been initialized rather than checking for the presence of the IFF_UP flag in if_flags. While debugging the previous problem, I noticed that bringing up the device would always produce failures from ndis_setmulti(). It turns out that the following steps now occur during device initialization: - IFF_UP flag is set in if_flags - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) - ifp->if_ioctl() called with SIOCADDMULTI - ifp->if_ioctl() called with SIOCADDMULTI (again) - ifp->if_ioctl() called with SIOCADDMULTI (yet again) - ifp->if_ioctl() called with SIOCSIFFLAGS Setting the receive filter and multicast filters can only be done when the underlying NDIS driver has been initialized, which is done by ifp->if_init(). However, we don't call ifp->if_init() until ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been set. It appears that now, the network stack tries to add multicast addresses to interface's filter before those steps occur. Normally, ndis_setmulti() would trap this condition by checking for the IFF_UP flag, but the network code has in fact set this flag already, so ndis_setmulti() is fooled into thinking the interface has been initialized when it really hasn't. It turns out this is usually harmless because the ifp->if_init() routine (in this case ndis_init()) will set up the multicast filter when it initializes the hardware anyway, and the underlying routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC haven't been initialized yet, but you end up spurious error messages on the console all the time. Something tells me this new behavior isn't really correct. I think the intention was to fix it so that ifp->if_init() is only called once when we ifconfig an interface up, but the end result seems a little bogus: the change of the IFF_UP flag should be propagated down to the driver before calling any other ioctl() that might actually require the hardware to be up and running.
2004-07-07 17:46:30 +00:00
if (!NDIS_INITIALIZED(sc))
Back out the last batch of changes until I have a chance to properly evaluate them. Whatever they're meant to do, they're doing it wrong. Also: - Clean up last bits of NULL fallout in subr_pe - Don't let ndis_ifmedia_sts() do anything if the IFF_UP flag isn't set - Implement NdisSystemProcessorCount() and NdisQueryMapRegisterCount().
2003-12-26 03:31:34 +00:00
return;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
len = sizeof(linkstate);
error = ndis_get_info(sc, OID_GEN_MEDIA_CONNECT_STATUS,
(void *)&linkstate, &len);
len = sizeof(media_info);
error = ndis_get_info(sc, OID_GEN_LINK_SPEED,
(void *)&media_info, &len);
if (linkstate == nmc_connected)
ifmr->ifm_status |= IFM_ACTIVE;
switch(media_info) {
case 100000:
ifmr->ifm_active |= IFM_10_T;
break;
case 1000000:
ifmr->ifm_active |= IFM_100_TX;
break;
case 10000000:
ifmr->ifm_active |= IFM_1000_T;
break;
default:
Clean up ndiscvt a bit (leaving out the -i flag didn't work) and add copyrights to the inf parser files. Add a -n flag to ndiscvt to allow the user to override the default device name of NDIS devices. Instead of "ndis0, ndis1, etc..." you can have "foo0, foo1, etc..." This allows you to have more than one kind of NDIS device in the kernel at the same time. Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c and subr_ndis.c. Create UMA zones for ndis_packet and ndis_buffer structs allocated on transmit. The zones are created and destroyed in the modevent handler in kern_ndis.c. printf() and UMA changes submitted by green@freebsd.org
2004-01-02 04:31:06 +00:00
device_printf(sc->ndis_dev, "unknown speed: %d\n", media_info);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
break;
}
return;
}
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
static void
ndis_setstate_80211(sc)
struct ndis_softc *sc;
{
struct ieee80211com *ic;
ndis_80211_ssid ssid;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
ndis_80211_config config;
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
ndis_80211_wep wep;
int i, rval = 0, len;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
uint32_t arg;
struct ifnet *ifp;
ic = &sc->ic;
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
ifp = &sc->arpcom.ac_if;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
Fix two problems: - In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags used for shared memory allocations with a lowaddr of 0x3E7FFFFF. This forces the buffers to be mapped to physical/bus addresses within the first 1GB of physical memory. It seems that at least one card (Linksys Instant Wireless PCI V2.7) depends on this behavior. I don't know if this is a hardware restriction, or if the NDIS driver for this card is truncating the addresses itself, but using physical/bus addresses beyong the 1GB limit causes initialization failures. - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in if_ndis.c to test whether the device has been initialized rather than checking for the presence of the IFF_UP flag in if_flags. While debugging the previous problem, I noticed that bringing up the device would always produce failures from ndis_setmulti(). It turns out that the following steps now occur during device initialization: - IFF_UP flag is set in if_flags - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) - ifp->if_ioctl() called with SIOCADDMULTI - ifp->if_ioctl() called with SIOCADDMULTI (again) - ifp->if_ioctl() called with SIOCADDMULTI (yet again) - ifp->if_ioctl() called with SIOCSIFFLAGS Setting the receive filter and multicast filters can only be done when the underlying NDIS driver has been initialized, which is done by ifp->if_init(). However, we don't call ifp->if_init() until ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been set. It appears that now, the network stack tries to add multicast addresses to interface's filter before those steps occur. Normally, ndis_setmulti() would trap this condition by checking for the IFF_UP flag, but the network code has in fact set this flag already, so ndis_setmulti() is fooled into thinking the interface has been initialized when it really hasn't. It turns out this is usually harmless because the ifp->if_init() routine (in this case ndis_init()) will set up the multicast filter when it initializes the hardware anyway, and the underlying routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC haven't been initialized yet, but you end up spurious error messages on the console all the time. Something tells me this new behavior isn't really correct. I think the intention was to fix it so that ifp->if_init() is only called once when we ifconfig an interface up, but the end result seems a little bogus: the change of the IFF_UP flag should be propagated down to the driver before calling any other ioctl() that might actually require the hardware to be up and running.
2004-07-07 17:46:30 +00:00
if (!NDIS_INITIALIZED(sc))
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
return;
/* Set network infrastructure mode. */
len = sizeof(arg);
if (ic->ic_opmode == IEEE80211_M_IBSS)
arg = NDIS_80211_NET_INFRA_IBSS;
else
arg = NDIS_80211_NET_INFRA_BSS;
rval = ndis_set_info(sc, OID_802_11_INFRASTRUCTURE_MODE, &arg, &len);
if (rval)
Clean up ndiscvt a bit (leaving out the -i flag didn't work) and add copyrights to the inf parser files. Add a -n flag to ndiscvt to allow the user to override the default device name of NDIS devices. Instead of "ndis0, ndis1, etc..." you can have "foo0, foo1, etc..." This allows you to have more than one kind of NDIS device in the kernel at the same time. Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c and subr_ndis.c. Create UMA zones for ndis_packet and ndis_buffer structs allocated on transmit. The zones are created and destroyed in the modevent handler in kern_ndis.c. printf() and UMA changes submitted by green@freebsd.org
2004-01-02 04:31:06 +00:00
device_printf (sc->ndis_dev, "set infra failed: %d\n", rval);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
/* Set WEP */
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
#ifdef IEEE80211_F_PRIVACY
if (ic->ic_flags & IEEE80211_F_PRIVACY) {
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
#else
if (ic->ic_wep_mode >= IEEE80211_WEP_ON) {
#endif
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
for (i = 0; i < IEEE80211_WEP_NKID; i++) {
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
if (ic->ic_nw_keys[i].wk_keylen) {
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
bzero((char *)&wep, sizeof(wep));
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
wep.nw_keylen = ic->ic_nw_keys[i].wk_keylen;
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
#ifdef notdef
/* 5 and 13 are the only valid key lengths */
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
if (ic->ic_nw_keys[i].wk_keylen < 5)
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
wep.nw_keylen = 5;
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
else if (ic->ic_nw_keys[i].wk_keylen > 5 &&
ic->ic_nw_keys[i].wk_keylen < 13)
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
wep.nw_keylen = 13;
#endif
wep.nw_keyidx = i;
wep.nw_length = (sizeof(uint32_t) * 3)
+ wep.nw_keylen;
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
if (i == ic->ic_def_txkey)
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
wep.nw_keyidx |= NDIS_80211_WEPKEY_TX;
bcopy(ic->ic_nw_keys[i].wk_key,
wep.nw_keydata, wep.nw_length);
len = sizeof(wep);
rval = ndis_set_info(sc,
OID_802_11_ADD_WEP, &wep, &len);
if (rval)
Clean up ndiscvt a bit (leaving out the -i flag didn't work) and add copyrights to the inf parser files. Add a -n flag to ndiscvt to allow the user to override the default device name of NDIS devices. Instead of "ndis0, ndis1, etc..." you can have "foo0, foo1, etc..." This allows you to have more than one kind of NDIS device in the kernel at the same time. Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c and subr_ndis.c. Create UMA zones for ndis_packet and ndis_buffer structs allocated on transmit. The zones are created and destroyed in the modevent handler in kern_ndis.c. printf() and UMA changes submitted by green@freebsd.org
2004-01-02 04:31:06 +00:00
device_printf(sc->ndis_dev,
"set wepkey failed: %d\n", rval);
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
}
}
arg = NDIS_80211_WEPSTAT_ENABLED;
len = sizeof(arg);
rval = ndis_set_info(sc, OID_802_11_WEP_STATUS, &arg, &len);
if (rval)
Clean up ndiscvt a bit (leaving out the -i flag didn't work) and add copyrights to the inf parser files. Add a -n flag to ndiscvt to allow the user to override the default device name of NDIS devices. Instead of "ndis0, ndis1, etc..." you can have "foo0, foo1, etc..." This allows you to have more than one kind of NDIS device in the kernel at the same time. Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c and subr_ndis.c. Create UMA zones for ndis_packet and ndis_buffer structs allocated on transmit. The zones are created and destroyed in the modevent handler in kern_ndis.c. printf() and UMA changes submitted by green@freebsd.org
2004-01-02 04:31:06 +00:00
device_printf(sc->ndis_dev,
"enable WEP failed: %d\n", rval);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
#ifndef IEEE80211_F_WEPON
Fix compilation and correct mapping from struct ifnet to struct ieee80211com after net80211 import. Submitted by: Tor Egge
2004-12-10 00:59:27 +00:00
#if 0
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
if (ic->ic_wep_mode != IEEE80211_WEP_8021X &&
ic->ic_wep_mode != IEEE80211_WEP_ON)
arg = NDIS_80211_PRIVFILT_ACCEPTALL;
else
Fix compilation and correct mapping from struct ifnet to struct ieee80211com after net80211 import. Submitted by: Tor Egge
2004-12-10 00:59:27 +00:00
#endif
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
#endif
arg = NDIS_80211_PRIVFILT_8021XWEP;
len = sizeof(arg);
rval = ndis_set_info(sc, OID_802_11_PRIVACY_FILTER, &arg, &len);
#ifdef IEEE80211_WEP_8021X /*IEEE80211_F_WEPON*/
/* Accept that we only have "shared" and 802.1x modes. */
if (rval == 0) {
if (arg == NDIS_80211_PRIVFILT_ACCEPTALL)
ic->ic_wep_mode = IEEE80211_WEP_MIXED;
else
ic->ic_wep_mode = IEEE80211_WEP_8021X;
}
#endif
- Rewrite the timer and event API routines in subr_ndis.c so that they are actually layered on top of the KeTimer API in subr_ntoskrnl.c, just as it is in Windows. This reduces code duplication and more closely imitates the way things are done in Windows. - Modify ndis_encode_parm() to deal with the case where we have a registry key expressed as a hex value ("0x1") which is being read via NdisReadConfiguration() as an int. Previously, we tried to decode things like "0x1" with strtol() using a base of 10, which would always yield 0. This is what was causing problems with the Intel 2200BG Centrino 802.11g driver: the .inf file that comes with it has a key called RadioEnable with a value of 0x1. We incorrectly decoded this value to '0' when it was queried, hence the driver thought we wanted the radio turned off. - In if_ndis.c, most drivers don't accept NDIS_80211_AUTHMODE_AUTO, but NDIS_80211_AUTHMODE_SHARED may not be right in some cases, so for now always use NDIS_80211_AUTHMODE_OPEN. NOTE: There is still one problem with the Intel 2200BG driver: it happens that the kernel stack in Windows is larger than the kernel stack in FreeBSD. The 2200BG driver sometimes eats up more than 2 pages of stack space, which can lead to a double fault panic. For the moment, I got things to work by adding the following to my kernel config file: options KSTACK_PAGES=8 I'm pretty sure 8 is too big; I just picked this value out of a hat as a test, and it happened to work, so I left it. 4 pages might be enough. Unfortunately, I don't think you can dynamically give a thread a larger stack, so I'm not sure how to handle this short of putting a note in the man page about it and dealing with the flood of mail from people who never read man pages.
2004-03-20 23:39:43 +00:00
arg = NDIS_80211_AUTHMODE_OPEN;
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
} else {
arg = NDIS_80211_WEPSTAT_DISABLED;
len = sizeof(arg);
ndis_set_info(sc, OID_802_11_WEP_STATUS, &arg, &len);
Add a kludge to avoid having ndis_init() called needlessly by dhclient on an SIOCSIFADDR (by way of brain damage in net80211). Also, avoid trying to set NDIS_80211_AUTHMODE_AUTO since the Microsoft documentation I have recommends not using it, and the Centrino driver seems to dislike being told to use it.
2004-01-27 07:57:42 +00:00
arg = NDIS_80211_AUTHMODE_OPEN;
- Add new 802.11 OID information obtained from NDIS 5.1 update to ndis_var.h - In kern_ndis.c:ndis_send_packets(), avoid dereferencing NULL pointers created when the driver's send routine immediately calls the txeof handler (which releases the packets for us anyway). - In if_ndis.c:ndis_80211_setstate(), implement WEP support.
2003-12-30 21:33:26 +00:00
}
Add a kludge to avoid having ndis_init() called needlessly by dhclient on an SIOCSIFADDR (by way of brain damage in net80211). Also, avoid trying to set NDIS_80211_AUTHMODE_AUTO since the Microsoft documentation I have recommends not using it, and the Centrino driver seems to dislike being told to use it.
2004-01-27 07:57:42 +00:00
len = sizeof(arg);
rval = ndis_set_info(sc, OID_802_11_AUTHENTICATION_MODE, &arg, &len);
Go back to using AUTHMODE_AUTO if WEP is on. In some cases, the Centrino won't associate in BSS mode if you use AUTHMODE_SHARED. I probably don't understand enough to know when SHARED should be used vs. OPEN or WPA. For now, go back to what works.
2004-01-29 03:16:58 +00:00
#ifdef notyet
Add a kludge to avoid having ndis_init() called needlessly by dhclient on an SIOCSIFADDR (by way of brain damage in net80211). Also, avoid trying to set NDIS_80211_AUTHMODE_AUTO since the Microsoft documentation I have recommends not using it, and the Centrino driver seems to dislike being told to use it.
2004-01-27 07:57:42 +00:00
if (rval)
device_printf (sc->ndis_dev, "set auth failed: %d\n", rval);
Go back to using AUTHMODE_AUTO if WEP is on. In some cases, the Centrino won't associate in BSS mode if you use AUTHMODE_SHARED. I probably don't understand enough to know when SHARED should be used vs. OPEN or WPA. For now, go back to what works.
2004-01-29 03:16:58 +00:00
#endif
Add a kludge to avoid having ndis_init() called needlessly by dhclient on an SIOCSIFADDR (by way of brain damage in net80211). Also, avoid trying to set NDIS_80211_AUTHMODE_AUTO since the Microsoft documentation I have recommends not using it, and the Centrino driver seems to dislike being told to use it.
2004-01-27 07:57:42 +00:00
In subr_ndis.c, when searching for keys in our make-pretend registry, make the key name matching case-insensitive. There are some drivers and .inf files that have mismatched cases, e.g. the driver will look for "AdhocBand" whereas the .inf file specifies a registry key to be created called "AdHocBand." The mismatch is probably a typo that went undetected (so much for QA), but since Windows seems to be case-insensitive, we should be too. In if_ndis.c, initialize rates and channels correctly so that specify frequences correctly when trying to set channels in the 5Ghz band, and so that 802.11b rates show up for some a/b/g cards (which otherwise appear to have no 802.11b modes). Also, when setting OID_802_11_CONFIGURATION in ndis_80211_setstate(), provide default values for the beacon interval, ATIM window and dwelltime. The Atheros "Aries" driver will crash if you try to select ad-hoc mode and leave the beacon interval set to 0: it blindly uses this value and does a division by 0 in the interrupt handler, causing an integer divide trap.
2004-05-29 06:41:17 +00:00
#ifdef notyet
/* Set network type. */
arg = 0;
switch (ic->ic_curmode) {
case IEEE80211_MODE_11A:
arg = NDIS_80211_NETTYPE_11OFDM5;
break;
case IEEE80211_MODE_11B:
arg = NDIS_80211_NETTYPE_11DS;
break;
case IEEE80211_MODE_11G:
arg = NDIS_80211_NETTYPE_11OFDM24;
break;
default:
device_printf(sc->ndis_dev, "unknown mode: %d\n",
ic->ic_curmode);
}
if (arg) {
len = sizeof(arg);
rval = ndis_set_info(sc, OID_802_11_NETWORK_TYPE_IN_USE,
&arg, &len);
if (rval)
device_printf (sc->ndis_dev,
"set nettype failed: %d\n", rval);
}
Unbreak the Intel 2100 Centrino wireless driver (and probably others): - In subr_ndis.c, my_strcasecmp() actually behaved like my_strncasecmp(): we really need it to behave like the former, not the latter. (It was falsely matching "RadioEnable", which defaults to 1 with "RadioEnableHW" which the driver creates itself and to 0, because we were using strlen("RadioEnable") as the length to test. This caused the radio to always be turned off. :( ) - In if_ndis.c, only set IEEE80211_CHAN_A for channels if we actually set any IEEE80211_MODE_11A rates. (ieee80211_attach() will "helpfully" add IEEE80211_MODE_11A to ic_modecaps for you if you initialize any 802.11a channels. This caused "ndis0: 11a rates:" to erroneously be displayed during driver load.) - Also in if_ndis.c, when using TESTSETRATE() to add in any missing 802.11b rates, remember to OR the rates with IEEE80211_RATE_BASIC, otherwise comparing against existing basic rates won't match. (1, 2, 5.5 and 11Mbps are basic rates, according to the 802.11b spec.) This erroneously cause 11Mbps to be added to the 11b rate list twice.
2004-06-04 04:43:36 +00:00
#endif
In subr_ndis.c, when searching for keys in our make-pretend registry, make the key name matching case-insensitive. There are some drivers and .inf files that have mismatched cases, e.g. the driver will look for "AdhocBand" whereas the .inf file specifies a registry key to be created called "AdHocBand." The mismatch is probably a typo that went undetected (so much for QA), but since Windows seems to be case-insensitive, we should be too. In if_ndis.c, initialize rates and channels correctly so that specify frequences correctly when trying to set channels in the 5Ghz band, and so that 802.11b rates show up for some a/b/g cards (which otherwise appear to have no 802.11b modes). Also, when setting OID_802_11_CONFIGURATION in ndis_80211_setstate(), provide default values for the beacon interval, ATIM window and dwelltime. The Atheros "Aries" driver will crash if you try to select ad-hoc mode and leave the beacon interval set to 0: it blindly uses this value and does a division by 0 in the interrupt handler, causing an integer divide trap.
2004-05-29 06:41:17 +00:00
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
len = sizeof(config);
Implement support for single packet sends. The Intel Centrino driver that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
2004-02-03 07:39:23 +00:00
bzero((char *)&config, len);
config.nc_length = len;
config.nc_fhconfig.ncf_length = sizeof(ndis_80211_config_fh);
Continue my efforts to imitate Windows as closely as possible by attempting to duplicate Windows spinlocks. Windows spinlocks differ from FreeBSD spinlocks in the way they block preemption. FreeBSD spinlocks use critical_enter(), which masks off _all_ interrupts. This prevents any other threads from being scheduled, but it also prevents ISRs from running. In Windows, preemption is achieved by raising the processor IRQL to DISPATCH_LEVEL, which prevents other threads from preempting you, but does _not_ prevent device ISRs from running. (This is essentially what Solaris calls dispatcher locks.) The Windows spinlock itself (kspin_lock) is just an integer value which is atomically set when you acquire the lock and atomically cleared when you release it. FreeBSD doesn't have IRQ levels, so we have to cheat a little by using thread priorities: normal thread priority is PASSIVE_LEVEL, lowest interrupt thread priority is DISPATCH_LEVEL, highest thread priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL matter to us. The immediate benefit of all this is that I no longer have to rely on a mutex pool. Now, I'm sure many people will be seized by the urge to criticize me for doing an end run around our own spinlock implementation, but it makes more sense to do it this way. Well, it does to me anyway. Overview of the changes: - Properly implement hal_lock(), hal_unlock(), hal_irql(), hal_raise_irql() and hal_lower_irql() so that they more closely resemble their Windows counterparts. The IRQL is determined by thread priority. - Make ntoskrnl_lock_dpc() and ntoskrnl_unlock_dpc() do what they do in Windows, which is to atomically set/clear the lock value. These routines are designed to be called from DISPATCH_LEVEL, and are actually half of the work involved in acquiring/releasing spinlocks. - Add FASTCALL1(), FASTCALL2() and FASTCALL3() macros/wrappers that allow us to call a _fastcall function in spite of the fact that our version of gcc doesn't support __attribute__((__fastcall__)) yet. The macros take 1, 2 or 3 arguments, respectively. We need to call hal_lock(), hal_unlock() etc... ourselves, but can't really invoke the function directly. I could have just made the underlying functions native routines and put _fastcall wrappers around them for the benefit of Windows binaries, but that would create needless bloat. - Remove ndis_mtxpool and all references to it. We don't need it anymore. - Re-implement the NdisSpinLock routines so that they use hal_lock() and friends like they do in Windows. - Use the new spinlock methods for handling lookaside lists and linked list updates in place of the mutex locks that were there before. - Remove mutex locking from ndis_isr() and ndis_intrhand() since they're already called with ndis_intrmtx held in if_ndis.c. - Put ndis_destroy_lock() code under explicit #ifdef notdef/#endif. It turns out there are some drivers which stupidly free the memory in which their spinlocks reside before calling ndis_destroy_lock() on them (touch-after-free bug). The ADMtek wireless driver is guilty of this faux pas. (Why this doesn't clobber Windows I have no idea.) - Make NdisDprAcquireSpinLock() and NdisDprReleaseSpinLock() into real functions instead of aliasing them to NdisAcaquireSpinLock() and NdisReleaseSpinLock(). The Dpr routines use KeAcquireSpinLockAtDpcLevel() level and KeReleaseSpinLockFromDpcLevel(), which acquires the lock without twiddling the IRQL. - In ndis_linksts_done(), do _not_ call ndis_80211_getstate(). Some drivers may call the status/status done callbacks as the result of setting an OID: ndis_80211_getstate() gets OIDs, which means we might cause the driver to recursively access some of its internal structures unexpectedly. The ndis_ticktask() routine will call ndis_80211_getstate() for us eventually anyway. - Fix the channel setting code a little in ndis_80211_setstate(), and initialize the channel to IEEE80211_CHAN_ANYC. (The Microsoft spec says you're not supposed to twiddle the channel in BSS mode; I may need to enforce this later.) This fixes the problems I was having with the ADMtek adm8211 driver: we were setting the channel to a non-standard default, which would cause it to fail to associate in BSS mode. - Use hal_raise_irql() to raise our IRQL to DISPATCH_LEVEL when calling certain miniport routines, per the Microsoft documentation. I think that's everything. Hopefully, other than fixing the ADMtek driver, there should be no apparent change in behavior.
2004-04-14 07:48:03 +00:00
rval = ndis_get_info(sc, OID_802_11_CONFIGURATION, &config, &len);
In subr_ndis.c, when searching for keys in our make-pretend registry, make the key name matching case-insensitive. There are some drivers and .inf files that have mismatched cases, e.g. the driver will look for "AdhocBand" whereas the .inf file specifies a registry key to be created called "AdHocBand." The mismatch is probably a typo that went undetected (so much for QA), but since Windows seems to be case-insensitive, we should be too. In if_ndis.c, initialize rates and channels correctly so that specify frequences correctly when trying to set channels in the 5Ghz band, and so that 802.11b rates show up for some a/b/g cards (which otherwise appear to have no 802.11b modes). Also, when setting OID_802_11_CONFIGURATION in ndis_80211_setstate(), provide default values for the beacon interval, ATIM window and dwelltime. The Atheros "Aries" driver will crash if you try to select ad-hoc mode and leave the beacon interval set to 0: it blindly uses this value and does a division by 0 in the interrupt handler, causing an integer divide trap.
2004-05-29 06:41:17 +00:00
/*
* Some drivers expect us to initialize these values, so
* provide some defaults.
*/
if (config.nc_beaconperiod == 0)
config.nc_beaconperiod = 100;
if (config.nc_atimwin == 0)
config.nc_atimwin = 100;
if (config.nc_fhconfig.ncf_dwelltime == 0)
config.nc_fhconfig.ncf_dwelltime = 200;
Continue my efforts to imitate Windows as closely as possible by attempting to duplicate Windows spinlocks. Windows spinlocks differ from FreeBSD spinlocks in the way they block preemption. FreeBSD spinlocks use critical_enter(), which masks off _all_ interrupts. This prevents any other threads from being scheduled, but it also prevents ISRs from running. In Windows, preemption is achieved by raising the processor IRQL to DISPATCH_LEVEL, which prevents other threads from preempting you, but does _not_ prevent device ISRs from running. (This is essentially what Solaris calls dispatcher locks.) The Windows spinlock itself (kspin_lock) is just an integer value which is atomically set when you acquire the lock and atomically cleared when you release it. FreeBSD doesn't have IRQ levels, so we have to cheat a little by using thread priorities: normal thread priority is PASSIVE_LEVEL, lowest interrupt thread priority is DISPATCH_LEVEL, highest thread priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL matter to us. The immediate benefit of all this is that I no longer have to rely on a mutex pool. Now, I'm sure many people will be seized by the urge to criticize me for doing an end run around our own spinlock implementation, but it makes more sense to do it this way. Well, it does to me anyway. Overview of the changes: - Properly implement hal_lock(), hal_unlock(), hal_irql(), hal_raise_irql() and hal_lower_irql() so that they more closely resemble their Windows counterparts. The IRQL is determined by thread priority. - Make ntoskrnl_lock_dpc() and ntoskrnl_unlock_dpc() do what they do in Windows, which is to atomically set/clear the lock value. These routines are designed to be called from DISPATCH_LEVEL, and are actually half of the work involved in acquiring/releasing spinlocks. - Add FASTCALL1(), FASTCALL2() and FASTCALL3() macros/wrappers that allow us to call a _fastcall function in spite of the fact that our version of gcc doesn't support __attribute__((__fastcall__)) yet. The macros take 1, 2 or 3 arguments, respectively. We need to call hal_lock(), hal_unlock() etc... ourselves, but can't really invoke the function directly. I could have just made the underlying functions native routines and put _fastcall wrappers around them for the benefit of Windows binaries, but that would create needless bloat. - Remove ndis_mtxpool and all references to it. We don't need it anymore. - Re-implement the NdisSpinLock routines so that they use hal_lock() and friends like they do in Windows. - Use the new spinlock methods for handling lookaside lists and linked list updates in place of the mutex locks that were there before. - Remove mutex locking from ndis_isr() and ndis_intrhand() since they're already called with ndis_intrmtx held in if_ndis.c. - Put ndis_destroy_lock() code under explicit #ifdef notdef/#endif. It turns out there are some drivers which stupidly free the memory in which their spinlocks reside before calling ndis_destroy_lock() on them (touch-after-free bug). The ADMtek wireless driver is guilty of this faux pas. (Why this doesn't clobber Windows I have no idea.) - Make NdisDprAcquireSpinLock() and NdisDprReleaseSpinLock() into real functions instead of aliasing them to NdisAcaquireSpinLock() and NdisReleaseSpinLock(). The Dpr routines use KeAcquireSpinLockAtDpcLevel() level and KeReleaseSpinLockFromDpcLevel(), which acquires the lock without twiddling the IRQL. - In ndis_linksts_done(), do _not_ call ndis_80211_getstate(). Some drivers may call the status/status done callbacks as the result of setting an OID: ndis_80211_getstate() gets OIDs, which means we might cause the driver to recursively access some of its internal structures unexpectedly. The ndis_ticktask() routine will call ndis_80211_getstate() for us eventually anyway. - Fix the channel setting code a little in ndis_80211_setstate(), and initialize the channel to IEEE80211_CHAN_ANYC. (The Microsoft spec says you're not supposed to twiddle the channel in BSS mode; I may need to enforce this later.) This fixes the problems I was having with the ADMtek adm8211 driver: we were setting the channel to a non-standard default, which would cause it to fail to associate in BSS mode. - Use hal_raise_irql() to raise our IRQL to DISPATCH_LEVEL when calling certain miniport routines, per the Microsoft documentation. I think that's everything. Hopefully, other than fixing the ADMtek driver, there should be no apparent change in behavior.
2004-04-14 07:48:03 +00:00
if (rval == 0 && ic->ic_ibss_chan != IEEE80211_CHAN_ANYC) {
int chan, chanflag;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
Continue my efforts to imitate Windows as closely as possible by attempting to duplicate Windows spinlocks. Windows spinlocks differ from FreeBSD spinlocks in the way they block preemption. FreeBSD spinlocks use critical_enter(), which masks off _all_ interrupts. This prevents any other threads from being scheduled, but it also prevents ISRs from running. In Windows, preemption is achieved by raising the processor IRQL to DISPATCH_LEVEL, which prevents other threads from preempting you, but does _not_ prevent device ISRs from running. (This is essentially what Solaris calls dispatcher locks.) The Windows spinlock itself (kspin_lock) is just an integer value which is atomically set when you acquire the lock and atomically cleared when you release it. FreeBSD doesn't have IRQ levels, so we have to cheat a little by using thread priorities: normal thread priority is PASSIVE_LEVEL, lowest interrupt thread priority is DISPATCH_LEVEL, highest thread priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL matter to us. The immediate benefit of all this is that I no longer have to rely on a mutex pool. Now, I'm sure many people will be seized by the urge to criticize me for doing an end run around our own spinlock implementation, but it makes more sense to do it this way. Well, it does to me anyway. Overview of the changes: - Properly implement hal_lock(), hal_unlock(), hal_irql(), hal_raise_irql() and hal_lower_irql() so that they more closely resemble their Windows counterparts. The IRQL is determined by thread priority. - Make ntoskrnl_lock_dpc() and ntoskrnl_unlock_dpc() do what they do in Windows, which is to atomically set/clear the lock value. These routines are designed to be called from DISPATCH_LEVEL, and are actually half of the work involved in acquiring/releasing spinlocks. - Add FASTCALL1(), FASTCALL2() and FASTCALL3() macros/wrappers that allow us to call a _fastcall function in spite of the fact that our version of gcc doesn't support __attribute__((__fastcall__)) yet. The macros take 1, 2 or 3 arguments, respectively. We need to call hal_lock(), hal_unlock() etc... ourselves, but can't really invoke the function directly. I could have just made the underlying functions native routines and put _fastcall wrappers around them for the benefit of Windows binaries, but that would create needless bloat. - Remove ndis_mtxpool and all references to it. We don't need it anymore. - Re-implement the NdisSpinLock routines so that they use hal_lock() and friends like they do in Windows. - Use the new spinlock methods for handling lookaside lists and linked list updates in place of the mutex locks that were there before. - Remove mutex locking from ndis_isr() and ndis_intrhand() since they're already called with ndis_intrmtx held in if_ndis.c. - Put ndis_destroy_lock() code under explicit #ifdef notdef/#endif. It turns out there are some drivers which stupidly free the memory in which their spinlocks reside before calling ndis_destroy_lock() on them (touch-after-free bug). The ADMtek wireless driver is guilty of this faux pas. (Why this doesn't clobber Windows I have no idea.) - Make NdisDprAcquireSpinLock() and NdisDprReleaseSpinLock() into real functions instead of aliasing them to NdisAcaquireSpinLock() and NdisReleaseSpinLock(). The Dpr routines use KeAcquireSpinLockAtDpcLevel() level and KeReleaseSpinLockFromDpcLevel(), which acquires the lock without twiddling the IRQL. - In ndis_linksts_done(), do _not_ call ndis_80211_getstate(). Some drivers may call the status/status done callbacks as the result of setting an OID: ndis_80211_getstate() gets OIDs, which means we might cause the driver to recursively access some of its internal structures unexpectedly. The ndis_ticktask() routine will call ndis_80211_getstate() for us eventually anyway. - Fix the channel setting code a little in ndis_80211_setstate(), and initialize the channel to IEEE80211_CHAN_ANYC. (The Microsoft spec says you're not supposed to twiddle the channel in BSS mode; I may need to enforce this later.) This fixes the problems I was having with the ADMtek adm8211 driver: we were setting the channel to a non-standard default, which would cause it to fail to associate in BSS mode. - Use hal_raise_irql() to raise our IRQL to DISPATCH_LEVEL when calling certain miniport routines, per the Microsoft documentation. I think that's everything. Hopefully, other than fixing the ADMtek driver, there should be no apparent change in behavior.
2004-04-14 07:48:03 +00:00
chan = ieee80211_chan2ieee(ic, ic->ic_ibss_chan);
chanflag = config.nc_dsconfig > 2500000 ? IEEE80211_CHAN_2GHZ :
IEEE80211_CHAN_5GHZ;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
if (chan != ieee80211_mhz2ieee(config.nc_dsconfig / 1000, 0)) {
config.nc_dsconfig =
Continue my efforts to imitate Windows as closely as possible by attempting to duplicate Windows spinlocks. Windows spinlocks differ from FreeBSD spinlocks in the way they block preemption. FreeBSD spinlocks use critical_enter(), which masks off _all_ interrupts. This prevents any other threads from being scheduled, but it also prevents ISRs from running. In Windows, preemption is achieved by raising the processor IRQL to DISPATCH_LEVEL, which prevents other threads from preempting you, but does _not_ prevent device ISRs from running. (This is essentially what Solaris calls dispatcher locks.) The Windows spinlock itself (kspin_lock) is just an integer value which is atomically set when you acquire the lock and atomically cleared when you release it. FreeBSD doesn't have IRQ levels, so we have to cheat a little by using thread priorities: normal thread priority is PASSIVE_LEVEL, lowest interrupt thread priority is DISPATCH_LEVEL, highest thread priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL matter to us. The immediate benefit of all this is that I no longer have to rely on a mutex pool. Now, I'm sure many people will be seized by the urge to criticize me for doing an end run around our own spinlock implementation, but it makes more sense to do it this way. Well, it does to me anyway. Overview of the changes: - Properly implement hal_lock(), hal_unlock(), hal_irql(), hal_raise_irql() and hal_lower_irql() so that they more closely resemble their Windows counterparts. The IRQL is determined by thread priority. - Make ntoskrnl_lock_dpc() and ntoskrnl_unlock_dpc() do what they do in Windows, which is to atomically set/clear the lock value. These routines are designed to be called from DISPATCH_LEVEL, and are actually half of the work involved in acquiring/releasing spinlocks. - Add FASTCALL1(), FASTCALL2() and FASTCALL3() macros/wrappers that allow us to call a _fastcall function in spite of the fact that our version of gcc doesn't support __attribute__((__fastcall__)) yet. The macros take 1, 2 or 3 arguments, respectively. We need to call hal_lock(), hal_unlock() etc... ourselves, but can't really invoke the function directly. I could have just made the underlying functions native routines and put _fastcall wrappers around them for the benefit of Windows binaries, but that would create needless bloat. - Remove ndis_mtxpool and all references to it. We don't need it anymore. - Re-implement the NdisSpinLock routines so that they use hal_lock() and friends like they do in Windows. - Use the new spinlock methods for handling lookaside lists and linked list updates in place of the mutex locks that were there before. - Remove mutex locking from ndis_isr() and ndis_intrhand() since they're already called with ndis_intrmtx held in if_ndis.c. - Put ndis_destroy_lock() code under explicit #ifdef notdef/#endif. It turns out there are some drivers which stupidly free the memory in which their spinlocks reside before calling ndis_destroy_lock() on them (touch-after-free bug). The ADMtek wireless driver is guilty of this faux pas. (Why this doesn't clobber Windows I have no idea.) - Make NdisDprAcquireSpinLock() and NdisDprReleaseSpinLock() into real functions instead of aliasing them to NdisAcaquireSpinLock() and NdisReleaseSpinLock(). The Dpr routines use KeAcquireSpinLockAtDpcLevel() level and KeReleaseSpinLockFromDpcLevel(), which acquires the lock without twiddling the IRQL. - In ndis_linksts_done(), do _not_ call ndis_80211_getstate(). Some drivers may call the status/status done callbacks as the result of setting an OID: ndis_80211_getstate() gets OIDs, which means we might cause the driver to recursively access some of its internal structures unexpectedly. The ndis_ticktask() routine will call ndis_80211_getstate() for us eventually anyway. - Fix the channel setting code a little in ndis_80211_setstate(), and initialize the channel to IEEE80211_CHAN_ANYC. (The Microsoft spec says you're not supposed to twiddle the channel in BSS mode; I may need to enforce this later.) This fixes the problems I was having with the ADMtek adm8211 driver: we were setting the channel to a non-standard default, which would cause it to fail to associate in BSS mode. - Use hal_raise_irql() to raise our IRQL to DISPATCH_LEVEL when calling certain miniport routines, per the Microsoft documentation. I think that's everything. Hopefully, other than fixing the ADMtek driver, there should be no apparent change in behavior.
2004-04-14 07:48:03 +00:00
ic->ic_ibss_chan->ic_freq * 1000;
ic->ic_bss->ni_chan = ic->ic_ibss_chan;
Implement support for single packet sends. The Intel Centrino driver that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
2004-02-03 07:39:23 +00:00
len = sizeof(config);
config.nc_length = len;
config.nc_fhconfig.ncf_length =
sizeof(ndis_80211_config_fh);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
rval = ndis_set_info(sc, OID_802_11_CONFIGURATION,
&config, &len);
if (rval)
device_printf(sc->ndis_dev, "couldn't change "
"DS config to %ukHz: %d\n",
config.nc_dsconfig, rval);
}
Continue my efforts to imitate Windows as closely as possible by attempting to duplicate Windows spinlocks. Windows spinlocks differ from FreeBSD spinlocks in the way they block preemption. FreeBSD spinlocks use critical_enter(), which masks off _all_ interrupts. This prevents any other threads from being scheduled, but it also prevents ISRs from running. In Windows, preemption is achieved by raising the processor IRQL to DISPATCH_LEVEL, which prevents other threads from preempting you, but does _not_ prevent device ISRs from running. (This is essentially what Solaris calls dispatcher locks.) The Windows spinlock itself (kspin_lock) is just an integer value which is atomically set when you acquire the lock and atomically cleared when you release it. FreeBSD doesn't have IRQ levels, so we have to cheat a little by using thread priorities: normal thread priority is PASSIVE_LEVEL, lowest interrupt thread priority is DISPATCH_LEVEL, highest thread priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL matter to us. The immediate benefit of all this is that I no longer have to rely on a mutex pool. Now, I'm sure many people will be seized by the urge to criticize me for doing an end run around our own spinlock implementation, but it makes more sense to do it this way. Well, it does to me anyway. Overview of the changes: - Properly implement hal_lock(), hal_unlock(), hal_irql(), hal_raise_irql() and hal_lower_irql() so that they more closely resemble their Windows counterparts. The IRQL is determined by thread priority. - Make ntoskrnl_lock_dpc() and ntoskrnl_unlock_dpc() do what they do in Windows, which is to atomically set/clear the lock value. These routines are designed to be called from DISPATCH_LEVEL, and are actually half of the work involved in acquiring/releasing spinlocks. - Add FASTCALL1(), FASTCALL2() and FASTCALL3() macros/wrappers that allow us to call a _fastcall function in spite of the fact that our version of gcc doesn't support __attribute__((__fastcall__)) yet. The macros take 1, 2 or 3 arguments, respectively. We need to call hal_lock(), hal_unlock() etc... ourselves, but can't really invoke the function directly. I could have just made the underlying functions native routines and put _fastcall wrappers around them for the benefit of Windows binaries, but that would create needless bloat. - Remove ndis_mtxpool and all references to it. We don't need it anymore. - Re-implement the NdisSpinLock routines so that they use hal_lock() and friends like they do in Windows. - Use the new spinlock methods for handling lookaside lists and linked list updates in place of the mutex locks that were there before. - Remove mutex locking from ndis_isr() and ndis_intrhand() since they're already called with ndis_intrmtx held in if_ndis.c. - Put ndis_destroy_lock() code under explicit #ifdef notdef/#endif. It turns out there are some drivers which stupidly free the memory in which their spinlocks reside before calling ndis_destroy_lock() on them (touch-after-free bug). The ADMtek wireless driver is guilty of this faux pas. (Why this doesn't clobber Windows I have no idea.) - Make NdisDprAcquireSpinLock() and NdisDprReleaseSpinLock() into real functions instead of aliasing them to NdisAcaquireSpinLock() and NdisReleaseSpinLock(). The Dpr routines use KeAcquireSpinLockAtDpcLevel() level and KeReleaseSpinLockFromDpcLevel(), which acquires the lock without twiddling the IRQL. - In ndis_linksts_done(), do _not_ call ndis_80211_getstate(). Some drivers may call the status/status done callbacks as the result of setting an OID: ndis_80211_getstate() gets OIDs, which means we might cause the driver to recursively access some of its internal structures unexpectedly. The ndis_ticktask() routine will call ndis_80211_getstate() for us eventually anyway. - Fix the channel setting code a little in ndis_80211_setstate(), and initialize the channel to IEEE80211_CHAN_ANYC. (The Microsoft spec says you're not supposed to twiddle the channel in BSS mode; I may need to enforce this later.) This fixes the problems I was having with the ADMtek adm8211 driver: we were setting the channel to a non-standard default, which would cause it to fail to associate in BSS mode. - Use hal_raise_irql() to raise our IRQL to DISPATCH_LEVEL when calling certain miniport routines, per the Microsoft documentation. I think that's everything. Hopefully, other than fixing the ADMtek driver, there should be no apparent change in behavior.
2004-04-14 07:48:03 +00:00
} else if (rval)
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
device_printf(sc->ndis_dev, "couldn't retrieve "
"channel info: %d\n", rval);
Continue my efforts to imitate Windows as closely as possible by attempting to duplicate Windows spinlocks. Windows spinlocks differ from FreeBSD spinlocks in the way they block preemption. FreeBSD spinlocks use critical_enter(), which masks off _all_ interrupts. This prevents any other threads from being scheduled, but it also prevents ISRs from running. In Windows, preemption is achieved by raising the processor IRQL to DISPATCH_LEVEL, which prevents other threads from preempting you, but does _not_ prevent device ISRs from running. (This is essentially what Solaris calls dispatcher locks.) The Windows spinlock itself (kspin_lock) is just an integer value which is atomically set when you acquire the lock and atomically cleared when you release it. FreeBSD doesn't have IRQ levels, so we have to cheat a little by using thread priorities: normal thread priority is PASSIVE_LEVEL, lowest interrupt thread priority is DISPATCH_LEVEL, highest thread priority is DEVICE_LEVEL (PI_REALTIME) and critical_enter() is HIGH_LEVEL. In practice, only PASSIVE_LEVEL and DISPATCH_LEVEL matter to us. The immediate benefit of all this is that I no longer have to rely on a mutex pool. Now, I'm sure many people will be seized by the urge to criticize me for doing an end run around our own spinlock implementation, but it makes more sense to do it this way. Well, it does to me anyway. Overview of the changes: - Properly implement hal_lock(), hal_unlock(), hal_irql(), hal_raise_irql() and hal_lower_irql() so that they more closely resemble their Windows counterparts. The IRQL is determined by thread priority. - Make ntoskrnl_lock_dpc() and ntoskrnl_unlock_dpc() do what they do in Windows, which is to atomically set/clear the lock value. These routines are designed to be called from DISPATCH_LEVEL, and are actually half of the work involved in acquiring/releasing spinlocks. - Add FASTCALL1(), FASTCALL2() and FASTCALL3() macros/wrappers that allow us to call a _fastcall function in spite of the fact that our version of gcc doesn't support __attribute__((__fastcall__)) yet. The macros take 1, 2 or 3 arguments, respectively. We need to call hal_lock(), hal_unlock() etc... ourselves, but can't really invoke the function directly. I could have just made the underlying functions native routines and put _fastcall wrappers around them for the benefit of Windows binaries, but that would create needless bloat. - Remove ndis_mtxpool and all references to it. We don't need it anymore. - Re-implement the NdisSpinLock routines so that they use hal_lock() and friends like they do in Windows. - Use the new spinlock methods for handling lookaside lists and linked list updates in place of the mutex locks that were there before. - Remove mutex locking from ndis_isr() and ndis_intrhand() since they're already called with ndis_intrmtx held in if_ndis.c. - Put ndis_destroy_lock() code under explicit #ifdef notdef/#endif. It turns out there are some drivers which stupidly free the memory in which their spinlocks reside before calling ndis_destroy_lock() on them (touch-after-free bug). The ADMtek wireless driver is guilty of this faux pas. (Why this doesn't clobber Windows I have no idea.) - Make NdisDprAcquireSpinLock() and NdisDprReleaseSpinLock() into real functions instead of aliasing them to NdisAcaquireSpinLock() and NdisReleaseSpinLock(). The Dpr routines use KeAcquireSpinLockAtDpcLevel() level and KeReleaseSpinLockFromDpcLevel(), which acquires the lock without twiddling the IRQL. - In ndis_linksts_done(), do _not_ call ndis_80211_getstate(). Some drivers may call the status/status done callbacks as the result of setting an OID: ndis_80211_getstate() gets OIDs, which means we might cause the driver to recursively access some of its internal structures unexpectedly. The ndis_ticktask() routine will call ndis_80211_getstate() for us eventually anyway. - Fix the channel setting code a little in ndis_80211_setstate(), and initialize the channel to IEEE80211_CHAN_ANYC. (The Microsoft spec says you're not supposed to twiddle the channel in BSS mode; I may need to enforce this later.) This fixes the problems I was having with the ADMtek adm8211 driver: we were setting the channel to a non-standard default, which would cause it to fail to associate in BSS mode. - Use hal_raise_irql() to raise our IRQL to DISPATCH_LEVEL when calling certain miniport routines, per the Microsoft documentation. I think that's everything. Hopefully, other than fixing the ADMtek driver, there should be no apparent change in behavior.
2004-04-14 07:48:03 +00:00
/* Set SSID -- always do this last. */
len = sizeof(ssid);
bzero((char *)&ssid, len);
ssid.ns_ssidlen = ic->ic_des_esslen;
if (ssid.ns_ssidlen == 0) {
ssid.ns_ssidlen = 1;
} else
bcopy(ic->ic_des_essid, ssid.ns_ssid, ssid.ns_ssidlen);
rval = ndis_set_info(sc, OID_802_11_SSID, &ssid, &len);
if (rval)
device_printf (sc->ndis_dev, "set ssid failed: %d\n", rval);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
return;
}
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
static void
ndis_media_status(struct ifnet *ifp, struct ifmediareq *imr)
{
Fix compilation and correct mapping from struct ifnet to struct ieee80211com after net80211 import. Submitted by: Tor Egge
2004-12-10 00:59:27 +00:00
struct ieee80211com *ic = &((struct ndis_softc *)ifp->if_softc)->ic;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
struct ieee80211_node *ni = NULL;
imr->ifm_status = IFM_AVALID;
imr->ifm_active = IFM_IEEE80211;
if (ic->ic_state == IEEE80211_S_RUN)
imr->ifm_status |= IFM_ACTIVE;
imr->ifm_active |= IFM_AUTO;
switch (ic->ic_opmode) {
case IEEE80211_M_STA:
ni = ic->ic_bss;
/* calculate rate subtype */
imr->ifm_active |= ieee80211_rate2media(ic,
ni->ni_rates.rs_rates[ni->ni_txrate], ic->ic_curmode);
break;
case IEEE80211_M_IBSS:
ni = ic->ic_bss;
/* calculate rate subtype */
imr->ifm_active |= ieee80211_rate2media(ic,
ni->ni_rates.rs_rates[ni->ni_txrate], ic->ic_curmode);
imr->ifm_active |= IFM_IEEE80211_ADHOC;
break;
case IEEE80211_M_AHDEMO:
/* should not come here */
break;
case IEEE80211_M_HOSTAP:
imr->ifm_active |= IFM_IEEE80211_HOSTAP;
break;
case IEEE80211_M_MONITOR:
imr->ifm_active |= IFM_IEEE80211_MONITOR;
break;
}
switch (ic->ic_curmode) {
case IEEE80211_MODE_11A:
imr->ifm_active |= IFM_MAKEMODE(IFM_IEEE80211_11A);
break;
case IEEE80211_MODE_11B:
imr->ifm_active |= IFM_MAKEMODE(IFM_IEEE80211_11B);
break;
case IEEE80211_MODE_11G:
imr->ifm_active |= IFM_MAKEMODE(IFM_IEEE80211_11G);
break;
Fix compilation and correct mapping from struct ifnet to struct ieee80211com after net80211 import. Submitted by: Tor Egge
2004-12-10 00:59:27 +00:00
case IEEE80211_MODE_TURBO_A:
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
imr->ifm_active |= IFM_MAKEMODE(IFM_IEEE80211_11A)
| IFM_IEEE80211_TURBO;
break;
}
}
static int
ndis_get_assoc(sc, assoc)
struct ndis_softc *sc;
The ndis_wlan_bssid_ex structure we retrieve in ndis_get_assoc() is variable length, so we should not be trying to copy it into a fixed length buffer, especially one on the stack. malloc() a buffer of the right size and return a pointer to that instead. Fixes a crash I discovered when testing whe a Cisco AP in infrastructure mode, which returns several information elements that make the ndis_wlan_bssid_ex structure larger than expected.
2004-03-24 05:35:03 +00:00
ndis_wlan_bssid_ex **assoc;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
{
ndis_80211_bssid_list_ex *bl;
ndis_wlan_bssid_ex *bs;
ndis_80211_macaddr bssid;
int i, len, error;
Add missing newlines to some device_printf()s. Don't do anything in ndis_get_assoc() if the link isn't up (avoids spurrious "couldn't get bssid" messages on the console).
2004-01-24 02:48:22 +00:00
if (!sc->ndis_link)
return(ENOENT);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
len = sizeof(bssid);
error = ndis_get_info(sc, OID_802_11_BSSID, &bssid, &len);
if (error) {
Add missing newlines to some device_printf()s. Don't do anything in ndis_get_assoc() if the link isn't up (avoids spurrious "couldn't get bssid" messages on the console).
2004-01-24 02:48:22 +00:00
device_printf(sc->ndis_dev, "failed to get bssid\n");
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
return(ENOENT);
}
len = 0;
error = ndis_get_info(sc, OID_802_11_BSSID_LIST, NULL, &len);
if (error != ENOSPC) {
Add missing newlines to some device_printf()s. Don't do anything in ndis_get_assoc() if the link isn't up (avoids spurrious "couldn't get bssid" messages on the console).
2004-01-24 02:48:22 +00:00
device_printf(sc->ndis_dev, "bssid_list failed\n");
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
return (error);
}
Use the M_BZERO flag with malloc() in a couple of places.
2004-01-27 03:14:59 +00:00
bl = malloc(len, M_TEMP, M_NOWAIT|M_ZERO);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
error = ndis_get_info(sc, OID_802_11_BSSID_LIST, bl, &len);
if (error) {
free(bl, M_TEMP);
Add missing newlines to some device_printf()s. Don't do anything in ndis_get_assoc() if the link isn't up (avoids spurrious "couldn't get bssid" messages on the console).
2004-01-24 02:48:22 +00:00
device_printf(sc->ndis_dev, "bssid_list failed\n");
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
return (error);
}
bs = (ndis_wlan_bssid_ex *)&bl->nblx_bssid[0];
for (i = 0; i < bl->nblx_items; i++) {
if (bcmp(bs->nwbx_macaddr, bssid, sizeof(bssid)) == 0) {
The ndis_wlan_bssid_ex structure we retrieve in ndis_get_assoc() is variable length, so we should not be trying to copy it into a fixed length buffer, especially one on the stack. malloc() a buffer of the right size and return a pointer to that instead. Fixes a crash I discovered when testing whe a Cisco AP in infrastructure mode, which returns several information elements that make the ndis_wlan_bssid_ex structure larger than expected.
2004-03-24 05:35:03 +00:00
*assoc = malloc(bs->nwbx_len, M_TEMP, M_NOWAIT);
if (*assoc == NULL) {
free(bl, M_TEMP);
return(ENOMEM);
}
bcopy((char *)bs, (char *)*assoc, bs->nwbx_len);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
free(bl, M_TEMP);
return(0);
}
bs = (ndis_wlan_bssid_ex *)((char *)bs + bs->nwbx_len);
}
free(bl, M_TEMP);
return(ENOENT);
}
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
static void
ndis_getstate_80211(sc)
struct ndis_softc *sc;
{
struct ieee80211com *ic;
ndis_80211_ssid ssid;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
ndis_80211_config config;
The ndis_wlan_bssid_ex structure we retrieve in ndis_get_assoc() is variable length, so we should not be trying to copy it into a fixed length buffer, especially one on the stack. malloc() a buffer of the right size and return a pointer to that instead. Fixes a crash I discovered when testing whe a Cisco AP in infrastructure mode, which returns several information elements that make the ndis_wlan_bssid_ex structure larger than expected.
2004-03-24 05:35:03 +00:00
ndis_wlan_bssid_ex *bs;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
int rval, len, i = 0;
uint32_t arg;
struct ifnet *ifp;
ic = &sc->ic;
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
ifp = &sc->arpcom.ac_if;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
Fix two problems: - In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags used for shared memory allocations with a lowaddr of 0x3E7FFFFF. This forces the buffers to be mapped to physical/bus addresses within the first 1GB of physical memory. It seems that at least one card (Linksys Instant Wireless PCI V2.7) depends on this behavior. I don't know if this is a hardware restriction, or if the NDIS driver for this card is truncating the addresses itself, but using physical/bus addresses beyong the 1GB limit causes initialization failures. - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in if_ndis.c to test whether the device has been initialized rather than checking for the presence of the IFF_UP flag in if_flags. While debugging the previous problem, I noticed that bringing up the device would always produce failures from ndis_setmulti(). It turns out that the following steps now occur during device initialization: - IFF_UP flag is set in if_flags - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) - ifp->if_ioctl() called with SIOCADDMULTI - ifp->if_ioctl() called with SIOCADDMULTI (again) - ifp->if_ioctl() called with SIOCADDMULTI (yet again) - ifp->if_ioctl() called with SIOCSIFFLAGS Setting the receive filter and multicast filters can only be done when the underlying NDIS driver has been initialized, which is done by ifp->if_init(). However, we don't call ifp->if_init() until ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been set. It appears that now, the network stack tries to add multicast addresses to interface's filter before those steps occur. Normally, ndis_setmulti() would trap this condition by checking for the IFF_UP flag, but the network code has in fact set this flag already, so ndis_setmulti() is fooled into thinking the interface has been initialized when it really hasn't. It turns out this is usually harmless because the ifp->if_init() routine (in this case ndis_init()) will set up the multicast filter when it initializes the hardware anyway, and the underlying routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC haven't been initialized yet, but you end up spurious error messages on the console all the time. Something tells me this new behavior isn't really correct. I think the intention was to fix it so that ifp->if_init() is only called once when we ifconfig an interface up, but the end result seems a little bogus: the change of the IFF_UP flag should be propagated down to the driver before calling any other ioctl() that might actually require the hardware to be up and running.
2004-07-07 17:46:30 +00:00
if (!NDIS_INITIALIZED(sc))
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
return;
- Add stubs for Ndis*File() functions - Fix ndis_time(). - Implement NdisGetSystemUpTime(). - Implement RtlCopyUnicodeString() and RtlUnicodeStringToAnsiString(). - In ndis_getstate_80211(), use sc->ndis_link to determine connect status. Submitted by: Brian Feldman <green@freebsd.org>
2003-12-25 00:40:02 +00:00
if (sc->ndis_link)
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
ic->ic_state = IEEE80211_S_RUN;
else
ic->ic_state = IEEE80211_S_ASSOC;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
/*
* If we're associated, retrieve info on the current bssid.
*/
Implement support for single packet sends. The Intel Centrino driver that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
2004-02-03 07:39:23 +00:00
if ((rval = ndis_get_assoc(sc, &bs)) == 0) {
The ndis_wlan_bssid_ex structure we retrieve in ndis_get_assoc() is variable length, so we should not be trying to copy it into a fixed length buffer, especially one on the stack. malloc() a buffer of the right size and return a pointer to that instead. Fixes a crash I discovered when testing whe a Cisco AP in infrastructure mode, which returns several information elements that make the ndis_wlan_bssid_ex structure larger than expected.
2004-03-24 05:35:03 +00:00
switch(bs->nwbx_nettype) {
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
case NDIS_80211_NETTYPE_11FH:
case NDIS_80211_NETTYPE_11DS:
ic->ic_curmode = IEEE80211_MODE_11B;
break;
case NDIS_80211_NETTYPE_11OFDM5:
ic->ic_curmode = IEEE80211_MODE_11A;
break;
case NDIS_80211_NETTYPE_11OFDM24:
ic->ic_curmode = IEEE80211_MODE_11G;
break;
default:
device_printf(sc->ndis_dev,
"unknown nettype %d\n", arg);
break;
}
record the bssid for an association Tested by: Daniel O'Connor
2004-12-12 07:45:42 +00:00
IEEE80211_ADDR_COPY(ic->ic_bss->ni_bssid, bs->nwbx_macaddr);
The ndis_wlan_bssid_ex structure we retrieve in ndis_get_assoc() is variable length, so we should not be trying to copy it into a fixed length buffer, especially one on the stack. malloc() a buffer of the right size and return a pointer to that instead. Fixes a crash I discovered when testing whe a Cisco AP in infrastructure mode, which returns several information elements that make the ndis_wlan_bssid_ex structure larger than expected.
2004-03-24 05:35:03 +00:00
free(bs, M_TEMP);
Implement support for single packet sends. The Intel Centrino driver that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
2004-02-03 07:39:23 +00:00
} else
return;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
len = sizeof(ssid);
bzero((char *)&ssid, len);
rval = ndis_get_info(sc, OID_802_11_SSID, &ssid, &len);
if (rval)
Clean up ndiscvt a bit (leaving out the -i flag didn't work) and add copyrights to the inf parser files. Add a -n flag to ndiscvt to allow the user to override the default device name of NDIS devices. Instead of "ndis0, ndis1, etc..." you can have "foo0, foo1, etc..." This allows you to have more than one kind of NDIS device in the kernel at the same time. Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c and subr_ndis.c. Create UMA zones for ndis_packet and ndis_buffer structs allocated on transmit. The zones are created and destroyed in the modevent handler in kern_ndis.c. printf() and UMA changes submitted by green@freebsd.org
2004-01-02 04:31:06 +00:00
device_printf (sc->ndis_dev, "get ssid failed: %d\n", rval);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
bcopy(ssid.ns_ssid, ic->ic_bss->ni_essid, ssid.ns_ssidlen);
ic->ic_bss->ni_esslen = ssid.ns_ssidlen;
len = sizeof(arg);
rval = ndis_get_info(sc, OID_GEN_LINK_SPEED, &arg, &len);
Implement support for single packet sends. The Intel Centrino driver that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
2004-02-03 07:39:23 +00:00
if (rval)
device_printf (sc->ndis_dev, "get link speed failed: %d\n",
rval);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
if (ic->ic_modecaps & (1<<IEEE80211_MODE_11B)) {
ic->ic_bss->ni_rates = ic->ic_sup_rates[IEEE80211_MODE_11B];
for (i = 0; i < ic->ic_bss->ni_rates.rs_nrates; i++) {
if ((ic->ic_bss->ni_rates.rs_rates[i] &
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
IEEE80211_RATE_VAL) == arg / 5000)
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
break;
}
}
if (i == ic->ic_bss->ni_rates.rs_nrates &&
ic->ic_modecaps & (1<<IEEE80211_MODE_11G)) {
ic->ic_bss->ni_rates = ic->ic_sup_rates[IEEE80211_MODE_11G];
for (i = 0; i < ic->ic_bss->ni_rates.rs_nrates; i++) {
if ((ic->ic_bss->ni_rates.rs_rates[i] &
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
IEEE80211_RATE_VAL) == arg / 5000)
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
break;
}
}
if (i == ic->ic_bss->ni_rates.rs_nrates)
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
device_printf(sc->ndis_dev, "no matching rate for: %d\n",
arg / 5000);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
else
ic->ic_bss->ni_txrate = i;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
if (ic->ic_caps & IEEE80211_C_PMGT) {
len = sizeof(arg);
rval = ndis_get_info(sc, OID_802_11_POWER_MODE, &arg, &len);
if (rval)
device_printf(sc->ndis_dev,
"get power mode failed: %d\n", rval);
if (arg == NDIS_80211_POWERMODE_CAM)
ic->ic_flags &= ~IEEE80211_F_PMGTON;
else
ic->ic_flags |= IEEE80211_F_PMGTON;
}
len = sizeof(config);
Implement support for single packet sends. The Intel Centrino driver that Asus provides on its CDs has both a MiniportSend() routine and a MiniportSendPackets() function. The Microsoft NDIS docs say that if a driver has both, only the MiniportSendPackets() routine will be used. Although I think I implemented the support correctly, calling the MiniportSend() routine seems to result in no packets going out on the air, even though no error status is returned. The MiniportSendPackets() function does work though, so at least in this case it doesn't matter. In if_ndis.c:ndis_getstate_80211(), if ndis_get_assoc() returns an error, don't bother trying to obtain any other state since the calls may fail, or worse cause the underlying driver to crash. (The above two changes make the Asus-supplied Centrino work.) Also, when calling the OID_802_11_CONFIGURATION OID, remember to initialize the structure lengths correctly. In subr_ndis.c:ndis_open_file(), set the current working directory to rootvnode if we're in a thread that doesn't have a current working directory set.
2004-02-03 07:39:23 +00:00
bzero((char *)&config, len);
config.nc_length = len;
config.nc_fhconfig.ncf_length = sizeof(ndis_80211_config_fh);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
rval = ndis_get_info(sc, OID_802_11_CONFIGURATION, &config, &len);
if (rval == 0) {
int chan;
chan = ieee80211_mhz2ieee(config.nc_dsconfig / 1000, 0);
if (chan < 0 || chan >= IEEE80211_CHAN_MAX) {
if (ifp->if_flags & IFF_DEBUG)
device_printf(sc->ndis_dev, "current channel "
"(%uMHz) out of bounds\n",
config.nc_dsconfig / 1000);
ic->ic_bss->ni_chan = &ic->ic_channels[1];
} else
ic->ic_bss->ni_chan = &ic->ic_channels[chan];
} else
device_printf(sc->ndis_dev, "couldn't retrieve "
"channel info: %d\n", rval);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
/*
len = sizeof(arg);
rval = ndis_get_info(sc, OID_802_11_WEP_STATUS, &arg, &len);
if (rval)
Clean up ndiscvt a bit (leaving out the -i flag didn't work) and add copyrights to the inf parser files. Add a -n flag to ndiscvt to allow the user to override the default device name of NDIS devices. Instead of "ndis0, ndis1, etc..." you can have "foo0, foo1, etc..." This allows you to have more than one kind of NDIS device in the kernel at the same time. Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c and subr_ndis.c. Create UMA zones for ndis_packet and ndis_buffer structs allocated on transmit. The zones are created and destroyed in the modevent handler in kern_ndis.c. printf() and UMA changes submitted by green@freebsd.org
2004-01-02 04:31:06 +00:00
device_printf (sc->ndis_dev,
"get wep status failed: %d\n", rval);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
if (arg == NDIS_80211_WEPSTAT_ENABLED)
ic->ic_flags |= IEEE80211_F_WEPON;
else
ic->ic_flags &= ~IEEE80211_F_WEPON;
*/
return;
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
static int
ndis_ioctl(ifp, command, data)
struct ifnet *ifp;
u_long command;
caddr_t data;
{
struct ndis_softc *sc = ifp->if_softc;
struct ifreq *ifr = (struct ifreq *) data;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
int i, error = 0;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
/*NDIS_LOCK(sc);*/
switch(command) {
case SIOCSIFFLAGS:
if (ifp->if_flags & IFF_UP) {
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
if (ifp->if_flags & IFF_RUNNING &&
ifp->if_flags & IFF_PROMISC &&
!(sc->ndis_if_flags & IFF_PROMISC)) {
sc->ndis_filter |=
NDIS_PACKET_TYPE_PROMISCUOUS;
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
i = sizeof(sc->ndis_filter);
error = ndis_set_info(sc,
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
OID_GEN_CURRENT_PACKET_FILTER,
&sc->ndis_filter, &i);
} else if (ifp->if_flags & IFF_RUNNING &&
!(ifp->if_flags & IFF_PROMISC) &&
sc->ndis_if_flags & IFF_PROMISC) {
sc->ndis_filter &=
~NDIS_PACKET_TYPE_PROMISCUOUS;
Properly program the multicast filter in ndis_setmulti(), and fix promisc mode in ndis_ioctl().
2004-01-19 07:03:46 +00:00
i = sizeof(sc->ndis_filter);
error = ndis_set_info(sc,
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
OID_GEN_CURRENT_PACKET_FILTER,
&sc->ndis_filter, &i);
} else
ndis_init(sc);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
} else {
if (ifp->if_flags & IFF_RUNNING)
ndis_stop(sc);
}
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
sc->ndis_if_flags = ifp->if_flags;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
error = 0;
break;
case SIOCADDMULTI:
case SIOCDELMULTI:
ndis_setmulti(sc);
error = 0;
break;
case SIOCGIFMEDIA:
case SIOCSIFMEDIA:
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
if (sc->ndis_80211) {
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
error = ieee80211_ioctl(&sc->ic, command, data);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
if (error == ENETRESET) {
Add a kludge to avoid having ndis_init() called needlessly by dhclient on an SIOCSIFADDR (by way of brain damage in net80211). Also, avoid trying to set NDIS_80211_AUTHMODE_AUTO since the Microsoft documentation I have recommends not using it, and the Centrino driver seems to dislike being told to use it.
2004-01-27 07:57:42 +00:00
ndis_setstate_80211(sc);
/*ndis_init(sc);*/
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
error = 0;
}
} else
error = ifmedia_ioctl(ifp, ifr, &sc->ifmedia, command);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
break;
Add support for TCP/IP checksum offload. No, really.
2004-01-22 02:36:34 +00:00
case SIOCSIFCAP:
ifp->if_capenable = ifr->ifr_reqcap;
if (ifp->if_capenable & IFCAP_TXCSUM)
ifp->if_hwassist = sc->ndis_hwassist;
else
ifp->if_hwassist = 0;
ndis_set_offload(sc);
break;
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
case SIOCG80211:
if (sc->ndis_80211)
error = ndis_80211_ioctl_get(ifp, command, data);
else
error = ENOTTY;
break;
case SIOCS80211:
if (sc->ndis_80211)
error = ndis_80211_ioctl_set(ifp, command, data);
else
error = ENOTTY;
break;
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
case SIOCGIFGENERIC:
case SIOCSIFGENERIC:
Fix two problems: - In subr_ndis.c:ndis_allocate_sharemem(), create the busdma tags used for shared memory allocations with a lowaddr of 0x3E7FFFFF. This forces the buffers to be mapped to physical/bus addresses within the first 1GB of physical memory. It seems that at least one card (Linksys Instant Wireless PCI V2.7) depends on this behavior. I don't know if this is a hardware restriction, or if the NDIS driver for this card is truncating the addresses itself, but using physical/bus addresses beyong the 1GB limit causes initialization failures. - Create am NDIS_INITIALIZED() macro in if_ndisvar.h and use it in if_ndis.c to test whether the device has been initialized rather than checking for the presence of the IFF_UP flag in if_flags. While debugging the previous problem, I noticed that bringing up the device would always produce failures from ndis_setmulti(). It turns out that the following steps now occur during device initialization: - IFF_UP flag is set in if_flags - ifp->if_ioctl() called with SIOCSIFADDR (which we don't handle) - ifp->if_ioctl() called with SIOCADDMULTI - ifp->if_ioctl() called with SIOCADDMULTI (again) - ifp->if_ioctl() called with SIOCADDMULTI (yet again) - ifp->if_ioctl() called with SIOCSIFFLAGS Setting the receive filter and multicast filters can only be done when the underlying NDIS driver has been initialized, which is done by ifp->if_init(). However, we don't call ifp->if_init() until ifp->if_ioctl() is called with SIOCSIFFLAGS and IFF_UP has been set. It appears that now, the network stack tries to add multicast addresses to interface's filter before those steps occur. Normally, ndis_setmulti() would trap this condition by checking for the IFF_UP flag, but the network code has in fact set this flag already, so ndis_setmulti() is fooled into thinking the interface has been initialized when it really hasn't. It turns out this is usually harmless because the ifp->if_init() routine (in this case ndis_init()) will set up the multicast filter when it initializes the hardware anyway, and the underlying routines (ndis_get_info()/ndis_set_info()) know that the driver/NIC haven't been initialized yet, but you end up spurious error messages on the console all the time. Something tells me this new behavior isn't really correct. I think the intention was to fix it so that ifp->if_init() is only called once when we ifconfig an interface up, but the end result seems a little bogus: the change of the IFF_UP flag should be propagated down to the driver before calling any other ioctl() that might actually require the hardware to be up and running.
2004-07-07 17:46:30 +00:00
if (sc->ndis_80211 && NDIS_INITIALIZED(sc)) {
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
if (command == SIOCGIFGENERIC)
error = ndis_wi_ioctl_get(ifp, command, data);
else
error = ndis_wi_ioctl_set(ifp, command, data);
} else
error = ENOTTY;
if (error != ENOTTY)
break;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
default:
Add a kludge to avoid having ndis_init() called needlessly by dhclient on an SIOCSIFADDR (by way of brain damage in net80211). Also, avoid trying to set NDIS_80211_AUTHMODE_AUTO since the Microsoft documentation I have recommends not using it, and the Centrino driver seems to dislike being told to use it.
2004-01-27 07:57:42 +00:00
sc->ndis_skip = 1;
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
if (sc->ndis_80211) {
Update for net80211 changes.
2004-12-08 17:36:51 +00:00
error = ieee80211_ioctl(&sc->ic, command, data);
Big round of updates: - Make ndis_get_info()/ndis_set_info() sleep on the setdone/getdone routines if they get back NDIS_STATUS_PENDING. - Add a bunch of net80211 support so that 802.11 cards can be twiddled with ifconfig. This still needs more work and is not guaranteed to work for everyone. It works on my 802.11b/g card anyway. The problem here is Microsoft doesn't provide a good way to a) learn all the rates that a card supports (if it has more than 8, you're kinda hosed) and b) doesn't provide a good way to distinguish between 802.11b, 802.11b/g an 802.11a/b/g cards, so you sort of have to guess. Setting the SSID and switching between infrastructure/adhoc modes should work. WEP still needs to be implemented. I can't find any API for getting/setting the channel other than the registry/sysctl keys.
2003-12-21 00:00:08 +00:00
if (error == ENETRESET) {
ndis_setstate_80211(sc);
error = 0;
}
} else
error = ether_ioctl(ifp, command, data);
Add a kludge to avoid having ndis_init() called needlessly by dhclient on an SIOCSIFADDR (by way of brain damage in net80211). Also, avoid trying to set NDIS_80211_AUTHMODE_AUTO since the Microsoft documentation I have recommends not using it, and the Centrino driver seems to dislike being told to use it.
2004-01-27 07:57:42 +00:00
sc->ndis_skip = 0;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
break;
}
/*NDIS_UNLOCK(sc);*/
return(error);
}
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
static int
ndis_wi_ioctl_get(ifp, command, data)
struct ifnet *ifp;
u_long command;
caddr_t data;
{
struct wi_req wreq;
struct ifreq *ifr;
struct ndis_softc *sc;
ndis_80211_bssid_list_ex *bl;
ndis_wlan_bssid_ex *wb;
struct wi_apinfo *api;
int error, i, j, len, maxaps;
sc = ifp->if_softc;
ifr = (struct ifreq *)data;
error = copyin(ifr->ifr_data, &wreq, sizeof(wreq));
if (error)
return (error);
switch (wreq.wi_type) {
case WI_RID_READ_APS:
len = 0;
error = ndis_set_info(sc, OID_802_11_BSSID_LIST_SCAN,
NULL, &len);
if (error == 0)
tsleep(&error, PPAUSE|PCATCH, "ssidscan", hz * 2);
len = 0;
error = ndis_get_info(sc, OID_802_11_BSSID_LIST, NULL, &len);
if (error != ENOSPC)
break;
Use the M_BZERO flag with malloc() in a couple of places.
2004-01-27 03:14:59 +00:00
bl = malloc(len, M_DEVBUF, M_WAITOK|M_ZERO);
Merge in some changes submitted by Brian Feldman. Among other things, these add support for listing BSSIDs via wicontrol -l. I added code to call OID_802_11_BSSID_LIST_SCAN to allow scanning for any nearby wirelsss nets. Convert from using individual mutexes to a mutex pool, created in subr_ndis.c. This deals with the problem of drivers creating locks in their DriverEntry() routines which might get trashed later. Put some messages under IFF_DEBUG.
2004-01-12 03:49:20 +00:00
error = ndis_get_info(sc, OID_802_11_BSSID_LIST, bl, &len);
if (error) {
free(bl, M_DEVBUF);
break;
}
maxaps = (2 * wreq.wi_len - sizeof(int)) / sizeof(*api);
maxaps = MIN(maxaps, bl->nblx_items);
wreq.wi_len = (maxaps * sizeof(*api) + sizeof(int)) / 2;
*(int *)&wreq.wi_val = maxaps;
api = (struct wi_apinfo *)&((int *)&wreq.wi_val)[1];
wb = bl->nblx_bssid;
while (maxaps--) {
bzero(api, sizeof(*api));
bcopy(&wb->nwbx_macaddr, &api->bssid,
sizeof(api->bssid));
api->namelen = wb->nwbx_ssid.ns_ssidlen;
bcopy(&wb->nwbx_ssid.ns_ssid, &api->name, api->namelen);
if (wb->nwbx_privacy)
api->capinfo |= IEEE80211_CAPINFO_PRIVACY;
/* XXX Where can we get noise information? */
api->signal = wb->nwbx_rssi + 149; /* XXX */
api->quality = api->signal;
api->channel =
ieee80211_mhz2ieee(wb->nwbx_config.nc_dsconfig /
1000, 0);
/* In "auto" infrastructure mode, this is useless. */
if (wb->nwbx_netinfra == NDIS_80211_NET_INFRA_IBSS)
api->capinfo |= IEEE80211_CAPINFO_IBSS;
if (wb->nwbx_len > sizeof(ndis_wlan_bssid)) {
j = sizeof(ndis_80211_rates_ex);
/* handle other extended things */
} else
j = sizeof(ndis_80211_rates);
for (i = api->rate = 0; i < j; i++)
api->rate = MAX(api->rate, 5 *
(wb->nwbx_supportedrates[i] & 0x7f));
api++;
wb = (ndis_wlan_bssid_ex *)((char *)wb + wb->nwbx_len);
}
free(bl, M_DEVBUF);
error = copyout(&wreq, ifr->ifr_data, sizeof(wreq));
break;
default:
error = ENOTTY;
break;
}
return (error);
}
static int
ndis_wi_ioctl_set(ifp, command, data)
struct ifnet *ifp;
u_long command;
caddr_t data;
{
struct wi_req wreq;
struct ifreq *ifr;
struct ndis_softc *sc;
uint32_t foo;
int error, len;
error = suser(curthread);
if (error)
return (error);
sc = ifp->if_softc;
ifr = (struct ifreq *)data;
error = copyin(ifr->ifr_data, &wreq, sizeof(wreq));
if (error)
return (error);
switch (wreq.wi_type) {
case WI_RID_SCAN_APS:
case WI_RID_SCAN_REQ: /* arguments ignored */
len = sizeof(foo);
foo = 0;
error = ndis_set_info(sc, OID_802_11_BSSID_LIST_SCAN, &foo,
&len);
break;
default:
error = ENOTTY;
break;
}
return (error);
}
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
static int
ndis_80211_ioctl_get(struct ifnet *ifp, u_long command, caddr_t data)
{
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
struct ndis_softc *sc;
struct ieee80211req *ireq;
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
ndis_80211_bssid_list_ex *bl;
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
ndis_wlan_bssid_ex *wb;
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
struct ieee80211req_scan_result *sr, *bsr;
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
int error, len, i, j;
char *cp;
uint8_t nodename[IEEE80211_NWID_LEN];
uint16_t nodename_u[IEEE80211_NWID_LEN + 1];
char *acode;
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
sc = ifp->if_softc;
ireq = (struct ieee80211req *) data;
switch (ireq->i_type) {
case IEEE80211_IOC_SCAN_RESULTS:
len = 0;
error = ndis_get_info(sc, OID_802_11_BSSID_LIST, NULL, &len);
if (error != ENOSPC)
break;
bl = malloc(len, M_DEVBUF, M_WAITOK | M_ZERO);
error = ndis_get_info(sc, OID_802_11_BSSID_LIST, bl, &len);
if (error) {
free(bl, M_DEVBUF);
break;
}
sr = bsr = malloc(ireq->i_len, M_DEVBUF, M_WAITOK | M_ZERO);
wb = bl->nblx_bssid;
len = 0;
for (i = 0; i < bl->nblx_items; i++) {
/*
* Check if we have enough space left for this ap
*/
j = roundup(sizeof(*sr) + wb->nwbx_ssid.ns_ssidlen
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
+ wb->nwbx_ielen -
sizeof(struct ndis_80211_fixed_ies),
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
sizeof(uint32_t));
if (len + j > ireq->i_len)
break;
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
bcopy(&wb->nwbx_macaddr, &sr->isr_bssid,
sizeof(sr->isr_bssid));
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
if (wb->nwbx_privacy)
sr->isr_capinfo |= IEEE80211_CAPINFO_PRIVACY;
sr->isr_rssi = wb->nwbx_rssi + 200;
sr->isr_freq = wb->nwbx_config.nc_dsconfig / 1000;
sr->isr_intval = wb->nwbx_config.nc_beaconperiod;
switch (wb->nwbx_netinfra) {
case NDIS_80211_NET_INFRA_IBSS:
sr->isr_capinfo |= IEEE80211_CAPINFO_IBSS;
break;
case NDIS_80211_NET_INFRA_BSS:
sr->isr_capinfo |= IEEE80211_CAPINFO_ESS;
break;
}
for (j = 0; j < sizeof(sr->isr_rates); j++) {
/* XXX - check units */
if (wb->nwbx_supportedrates[j] == 0)
break;
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
sr->isr_rates[j] =
wb->nwbx_supportedrates[j] & 0x7f;
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
}
sr->isr_nrates = j;
sr->isr_ssid_len = wb->nwbx_ssid.ns_ssidlen;
cp = (char *)sr + sizeof(*sr);
bcopy(&wb->nwbx_ssid.ns_ssid, cp, sr->isr_ssid_len);
cp += sr->isr_ssid_len;
sr->isr_ie_len = wb->nwbx_ielen
- sizeof(struct ndis_80211_fixed_ies);
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
bcopy((char *)wb->nwbx_ies +
sizeof(struct ndis_80211_fixed_ies),
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
cp, sr->isr_ie_len);
sr->isr_len = roundup(sizeof(*sr) + sr->isr_ssid_len
+ sr->isr_ie_len, sizeof(uint32_t));
len += sr->isr_len;
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
sr = (struct ieee80211req_scan_result *)((char *)sr +
sr->isr_len);
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
wb = (ndis_wlan_bssid_ex *)((char *)wb + wb->nwbx_len);
}
ireq->i_len = len;
error = copyout(bsr, ireq->i_data, len);
free(bl, M_DEVBUF);
free(bsr, M_DEVBUF);
break;
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
case IEEE80211_IOC_STATIONNAME:
error = ndis_get_info(sc, OID_GEN_MACHINE_NAME,
&nodename_u, &len);
if (error)
break;
acode = nodename;
bzero((char *)nodename, IEEE80211_NWID_LEN);
ndis_unicode_to_ascii(nodename_u, len, &acode);
ireq->i_len = len / 2 + 1;
error = copyout(acode, ireq->i_data, ireq->i_len);
break;
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
default:
error = ieee80211_ioctl(&sc->ic, command, data);
}
return(error);
}
static int
ndis_80211_ioctl_set(struct ifnet *ifp, u_long command, caddr_t data)
{
struct ndis_softc *sc;
struct ieee80211req *ireq;
int error, len;
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
uint8_t nodename[IEEE80211_NWID_LEN];
uint16_t nodename_u[IEEE80211_NWID_LEN + 1];
uint16_t *ucode;
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
sc = ifp->if_softc;
ireq = (struct ieee80211req *) data;
switch (ireq->i_type) {
case IEEE80211_IOC_SCAN_REQ:
len = 0;
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
error = ndis_set_info(sc, OID_802_11_BSSID_LIST_SCAN,
NULL, &len);
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
tsleep(&error, PPAUSE|PCATCH, "ssidscan", hz * 2);
rt_ieee80211msg(ifp, RTM_IEEE80211_SCAN, NULL, 0);
break;
Finally bring an end to the great "make the Atheros NDIS driver work on SMP" saga. After several weeks and much gnashing of teeth, I have finally tracked down all the problems, despite their best efforts to confound and annoy me. Problem nunmber one: the Atheros windows driver is _NOT_ a de-serialized miniport! It used to be that NDIS drivers relied on the NDIS library itself for all their locking and serialization needs. Transmit packet queues were all handled internally by NDIS, and all calls to MiniportXXX() routines were guaranteed to be appropriately serialized. This proved to be a performance problem however, and Microsoft introduced de-serialized miniports with the NDIS 5.x spec. Microsoft still supports serialized miniports, but recommends that all new drivers written for Windows XP and later be deserialized. Apparently Atheros wasn't listening when they said this. This means (among other things) that we have to serialize calls to MiniportSendPackets(). We also have to serialize calls to MiniportTimer() that are triggered via the NdisMInitializeTimer() routine. It finally dawned on me why NdisMInitializeTimer() takes a special NDIS_MINIPORT_TIMER structure and a pointer to the miniport block: the timer callback must be serialized, and it's only by saving the miniport block handle that we can get access to the serialization lock during the timer callback. Problem number two: haunted hardware. The thing that was _really_ driving me absolutely bonkers for the longest time is that, for some reason I couldn't understand, my test machine would occasionally freeze or more frustratingly, reset completely. That's reset and in *pow!* back to the BIOS startup. No panic, no crashdump, just a reset. This appeared to happen most often when MiniportReset() was called. (As to why MiniportReset() was being called, see problem three below.) I thought maybe I had created some sort of horrible deadlock condition in the process of adding the serialization, but after three weeks, at least 6 different locking implementations and heroic efforts to debug the spinlock code, the machine still kept resetting. Finally, I started single stepping through the MiniportReset() routine in the driver using the kernel debugger, and this ultimately led me to the source of the problem. One of the last things the Atheros MiniportReset() routine does is call NdisReadPciSlotInformation() several times to inspect a portion of the device's PCI config space. It reads the same chunk of config space repeatedly, in rapid succession. Presumeably, it's polling the hardware for some sort of event. The reset occurs partway through this process. I discovered that when I single-stepped through this portion of the routine, the reset didn't occur. So I inserted a 1 microsecond delay into the read loop in NdisReadPciSlotInformation(). Suddenly, the reset was gone!! I'm still very puzzled by the whole thing. What I suspect is happening is that reading the PCI config space so quickly is causing a severe PCI bus error. My test system is a Sun w2100z dual Opteron system, and the NIC is a miniPCI card mounted in a miniPCI-to-PCI carrier card, plugged into a 100Mhz PCI slot. It's possible that this combination of hardware causes a bus protocol violation in this scenario which leads to a fatal machine check. This is pure speculation though. Really all I know for sure is that inserting the delay makes the problem go away. (To quote Homer Simpson: "I don't know how it works, but fire makes it good!") Problem number three: NdisAllocatePacket() needs to make sure to initialize the npp_validcounts field in the 'private' section of the NDIS_PACKET structure. The reason if_ndis was calling the MiniportReset() routine in the first place is that packet transmits were sometimes hanging. When sending a packet, an NDIS driver will call NdisQueryPacket() to learn how many physical buffers the packet resides in. NdisQueryPacket() is actually a macro, which traverses the NDIS_BUFFER list attached to the NDIS_PACKET and stashes some of the results in the 'private' section of the NDIS_PACKET. It also sets the npp_validcounts field to TRUE To indicate that the results are now valid. The problem is, now that if_ndis creates a pool of transmit packets via NdisAllocatePacketPool(), it's important that each time a new packet is allocated via NdisAllocatePacket() that validcounts be initialized to FALSE. If it isn't, and a previously transmitted NDIS_PACKET is pulled out of the pool, it may contain stale data from a previous transmission which won't get updated by NdisQueryPacket(). This would cause the driver to miscompute the number of fragments for a given packet, and botch the transmission. Fixing these three problems seems to make the Atheros driver happy on SMP, which hopefully means other serialized miniports will be happy too. And there was much rejoicing. Other stuff fixed along the way: - Modified ndis_thsuspend() to take a mutex as an argument. This allows KeWaitForSingleObject() and KeWaitForMultipleObjects() to avoid any possible race conditions with other routines that use the dispatcher lock. - Fixed KeCancelTimer() so that it returns the correct value for 'pending' according to the Microsoft documentation - Modfied NdisGetSystemUpTime() to use ticks and hz rather than calling nanouptime(). Also added comment that this routine wraps after 49.7 days. - Added macros for KeAcquireSpinLock()/KeReleaseSpinLock() to hide all the MSCALL() goop. - For x86, KeAcquireSpinLockRaiseToDpc() needs to be a separate function. This is because it's supposed to be _stdcall on the x86 arch, whereas KeAcquireSpinLock() is supposed to be _fastcall. On amd64, all routines use the same calling convention so we can just map KeAcquireSpinLockRaiseToDpc() directly to KfAcquireSpinLock() and it will work. (The _fastcall attribute is a no-op on amd64.) - Implement and use IoInitializeDpcRequest() and IoRequestDpc() (they're just macros) and use them for interrupt handling. This allows us to move the ndis_intrtask() routine from if_ndis.c to kern_ndis.c. - Fix the MmInitializeMdl() macro so that is uses sizeof(vm_offset_t) when computing mdl_size instead of uint32_t, so that it matches the MmSizeOfMdl() routine. - Change a could of M_WAITOKs to M_NOWAITs in the unicode routines in subr_ndis.c. - Use the dispatcher lock a little more consistently in subr_ntoskrnl.c. - Get rid of the "wait for link event" hack in ndis_init(). Now that I fixed NdisReadPciSlotInformation(), it seems I don't need it anymore. This should fix the witness panic a couple of people have reported. - Use MSCALL1() when calling the MiniportHangCheck() function in ndis_ticktask(). I accidentally missed this one when adding the wrapping for amd64.
2005-03-27 10:14:36 +00:00
case IEEE80211_IOC_STATIONNAME:
error = suser(curthread);
if (error)
break;
if (ireq->i_val != 0 ||
ireq->i_len > IEEE80211_NWID_LEN) {
error = EINVAL;
break;
}
bzero((char *)nodename, IEEE80211_NWID_LEN);
error = copyin(ireq->i_data, nodename, ireq->i_len);
if (error)
break;
ucode = nodename_u;
ndis_ascii_to_unicode((char *)nodename, &ucode);
len = ireq->i_len * 2;
error = ndis_set_info(sc, OID_GEN_MACHINE_NAME,
&nodename_u, &len);
break;
Merge in patch to support AP scanning via ifconfig and the new net80211 API. Submitted by: Stephane E. Potvin sepotvin at videotron dot ca
2005-02-11 02:13:12 +00:00
default:
error = ieee80211_ioctl(&sc->ic, command, data);
if (error == ENETRESET) {
ndis_setstate_80211(sc);
error = 0;
}
}
return(error);
}
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
static void
ndis_watchdog(ifp)
struct ifnet *ifp;
{
struct ndis_softc *sc;
sc = ifp->if_softc;
NDIS_LOCK(sc);
ifp->if_oerrors++;
Clean up ndiscvt a bit (leaving out the -i flag didn't work) and add copyrights to the inf parser files. Add a -n flag to ndiscvt to allow the user to override the default device name of NDIS devices. Instead of "ndis0, ndis1, etc..." you can have "foo0, foo1, etc..." This allows you to have more than one kind of NDIS device in the kernel at the same time. Convert from printf() to device_printf() in if_ndis.c, kern_ndis.c and subr_ndis.c. Create UMA zones for ndis_packet and ndis_buffer structs allocated on transmit. The zones are created and destroyed in the modevent handler in kern_ndis.c. printf() and UMA changes submitted by green@freebsd.org
2004-01-02 04:31:06 +00:00
device_printf(sc->ndis_dev, "watchdog timeout\n");
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
NDIS_UNLOCK(sc);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
The watchdog callout executes with the (non-sleepable) ifnet lock held now, but it's possible for ndis_reset_nic() to sleep (sometimes the MiniportReset() method returns NDIS_STATUS_PENDING and we have to wait for completion). To get around this, execute the ndis_reset_nic() routine in the NDIS_TASKQUEUE thread.
2004-08-01 22:25:12 +00:00
ndis_sched((void(*)(void *))ndis_reset_nic, sc, NDIS_TASKQUEUE);
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
ndis_sched(ndis_starttask, ifp, NDIS_TASKQUEUE);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return;
}
/*
* Stop the adapter and free any mbufs allocated to the
* RX and TX lists.
*/
static void
ndis_stop(sc)
struct ndis_softc *sc;
{
struct ifnet *ifp;
ifp = &sc->arpcom.ac_if;
untimeout(ndis_tick, sc, sc->ndis_stat_ch);
ndis_halt_nic(sc);
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
NDIS_LOCK(sc);
ifp->if_timer = 0;
sc->ndis_link = 0;
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
ifp->if_flags &= ~(IFF_RUNNING | IFF_OACTIVE);
Convert from using taskqueue_swi to using private kernel threads. The problem with using taskqueue_swi is that some of the things we defer into threads might block for up to several seconds. This is an unfriendly thing to do to taskqueue_swi, since it is assumed the taskqueue threads will execute fairly quickly once a task is submitted. Reorganized the locking in if_ndis.c in the process. Cleaned up ndis_write_cfg() and ndis_decode_parm() a little.
2004-01-18 22:57:11 +00:00
NDIS_UNLOCK(sc);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return;
}
/*
* Stop all chip I/O so that the kernel's probe routines don't
* get confused by errant DMAs when rebooting.
*/
Add preliminary support for PCMCIA devices in addition to PCI/cardbus. if_ndis.c has been split into if_ndis_pci.c and if_ndis_pccard.c. The ndiscvt(8) utility should be able to parse device info for PCMCIA devices now. The ndis_alloc_amem() has moved from kern_ndis.c to if_ndis_pccard.c so that kern_ndis.c no longer depends on pccard. NOTE: this stuff is not guaranteed to work 100% correctly yet. So far I have been able to load/init my PCMCIA Cisco Aironet 340 card, but it crashes in the interrupt handler. The existing support for PCI/cardbus devices should still work as before.
2004-03-07 02:49:06 +00:00
void
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
ndis_shutdown(dev)
device_t dev;
{
struct ndis_softc *sc;
Add a kludge to avoid having ndis_init() called needlessly by dhclient on an SIOCSIFADDR (by way of brain damage in net80211). Also, avoid trying to set NDIS_80211_AUTHMODE_AUTO since the Microsoft documentation I have recommends not using it, and the Centrino driver seems to dislike being told to use it.
2004-01-27 07:57:42 +00:00
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
sc = device_get_softc(dev);
Rework mbuf<->ndis_packet/ndis_packet<->mbuf translation a little to make it more robust. This should fix problems with crashes under heavy traffic loads that have been reported. Also add a 'query done' callback handler to satisfy the e100bex.sys sample Intel driver.
2003-12-14 21:31:32 +00:00
ndis_shutdown_nic(sc);
Commit the first cut of Project Evil, also known as the NDISulator. Yes, it's what you think it is. Yes, you should run away now. This is a special compatibility module for allowing Windows NDIS miniport network drivers to be used with FreeBSD/x86. This provides _binary_ NDIS compatibility (not source): you can run NDIS driver code, but you can't build it. There are three main parts: sys/compat/ndis: the NDIS compat API, which provides binary compatibility functions for many routines in NDIS.SYS, HAL.dll and ntoskrnl.exe in Windows (these are the three modules that most NDIS miniport drivers use). The compat module also contains a small PE relocator/dynalinker which relocates the Windows .SYS image and then patches in our native routines. sys/dev/if_ndis: the if_ndis driver wrapper. This module makes use of the ndis compat API and can be compiled with a specially prepared binary image file (ndis_driver_data.h) containing the Windows .SYS image and registry key information parsed out of the accompanying .INF file. Once if_ndis.ko is built, it can be loaded and unloaded just like a native FreeBSD kenrel module. usr.sbin/ndiscvt: a special utility that converts foo.sys and foo.inf into an ndis_driver_data.h file that can be compiled into if_ndis.o. Contains an .inf file parser graciously provided by Matt Dodd (and mercilessly hacked upon by me) that strips out device ID info and registry key info from a .INF file and packages it up with a binary image array. The ndiscvt(8) utility also does some manipulation of the segments within the .sys file to make life easier for the kernel loader. (Doing the manipulation here saves the kernel code from having to move things around later, which would waste memory.) ndiscvt is only built for the i386 arch. Only files.i386 has been updated, and none of this is turned on in GENERIC. It should probably work on pc98. I have no idea about amd64 or ia64 at this point. This is still a work in progress. I estimate it's about %85 done, but I want it under CVS control so I can track subsequent changes. It has been tested with exactly three drivers: the LinkSys LNE100TX v4 driver (Lne100v4.sys), the sample Intel 82559 driver from the Windows DDK (e100bex.sys) and the Broadcom BCM43xx wireless driver (bcmwl5.sys). It still needs to have a net80211 stuff added to it. To use it, you would do something like this: # cd /sys/modules/ndis # make; make load # cd /sys/modules/if_ndis # ndiscvt -i /path/to/foo.inf -s /path/to/foo.sys -o ndis_driver_data.h # make; make load # sysctl -a | grep ndis All registry keys are mapped to sysctl nodes. Sometimes drivers refer to registry keys that aren't mentioned in foo.inf. If this happens, the NDIS API module creates sysctl nodes for these keys on the fly so you can tweak them. An example usage of the Broadcom wireless driver would be: # sysctl hw.ndis0.EnableAutoConnect=1 # sysctl hw.ndis0.SSID="MY_SSID" # sysctl hw.ndis0.NetworkType=0 (0 for bss, 1 for adhoc) # ifconfig ndis0 <my ipaddr> netmask 0xffffff00 up Things to be done: - get rid of debug messages - add in ndis80211 support - defer transmissions until after a status update with NDIS_STATUS_CONNECTED occurs - Create smarter lookaside list support - Split off if_ndis_pci.c and if_ndis_pccard.c attachments - Make sure PCMCIA support works - Fix ndiscvt to properly parse PCMCIA device IDs from INF files - write ndisapi.9 man page
2003-12-11 22:34:37 +00:00
return;
}
Reference in New Issue Copy Permalink