Circumventing ThinkPad’s WiFi Card Whitelisting

What started as a simple Mini PCI Express WiFi card swap on a ThinkPad T61 notebook, turned into deploying a custom BIOS in order to get the card to work.

I love ThinkPad notebooks, they are workhorses that keep on going and going. I always keep my older models around for testing, and one of my old T61’s had an Intel 4965AGN card, that worked fine with Windows 10, until the release of the Anniversary / Redstone 1 update. After the RS1 update, WiFi would either fail to connect, or randomly drop out. The 4965AGN card is not supported by Intel on Win10, and the internet is full of problem reports of Win10 and 4965AGN cards.

Ok, no problem, I’ll just get a cheap, reasonably new, with support for Win10, Mini PCIe WiFi card, and swap the card. I got an Intel 3160 dual band 802.11AC card and mounting bracket for about $20. The 3160 is a circa 2013 card with Win10 support. I installed the card, booted, and got a BIOS error 1802: Unauthorized network card is plugged in.

This lead me to the discovery of ThinkPad hardware whitelisting, where the BIOS only allows specific cards to be used, which lead me to Middleton’s BIOS, a custom T61 BIOS, that removes the hardware whitelisting, and enables SATA-2 support. I found working download links to the v2.29-1.08 Middleton BIOS here.

The BIOS update is packaged as a Win7 x86 executable or DOS bootable ISO image. As I’m running Win10 x64, and I could not find any CD-R discs around, I used Rufus to create a bootable DOS USB key, and I extracted the ISO contents using 7-Zip to a directory on the USB key. The ISO is created using a bootable 1.44MB DOS floppy image, and AUTOEXEC.BAT launches “FLASH2.EXE /U”, I created a batch file that does the same.

I removed the WiFi card, booted from USB, ran the flash, and got an error 1, complaining that flashing over the LAN is disabled. Ok, I enabled flashing the BIOS over the LAN in the BIOS, and rebooted.

I ran the update again, and this time I got error 99, complaining that BitLocker is enabled, and to temporarily disable BitLocker. I did not have BitLocker enabled, so I removed the hard drive and tried again, same error. Must be something in the BIOS, I disabled the security chip in the BIOS, tried again, and the update starts, but a minute or so later the screen goes crazy with INVALID OPCODE messages.

Hmm, maybe the updater does not like the FreeDOS boot image used by Rufus. Ok, let me create a MS-DOS USB key, uhh, on Win10, that turned out to be near impossible. Win10 does not include MS-DOS files, Rufus does not support custom locations for MS-DOS files, nor does it support getting them from floppy or CD images (readily available for download), the HP USB Disk utility complains my USB drive is locked, and writing raw images to USB result in a FAT12 disk structure that is too small to use. I say near impossible because I gave up, and instead went looking for an existing MS-DOS USB key I had made a long time ago. I am sure with a bit more persistence I could have found a way to create MS-DOS bootable USB keys on Win10, but that is an exercise of another day.

Trying again with a MS-DOS USB key, and voilà, BIOS flashed, and WiFi working.

I am annoyed that I had to go to this much trouble to get the new WiFi card working, but the best part of the exercise turns out to be the SATA-2 speed increase. This machine had a SSD drive, that I always found to be slow, but with the SATA-2 speed bump in Middleton’s BIOS, the machine is noticeably snappier.

A couple hours later, my curiosity got the better of me, and I made my own version of Rufus that will allow formatting of MS-DOS USB drives on Win10. In the process I engaged in an interesting discussion with the author of Rufus. I say interesting, but it was rather frustrating, Microsoft removed the MS-DOS files from Win10, and Rufus refuses to add support for sourcing of MS-DOS files from a user specified location, citing legal reasons, and my reluctance to first report the issue to FreeDOS. Anyway, can code, have compiler, if have time, will solve problem.

Panasonic Lumix WiFi Dissapoints

I’ve been a long time fan of Panasonic Lumix digital cameras, and I tend to update them every couple of years. My current cameras are the DMC-ZS20 for travel, and the DMZ-ZS7 for pocket use.

 

My workflow typically entails taking lots of pictures, and then using a Transcend USB3 card reader and ImageIngester Pro to copy and rename them to my PC, and finally import them into Adobe Photoshop Lightroom. This is a tedious process, but with the release of the Lumix WiFi capable handheld cameras, an opportunity to make my life simpler by uploading directly using WiFi.

 

I bought the WiFi enabled DMC-ZS30 to replace my DMC-Z20, and a DMC-TS5 to replace my DMC-ZS7. The TS5 is not really an upgrade to the ZS7, but it is waterproof, shockproof, and kids-proof.

 

The cameras were typical great Lumix quality, but my interest was the WiFi capability.

 

The camera offers several modes of connecting, I setup the PC WiFi connected option. During the setup process you have to select the access point SSID, in my case I have a couple roaming enabled access points around me, and the camera showed multiple access points with the same SSID. I’ve seen this behavior in some devices that bind to a specific access point, and these devices would refuse to roam, requiring a new setup for every single access point.

It did not really matter as the camera would not connect, it would ask for my password, but fail to connect. My camera was running firmware 1.0, and there was a v1.2 available, I upgraded, and the WiFi connection succeeded. The firmware notes say nothing about WiFi connectivity, but for whatever reason it helped.

 

First big frustration; every time anything in the connection setup flow fails, you have to re-enter the WiFi password, the login username, and the password, very painful when using a navigation only keyboard, and long complicated passwords. It would have been much more convenient to configure WiFi in one place, save the WiFi connection, and then configure transfer profiles, or at least always remember the previously entered values.

 

PC connectivity requires a SMB network share and a named host, i.e. no support for any protocol other than SMB, and no support for entering servers by IP address.

I could not get the camera to connect to my server, looking at the security logs, I could see that the connection was using “WORKGROUP” as the domain, and using the DOMAIN portion of  [DOMAIN\UserName] specification as part of the literal username. The camera has no provisioning for changing the workgroup or domain, and I had to resort to creating a machine local account in order to connect. Once I had my local account created, and again re-entered all information, I could finally connect.

 

I took some pictures, pressed the WiFi button, navigated to the profiles, and uploaded the pictures, it took forever, around 90s per 5MB average picture, or around 400Kbps. Using my USB3 card reader the same pictures all transferred in a few seconds. Yes, USB3 is much faster than WiFi 802.11n, but 400 kilo bits per second is super slow, not near the capability of the WiFi network.

 

I also tried the Panasonic Lumix Club Cloud Sync service, what a joke. You setup the account from the camera, it reports your a username in the form of aaaa-bbbb-cccc-dddd, then you enter your own password, but when you try to login at the website, that you need to find using google, you need to use aaaabbbbccccdddd. I only discovered this through trial and error.

On logging in, you need to supply an email address, and then validate the email address, by clicking a link emailed to you. On clicking the link, it takes you to the service page, and it displays an error message, any action more errors. If you manually login again, you are in.

From there nothing works. From what I can tell from FAQ’s, you are supposed to be able to create a drop that allows you to pull the data from the cloud to your PC. But when you go to configure the devices and services, none of the links work.

 

What Panasonic should have done is build a very simple get connected flow, many small complicated devices today use a USB connection and an app, PC or mobile, to get the device provisioned, there are many other novel ways of simplifying this process, e.g. QR codes, BT, P2P, SD card data file, etc. Not supporting FTP, or IP addresses, or domain credentials, or workgroup configurations would be forgiven if connecting was easy, and transfer speed was at WiFi capacity, sadly, it is not. 

 

From my perspective the WiFi capability on these cameras are a waste of good silicon and battery power.