GL-MT300A tricks – WIFI Bridge/Bridging mode

In a search to replace several NetGear WNCE2001 devices which had, over time, proven themselves to be so unreliable they would literally kill the entire wireless AND wired network by randomly hijacking DHCP. I tried many devices — some either couldn’t bridge at all, others ‘worked’ but had such terrible range or connection quality they were practically useless, others were simply too large, the list goes on.   I was almost ready to give up.

Then I discovered the GL-MT300A – a tiny Linux / OpenWRT powered WIFI/Ethernet cube for around $35.   The list of built-in features is endless.   But I needed it for only one thing – wifi client-mode bridging.

3154ku5uvqlI had high hopes – given the fact it ran OpenWRT along with the LUCI web interface – that I’d be able to do practically whatever I wanted — such as a straight-up WIFI bridge.  And with it’s USB port and 3G/4G tethering functions, theoretically this thing could be used anywhere – with or without wifi!

Unfortunately, after some tweaking around with both the proprietary GUI and OpenWRT LUCI (advanced) GUI, I discovered it wouldn’t be so easy.   There’s no ‘built-in’ functionality to enable bridging mode as I had with the [extrememly buggy] NetGear devices.   Basically there’s always NAT which I absolutely need to avoid.  Attempts to bridge between wireless and wired interfaces would always fail.  It turns out that due to limitations on its wifi chipset (and most chipsets other than Broadcomm, apparently), wifi bridging isn’t supported in the hardware itself.   Bummer.

After some more research, I discovered an open-source software ‘fix’ for this hardware limitation called ‘relayd’.   It’s available through the built-in package manager and can be installed with a few clicks.   Configuring everything ‘correctly’ is a whole different story – I spent countless hours trying, failing, factory-resetting, trying again – until I found a repeatable, working and reliable step-by-step solution that doesn’t break things when you change settings afterwards in the standard GUI.

Here is the result of the project I now call “Wifi-Dongle 3.0” (this is actually my 3rd hardware attempt as mentioned in the first paragraph):

  • Bridge WIFI in client mode to the physical WAN port
  • Provide administration (and NAT) via the LAN port
  • Optional WIFI hotspot mirroring the LAN port, serving for administration via mobile device and/or range extending
  • Manage WIFI networks and hotspot settings via standard (non-advanced) GUI

Here are the steps required to achieve all of this.  You will need SSH/vi experience for one of the steps if you want visual status and/or better connectivity:

  1. Connect laptop or PC to the LAN port, and perform a factory reset (hold reset button for at least 10 seconds)
  2. Log into with a browser and do the initial setup.
  3. Standard GUI -> In WAN setup – Set to ‘repeater’ mode and join a network.  Wait at least a minute for the connection to come fully online before the next step.
  4. Standard GUI -> Make sure you are on the latest firmware (v2.22 as of this writing).
  5. Standard GUI -> Go into ‘app repo’,  seach for “relayd” and install both packages.   The GUI will show ‘error status 255’ each time but don’t worry, it worked.
  6. Advanced GUI -> Network -> Interfaces – Delete WAN6.
  7. Advanced GUI -> Network -> Interfaces – Create an interface called ‘stabridge’ with type set to ‘Relay Bridge’.   On the next page, leave IP address blank, and select ALL interfaces for relaying.
  8. Advanced GUI -> Network -> Interfaces – Edit WAN and change protocol to ‘unmanaged’.
  9. Advanced GUI -> Network -> Firewall – Set everything to forwarding in default settings and in both zones, add stabridge to the WAN zone, and finally enable forwarding between both zones.
  10. Advanced GUI -> System -> Startup -> Enable and ‘restart’ relayd

If you would like to change the WIFI network – keeping in mind the device will remember all network connections and automatically connect to whatever is available – simply go to the standard GUI and repeat step 3.

If you would like to enable/disable or change the name or password of the ‘hotspot’, go into the standard GUI and toggle the ‘switch’ to enable/disable it or click on the WIFI icon to change the settings.

I’ve been using several of these devices with these settings for a few weeks now and I would like to report that the reliability, range and performance is quite amazing.   The amount of stuff you can do with these little guys is nothing short of impressive.   Hopefully version 3.0 of this project will be the final solution.

I eventually plan to explore 3G/4G tethering functions and how they cooperate with the current settings.

Enable megasas2.sys Critical Mass Storage Driver

This reg key will enable the ability to boot from MegaRAID storage devices using the megasys2.sys driver. Useful to run before hand when upgrading or otherwise changing hardware to something with a LSI 9260, 9271 or similar card. This reg key REQUIRES that you already have the correct megasas2.sys driver installed one way or another.

OpenVPN Slow Downloads on Windows clients

Recently I upgraded my remote office connection to 100Mbps (cable) and spent almost a month dealing with slow downloads over an openVPN client connection. Uploads were fine (maxing out the pipe) but downloads were 12-20 Mbps at best and fluctuating like crazy. TCP client mode actually performed better than UDP so I knew something was wrong. After making sure my MSS/MTU was fine and UDP iperf tests were able to max out my connection (without the VPN, proving my ISP wasn’t throttling UDP), the following config on the server side is what ended up fixing it:

sndbuf 0;
rcvbuf 0;
push "sndbuf 393216";
push "rcvbuf 393216";

I now get 105 Mbps downloads on my openVPN connection (115 without VPN). Turns out the default buffers are just too small for high speed tunnels. Who would have known.

Debian PXE boot image from scratch

After facing issue after issue with Idera/R1soft’s PXE and CD-ROM boot media — specifically, ancient kernels which are unable to obtain network connectivity on modern hardware, I decided to roll my own PXE boot image including the R1soft agent and a few other tools with the latest Debian stable. It turned out to be easier than I expected — kudos to the debian-live project.

Boot into a debian Live-CD and set up the bootstrap environment. I’m using 7.6.0 (latest stable at this time).

apt-get install debootstrap squashfs-tools
mkdir -p work/chroot
cd work

If you’re creating the image from scratch, use the following commands.

debootstrap --arch=amd64 stable chroot
cp /etc/network/interfaces chroot/etc/network/interfaces # Needed for network connectivity

If you are re-working an existing image, you can import it instead.

wget http://webserver/debian-live/filesystem.squashfs
unsquashfs -f -d chroot filesystem.squashfs
rm -f filesystem.squashfs

Now we prep the image and chroot.

cp /etc/resolv.conf chroot/etc/resolv.conf # Needed for network connectivity
chroot chroot
mount none -t proc /proc
mount none -t sysfs /sys
mount none -t devpts /dev/pts
export HOME=/root
export LC_ALL=C

Now you can do whatever you want to the image by installing packages and modifying configurations. You need to install the kernel at a minimum if you want to load modules after boot such as raid. You can install kernel headers and compile 3rd party modules like the r1soft cdp agent. This is a minimal image, so don’t forget basic filesystem utilities like mdadm if you’re installing the r1soft agent; I learned the hard way and had to re-work the image several times. I enabled auto-login on tty1 through tty3 by installing mingetty and modifying inittab. I also like to redirect syslog to tty4 and disable any console logging on tty1 – tty3.

When you think you’re done, clean up and exit the chroot.

apt-get clean
rm -rf /tmp/*
rm /etc/resolv.conf
umount -lf /proc
umount -lf /sys
umount -lf /dev/pts

Compress and package the new filesystem image.

mksquashfs chroot filesystem.squashfs -e boot

Send it off to your HTTP webserver:

scp filesystem.squashfs user@webserver:/var/www/html/debian-live/.

And a working pxelinux.cfg entry after we’ve got the kernel and initrd in the correct place on the tftp server:

LABEL deblive
        KERNEL /debian-live/debian-live-7.6.0-amd64-standard.vmlinuz
        APPEND initrd=/debian-live/debian-live-7.6.0-amd64-standard.initrd.img dhcp ethdevice=eth0,eth1 boot=live fetch=http://webserver/debian-live/filesystem.squashfs

Grub with Xen Guests

In order for grub to ‘see’ virtual disks, you have to tell it about them with the ‘device’ command:

# grub
grub> device (hd0) /dev/xvda
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

Keep in mind, installing grub on the MBR is not always necessary with Xen PV guests, but is highly useful for V2P conversions.

XenServer 6.2 with Software RAID

Historically XenServer does not support software RAID out-the-box, and this is unchanged in the latest 6.2 release. We can convert it to RAID after installation.

First we set up the 2nd disk by copying the partition tables whilst enabling a degraded RAID on it, then copy data over with custom initrd.

sgdisk -R/dev/sdb /dev/sda  # Replicate partion table from /dev/sda to /dev/sdb with unique identifier
sgdisk --typecode=1:fd00 /dev/sdb
sgdisk --typecode=2:fd00 /dev/sdb
sgdisk --typecode=3:fd00 /dev/sdb
# Sleep 5 seconds here if you script this...
yes|mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb1 missing # Create md0 (root)
yes|mdadm --create /dev/md1 --level=1 --raid-devices=2 /dev/sdb2 missing # Create md0 (swap)
yes|mdadm --create /dev/md2 --level=1 --raid-devices=2 /dev/sdb3 missing # Create md0 (storage)
# Sleep 5 seconds here if you script this...
mkfs.ext3 /dev/md0 # Create root FS
mount /dev/md0 /mnt # Mount root FS
cp -xR --preserve=all / /mnt # Replicate root files
sed -i 's/LABEL=[a-zA-Z\-]*/\/dev\/md0/' /mnt/etc/fstab # Update fstab for new RAID device
mkdir /mnt/root/initrd-raid && cd /mnt/root/initrd-raid
mkinitrd -v --fstab=/mnt/etc/fstab /mnt/root/initrd-raid/initrd-`uname -r`-raid.img `uname -r`
zcat initrd-`uname -r`-raid.img | cpio -i
sed -i 's/raidautorun \/dev\/md0/raidautorun \/dev\/md0\nraidautorun \/dev\/md1\nraidautorun \/dev\/md2/' init
rm -f initrd-`uname -r`-raid.img
find . -print | cpio -o -Hnewc | gzip -c > /mnt/boot/initrd-`uname -r`-raid.img
rm -f /mnt/boot/initrd-2.6-xen.img
ln -s initrd-`uname -r`-raid.img /mnt/boot/initrd-2.6-xen.img
sed -i 's/LABEL=[a-zA-Z\-]*/\/dev\/md0/' /mnt/boot/extlinux.conf
cat /mnt/usr/share/syslinux/gptmbr.bin > /dev/sdb
cd /mnt && extlinux  --raid -i boot/
sgdisk /dev/sda --attributes=1:set:2
sgdisk /dev/sdb --attributes=1:set:2
cd && umount /dev/md0

Now, make sure BIOS forces booting from 2nd disk. This is VERY important! After reboot, finish off:

sgdisk -R/dev/sda /dev/sdb  # Replicate partion table from /dev/sdb to /dev/sda with unique identifier
mdadm -a /dev/md0 /dev/sda1
mdadm -a /dev/md1 /dev/sda2
mdadm -a /dev/md2 /dev/sda3  # If this command gives error, you need to forget/destroy an active SR first
mdadm --detail --scan > /etc/mdadm.conf
xe sr-create content-type=user device-config:device=/dev/md2 host-uuid=[host_uuid] name-label="Local Storage" shared=false type=lvm

Before going into production, try booting from each disk (with the other removed from the boot priorities), then restore the boot priority to normal.

Be careful with Xenserver patches, especially any patch which requires a reboot – if the initrd image is rewritten (for example, kernel updated), you need to carefully rebuild the initrd for RAID support again which is NOT covered in this article.

EXT and LVM Local Storage in XenServer

On a new XenServer deployment EXT storage is default. Although EXT is nice (ability to manipulate raw VHD files and use sparse storage), LVM is faster and more stable. Here is how to switch between storage modes (be sure to back up all data first, as this will wipe everything in the repo):

Use ‘xe sr-list’ and ‘xe pbd-list’ to find your local storage SR and it’s PBD. Also note the physical device number / partition in the PBD, so you can re-create it on the same device later on.

Unplug the active SR’s PBD (physical block device):

xe pbd-unplug uuid=<pbd_uuid>

Destroy the SR:

xe sr-destroy uuid=<sr_uuid>

Create a new SR of the specified type and location:

xe sr-create content-type=user device-config:device=/dev/<device> host-uuid=<host_uuid> name-label="Local Storage" shared=false type=<lvm|ext>

You can verify the SR again with ‘xe sr-list’ and it should already be in XenCenter as the default.