Jaap Haagmans The all-round IT guy

30Nov/140

Expanding the reach of a WiFi network

I live in a modern home, where all bearing walls and floors consist of fortified concrete. Our internet connection enters the house on the ground floor, where our WiFi router and my office is located and we sleep on the second floor (or third floor if we'd live in the US or Russia). The (first-world) problem with this is that we have nearly no WiFi signal in our bedroom. During the winter, I always like to use my laptop in bed on weekend mornings, but we only have one RJ45 socket in our bedroom, which means my wife will have to use the crappy WiFi connection (as I usually wake up earlier).

So I've picked up the plan to expand the reach of our WiFi network to the 2nd storey. To do this, I'm buying a second WiFi access point that I can connect to one of the RJ45 sockets on our first floor. By setting the authentication settings (including the SSID) to exactly the same configuration as the other WiFi AP, all our devices (phones, tablets, laptops, refrigerator, just kidding) will be able to connect to this second AP seamlessly. However, you need to make sure your second AP doesn't interfere with the first one. To do this, first disable any router functionality on the second AP to create a "bridge" where the first AP (and router) serves as a DHCP server. If you can, also give your second AP a static IP address not included in the DHCP range so you can easily access it.

The second important step is to pick a WiFi channel for both your APs. These channels correspond with frequencies (usually) ranging from 2.4 to 2.5 Ghz, usually numbered 1 - 12 or 14. The bandwidth of a WiFi signal is approximately 20 Mhz while the steps between the channels are 5 Mhz, which is why it is advised to keep 4 unused channels (25 Mhz) between your used channels. This is why you'll find that most networks use channels 1, 6 and 11. You're not bound to these channels though. So, pick two channels you like (e.g. 1 and 6) to make sure the two networks don't interfere with each other.

You can also easily expand to three APs this way, but when expanding further, make sure that when you place your APs, they don't interfere with APs within your network that use the same channel. This can be done using measurement tools like WirelessMon. This will need some careful planning though.

11Sep/145

Replacing a Bitlocker encrypted disk (with an SSD)

Our laptops use Dell docking stations, which leads to most of them being used in a (slightly) tilted stance. Of course, laptops are also carried around frequently, but this tilted stance seems to have a big impact on our disk performance and durability. We've had harddisks breaking down after just under 1 year and few have survived the 2-year mark. Of course, Dell replaces these harddisks, but the disk performance has become so low that we've decided to replace them all with SSDs.

So, we bought a stack of 128GB SSD drives, which led to problem 1: the source disk (320GB) is larger than the target disk. Windows ordinarily won't let you resize a 320GB disk below the 160GB mark and generic solutions to this problem (like using Perfectdisk to optimize a drive for shrinking) didn't work. So I thought I'd use GParted to resize the partition, but there was problem 2: the drives are encrypted with Bitlocker. GParted doesn't support the resizing of Bitlocker encrypted partitions.

After giving it much thought, I decided to decrypt the drive, something I was unwilling to do at first, but I unfortunately had to. It took just over 4 hours to finish (during which it rattled loudly. After that, I used GParted to resize the drive to 75 GB (to make the copy process faster), booted back into Windows and encrypted the drive. "Why?", you might ask. Well, I wasn't sure whether Dell would void the warranty when the laptop would have a non-Dell drive and my contact couldn't tell for sure either, so I wanted to keep hold of the old drives until our warranty period has passed. An important thing to note is that I don't recommend to store the new encryption key on the drive. I hope I don't have to explain why. If you're worried about USB safety (and you should), print out the key, put it in a sealed envelope and store it wherever your company stores important (confidential) documents.

N.B. If you are copying to a disk that is at least larger than half the size of your current disk and you can free up more than 50% of the space on your current disk, you can skip decrypting the drive. You will most likely be able to use the Windows partition manager to shrink the drive enough to be able to copy the partition to the new drive.

Copy the MBR

I use a desktop PC running Linux for development and it had 2 unused SATA3 slots. If you don't have one available, you can also buy an external SATA3 adapter and do all this from a Linux Live CD (like Ubuntu). So from here I put both the old disk and the SSD into the Linux machine. Because the drives had been re-encrypted with Bitlocker enabled, I had to ensure the entire MBR would remain the same. The MBR is located in the first 512 bytes of a drive and consists of the boot code, the partition table and a signature. I wanted to copy them all, so I issued the following dd command:

dd if=/dev/sdc of=/dev/sdd bs=512 count=1

Mind that I already have 2 disks in the desktop PC I'm using to clone these drives, so the drives are located at /dev/sdc and /dev/sdd. If the new drive is as big as or bigger than the old drive, you can easily copy the entire drive this way (just choose a bigger block size and omit the count), but for me this wasn't the case.

Clone the partitions

You'll now see in /proc/partitions that the drive /dev/sdd is partitioned the exact same way as /dev/sdc. From here on, you can copy all partitions (one by one) from /dev/sdc to /dev/sdd. I had two partitions, the first one was exactly 100 MB and the second just over 58 GB. Choosing a bigger block size (of at most the size of your drives' cache) will make the copying faster, but if your partition doesn't consist of a round number of these blocks, it will run out of space on the partition, so this will need some calculation. For me, /dev/sda1 was easy, because it was exactly 102400 KB in size (as seen in /proc/partitions), so I chose a block size of 10485760 (10 MB), meaning 10 equal blocks were to be copied. My second partition was a little more difficult and the biggest round divider I could find that was under 32 MB was 1 MB, which is what I chose. It took just under an hour to make the copy. These are the commands I used:

dd if=/dev/sdc1 of=/dev/sdd1 bs=10485760 conv=notrunc,noerror,sync
dd if=/dev/sdc2 of=/dev/sdd2 bs=1048576 conv=notrunc,noerror,sync

Important: Make sure you get the "if" and "of" bits right, please double check! If after copying, you discover your old disk is at /dev/sdd and your new one is at /dev/sdc, you've just erased your old disk!

Resize the disk

After this, I placed the new drive into the laptop and it immediatly worked, but I had to enlarge the partition. This can be easily done in Windows' own partition manager, but be sure to temporarily disable Bitlocker and restart once before re-enabling Bitlocker, because otherwise you will have to dig up the Bitlocker key you just hid somewhere sneaky. Changes to the partition table will trigger Bitlocker to lock your computer and ask for the key. Disabling Bitlocker for the next restart prevents this from happening.