Unofficial Smartq V5/V7 Linux Development Guide

This is a backup of the original doc at: http://docs.google.com/View?id=ddtx8wkh_18g39zskpm

Unofficial Smartq V5/V7 Linux Development Guide

This guide describes how to compile your own linux kernel and how to create SmartqV firmware image for flashing the V5 or V7.
You need a working linux host for development, I'm using Ubuntu.

1. Download the SmartqV SDK: http://rghost.net/980682
2. Extract SDK to your working directory: tar -xvf SmartqV_SDK.tar.gz
3. Install ARM toolchain:

• Extract armv6_codesourcery.tar.bz2 file into /opt directory: tar –xvf armv6_codesourcery.tar.bz2
• You should see /opt/armv6/... directory created.

4. Go back to SmartqV_SDK directory and extract the kernel:

• tar -xvf mer-smartq-mer-smartq-kernel-smartqv.tar.gz
• You can always download the latest kernel from: http://gitorious.org/mer-smartq/mer-smartq-kernel/commits/smartqv

5. Extract fw-utils:

• tar -xvf fw-utils.tar.bz2

6. Compiling the kernel:

• cd mer-smartq-mer-smartq-kernel

• Create default configuration: make SmartV7_defconfig for V7 or make SmartV5_defconfig for V5.
• Run ./make_zImage_rootfs.sh and you can find a file named linux.rom under ../fw-utils directory.
• make modules && make modules_install INSTALL_MOD_PATH=`pwd`/module-collection
  This pulls the generated modules into the ./module-collection directory, which can then be easily transferred with the kernel.

7. Creating firmware image:
• cd ../fw-utils
  
• For V7: ./compress.v tcboot.V7 linux.rom 0 && mv SmartQV5 SmartQV7
• For V5: ./compress.v tcboot.V5 linux.rom 0. The tcboot.V5 is not included in SDK, but you can extract it from official V5 image (see below).
  
• This will create SmartQV5 or SmartQV7 firmware image.
  

8. Copy the image to SD card and flash as usual.
9. Notes: The firmware image will update only the bootloader and kernel image.
   You can create a full image including rootfs and homefs using compress.v utility.
   Use uncompress utility to extract newest bootloader from official firmware. Extracted files saved in /tmp directory.

Enjoy!

pause/resume a linux process

To pause:

kill -STOP pid

To Resume:

kill -CONT pid

Works perfectly.

Simple NAT for Internet sharing

You need a Linux machine (or virtual machine running Linux, or Colinux) to do this:

#enable routing
echo 1 > /proc/sys/net/ipv4/ip_forward

#flush iptable
iptables -t nat -F

#enable DNAT (also known as IP masquerading)
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

#enable port forwarding
iptables -t nat -A PREROUTING -i eth1 -p tcp --dport 2401 -j DNAT --to 192.168.16.66:2401
iptables -t nat -A PREROUTING -i eth1 -p ALL --dport 82:88 -j DNAT --to 192.168.16.66:5000:5006

A good Javascript Calculator

http://cc.joensuu.fi/~tniemi/tools/calc.html

rpl_malloc error with configure

If you get a problem about an undefined reference to rpl_malloc, you probably need to do:
$ export ac_cv_func_malloc_0_nonnull=yes
before running ./configure ...

Serial Terminal Emulator on Linux/Ubuntu

Minicom, PuTTY, picocom, gtkterm, or cutecom

Console based:

1. minicom: the grand master and the one most people use
2. picocom: a mini minicom
3. some others not very well used such as: microcom, nanocom

GUI based:
1. cutecom (Qt based), able to dispaly and send HEX
2. gtkterm (GTK based, last release 2005), able to set serial port pin, and read pin status, and display and send HEX
3. PUTTY for linux (GTK based)

I recommend minicom, picocom and gtkterm.

Sichua Earthquake and Three Gorges Dam

From the following article, this Dam most likely have contributed to the Sichua earthquake. You use use Google Translate to read it in English.

http://www.zaobao.com/special/feature/pages/feature080706.shtml

　　中国地震界制定了可能产生水库诱发地震的七项定性标准：①坝高于100米，库容大约10亿立方米；②库坝区有活动断裂；③库坝区为中新生代断陷 盆地或其边缘，近代升降活动明显；④深部存在重力梯度异常；⑤岩体深部张裂隙发育，透水性强；⑥库坝区曾有地震发生；⑦库坝区有温泉。上述七项，符合数越 多，该水库蓄水后诱发地震的可能性就越大。

　　范晓说：“紫坪铺水库符合了上述七项标准中的前六项。”惟独没有的是，紫坪铺附近没有温泉。

　　他根据本身进行的调查进一步指出，紫坪铺水库所处的地质结构位置相当令人担忧。“水库大坝下距龙门山主边界断裂在地表的出露迹线仅2公里，库尾淹没线上距龙门山中央断裂地表出露迹线仅约500米，库区还有与上述断裂平行的密集断层群通过。”

ctags for matlab on Windows

1. create a environment variable called HOME, and pointed it to whatever directory you like. On vista, I pointed to c:\Users\MYNAME

2. create file ctags.cnf under HOME directory you just pointed to with the following 3 lines:

--langdef=matlab
--langmap=matlab:.m
--regex-matlab=/^function([] A-Za-z0-9,_[]+=[ ]?|[ ]+)([^.(]+).*$/\2/f,function/

And done. Now you can run Ctags -R * on top of your project to create matlab tags file.

a short guide to enable samba server on Ubuntu

1. sudo apt-get install samba
2. sudo vi /etc/samba/smb.conf, look for [homes] and uncomment the following lines starting with [homes], change browserable to yes and readonly to no

[homes]
comment = Home Directories
browseable = yes

# By default, the home directories are exported read-only. Change the
# next parameter to 'no' if you want to be able to write to them.
  read only = no

3. give samba user a password by doing:

sudo  smbpasswd -a USERNAME

4. reload samba conf file by doing:

sudo /etc/init.d/samba reload

Done.

On Windows Explorer, type \\UBUNTU_IP_ADDRESS\USERNAME to see the share.

ssh file system mount

1. sudo adduser USER fuse
2. mkdir destdir
3. sshfs USER@REMOTEHOST:. destdir

done.

Setup Ubuntu to be a remote desktop server

http://ubuntuwiki.net/index.php/Xrdp,_installing

1. sudo apt-get install xrdp

2. run as your user (not root) this: "vncserver :1

3. vi /etc/xrdp/xrdp.ini and make sure you have this section. You can have one session for each user.

[xrdp1]
name=Your Name
lib=libvnc.so
username=na
password=ask
ip=127.0.0.1
port=5901

4. comment any line about twm or xterm and add this line to your local ~/.vnc/xstartup file:
#vncconfig -iconic &
#xterm -geometry 80x24+10+10 -ls -title "$VNCDESKTOP Desktop" &
#twm &
/etc/X11/Xsession

5. restart xrdp sevice: /etc/initrd/xrdp restart

6. vi /etc/rc.local to add this line for each user (vncserver :number should be different for each user):
su USER1 -c "cd && vncserver :1"
su USER2 -c "cd && vncserver :2"



done

List Debian installed packages by size

dpkg-query -W --showformat='${Installed-Size;10}\t${Package}\n' | sort -k1,1n

size is KBytes

Fix Mic for Skype on T61 Ubuntu 9.10

# In Skype’s Options / Sound Devices, change “Sound In” to the raw hardware device; mine was “HDA Intel (hw:Intel:0)”, but it will take some experimentation and some test calls to figure out the correct setting. Do NOT set it to “pulse”; there is a known bug in Ubuntu’s implementation of PulseAudio that causes delays of many seconds on microphone input.

# Also in Skype’s Options / Sound Devices, set both “Sound Out” and “Ringing” to “pulse”.

# Also in Skype’s Options / Sound Devices, it may be necessary to uncheck “Allow Skype to automatically adjust my mixer levels”.

# Right click on the task bar’s volume control (the speaker icon), and select Open Volume Control. Hit the Preferences button, and add the following two controls: Capture (Recording) and Input Source (Options). Then in the Volume Control dialog, in the Recording tab, bring up the Capture level to near full, and in the Options tab, set the Input Source to Internal Mic. On Xubuntu (XFCE), use the Mixer, and "select controls", and make sure you select the two "Input"s.

This should fix it. No reboot needed. I think the last line is the actual fix.

Two steps to install bootloader on your USB key

You can also use this to boot into Ubuntu Wubi installation while having your windows in Hibernation!

Install MBR on the USB stick

On windows:

1. download grubutil for windows then extract all and run grubinst_gui.exe
   
2. Select from the menu 'Disk' and click 'Disk Refresh' then choose your usb device.
3. Select 'Part List Refresh' and choose 'Whole Disk (MBR)'
4. Click 'Install', and that's it.

On Linux:
- Download the source of grubinst from SourceForge http://downloads.sourceforge.net/gru...7&big_mirror=0
- Uncompress the zip file to some directory (in your home partition for example)
- Open a terminal
- Go to that directory
- Compile grubinst using
Code:

make -f Makefile.lnx

- Get the proper device name of you USB key. It is IMPORTANT you do not do mistakes here otherwise you will destroy you hard disk regular MBR. So for example, type
Code:

sudo fdisk -l

and try to see how is your USB key named. For example, mine is /dev/sdc
- In case we got wrong (2 precautions), we are going to save the MBR we will overwrite, so that we should be able to put it back if there was a problem. So type:
Code:

sudo ./grubinst --save-mbr=USB.mbr /dev/sdX

(replace X by the proper letter of your USB)
- Now the MBR of you key has been saved next to grusint program.
- We can now write Grub4DOS MBR to the key (always replace X by relevant letter):

Code:

sudo ./grubinst /dev/sdX

Install a bootloader on a USB stick

To install wubi loader:
- Copy wubildr to the root of your key, and rename it grldr
- Make a ubuntu directory to the root of your key
- From your harddrive, copy /ubuntu/winboot to the /ubuntu on the key, so that you usb key will have the directory /ubuntu/winboot.
done.

To install regular grub4dos:

1. download latest grub4dos here: http://download.gna.org/grub4dos/ and extract grldr and menu.lst to your usb flashdrive top directory.
2. edit menu.1st as you wish.
   

Helpful links:
1. http://it.dennyhalim.com/2009/02/install-grub4dos-make-usb-bootable-from.html
2. http://ubuntuforums.org/showpost.php?p=5966083&postcount=7

Enable Windows Vista Hibernation

run "cmd" as administrator, and run the following command:

powercfg /hibernate on

Merge PDF file, FREE and EASY, NO acrobat needed

1. Downloand pdftk at http://www.accesspdf.com/pdftk/, unzip it and put the pdftk.exe to c:\windows\system32
   
2. Open cmd window by go to "Start -> Run, type cmd"
3. On Vista and Windows 7, do "cd %APPDATA%\Microsoft\Windows\SendTo", On Windows XP, do "cd c:\documents and settings\YOUR_UESER_ID\sendto"
4. use notepad to create a text file named MERGE-PDF.bat with the following one line in the file: pdftk %1 %2 %3 %4 %5 %6 %7 %8 %9 cat output pdftk-output.pdf
   
5. done.

Now to merge two or multiple pdf files, simply select them in Windows File Exploerer, and right click, then "send to -> MERGE-PDF.bat", the new merged file will be called "pdftk-output.pdf" in your folder.

Now where is my beer?

Parse HTML

Use this link to parse your code so that it can be pasted on blogger.

http://www.blogcrowds.com/resources/parse_html.php

Mini2440 download program on Linux

To download image to the mini2440 bootloader, the manual requires to install a Windows USB Driver, and a DNW2.exe program. I did not want to install some unknown EXE program on my computer. Fortunately, core_rui wrote a simple Linux program to do the whole trick. No driver needed. I simply LOVE the simplicity of this. You can run this program in a Vmware virtual machine (with USB 2.0 emulation enabled). Note this program uses libusb. So to compile it you need to install libusb-dev on your computer.

/* dnw2 linux main file. This depends on libusb.
*
* Author: Fox <hulifox008@163.com>
* License: GPL
*
*/



#include <stdio.h>
#include <usb.h>
#include <errno.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

#define QQ2440_SECBULK_IDVENDOR 0x5345
#define QQ2440_SECBULK_IDPRODUCT 0x1234


struct usb_dev_handle * open_port()
{
struct usb_bus *busses, *bus;

usb_init();
usb_find_busses();
usb_find_devices();

busses = usb_get_busses();
for(bus=busses;bus;bus=bus->next)
{
struct usb_device *dev;
for(dev=bus->devices;dev;dev=dev->next)
{
if( QQ2440_SECBULK_IDVENDOR==dev->descriptor.idVendor
&& QQ2440_SECBULK_IDPRODUCT==dev->descriptor.idProduct)
{
printf("Target usb device found!n");
struct usb_dev_handle *hdev = usb_open(dev);
if(!hdev)
{
perror("Cannot open device");
}
else
{
if(0!=usb_claim_interface(hdev, 0))
{
perror("Cannot claim interface");
usb_close(hdev);
hdev = NULL;
}
}
return hdev;
}
}
}

printf("Target usb device not found!n");

return NULL;
}

void usage()
{
printf("Usage: dnw2 <file>nn");
}

unsigned char* prepare_write_buf(char *filename, unsigned int *len)
{
unsigned char *write_buf = NULL;
struct stat fs;

int fd = open(filename, O_RDONLY);
if(-1==fd)
{
perror("Cannot open file");
return NULL;
}
if(-1==fstat(fd, &fs))
{
perror("Cannot get file size");
goto error;
}
write_buf = (unsigned char*)malloc(fs.st_size+10);
if(NULL==write_buf)
{
perror("malloc failed");
goto error;
}

if(fs.st_size != read(fd, write_buf+8, fs.st_size))
{
perror("Reading file failed");
goto error;
}

printf("Filename : %sn", filename);
printf("Filesize : %d bytesn", fs.st_size);

*((u_int32_t*)write_buf) = 0x30000000; //download address
*((u_int32_t*)write_buf+1) = fs.st_size + 10; //download size;

*len = fs.st_size + 10;
return write_buf;

error:
if(fd!=-1) close(fd);
if(NULL!=write_buf) free(write_buf);
fs.st_size = 0;
return NULL;

}

int main(int argc, char *argv[])
{
if(2!=argc)
{
usage();
return 1;
}

struct usb_dev_handle *hdev = open_port();
if(!hdev)
{
return 1;
}

unsigned int len = 0;
unsigned char* write_buf = prepare_write_buf(argv[1], &len);
if(NULL==write_buf) return 1;

unsigned int remain = len;
unsigned int towrite;
printf("Writing data ...n");
while(remain)
{
towrite = remain>512 ? 512 : remain;
if(towrite != usb_bulk_write(hdev, 0x03, write_buf+(len-remain), towrite, 3000))
{
perror("usb_bulk_write failed");
break;
}
remain-=towrite;
printf("r%d%t %d bytes ", (len-remain)*100/len, len-remain);
fflush(stdout);
}
if(0==remain) printf("Done!n");
return 0;
}

To compile: gcc dnw2.c -o dnw2 -lusb

Troubleshooting: X connection to localhost:10.0 broken (explicit kill or server shutdown).

If you remote connect to UNIX from Windows, then it's likely you will bump into this error message at least once in your lifetime:

X connection to localhost:10.0 broken (explicit kill or server shutdown).

This error messages occurs when you try to execute an X Window graphics user interface software, but you haven't started the X Windows display software on your Windows machine.

The X Window display server that I prefer to use on Windows is Xming 6.9.0.31. It's available on SourceForge and it's low-maintenance. If you haven't gotten a X Window display server software, you might give it a try. After starting Xming, you should not have this problem again.

However, if this problem does occur when you have Xming running, it's probably because you did not enable X11 forwarding in PuTTY, or your ssh software.

Chieh Cheng
Sun, 07 Jun 2009 18:35:41 +0000

Checklist for using Xming through a tunneled Putty session.

Putty:
* In the Connection->SSH->X11 panel, set the Enable X11 forwarding checkbox.
* (optional) In the same panel, enter "localhost:0" as the X display location. This redirects forwarded X traffic to display number 0. Match the Xming Display number, set below.
* Generally, MIT-Magic-Cookie-1 (set by default) is the most common authentication protocol. This will be added/updated in your .Xauthority file after a successful login for each display (one per Putty session).

Xming:
* In the Select display settings panel, set the Display number to 0. The IP port number used is 6000 + this number, so anything other than 0 will affect the display number used by X clients.
* In the same panel, if you want to connect directly from the remote client to the Xming server (not through Putty's X Forwarding), you should probably check the No Access Control box or your connection will be refused.

Remote system:
* Verify your SSH configuration allows X11 forwarding. In OpenSSH, the .ssh/config file should contain the entry "ForwardX11 yes".
* Your DISPLAY environment variable will be set automatically by Putty upon successful login. This will be "localhost:10.0" for the first session when the remote system's SSH daemon X11DisplayOffset is set to 10 (default). This display number will correspond to a TCP port that is listening on 6000 + display number, e.g. 6010. Use the command "netstat -an | grep -i listen" to see the ports on a Unix/Linux/Solaris box.
* If you "su" or "sudo" to a different user after login, you must merge the .Xauthority entry for the display associated with your session into the .Xauthority file of the new user. The DISPLAY environment variable should be set and exported the same as for the login user, for convenience. Otherwise, the X applications you lanuch with the new user will not have the authority to connect to your X server.

Windows:

* For the "localhost" part of the X display location to be converted to the correct IP address, your hosts file (%SYSTEMROOT%\System32\drivers\etc\hosts) must contain the entry "127.0.0.1 localhost".

* IMPORTANT: If you are using Windows Vista, the hosts file does not contain this entry by default. Instead, there is a "::1 localhost", which is for IPv6 instead of IPv4. Comment out/delete that entry and add the entry " 127.0.0.1 localhost". This causes the "X connection to localhost:10.0 broken (explicit kill or server shutdown)" error to appear when you try to launch an X client application.

* If you use a firewall, make sure that Putty SSH is allowed through it. If you can't establish a login session with Putty, X applications aren't going to work, either.

Ad hoc cell splitting re-post (original website down)

Information about cell-id splitting, stuck beacons, and failed IBSS merges!

From VillageTelco

Jump to: navigation, search

Contents 1 The trouble with Madwifi and IBSS (ad-hoc) mode 2 The emission of beacons in IBSS mode 3 The process of an "IBSS merge" 4 The phenomenon of IBSS-ID cell splits 4.1 Problem solved! 5 'Real' Ad-Hoc (IBSS) mode versus Ah-Demo (Pseudo-IBSS) mode 5.1 Example how to set up Madwifi VAPs 5.2 Recommended tools for 802.11 MAC analysis

The trouble with Madwifi and IBSS (ad-hoc) mode

While testing the Atheros Madwifi driver on the Ubiquity Nanostation2 in the Freifunk mesh network I ran into the problem that from time to time the card stopped working for approximately 30 seconds. I performed VOIP-calls with David Rowe using the Nanostation via the Freifunk network, but those irregular intermissions are annoying and would be a real show-stopper for the Villagetelco project. (If you depend on a chain of forwarding nodes to your gateway and they all stop working randomly for one minute within 15 minutes, there is always one that interrupts your call!)

It is the notorious Madwifi "stuck beacon" problem that causes intermittent operation in IBSS mode, caused by MAC timer skews when cards try to perform an "IBSS merge". If a MAC timer shift occurs because of an attempted IBSS merge it could happen that a beacon in the transmit queue gets stuck - the transmission gets never triggered. Until the transmit queue gets purged the card ceases to transmit forever. One way to purge the transmit buffer is to perform manually a

 iwlist ath0 scan 

Note that this helps only for a while until the next beacon gets stuck in the transmit buffer!

The emission of beacons in IBSS mode

Every ~100 ms (default settings) someone in the ad-hoc cell has to send a beacon to reveal the presence of the ad-hoc cell to other WiFi devices. There is a mechanism to avoid that multiple beacons get send redundantly by multiple nodes which are part of the same ad-hoc cell. After the last beacon has been send WiFI cards calculate a time that is 100ms ± random jitter in the future and wait whether another ad-hoc node sends a beacon before their own timer reaches this value. If another node sends the beacon before their own emission is triggered they discard the beacon. Otherwise they send the beacon.

The "stuck beacon" occurs when a shift of the MAC clock in the card occurs due to the process of an attempted "IBSS merge". In order to separate different wireless cells on MAC level they identify themselves by transmitting a IBSS-ID (I simply call them Cell-ID). In accesspoint mode the Cell-ID is identical with the MAC address of the accesspoints WiFI card. In ad-hoc mode there is no master node. Hence the developers of 802.11 thought there must be a process to negotiate and merge the IBSS-ID between nodes.

The process of an "IBSS merge"

If you configure your WiFi card to operate in ad-hoc mode on channel 1 with the ESSID "village-telco-adhoc-mesh" and activate the interface, your card will listen on the channel to see if beacons are transmitted for that ESSID. In case there are no beacons your card generates a random Cell-ID and starts to send beacons containing timestamps according to its own MAC timer and the Cell-ID. Now someone else does exactly the same with another WiFi card, while being not in range of the transmissions. The card is configured to use the same ESSID and channel in ad-hoc mode. Because the card doesn't receive any beacons for the ESSID after start up it also generates a new random Cell-ID and starts to send beacons.

Imagine that both cards are used in mobile devices that move around. At one point both cards receive each others beacons. Since both cards use the same ESSID they should be in the same wireless cell. However their Cell-IDs are different so they belong to different wireless networks until they agree to merge to one Cell-ID and drop the other. In order to decide to which Cell-ID they have to merge, the cards compare their time stamps. The older time stamp wins. So the card with the younger time stamp switches to the other Cell-ID and adjusts its MAC timer to the time stamp which it has received in the beacon. Beacons issued by this card from now on will contain the older time stamp.

This way multiple wireless cells consisting of multiple ad-hoc nodes configured with the same channel and ESSID can merge to one big wireless cell. In Berlin the Freifunk community mesh network is a single wireless ad-hoc cell operating on channel 10 with the ESSID "olsr.freifunk.net". This single ad-hoc cell is nearly as big on roof level as the city of Berlin and it consists of ~550 wireless interfaces on average - mostly routers, but also laptops and PCs.

The phenomenon of IBSS-ID cell splits

The ad-hoc mode has been widely neglected by chipset manufacturers and driver developers. Implementing ad-hoc mode is much more complicated than implementing station mode (accesspoint client). As a matter of fact if WiFi would have started only with ad-hoc mode as basic mode of operation we wouldn't miss anything. Ad-hoc mode means the capability that everyone in range can talk to everyone (multipoint to multipoint) while access point mode means everyone can only talk to the access point - only the accesspoint can talk to everone (point to multipoint). Who needs a communication mode where all can only talk to one and via one, while there is a mode available where everyone can talk to everyone? The simple functionality of an Accesspoint (DHCP, DNS relay) can also be performed by an ad-hoc station. There is only one reason why you shouldn't run an accesspoint in ad-hoc mode: Most devices that you want to connect to it have a buggy implementation of the ad-hoc mode, they simply don't work at all or are unreliable. What is worse: Even if most nodes in your network are operating properly according to the specs of 802.11, it takes a single buggy device to mess up your network!

A buggy device can do all kind of nasty things like:

• Send wrong time stamps after merging to the Cell-ID..
• Not merging at all.
• Send the right time stamp but with the wrong Cell-ID.

The result of false timestamps are IBSS-ID cell-splits, WiFi card lock-ups, intermittent operation. That is the situation when beacons with different timestamps and the same Cell-ID are in the air, which results in timestamps that are jumping forth and back. Or you have different Cell-IDs that carry the same time stamp. Or the time stamp tells your card that the Cell is now running since 500000 years - so there is an overflow in the counter and the MAC timer starts from zero.

At Freifunk we have learned that in such a environment you have to use some tricks to get around - otherwise your wireless card (or the whole operating system) will crash, you have multiple little ad-hoc cells that don't talk to each other instead of a single one.

I have compiled a recent version of the iwl3945 driver for a Intel 802.11abg with verbose debugging options enabled. This is what dmesg tells me when I try to connect to the Freifunk mesh:

[ 1655.102233] RX beacon SA=00:0b:6b:20:22:fe BSSID=02:ca:ff:ee:ba:be TSF=0x0 BCN=0xffff95d81ca98181 diff=116719550365311 @338775
[ 1655.102241] eth1: beacon TSF higher than local TSF - IBSS merge with BSSID 02:ca:ff:ee:ba:be
[ 1655.102249] phy1: Removed STA 00:0b:6b:20:22:fe
[ 1655.102254] phy1: Removed STA 00:80:48:52:ff:9e
[ 1655.102260] phy1: Removed STA 00:14:bf:3d:4d:12
[ 1655.103464] phy1: Adding new IBSS station 00:80:48:52:ff:9e (dev=eth1)
[ 1655.103468] phy1: Allocated STA 00:80:48:52:ff:9e
[ 1655.103472] phy1: Inserted STA 00:80:48:52:ff:9e
[ 1655.104592] phy1: Adding new IBSS station 00:14:bf:3d:4d:12 (dev=eth1)
[ 1655.104604] phy1: Allocated STA 00:14:bf:3d:4d:12
[ 1655.104610] phy1: Inserted STA 00:14:bf:3d:4d:12
[ 1655.105331] phy1: HW CONFIG: freq=2457
[ 1655.105821] phy1: Adding new IBSS station 00:0b:6b:20:22:fe (dev=eth1)
[ 1655.105826] phy1: Allocated STA 00:0b:6b:20:22:fe
[ 1655.105829] phy1: Inserted STA 00:0b:6b:20:22:fe
[ 1655.105847] RX beacon SA=00:80:48:52:ff:9e BSSID=02:ca:ff:ee:ba:be TSF=0x0 BCN=0xffff95d81ca981ed diff=116719550365203 @338776
[ 1655.105852] eth1: beacon TSF higher than local TSF - IBSS merge with BSSID 02:ca:ff:ee:ba:be
[ 1655.105856] phy1: Removed STA 00:0b:6b:20:22:fe
[ 1655.105859] phy1: Removed STA 00:14:bf:3d:4d:12
[ 1655.105861] phy1: Removed STA 00:80:48:52:ff:9e
[ 1655.106818] phy1: HW CONFIG: freq=2457
[ 1655.107303] phy1: Adding new IBSS station 00:80:48:52:ff:9e (dev=eth1)
[ 1655.107308] phy1: Allocated STA 00:80:48:52:ff:9e
[ 1655.107312] phy1: Inserted STA 00:80:48:52:ff:9e
[ 1655.107326] RX beacon SA=00:14:bf:3d:4d:12 BSSID=02:ca:ff:ee:ba:be TSF=0x0 BCN=0xffff95d81ca9d368 diff=116719550344344 @338776
[ 1655.107330] eth1: beacon TSF higher than local TSF - IBSS merge with BSSID 02:ca:ff:ee:ba:be
[ 1655.107334] phy1: Removed STA 00:80:48:52:ff:9e
[ 1655.108068] phy1: Destroyed STA 00:0b:6b:20:22:fe
[ 1655.108293] phy1: HW CONFIG: freq=2457
[ 1655.108772] phy1: Adding new IBSS station 00:14:bf:3d:4d:12 (dev=eth1)
[ 1655.108778] phy1: Allocated STA 00:14:bf:3d:4d:12
[ 1655.108782] phy1: Inserted STA 00:14:bf:3d:4d:12
[ 1655.118298] phy1: Destroyed STA 00:80:48:52:ff:9e
[ 1655.120046] phy1: Destroyed STA 00:14:bf:3d:4d:12
[ 1655.121053] phy1: Destroyed STA 00:0b:6b:20:22:fe
[ 1655.122713] phy1: Destroyed STA 00:14:bf:3d:4d:12
[ 1655.124048] phy1: Destroyed STA 00:80:48:52:ff:9e
[ 1655.124865] phy1: Destroyed STA 00:80:48:52:ff:9e
[ 1655.156680] phy1: Adding new IBSS station 00:80:48:52:ff:9e (dev=eth1)
[ 1655.156693] phy1: Allocated STA 00:80:48:52:ff:9e
[ 1655.156699] phy1: Inserted STA 00:80:48:52:ff:9e
[ 1655.205880] RX beacon SA=00:80:48:52:ff:9e BSSID=02:ca:ff:ee:ba:be TSF=0x0 BCN=0xffff95d81cab11ef diff=116719550262801 @338801
[ 1655.205893] eth1: beacon TSF higher than local TSF - IBSS merge with BSSID 02:ca:ff:ee:ba:be
[ 1655.205901] phy1: Removed STA 00:80:48:52:ff:9e
[ 1655.205906] phy1: Removed STA 00:14:bf:3d:4d:12
[ 1655.207037] phy1: Destroyed STA 00:80:48:52:ff:9e
[ 1655.207316] phy1: Adding new IBSS station 00:14:bf:3d:4d:12 (dev=eth1)
[ 1655.207324] phy1: Allocated STA 00:14:bf:3d:4d:12
[ 1655.207330] phy1: Inserted STA 00:14:bf:3d:4d:12
[ 1655.207965] phy1: HW CONFIG: freq=2457
[ 1655.208477] phy1: Adding new IBSS station 00:80:48:52:ff:9e (dev=eth1)
[ 1655.208482] phy1: Allocated STA 00:80:48:52:ff:9e
[ 1655.208485] phy1: Inserted STA 00:80:48:52:ff:9e
[ 1655.208504] RX beacon SA=00:14:bf:3d:4d:12 BSSID=02:ca:ff:ee:ba:be TSF=0x0 BCN=0xffff95d81cab64ba diff=116719550241606 @338802
[ 1655.208509] eth1: beacon TSF higher than local TSF - IBSS merge with BSSID 02:ca:ff:ee:ba:be

As you can see the card is merging, disassociating and merging five times within 0,106 seconds with a wireless ad-hoc cell it has already merged to long ago. Every time it gets another false timestamp it assumes that it is merging to a new IBSS-ID. The driver is purging it's MAC table from known stations, waiting to populate it again. No wonder I don't get more than 2-3 ICMP messages through.

The first trick is a non-standard hack: We fix the Cell-ID, rather than letting the cards negotiate one. We have modified the Madwifi driver and tricked the Broadcom driver to ignore any attempt to change the Cell-ID. "My Cell-ID is 02:CA:FF:EE:BA:BE - period." You can set the Cell-ID with the command:

 iwconfig ath0 ap 02:CA:FF:EE:BA:BE (or whatever you like best as a Cell-ID that is easy to remember) 

But still currently the Atheros cards try to synchronize their MAC timers, which results in race conditions of the software and the stuck beacon problem. There is now a workaround which will be added to Madwifi in OpenWRT and the Villagetelco firmware. With a trick we will make the cards ignore all attempts to shift the MAC timer - we just tell the hardware of the WiFi card that we are in accesspoint mode, which stops the card from trying to synchronize the MAC timer. Actually we don't need to synchronize the MAC timers in the hardware at all - this is better done in software, in the driver running on the host CPU of your PC.

Problem solved!

The problems with stuck beacons and race conditions triggered by MAC timer skews/attempted IBSS merges are fixed now in the Openwrt Kamikaze development trunk, in Kamikaze 8.09_RC1 and our Villagetelco development repository. Both IBSS mode and Pseudo-IBSS mode (a.k.a. Ad-hoc demo mode or Ahdemo mode, for short) are working fine now. I was running the DIR-300 for several days in the Freifunk mesh cloud without any issues.

The trick is to load the binary HAL for accesspoint mode upon initialization of the WiFi interface, rather than the HAL for IBSS mode. In accesspoint mode the card does not try to synchronize its MAC clock with any other wireless device in the cell - hence this functionality is missing in the HAL. In IBSS mode ('real' ad-hoc mode) this is done in software on the host system now, if you create the IBSS VAP (Virtual Access-Point) with the option nosbeacon:

 wlanconfig ath0 create wlandev wifi0 wlanmode adhoc nosbeacon 

Erroneous TSF timestamps received with beacons don't cause race conditions anymore. Pseudo-IBSS mode doesn't depend on sending beacons anyway, however there have been issues with this mode before.

Both modes have been tested in the Freifunk mesh cloud in Berlin without any stability problems for 72 hours each.

There is one problem however with TSF timestamps generated on the host CPU: The software generated timestamps are not as precise as the timestamps from the cards MAC clock, and they never will be. The communication between the Madwifi driver in the Linux kernel and the WiFi card is not real-time, and so there will be always lags that vary. It has been observed that this little TSF deviants confused devices with Broadcom chipsets, such as the Linksys WRT54GL: They were still working but they stopped sending beacons.

Apart from that Atheros devices with Madwifi operating in Ahdemo mode and Broadcom based devices with their closed-source driver operating in 'real' IBSS mode, work together nicely in the ~500 node community mesh that we use here in Berlin.

Personal comment: I have replaced the WiFi card in my Asus EEE PC 901 with a Atheros 802.11abg card and use it in the mesh about 15 hours every day - and I'm completely happy with it. I'm using the Madwifi driver sources from our Villagetelco repository on my PC.

'Real' Ad-Hoc (IBSS) mode versus Ah-Demo (Pseudo-IBSS) mode

As has been explained earlier on this page the 'Real' Ad-Hoc (IBSS) mode is complex and not usable in a large scale mesh ad-hoc cell. However there has always been the non-standard Ahdemo mode, which is not widely known. Ahdemo mode was (and maybe still is) popular amongst people setting up wireless long shots. The first world records of wireless long shots were achieved with Lucent/Orinoco 801.11b PCMCIA cards.

Ahdemo mode is supported only by a few chipsets and drivers, namely old Lucent Orinoco, Intersil Prism chipsets generation 2, 2.5, 3 (all 802.11b only) and Madwifi. However it is not guaranteed that the forementioned chipsets and their respective drivers will interoperate with each other in Ahdemo mode.

In Ahdemo mode cards don't send any beacons, and hence there is no process of IBSS merges. A Ahdemo cell doesn't reveal its presence to other wireless networks - because this detection works by receiving beacons. Usually the Cell-ID of Ahdemo cells is 00:00:00:00:00:00 but the Madwifi driver can utilize a fixed Cell-ID, that can be configured with the iwconfig option to fix the Cell-ID which has already been shown earlier on this page:

 iwconfig ath0 ap 02:CA:FF:EE:BA:BE 

Atheros cards with Madwifi driver operating in Ahdemo mode and Atheros cards with Madwifi driver operating in real Adhoc mode have no problems communicating with each other, as long as all cards use the same fixed Cell-ID.

In competition with another wireless network operating/colliding on the same channel the Madwifi Ahdemo mode is losing more throughput than Madwifi Ad-Hoc mode. If a Madwifi Ahdemo cell doesn't compete for the same channel with another network the Ahdemo performance is slightly better than in Adhoc mode. The reason is that Adhoc beacons are send at basic (slowest) rate and hence consume airtime which is reducing the channel capacity.

There is another advantage of Ahdemo: It is possible to configure a Madwifi interface to operate as accesspoint VAP and ahdemo VAP at the same time. The RO.B.I.N. and Nightwing firmware for Atheros AP51 based devices are using this capability. They use the Ahdemo VAP to create the mesh as a backbone and the accesspoint to give client access. This is a interesting concept but not in the scope of the Villagetelco project - since we are using the mesh only for telephony.

Example how to set up Madwifi VAPs

Here a brief instruction how to set up three VAPs (1 Ahdemo, 1 Master, 1 Monitor). A monitor VAP is mandatory to do advanced 802.11 traffic analysis.

wlanconfig ath0 destroy (if you already had a VAP instance running)
wlanconfig ath0 create wlandev wifi0 wlanmode ahdemo
wlanconfig ath1 create wlandev wifi0 wlanmode sta
wlanconfig ath2 create wlandev wifi0 wlanmode monitor

Recommended tools for 802.11 MAC analysis

You can use the monitor VAP to receive raw 802.11 packets, which will include 802.11 MAC, Radiotap or Prism headers for advanced 802.11 analysis. The Rolls-Royce of traffic monitoring software is Wireshark. The Porsche for mesh analysis is Horst [1]. Horst was designed to debug MAC problems of WiFi mesh networks. Also Kismet [2] should be mentioned at this point, of course.

Stay tuned!

Cheers elektra