TP-WN822N AP/Master Mode - Summary

If you have been following my previous threads on this topic, you will know the pains I have been through with this, both involving the ARM architecture and the Atheros ath9k driver for the TP-WN822N adapter.  The goals were simple enough:

• Incorporate Wi-Fi access point into NAS driver.
• Eliminate requirement for attaching ADSL / Wi-Fi switch.
• Eliminate requirement for attaching secondary USB Ethernet port.
• Upgrade kernel from 2.6 to 3.X.
• Setup PPPoE on primary Ethernet port to also eliminate the need for an ADSL modem.

The end goal was really about reducing the number of things plugged into the mains.  Previously, there were roughly three devices drawing power through transformers.  The NAS itself, the ADSL / Wi-Fi switch and a EOP (Ethernet over Power) home plug.  The Wi-Fi was G rated, so was no good for use as the primary form of network connectivity.  However, upgrading to N rated adapters throughout the house and being able to relocate the NAS drive makes for there being no real requirement for physical network connectivity; wireless seems to be the way to go.  So ditching everything and upgrading to BT Infinity leaves me with the NAS drive and the Infinity modem plugged in.  The Infinity modem is a necessity unfortunately but BT kindly mounted it on the wall next to the phone socket.  What I don't have is the BT home hub or any other form of wireless switch / infinity / ADSL modem.  Instead, PPPoE on eth0 and a USB wireless adapter running in AP mode is all that is required.

How to summary:

Let me summarize the three previous posts and fill in the gaps on how I eventually got this all to work.  So firstly, let's mention that I couldn't get this working using the 3.2 kernel, though I am yet to identify the reason, given my TTL cable has only just arrived.  So a 3.4 kernel is a minimum requirement.  Building is fairly simple, you can do it on box (NAS) or cross compile it.  The choice is yours, but it could be the difference between 7 hours or 5 minutes.  Cross compiling on my i7 running parallel make processes up to a load average of 15, utilises all the memory and finishes the entire kernel build, including modules, in around four and a half minutes.  Great if you need keep changing it in experimentation mode!  I have a script that can be downloaded for making cross compilation a simple one-liner.  It will ask for permission to install the necessary modules for cross compilation against ARM architecture and will auto create base kernel configuration.  It has a usage '--help' option, so if you choose to use it, check out the options: --menuconfig is a good one to note, since you will need that for selecting the appropriate kernel modules.

Building the kernel:

Building is fairly straight forward.  Depending on the platform, be it, armel or armhf, you can use the gnueabi cross compiler.  To get started, install the following packages:

• g++-arm-linux-gnueabi
• dpkg-cross
• devio
• fakeroot
• uboot-mkimage
• u-boot-tools

If you want to use the graphical menu configuration tool, then also install:

• libcurses5
• libcurses5-dev

Next you need to be aware that all make invocations need to run with the architecture and cross compiler options set.  The simplest way to make sure you get this right is to run the following:

alias make='make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-'

This way, you can't forget!  I actually went to the extent of creating a new user with this set in the .bashrc file.

So to build the kernel, clean it out first:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- mrproper

Now copy in your existing configuration.  This will be the configuration you have on the target machine, not the one you are building on.  The easiest way to obtain it, is to use the following command:

ssh you@yourmachine "zcat /proc/config.gz" > ~/linux-3.4.X/.config

The output file is within the root of the kernel source you will build.

Now you have that in place, you will need to upgrade the configuration.  Run:

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- oldconfig

That will prompt you for some details about what modules to build.  For this, you may choose to accept the defaults.  You should then change the following settings in the file:


CONFIG_ARCH="arm"
CONFIG_CROSS_COMPILE="arm-linux-gnueabi-"
CONFIG_LOCALVERSION="-2012-12-12-1212"
CONFIG_LOCALVERSION_AUTO=n

Set the LOCALVERSION to the date in the form of YYYY-MM-DD-HHMM.  This makes it easier to identify when you built it, as opposed to some sequential value.  Alternatively, set it to some unique name that you would prefer to use.

Once you have been through the setup, you then just need to setup the Atheros modules.

make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig

This will start the graphical menu configuration.  To build the Atheros drivers for the TP-LINK device, you need to locate them under:

 Device Drivers ---> Network Device Support ---> Wireless LAN ---> Atheros Wireless Cards 

Before you can select what Atheros drivers to build, you must first select this category using the space bar.  Once selected, you can hit enter to expand the category and enable the following modules:

Once you have selected these modules and any others you desire, you can exit the menu and build the kernel.  Now, the target you need to build with depends on whether you need the uboot hack.  If you are installing this kernel on your hacked Buffalo LinkStation NAS, you will need to build the zImage and perform the necessary hacks to create your uImage.  However, if you are using a standard uboot configuration, then just get cracking by using the uImage target:

make -j -l 15 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage modules

For the uImage hack:

make -j -l 15 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- zImage modules

( devio  'wl 0xe3a01c06,4' 'wl 0xe3811031,4' ; cat arch/arm/boot/zImage ) > /tmp/zImage
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n linux -d /tmp/zImage arch/arm/boot/uImage

Next, setup the modules install package, by installing them into a temporary directory.


make -j -l 15 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules_install INSTALL_MOD_PATH=/some/temporary/path


You will now have a uImage that you can copy into your boot partition on your ARM device.  You will also have modules setup and ready to install.  To install them, use ssh to transfer them across:

( cd /some/temporary/path ; tar Jcf - lib ) | ssh you@yourmachine "cd / && sudo tar Jxvf && sudo chown -R root:root /lib/modules/linux-3.4.X-2012-12-12-1212"

You get the idea.  But you can get the modules and firmware on however you choose.

MK802 - Linux (Debian) how to

Installing Linux is fairly straight forward providing you have an appropriately sized SD card.  Rather than go into too much detail, the images and a guide to installing can be found here:

https://www.miniand.com/forums/forums/development/topics/debian-wheezy-lxde-armhf-build

After installing however, it's extremely advisable that you lock it down before attaching it to your network.  I've never met the author of the image, don't know him and therefore can not trust the image entirely.  My first port call was to build my own kernel.  You are best using cross tools for this, which I have explained in detail in another post.  Ensure the kernel is built with the appropriate configuration.  You can use the existing kernel configuration as follows:

$ cat /proc/config > ~/mk802-kernel-config

Next, lock down the firewall and update the rules.  Go for a block everything and open what is required approach.  If you accidentally lock yourself out, just power off the device, remove the SD card, mount on your computer and revert whatever changes necessary to allow you access again.

Go through running processes with a fine tooth comb.  Make sure you are only running what you need.  If you don't need the GUI, make sure you change the default runlevel in /etc/inittab.  A runlevel of 3 will disable the GUI normal (unless it is a fluffy distro like Ubuntu).

Make sure you change the access point passphrase if you intend to create an access point.  Also make sure the network interfaces configuration isn't defining soft MAC addresses for your network devices.

There are many more ways to harden the system.  Take a look at some of the many Linux hardening guides on the net.

RSync for Google Drive is here...

I have been working on an implementation of RSync specifically for Google Drive.  I now have it synchronizing between client and server using many of the basic rsync options.  I am limited on the time I have with which to develop it and test it, so am looking to find volunteers willing to use the software and identify issues.  The project is hosted on git hub here:

GSync on Github

Update:  I have published the GSync application to pypi.python.org.

https://pypi.python.org/pypi/gsync/0.1.0

To install using pypi, you just need to execute the following command:

    $ sudo pypi-install gsync

It will autoresolve dependencies and install require packages.  To install the pypi-install utility on debian, execute the following command:

    $ sudo apt-get install python-stdeb

Thanks.