Re: Lasted NDIS wrapper for D-Link DWL-520+ on RELENG_6

> > Now, The first thing you should have done is to actually inspect the
> > .INF file. Like the self-documenting ndisgen(8) script tells you, this
> > is the file that actually contains the device ID information that the
> > Windows Plug & Play Mangler will use when trying to match a device
> > to a driver. The AIRPLUS.INF file says:
> > 
> > [D-Link]
> > %AIRPLUS.DeviceDesc1% = AIRPLUS.8400, PCI\VEN_104C&DEV_8400&SUBSYS_3B001186
> > %AIRPLUS.DeviceDesc2% = AIRPLUS.8400, PCI\VEN_104C&DEV_8400&SUBSYS_3B011186
> > 
> > Note that the PCI vendor ID (0x104c) matches your device, but the
> > device ID (0x8400) does not (yours is 0x9066).
> > 
> > In this case, the .INF file tells Windows to look for two possible
> > devices. In reality, both devices use the same chip (vendor 0x104c,
> > device 0x8400), but there are two board variants (one with 0x3b001186,
> > the other 0x3b011186). The subsystem ID is really another vendor/device
> > ID combination (0x1186 is D-Link's vendor ID, 0x3b00 and 0x3b01 are
> > the device codes D-Link has assigned to their boards). Exactly what
> > the differences are between the board revs is anyone's guess. Maybe
> > they use the same Texas Instruments chip, but with slightly different
> > RF circuitry. Maybe they're really the same electronically, but D-Link
> > decided to give each production run their own ID code because they're
> > funny that way.
> > 
> > In any case, not only do the vendor ID and device ID not match your board,
> > the subsystem IDs don't match yours either (0x3b041186). So this driver
> > is not the one that goes with your card.
> 
> Ok thank you very much for this explanation, this is now very clear.
> I'm going to try other drivers, I think looking on Google for these
> vendor and device IDs will point out a relevant driver.  At first
> glance it seems that NetGear WG-311 uses the same chip, I'm going to
> have a try to their driver.

One more thing. Different board distributors will often use the same
chips, but sometimes they assign their cards different subsystem IDs,
just to fool people into thinking the cards are really different. For
example, the Netgear WG311 driver's .INF file might have entries that
specify the same VEN/DEV values, but with a different subsystem ID.
This would prevent Windows from recognizing that Netgear's driver
will work with D-Link's card, and vice-versa.

To defeat this, you need to edit the .INF a little. You can remove
the &SUBSYS portion of the device description. In other words, if
the .INF says this:

[D-Link]
%AIRPLUS.DeviceDesc1% = AIRPLUS.8400, PCI\VEN_104C&DEV_8400&SUBSYS_3B001186
%AIRPLUS.DeviceDesc2% = AIRPLUS.8400, PCI\VEN_104C&DEV_8400&SUBSYS_3B011186

Then make it say this:

[D-Link]
%AIRPLUS.DeviceDesc1% = AIRPLUS.8400, PCI\VEN_104C&DEV_8400
%AIRPLUS.DeviceDesc2% = AIRPLUS.8400, PCI\VEN_104C&DEV_8400&SUBSYS_3B011186

Note that you don't have to remove the &SUBSYS specification from both
lines: one is enough. This will allow Windows (and, coincidentally,
the NDISulator), to match the driver to any card with the correct
PCI vendor/device ID, regardless of its subsystem ID.

A couple of points:

- Some .INF files don't have the &SUBSYS specifications to begin with.
  Usually these are driver kits supplied by the chip manufacturer
  directly, which are meant to work with any board that uses their
  chipset.

- Do _NOT_ add or remove lines to the device specification section of
  the .INF file. The .INF file syntax is very tricky: you can sometimes
  edit existing entries, but you can't add or remove lines without making
  additional changes. Just putting in a new line will make the .INF
  file invalid and ndiscvt(8) won't be able to parse it correctly
  anymore. (Always keep a copy of the original file handy.)

- In rare cases, someone will go the extra step and modify the driver
  source code itself so that it will only work with specific boards,
  so even changing the .INF file won't work. I've only seen this once
  though. Alteon Networks had code in their drivers to check for a special
  byte in the EEPROMs of all the gigabit ethernet cards with their chips
  (the Tigon I and II). This byte contained the OEM vendor code. There
  were a lot of Alteon OEM cards: IBM, SGI, 3Com, Netgear, etc. Some of them
  were very expensive (the IBM card sold specifically for AIX RS/6000
  systems cost over $1000) and some were very cheap (the Netgear one
  was $200, which at the time was amazing). But they were all really
  the same hardware. In theory, if you had an RS/6000 machine, you
  could save $800 by buying a Netgear card instead of the IBM one.
  Alteon had to stop people doing that though, since it would piss
  off some of their OEMs, so each OEM's driver would specifically check
  to make sure you were using it with the right card. This would stop
  the AIX driver from working with a Netgear card. If you were really
  clever, I suppose you could patch the AIX driver binary to recognize
  a different OEM ID code (it was just one byte) but as far as I know
  I don't think anyone did this.

- When a driver is 'digitally signed' by Microsoft, the signature is
  calculated using both the .SYS file and the .INF file, so if you edit
  the .INF file for a signed driver, you'll invalidate the digital
  signature, and Windows will whine that you're trying to load an
  unsigned driver. Just tell it to load the driver anyway. (The
  NDISulator obviously doesn't care.)

-Bill

--
=============================================================================
-Bill Paul            (510) 749-2329 | Senior Engineer, Master of Unix-Fu
                 wpaul_at_windriver.com | Wind River Systems
=============================================================================
              <adamw> you're just BEGGING to face the moose
=============================================================================