After installing OpenBSD on a Dell Latitude E6500 I wanted to add a wireless capability to the laptop, as the inbuilt wireless adapter is not supported:
"Broadcom BCM4315" rev 0x01 at pci2 dev 0 function 0 not configured
After a little research into the USB wireless adapters supported by OpenBSD, I purchased a Netgear WNA1000M. With the adapter inserted I booted the OS, to find to my horror:
ugen0 at uhub1 port 4 "Realtek WNA1000Mv2" rev 2.00/2.00 addr 2
Thanks guys! More in hope than expectation, I decided to add the
device ID to the relevant driver urtwn
and see if that
would enable the adapter to (a) be recognised and (b) work.
First, how to find the device ID on OpenBSD? This is performed by:
usbdevs -v
which returned:
port 4 addr 2: high speed, power 500 mA, config 1, WNA1000Mv2(0x9043), Realtek(0x0846), rev 2.00, iSerialNumber 00e04c000001
Hmm, a device ID of 0x9043
wasn't too far away from the
device ID of previous adapter version, 0x9041
. Just maybe...
Armed with the device ID, the list of USB devices in
/usr/src/sys/dev/usb/usbdevs
can be augmented, and the new
device definition added to the list of devices to recognise in the
driver code at /usr/src/sys/dev/usb/if_urtwn.c
. Here are
the diffs against the OpenBSD 5.7 source:
--- usbdevs Thu Aug 20 13:13:04 2015 +++ /usr/src/sys/dev/usb/usbdevs Thu Aug 20 13:14:54 2015 @@ -3095,6 +3095,7 @@ product NETGEAR WNA1100 0x9030 WNA1100 product NETGEAR WNA1000 0x9040 WNA1000 product NETGEAR WNA1000M 0x9041 WNA1000M +product NETGEAR WNA1000Mv2 0x9043 WNA1000Mv2 /* Netgear(2) products */ product NETGEAR2 MA101 0x4100 MA101
and
--- if_urtwn.c Thu Aug 20 13:13:04 2015 +++ /usr/src/sys/dev/usb/if_urtwn.c Thu Aug 20 13:17:32 2015 @@ -110,6 +110,7 @@ { USB_VENDOR_IODATA, USB_PRODUCT_IODATA_WNG150UM }, { USB_VENDOR_IODATA, USB_PRODUCT_IODATA_RTL8192CU }, { USB_VENDOR_NETGEAR, USB_PRODUCT_NETGEAR_WNA1000M }, + { USB_VENDOR_NETGEAR, USB_PRODUCT_NETGEAR_WNA1000Mv2 }, { USB_VENDOR_NETGEAR, USB_PRODUCT_NETGEAR_RTL8192CU }, { USB_VENDOR_NETGEAR4, USB_PRODUCT_NETGEAR4_RTL8188CU }, { USB_VENDOR_NETWEEN, USB_PRODUCT_NETWEEN_RTL8192CU },
The initial attempt to recompile the kernel failed at
if_urtwn.c
, complaining that USB_PRODUCT_NETGEAR_WNA1000Mv2
was undefined. Looks like the usbdevs.h
and
usbdevs_data.h
files had not been re-generated following
the addition to usbdevs. I manually ran the Makefile in
/usr/src/sys/dev/usb
and restarted the kernel build. All
ran OK.
I rebooted into the new kernel and, lo:
urtwn0 at uhub1 port 4 "Realtek WNA1000Mv2" rev 2.00/2.00 addr 2
After running ifconfig
to configure the adapter, I had a
working wireless connection.
urtwn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr a4:2b:8c:f0:31:2e priority: 4 groups: wlan egress media: IEEE802.11 autoselect (OFDM54 mode 11g) status: active ieee80211: nwid hydrus chan 11 bssid 00:1d:68:e9:65:d5 -66dBm nwkey <not displayed> inet 192.168.0.18 netmask 0xffffff00 broadcast 192.168.0.255
I submitted the information and diffs to the
misc@openbsd.org
mailling list; two days later the changes
had been applied to current. How's that for service!
I then figured I would upgrade the machine to current so that I didn't have to maintain the patches for the driver. I used cvs to update the source tree to HEAD and rebuilt the kernel without issues. However, this was not the case when building the userland, where I encountered this error:
vpaes-x86_64.S: Assembler messages: vpaes-x86_64.S:172: Error: no such instruction: `palignr $12,%xmm5,%xmm5' vpaes-x86_64.S:298: Error: no such instruction: `palignr $8,%xmm6,%xmm0' vpaes-x86_64.S:436: Error: no such instruction: `palignr $15,%xmm8,%xmm1' vpaes-x86_64.S:437: Error: no such instruction: `palignr $15,%xmm8,%xmm8' vpaes-x86_64.S:442: Error: no such instruction: `palignr $1,%xmm0,%xmm0' *** Error 1 in lib/libcrypto/crypto (<bsd.lib.mk>:120 'vpaes-x86_64.o': <at> cc -g -c -DDSO_DLFCN -DHAVE_DLFCN_H -DHAVE_FUNOPEN -DLIBRESSL_INTE...) *** Error 1 in lib/libcrypto (<bsd.subdir.mk>:48 'all') *** Error 1 in lib (<bsd.subdir.mk>:48 'all') *** Error 1 in /usr/src (Makefile:79 'build')
Others had encountered this. The reason is that the version of binutils installed on the running userland was too old, 2.15 rather than 2.17, which is required now. However, the real reason for my problem was that I had not followed the true way to move to current, which is to install from the latest snapshot first and then update the source tree.
In this particular case, the workaround was relatively simple:
cd /usr/src/gnu/usr.bin/binutils-2.17 make -f Makefile.bsd-wrapper && make -f Makefile.bsd-wrapper install
After this, the userland build ran successfully.