Feature #3367


Driver support for Broadcom BCM43*** 802.11a/b/g/n devices

Added by Ken Mays over 8 years ago. Updated about 8 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
40.00 h


Provide Broadcom BCM43*** 802.11a/b/g/n device driver support for BCM4301, BCM4306, BCM4309, BCM4311, BCM4312, BCM4313, BCM4318, BCM4320, BCM4321, BCM4322, BCM4323, BCM4331, BCM43142, BCM43222, BCM43224, BCM43225, BCM43227, BCM43228, and BCM43421


ndis.1.3.0.rc3jim.patch6 (25.8 KB) ndis.1.3.0.rc3jim.patch6 Jim Klimov, 2013-04-28 12:09 PM
ndis.1.3.0.rc3.tar.gz (236 KB) ndis.1.3.0.rc3.tar.gz Jean-Pierre André, 2013-06-19 07:29 AM
ndis-1.3.0.tar.gz (237 KB) ndis-1.3.0.tar.gz Ken Mays, 2013-06-19 08:38 PM
ndis.1.3.0.driverver.patch (3.06 KB) ndis.1.3.0.driverver.patch This patch adds the DriverVer string (from bcmwl5.inf) into the bcmndis driver and its messages Jim Klimov, 2013-06-26 03:01 PM
Actions #1

Updated by Ken Mays over 8 years ago

  • Status changed from New to Closed

Ticket closed. Not enough user demand.

Actions #2

Updated by Maxim Kondratovich over 8 years ago

I'm personally interested in this driver :)
I even started to port driver but not moved to far atm.. I'm sure that this driver should be ported even if nobody uses such hardware now, it will open a lot of laptops for OI.

Actions #3

Updated by Robert Gilbert over 8 years ago

  • Status changed from Closed to Feedback

I just re-purposed a system with this chipset. Is the work non-trivial? Is there any way to re-open this?

Actions #4

Updated by Jim Klimov over 8 years ago

(As you do know) I have a laptop with a BCM4313 which is currently useless for WiFi in OI, and the tricks we tried with "bwn" and NDIS did not work, panicking my system instantly upon driver load (both 32 and 64 bit tests with appropriate kernels).

So for user demand - there is some, count me in. I believe, quite a few modern notebooks include something from this line. Sorry, I did not notice ths bug earlier to chime in.

Actions #5

Updated by Ken Mays over 8 years ago

Jean-Pierre André is working on enabling the bwn driver to resolve the remaining issues with the ndis-1.2.x wrapper:

Actions #6

Updated by Ken Mays over 8 years ago

  • Assignee set to OI illumos
Actions #7

Updated by Ken Mays over 8 years ago

  • Assignee deleted (OI illumos)
  • % Done changed from 0 to 100

Test OS: oi_151a7 or higher
Test compiler: Illumos_GCC 4.4.4
Test machine: Lenovo ThinkPad Edge E335 laptop
Test Drivers (below):

1. HP sp39912.exe [7.00 E, 1 Jul 2008, Win XP Pro]

2. Lenovo IN2WLN38WW1.exe [, 01 Jun 2010, Win XP]

3. Dell Dell_multi-device_A17_R174291.exe [,A17, 3/6/2012, Win XP]

Note: Jean-Pierre provided the updated ndis wrapper sources tested with his equipment.

Test with your Broadcom 43*** devices with the Windows drivers for further review and feedback.

The Broadcom Linux STA driver [] supports all of the devices below. The Windows XP drivers may vary.

BRCM            PCI          PCI          Dell
Product Name Vendor ID Device ID Product ID
------------- ---------- --------- -----------
4311 2.4 Ghz 0x14e4 0x4311 Dell 1390
4311 Dualband 0x14e4 0x4312 Dell 1490
4311 5 Ghz 0x14e4 0x4313
4312 2.4 Ghz 0x14e4 0x4315 Dell 1395 / 1710
4313 2.4 Ghz 0x14e4 0x4727 Dell 1501
4321 Dualband 0x14e4 0x4328 Dell 1505
4321 Dualband 0x14e4 0x4328 Dell 1500
4321 2.4 Ghz 0x14e4 0x4329
4321 5 Ghz 0x14e4 0x432a
4322 Dualband 0x14e4 0x432b Dell 1510
4322 2.4 Ghz 0x14e4 0x432c
4322 5 Ghz 0x14e4 0x432d
43224 Dualband 0x14e4 0x4353 Dell 1520
43225 2.4 Ghz 0x14e4 0x4357
43227 2.4 Ghz 0x14e4 0x4358
43228 Dualband 0x14e4 0x4359 Dell 1530

This is mainly for NDIS5 drivers. The NDIS6 drivers are not supported yet.
Fetch all the required packages & files and store them in a common directory

Broadcom driver : From the HP support site :-)
Last version of the NDIS driver (attached to this bug report)
The flex package : ( You need to be connected to the Internet )
  1. pkg install -v pkg:/SUNWflexlex
    The onbld package : From Sun download center
    Bunzip, untar & add the pkg using # pkgadd -d .

Unzip the ndis archive

  1. gzip -dc ndis-1.2.1.tar.gz | tar xvf -

Extract the Windows driver archive, rename the relevant files & convert the .inf file to ascii instead of UTF encoding

  1. mv Bcm_wlan_drivers.exe Bcm_wlan_drivers.exe.7z
  2. p7zip -d Bcm_wlan_drivers.exe.7z
  3. mv bcmwl5.sys ndis-1.2.1/i386/ndis.sys
  4. iconv -futf-16 -t ascii bcmwl5.inf > ndis-1.2.1/i386/ndis.inf
  5. cd ndis-1.2.1/i386/

Follow the building procedure :

  1. make ndiscvt
  2. ./ndiscvt -i ndis.inf -s ndis.sys -o ndis.h
  3. make ndis
  4. cp bcmndis /kernel/drv/bcmndis
  5. make ndisapi
  6. cp ndisapi /kernel/misc
Find the identifier of your network card : in my case “pci14e4,4315”
  1. scanpci -v
    pci bus 0×0006 cardnum 0×00 function 0×00: vendor 0×14e4 device 0×4315
    Broadcom Corporation BCM4312 802.11b/g
    CardVendor 0×1028 card 0×000b (Dell Wireless 1395 WLAN Mini-Card)
    Load the driver module
  1. add_drv -i ‘”pci14e4,4315″‘ bcmndis

Check that OpenSolaris now shows your newly configured network card

  1. ifconfig -a
    bcmndis0: flags=201004803 mtu 1500 index 3
    inet netmask ff000000
    ether 0:22:5f:2e:9a:d1

Start configuring with Nwam, wificonfig, …

Actions #8

Updated by Ken Mays over 8 years ago

  • File ndis-1.2.6.tar.gz added
  • % Done changed from 100 to 90

Adding original ndis-1.2.6 for further patching purposes.

Actions #9

Updated by Jean-Pierre André over 8 years ago

I have uploaded an update of the source code of the ndis emulator to
This is based on the Bill Paul's emulator ndis-1.2.6. It was essentially made to run on a 64-bit computer, with (at least in theory) no change for 32-bit computers.

It has been tested with Windows driver bcmwl564.sys (described in bcmwl5.inf) from Broadcom (version on a Wireless device shown as :
pci bus 0x0004 cardnum 0x00 function 0x00: vendor 0x14e4 device 0x4315
Broadcom Corporation BCM4312 802.11b/g LP-PHY
CardVendor 0x103c card 0x137d (Hewlett-Packard Company, BCM4312 802.11b/g Wireless LAN Controller).

According the the file bcmwl5.inf, the tested driver can be used for the following devices :
vendor 0x14E4 device 0x4311
vendor 0x14E4 device 0x4312
vendor 0x14E4 device 0x4315
vendor 0x14E4 device 0x4318
vendor 0x14E4 device 0x4319
vendor 0x14E4 device 0x4320
vendor 0x14E4 device 0x4320 rev 03
vendor 0x14E4 device 0x4324
vendor 0x14E4 device 0x4324 rev 03
vendor 0x14E4 device 0x4328

Note : the driver for Linux available from Broadcom would probably be a better base. Contributors welcome.

Actions #10

Updated by Ken Mays over 8 years ago

  • File ndis.1.3.beta6.tar.gz added
  • File ndis.1.3.execbeta6.tar.gz added
Actions #11

Updated by Jim Klimov over 8 years ago

My WiFi device is BCM 4313, recognized as pciex14e4,4727. I've tested out Jean-Pierre's works based on older and newer ndis code, however, so far I couldn't forge a driver that would support my card. Apparently, newer BCMWL drivers make calls that are not implemented by the NDIS emulation layer - though there are much less of missing symbols in ndis-1.2.6-based version.

For more details, I'll refer to my latest mail-list report.

On 2013-03-26 19:18, Jean-Pierre wrote:> Hi,

I have uploaded the source code of a new beta version of
the Windows Wireless emulator on :

I gave this a shot and it builds on my box with gcc-4.4.4-il now, although with several warnings. Linked with the older bcmwl drivers (which you use for your card) the NDIS driver even loads cleanly, both with your ndisapi and with a freshly-built one. However, as before, this driver version does not support my own card.

Other bcmwl* drivers that I tried to feed it, that are supposed to support my card, did not modload, due to not finding several symbols (below). One driver did not get processed into a driver.s file (though it did before, when I tried with stock gcc-3.4.3). I can't say if it was GCC's fault, or if you changed something in ndiscvt to such effect, but the curious fact is there.

One driver's missing symbols:

Apr 4 02:47:19 nbofh genunix: [ID 826211 kern.notice] 'IoWMIOpenBlock'
Apr 4 02:47:19 nbofh genunix: [ID 826211 kern.notice] 'ExFreePoolWithTag'
Apr 4 02:47:19 nbofh genunix: [ID 826211 kern.notice] 'DbgPrint'
Apr 4 02:47:19 nbofh genunix: [ID 826211 kern.notice] 'MmMapIoSpace'
Apr 4 02:47:19 nbofh genunix: [ID 826211 kern.notice] 'IoWMIQueryAllData'
Apr 4 02:47:19 nbofh genunix: [ID 826211 kern.notice] 'RtlInitUnicodeString'
Apr 4 02:47:19 nbofh genunix: [ID 826211 kern.notice] 'MmUnmapIoSpace'
Apr 4 02:47:19 nbofh genunix: [ID 472681 kern.notice] WARNING: mod_load: cannot load module 'bcmndis'

Another one's are different:

Apr 4 02:52:20 nbofh genunix: [ID 826211 kern.notice] 'IoUnregisterPlugPlayNotification'
Apr 4 02:52:20 nbofh genunix: [ID 826211 kern.notice] 'ExFreePoolWithTag'
Apr 4 02:52:20 nbofh genunix: [ID 826211 kern.notice] 'DbgPrint'
Apr 4 02:52:20 nbofh genunix: [ID 826211 kern.notice] 'ZwQueryInformationFile'
Apr 4 02:52:20 nbofh genunix: [ID 826211 kern.notice] 'ZwReadFile'
Apr 4 02:52:20 nbofh genunix: [ID 826211 kern.notice] 'RtlInitUnicodeString'
Apr 4 02:52:20 nbofh genunix: [ID 826211 kern.notice] 'ZwCreateFile'
Apr 4 02:52:20 nbofh genunix: [ID 472681 kern.notice] WARNING: mod_load: cannot load module 'bcmndis'

I did not yet dig any further, i.e. if there is anywhere to snatch implementations from (BSD?) My notebook is essentially without networking when booted in OI, so it is not very easy to test such things out and try to get code from internet ;)

Thanks for your work however,
//Jim Klimov

Actions #12

Updated by Jean-Pierre André over 8 years ago

I have uploaded to
a release candidate for an ndis emulator which can emulate the NDIS5 interface in 64-bit mode for Broadcom wireless drivers designed for Windows.

This is a source tarball for which completing a Makefile really usable on OpenIndiana is left as an exercice for the user. Please read the included bcm4312.htm files for the procedure to compile and install.

I have tested the emulator with my wireless device (vendor 14E4 device 4315) and the three versions of the Broadcom driver described below. Jim Klimov has sucessfully tested the latest version with his own device (vendor 14E4 device 4727).

Only WEP encryption is available so far (WPA is not supported).

Supported devices by driver, September 21, 2007
(from Dell R174291.exe) :

Vendor 14E4 device 4311
Vendor 14E4 device 4312
Vendor 14E4 device 4315
Vendor 14E4 device 4318
Vendor 14E4 device 4319
Vendor 14E4 device 4320 rev 03
Vendor 14E4 device 4324 rev 03
Vendor 14E4 device 4328

Supported devices by driver, March 22, 2008
(from HP sp39912.exe), same as above, plus :

Vendor 14E4 device 4307
Vendor 14E4 device 432B

Supported devices by driver 5.60.350.6, March 23, 2010
(from HP sp48616.exe), same as above, plus :

Vendor 14E4 device 4353
Vendor 14E4 device 4357
Vendor 14E4 device 4727

Actions #13

Updated by Jim Klimov over 8 years ago

I have worked with Jean-Pierre to make his code compile on an OpenIndiana system (he uses something else), and now the driver built from scratch on my oi_151a7 laptop loads and works (with the HP driver referenced above and both an OI default gcc-3.4.3 and a tarballed gcc-444-il compiler).

My patch against his "ndis1.3.0.rc2" tarball linked above is attached so that people can finally try the builds themselves and report what works and what doesn't, so we can test more hardware and binary driver versions (and maybe compilers), and ultimately move closer to a release.

My part in this is much smaller, I tested the lot, and made sure it builds in oi_151a7; contributed an enhanced Makefile which can take the given bcmwl564.sys and bcmwl5.inf files in its current copy of the amd64 directory, and then build, test and install the driver.

I also added an init-script based on the same logic as in the Makefile to facilitate plumbing/unplumbing of the interfaces and mod(un)loading of the driver itself. It was needed to avoid normal OS auto-configuration of interfaces in my case, because a botched driver got the system into a loop of kernel panics. The init-script makes a block-file before trying to modload+plumb, so if it fails quickly - next time it will skip the activity, hopefully.

Actions #14

Updated by Ken Mays over 8 years ago

  • File deleted (ndis-1.2.6.tar.gz)
Actions #15

Updated by Ken Mays over 8 years ago

  • File deleted (ndis.1.3.beta6.tar.gz)
Actions #16

Updated by Ken Mays over 8 years ago

  • File deleted (ndis.1.3.execbeta6.tar.gz)
Actions #17

Updated by Ken Mays over 8 years ago

  • File ndis.1.3.0.rc3.tar.gz added
  • Target version set to oi_151_stable

I'm providing the ndis-1.3.0.rc3.tar.gz source here for easier accessibility and testing.

Actions #20

Updated by Ken Mays about 8 years ago

Ticket resolved based on final submittal by Jean-Pierre André, and test period with no further issues reported.

Actions #21

Updated by Ken Mays about 8 years ago

  • File deleted (ndis.1.3.0.rc3.tar.gz)
Actions #22

Updated by Jim Klimov about 8 years ago

I'd like to thank Jean-Pierre again for the nice work he did, and some list members - for asking questions which lead to better product, helping me advance the Makefile in this project in particular :)

A larger report is in the mail archives: so I'd just cover a few points from there.

1) This bug report currently has older revisions attached, which can be removed (namely, JPA's ndis.1.3.0rc3 tarball and my patch version 6); the final released tarball (ndis-1.3.0.tar.gz) is good and matches the source for my tested driver variant, except for one point - the DrvierVer described below.

2) The original Broadcom driver INF files include a DriverVer string which identifies the original binary driver. Baking it into the NDIS wrapped driver is often crucial while one is testing many builds of the driver, until a working one is compiled - this string allows to easily differentiate among the many built variants. So I attach the optional ndis.1.3.0.driverver.patch which adds this functionality to the released ndis.1.3.0rc3 tarball.

Note however that the resulting module name (string in struct modldrv) would exceed the field length in modinfo output, but this is only a cosmetic drawback as far as I know:

_# modinfo | grep ndis
224 fffffffff83be000 3a8be0 298 1 bcmndis (Ndiswrapper 1.3.0, DriverVer=03)
225 fffffffff86cc000 13bb8 - 1 ndisapi (NDIS API 1.3.0)

_# strings /kernel/drv/amd64/bcmndis | grep DriverVer
Ndiswrapper 1.3.0, DriverVer=03/22/2010, 5.60.350.6

For my BCM4313 "pciex14e4,4727" I used an HP driver, from their huge collection of drivers for Compaq nx4300 - namely, sp48616.exe version 5.60.350.6, file dated 2010-05-11 in their archives.

Note that, as the explanative post specifies, the emulator is developed to implement certain Windows API routines as used by particular builds of binary drivers. That is, it is not "granted" that any driver version, older or newer than those tested during development, will work out of the box.

3) Some users mailed me about building problems. They usually get stuck with this report:
/opt/gcc/4.4.4/bin/gcc ndis.o -o ndis
ld: fatal: file ndis.o: wrong ELF class: ELFCLASS64
ld: fatal: file processing errors. No output written to ndis

Apparently, for some reason the 64-bit flags (a lot of them) did not get passed to the make process. The email post I linked to above contains a copy of the successful build's output.

I confess that I have mostly tested the Makefile's by using the master commands such as "gmake clean all" instead of manually building the different steps (as original and JPA's readme files propose) - and these automated builds did work for me. It is possible that some variable expansion fails for explicit component builds, and/or that order of execution matters. So, first of all, if you hit problems like these - try a clean restart with a "gmake all".

4) Some other pieces of knowledge might and should wind up on the Wiki someday, but for now I'd put them here so all info is in one place:

Also, these drivers are not illumos-architected WiFi drivers; the security (WEP/WPA) support for example is part of the Windows API implementation and not really aligned with the OS. This version in particular does not support WPA, and Jean-Pierre did not need that, so it is up to some other developer to add the support if needed.

The Makefile also includes some targets to simplify testing:
  • clean and distclean to retry afresh;
  • install -> install64 to place the built files into the kernel areas (/kernel/drv/amd64/bcmndis and /kernel/misc/amd64/ndisapi);
  • testunload tries to modunload the drivers if present; fails the target if the drivers remain present after removal attempts;
  • testpresence just checks if the module files exist in current directory and modules of this name have been loaded; does not fail on not-loaded drivers;
  • test -> testload tries to testunload whatever exists and to modload the currently built drivers; similarly, testload64 tries to install and then load the installed driver files;
  • plumb and unplumb targets try to wificonfig and ifconfig the interface with the loaded drivers (according to your system config files, if they methodologically match what I've had on my box at least), or unconfigures and unplumbs the interface, accordingly;

In short, the minimal hands-free installation would involve a "gmake install" and if you're lucky (the driver fits your hardware) everything would work after "gmake testload". Well, and maybe some magic with the /etc/driver_aliases, /etc/name_to_major and /etc/path_to_inst text files. In my case, for reference only (YMMV):

_# grep bcmndis /etc/*
/etc/driver_aliases:bcmndis "pciex14e4,4727"
/etc/name_to_major:bcmndis 298
/etc/path_to_inst:"/pci@0,0/pci1022,1513@5/pci14e4,608@0" 0 "bcmndis"

The contrib/ directory includes my init-script with logic similar to that seen in the Makefile to load, configure or unplumb and unload the interfaces and their drivers. This may be convenient to have the WiFi parts start up later in the system initialization, including manual startup or via /etc/rc3.d for example, so that some waiting for the network to be found and DHCP config to be acquired wouldn't noticeably delay initialization of the rest of your system - especially if you're out of reach for the WiFi radio (fail-timeouts are quite long).

In particular, to have the OS do nothing automatically with the WiFi interfaces, their static config snippets can be kept in /etc/wifilink.$nicName files which mimic the standard /etc/hostname.$nicName - their contents are passed line-by-line as arguments to ifconfig of the named interface.

//Jim Klimov

Actions #23

Updated by Jim Klimov about 8 years ago

A user reported a fix to the Makefile by email: the separated "make ndiscvt" step does require GNU make for proper execution, just like the main building process does:

_# gmake all
if [ ! -x ./ndiscvt ]; then \\
make ndiscvt || exit; \\
else true; fi

make: Fatal error in reader: Makefile, line 45: Macro assignment on dependency line

_# vim Makefile:
cp f bcmwl564.sys ndis.sys
if [ ! -x ./ndiscvt ]; then \\
make ndiscvt || exit; \\ ---
> to gmake ndiscvt

And it`s done.


Also available in: Atom PDF