OpenIndiana Distribution

Ticket closed. Not enough user demand.

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

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]
http://ftp.hp.com/pub/softpaq/sp39501-40000/sp39912.exe

2. Lenovo IN2WLN38WW1.exe [ 5.60.18.41, 01 Jun 2010, Win XP]
http://download.lenovo.com/UserFiles/Driver/en/Downloads%20and%20Drivers/S10-3s/XP/IN2WLN38WW1.exe

3. Dell Dell_multi-device_A17_R174291.exe [4.170.25.12,A17, 3/6/2012, Win XP]
http://www.dell.com/support/drivers/us/en/19/driverdetails?driverid=D7HGJ

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 [5.100.82.112] 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.
Link: http://learningsolaris.com/archives/2009/03/10/opensolaris-wifi-broadcom-bcm4312-on-dell-vostro-1710/
Fetch all the required packages & files and store them in a common directory

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

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 0.0.0.0 netmask ff000000
   ether 0:22:5f:2e:9a:d1

Start configuring with Nwam, wificonfig, …

Adding original ndis-1.2.6 for further patching purposes.

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.

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

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

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: http://permalink.gmane.org/gmane.os.openindiana.devel/2252 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 http://permalink.gmane.org/gmane.os.openindiana.devel/2248 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:

• http://permalink.gmane.org/gmane.os.openindiana.devel/2252
• http://permalink.gmane.org/gmane.os.openindiana.devel/2248

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.

• 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