Posted tagged ‘Hardware’

Configuring a Generic Wireless LAN Bridge

August 18, 2013

Some time ago, I purchased a generic 802.11n Wireless LAN repeater, after having issues with receiving a reliable wireless connection to my ADSL residential gateway/router due to interference from neighbouring networks, and the signal propagating poorly throughout the back of the house.

I ended up buying it as a “cheap workaround”, after getting frustrated with being unable to maintain a reliable connection on my laptop, or various phones – despite trying things like switching to less congested channels (usually 9, or 13), increasing transmission power rates (at the expense of battery life); and decreasing maximum bitrates to ridiculously-levels.

Technically, the bridge is a small, embedded Linux-based device with a RealTek RTL8186 MIPS-derived system-on-chip, supporting Ethernet, and 802.11; PCI, and even PCM audio. (Which seems like overkill – but I suppose that it’s probably cheaper to design, and distribute a universal, multipurpose chipset, than it would be to produce cut-down variants).

Common complaints that buyers on Amazon had were that the firmware was buggy, the device was unreliable, and that the device’s Web-based configuration tool supposedly became inaccessible, post-configuration.

However, I found that if I ignored the supplied instructions, and attempted to configure the device by using a direct connection to my PC using Ethernet, I was able to configure it in a reliable manner that allowed for continued access to its administration server, as well as roaming throughout the house using the same SSID

Please note that the values in the screenshots are specific to my home network, and are not factory defaults.

Unfortunately, since I have discarded the packaging, I can’t provide photos of its contents – although I’m sure that they consisted of at least:

  • The device itself
  • An instruction leaflet
  • A short Ethernet cable
  • A detachable 3-pin UK mains plug

To begin with, I unpacked the product; plugged into a power outlet, and connected the Ethernet cable to my laptop.

Next, I temporarily disabled the use of my laptop’s wireless LAN chipset, using the hardware kill-switch, to ensure that requests for multiple IPv4 addresses via two hardware interfaces won’t be made.

The bridge ships configured with a DHCP server enabled by default, issuing IPv4 addresses within the 192.168.10.x range, and reserving for itself – but we’ll change this, later.

First, navigate to the default configuration URL (, using your preferred browser:

Next, select the “Wireless” option from the “Professional Setup” category:

Here, set the following options:

  • “Mode”: “Repeater”
  • “Network Type”: “Infrastructure”
  • “SSID of Connect to” (sic): Enter the SSID of your primary access point
  • Check the “Enable Universal Repeater Mode (Acting as AP and client simultaneouly” (sic) checkbox
  • “SSID of Extended Interface”: Enter the SSID of your primary access point again

If you have configured your primary access point to enable operation in 802.11n mode, then select either “2.4GHz (N)”, “2.4GHz (G + N)”, or “2.4GHz (B+G+N)” from the “Band” menu. Otherwise, “2.4GHz (B+G)” should deliver satisfactory performance for most WAN-based activities.

In order for seamless handover between access points using the same SSID to work well, it is then necessary to set the default 802.11 channel of your primary access point to 11. (This seems to be a hard-coded, preset value).

It may also be necessary to configure WEP, or WPA keys for your primary access point on the “Security” page; and I also recommend changing the configuration tool’s access credentials to something more secure than their default values.

After configuring these settings, the bridge will reboot automatically…

Once the bridge has rebooted, return to the “LAN Interface” page:

On this page, set the “DHCP” setting to “Client”, and apply changes. At this point, because the bridge will attempt to obtain its configuration IPv4 address from your primary access point/gateway’s DHCP server, it’d be a good idea to disconnect the Ethernet cable, and re-enable the PC’s wireless LAN interface.

Hopefully, at this point, a successful WLAN connection will have been made.

However, in order to maintain future access to the bridge’s configuration server, it is necessary to assign a static IPv4 address to its MAC address (printed on a sticker on the case – but it’ll probably also appear in system/DHCP server logs) using the configuration tool of your primary access point.

After configuring this, power-cycle the bridge, and attempt to access its configuration page via the newly-set IPv4 address. If successful, you should be presented with an authentication dialogue, and be able to see the configuration tool’s status page, as at the beginning.

Hopefully, this will be of assistance to other owners of these devices, or folks contemplating purchasing one.

Let’s Try RTL-SDR! – Part 1

July 26, 2012

Recently, I received a device that was originally marketed as a USB DAB/DVB/FM receiver, containing a chipset compatible with the utilities from the RTL-SDR project.

It cost £17.50 (roughly €22.42/2159円/US$27.45, according to WolframAlpha) including free shipping from the US.

What’s in the kit?

The receiver that I ordered was supplied with only a remote control, and a stubby antenna with a magnetic base. No CD-ROMs, or user manuals were included.

About the hardware

The eBay listing page claims that it contains an Elonics E4000 tuner IC, and a RealTek RTL2832U DVB-T demodulator IC.

lsusb -v Reports:

Installing RTL-SDR, and associated utilities

Download and run the build-gnuradio script, as recommended by Andrew Back:

At this stage, the script will request elevated privileges, in order to search for prerequisite packages using the system package management utilities.

Since the disclaimer warns that the process may take a long time, I’d recommend obtaining one’s favourite beverage; ensuring that the PC used has a sufficient amount of free disk space, and is well-ventilated (if using a laptop), to prevent it from potentially overheating, and unexpectedly shutting down; and searching for something else to do in the meantime…

For some reason, the Checking for package python-gtk2 step seems to take an unusually long time on my laptop; and temporarily stopping the script yielded:

It seems that despite my best efforts to prepare things in advance, I ran out of disk space at that stage:

Eventually, I resorted to running apt-get clean && apt-get autoclean, and moving some large files to an external disk, in order to free 1.5GB of 9.4GB; and re-ran the script, with more successful results:

It seems that on a 64-bit Ubuntu installation, a full instance of the script’s working directory (containing all source code, and binaries) is about 520MB in size.

Notes on AirProbe installation

For readers wishing to install AirProbe using the instructions on the project’s Website, I recommend running sudo ln -s /usr/local/include/gruel/swig/gruel_common.i /usr/local/include/gnuradio/swig/ && ldconfig, after installing GNURadio, in order to avoid some frustrating bugs in various build scripts related to missing “Gruel”, and “SWIG”-related files.

Testing the result

Since this post is becoming rather long, and I’m unsatisfied with the content that I planned for this section, I’ll follow up with a second post related to testing the software post-installation, soon.

Attempting to boot Symbian^3 on the TMDSEVM3530 : Take 2

August 1, 2011

I’ve just received the USB/RS-232 adapter (which is based around the FTDI FT232BM chipset, and supported under Linux without any additional work), and connected it to the board’s UART1/2 port and my laptop using the null modem cable supplied with the board.

For the curious, dmesg reports:
[ 177.992226] usb 2-2: new full speed USB device using ohci_hcd and address 3
[ 1090.655407] usb 2-2: USB disconnect, address 3
[ 1160.036191] usb 2-2: new full speed USB device using ohci_hcd and address 4
[ 1160.656891] usbcore: registered new interface driver usbserial
[ 1160.656938] USB Serial support registered for generic
[ 1160.659703] usbcore: registered new interface driver usbserial_generic
[ 1160.659709] usbserial: USB Serial Driver core
[ 1160.676061] USB Serial support registered for FTDI USB Serial Device
[ 1160.677502] ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
[ 1160.677628] usb 2-2: Detected FT232BM
[ 1160.677632] usb 2-2: Number of endpoints 2
[ 1160.677635] usb 2-2: Endpoint 1 MaxPacketSize 64
[ 1160.677639] usb 2-2: Endpoint 2 MaxPacketSize 64
[ 1160.677642] usb 2-2: Setting MaxPacketSize 64
[ 1160.694632] usb 2-2: FTDI USB Serial Device converter now attached to ttyUSB0
[ 1160.696459] usbcore: registered new interface driver ftdi_sio
[ 1160.696466] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver

sudo lsusb -v reports:

Bus 002 Device 004: ID 0403:6001 Future Technology Devices
    International, Ltd FT232 USB-Serial (UART) IC
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0403 Future Technology Devices
     International, Ltd
  idProduct          0x6001 FT232 USB-Serial (UART) IC
  bcdDevice            4.00
  iManufacturer           1 FTDI
  iProduct                2 USB-to-Serial
  iSerial                 3 FTE2QSKA
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower               44mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              2 USB-to-Serial
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
Device Status:     0x0000
(Bus Powered)

We can confirm that everything works by running cat /dev/ttyUSB0 from a BASH session, and powering on the board:

tyson@UmBongo:~$ cat /dev/ttyUSB0 

Texas Instruments X-Loader 1.47 (Jan 14 2011 - 15:43:28)
Starting X-loader on MMC
Reading boot sector

212836 Bytes Read from MMC
Starting OS Bootloader from MMC...
Starting OS Bootloader...

U-Boot 2010.06 (Jan 14 2011 - 15:43:45)

OMAP3430/3530-GP ES3.1, CPU-OPP2 L3-165MHz
I2C:   ready
DRAM:  128 MiB
NAND:  256 MiB
*** Warning - bad CRC or NAND, using default environment

In:    serial
Out:   serial
Err:   serial
Read back SMSC id 0xffff0000
Die ID #2f7c000400000000040365fa1801900d
Net:   smc911x-0
Hit any key to stop autoboot:  0
mmc1 is available
reading boot.scr

421 bytes read
Running bootscript from mmc ...
## Executing script at 82000000
reading uImage

** Unable to read "uImage" from mmc 0:1 **
***** RootFS: /dev/mmcblk0p2 *****
Wrong Image Format for bootm command
ERROR: can't get kernel image!

Obviously, since I renamed the uImage file on my Android SD card from earlier (to kuImage), the board fails to successfully boot Linux.

After downloading and installing CuteCom (a Qt-based serial console utility), and configuring it to communicate with the board at 115200 baud, using 8 data bits, and without parity or software/hardware handshaking, the help command command can be issued to the board’s bootloader – which results in:

OMAP3_EVM # help
?       - alias for 'help'
base    - print or set address offset
bdinfo  - print Board Info structure
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
bootp   - boot image via network using BOOTP/TFTP protocol
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dhcp    - boot image via network using DHCP/TFTP protocol
echo    - echo args to console
editenv - edit environment variable
exit    - exit script
ext2load- load binary file from a Ext2 filesystem
ext2ls  - list files in a directory (default /)
false   - do nothing, unsuccessfully
fastboot- fastboot- use USB Fastboot protocol

fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
fsinfo  - print information about filesystems
fsload  - load binary file from a filesystem image
go      - start application at address 'addr'
help    - print command description/usage
i2c     - I2C sub-system
imxtract- extract a part of a multi-image
itest   - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
ls      - list files in a directory (default /)
md      - memory display
mm      - memory modify (auto-incrementing address)
mmc     - MMC sub-system
mtest   - simple RAM read/write test
mw      - memory write (fill)
nand    - NAND sub-system
nandecc - switch OMAP3 NAND ECC calculation algorithm
nboot   - boot from NAND device
nfs     - boot image via network using NFS protocol
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv  - set environment variables
showvar - print local hushshell variables
sleep   - delay execution for some time
source  - run script from memory
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
true    - do nothing, successfully
version - print monitor version

At this stage, it’s necessary to remove the SD card from the board, and attempt to copy a Symbian ROM image to it.

Unfortunately, after installing Android, it’s also necessary to resize the ~70MB primary partition in order to make it fit. The quickest way to do so would probably be to use GParted and a USB card reader, if you’re using Linux under a virtual machine (as opposed to rebooting into a Wubi installation, in order to use my laptop’s internal reader, which I was initially tempted to do).

An SD card prepared using the the tool from the aforementioned archive contains an x86 partition table, and 3 partitions (a 70.57MiB FAT32 boot partition, a 941.31MiB Ext3 root partition, and an 870.71MiB FAT32 data partition).

Since it is possible to reconstitute these partitions using that tool, and since they’re unnecessary for the Symbian Platform, we can remove the root and data partitions, and then resize the boot partition to be 512.97MiB in order to store the Symbian ROM with some allowances for future growth.

If that process fails with “GNU Parted cannot resize this partition to this size. We're working on it!“, then:

  • Mount the boot partition (usually sdb1)
  • Copy all of its contents to a convenient location
  • Unmount the partition
  • Remove the partition using GParted
  • Create a new 512.97MiB FAT32 partition with 0MiB free space preceding it
  • Mount the newly created boot partition
  • Copy the “boot.scr“, “MLO” and “u-boot.bin” files from earlier to said partition
  • Unmount the partition – if you’re using a VM, and want to copy the ROM using the host OS, instead of the guest OS

Now, we can attempt to copy “beagle.rom.img” from the “ROM Images” directory to the root of the boot partition as “uImage“, unmount the partition, and then insert the card back into the board.

Unfortunately, at this stage, although several LEDs on the board illuminate, I can’t see any output from it on the serial console – which leads me to suspect that the bootloader and firmware on the card isn’t being loaded. Testing using the Windows CE card lends credence to that thought.

Attempting to copy the x-load.bin.ift file from /OMAP35X/Boot_Images to the root of the boot partition also yields the same result.

After quickly making some raw sector dumps of both SD cards, I suspect that the structure of the x86 MBR/partition table, and the location of the boot partition is a factor in the ability to boot the board.

For comparison, file reports the following, for the Windows CE card:

dump: x86 boot sector, code offset 0x0, OEM-ID "MSDOS5.0", sectors/cluster 64, root entries 512, Media descriptor 0xf8, sectors/FAT 236, heads 64, hidden sectors 135, sectors 3858489 (volumes > 32 MB) , serial number 0x61636637, unlabeled, FAT (16 bit)

For the modified Android card, this is reported, instead:

dump2: x86 boot sector; partition 1: ID=0xb, starthead 32, startsector 2048, 1048576 sectors, code offset 0xb8

With that in mind, since I’ve got a complete raw backup of the Windows card that I can restore later; I’ll remove the EBOOTSD.NB0, MLO, and NK.BIN files, and copy over the Android boot files (modulo the Linux kernel binary), plus a Symbian ROM image.

Lo and behold, we now have X-Loader and U-Boot, which attempt to boot our “Linux” kernel into 0x82000000, but seem to get stuck afterwards.

After getting this far, I’ll probably take a break, and see if manual intervention at the bootloader prompt gets us any further, later. 🙂

Attempting to boot Symbian^3 on the TMDSEVM3530 : Take 1

July 31, 2011

Given that I’ve recently obtained a Texas Instruments TMDSEVM3530 development board (which is supposedly a cousin of the slightly-more-popular BeagleBoard, from what I can gather), thanks to Andrew Back (and DesignSpark), I thought that it’d be interesting to see if I could get Symbian^3 running on it.

I’ve got another, more detailed post sitting in my WordPress drafts, but I thought that I’d share some rough notes that I managed to salvage from an unsaved document, prior to yet another ATI driver-induced BSOD moment, in the meantime.

Note: Everything mentioned here is the hypothetical product of “thinking out aloud”, and I can’t guarantee that anything mentioned here will actually work, or that your expensive development board won’t be reduced to a smouldering pile of rubble.

I also recommend obtaining a USB/RS-232 cable, if you haven’t either already got one, or you’re unfortunate enough to have a “modern”/”legacy-free” PC without RS-232 serial ports. Unfortunately, mine’s currently in Paris according to FedEx, so I’m working blindly for the moment.

It’s also probably a good idea to make either a copy of the individual files from the Windows CE demo SD card that ships with the board, or create a raw disk image of its sectors using WinImage, dd or a similar tool.

With that in mind:

  • Download and unpack the ROM archive from DropBox
  • Rename or move the NK.BIN file in the root directory of the aforementioned SD card, so that it can be restored later
  • Copy either beagle.rom.img or wildducks_demo.rom.img from the ROM Images directory to the root directory of the card as NK.BIN
  • Unmount the card and insert it into the board’s SD card slot
  • Attempt to boot the board…

It’s probably also necessary to replace the MLO and/or EBOOTSD.NB0 files with new ones, although I haven’t got around to figuring out what to replace them with, yet.

Inserting the card into the board’s SD Card slot will cause it to display a splash screen containing 4 coloured squares during the boot process – but seemingly causes it to do little else (unsurprisingly).

At this stage, if you rely on using the Windows CE card to test booting from SD, it’d be a good idea to reinstate the original NK.BIN file.

Another approach would be to obtain another SD card, use the shell script contained within the “OMAP35x EVM” package from this page to install Android on it, and then replace the uImage file (after backing it up) with one of the files from ROM Images.

However, doing so results in the board’s LCD being blank during boot.

The chances are that at this stage, you’ve either:

  • Irreversibly damaged your board – unlikely, since booting the WinCE card works successfully
  • Got stuck in a bootloader loop somewhere – very likely, according to a wild guess
  • Successfully achieved a boot of the OMAP35x evaluation board using a ROM that obviously wasn’t intended for it – very unlikely

If you’re unable to debug the board using one of its serial ports afterwards, then the most that you can do is either stare at 4 LEDs, or replace the uImage file with the original version and play with an unstable build of Android.

With a serial cable, and the board’s bootloader console, you could probably attempt to try a modified version of the Quick Start instructions from the old Symbian Wiki.

If those don’t work, then attempting to load the ROM image at one of the memory locations mentioned in this QNX-related page, or at the Wild Ducks page might (if you’re lucky).

I’ll probably have another play, once my cable arrives…