Fonera and its MTU (and the non-working wireless connection)

A friend of mine recently bought the La Fonera (no, not really… he just had it as gift since the fon’s guys were givin’ it for free during the hol­i­days), but he had some issues: the wire­less con­nec­tion wasn’t work­ing as expected: most of the time the signal was lost and I can’t under­stand why since the signal’s power was strong enough. So I said to myself “that’s time to work on”. And now here I am :)


Let say that I first thought that the prob­lem was the WPA, so I changed the authen­ti­ca­tion to WEP but the result didn’t changed.

First of all: this Fonera comes with the 0.7.1-1 (or 0.7.1 r1, as you want to call it, it’s the same) firmware, so it’s “hack­able” with exploits pub­lished by sev­eral sources. But as you con­nect the Fonera to inter­net, it auto­mat­i­cally down­loads the new 0.7.1-2 firmware that apply a patch to the web inter­faces so you can’t use that exploits any­more. Why do I wanted to exploit it? Well, my inten­tions wasn’t to exploit it to get the Fonera unlocked, I just needed a ssh con­nec­tion because I wanted to under­stand why the wire­less signal was lost.

When you exploited it (I won’t tell you how to do, google is full of this infor­ma­tion) and finally you had access to a ssh con­nec­tion, you’ll get some­thing like this:

kratorius@becks:~$ ssh root@169.254.255.1
root@169.254.255.1's password:

BusyBox v1.1.3 (2006.11.21-19:49+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
_______  _______  _______
|   ____||       ||   _   |
|   ____||   -   ||  | |  |
|   |    |_______||__| |__|
|___|
Fonera Firmware (Version 0.7.1 rev 1) -------------
*
* Based on OpenWrt - http://openwrt.org
* Powered by FON - http://www.fon.com
---------------------------------------------------

root@OpenWrt:~#

The root’s pass­word for ssh is “admin”. Well, we have access into the router, so where should we begin to look at? Obvi­ously, let see what dmesg says. You’ll soon notice that the log is lit­er­ally full of this printk’statement:

wifi0: stuck beacon; resetting (bmiss count 4)

And let see the ifconfig’s output:

root@OpenWrt:~# ifconfig
ath1      Link encap:Ethernet  HWaddr 00:18:84:18:0A:72
inet addr:192.168.10.1  Bcast:192.168.10.255  Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST  MTU:2290  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 00:18:84:18:0A:70
UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
RX packets:743 errors:0 dropped:0 overruns:0 frame:0
TX packets:1415 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:63354 (61.8 KiB)  TX bytes:630340 (615.5 KiB)
Interrupt:4 Base address:0x1000

eth0:1    Link encap:Ethernet  HWaddr 00:18:84:18:0A:70
inet addr:169.254.255.1  Bcast:169.254.255.255  Mask:255.255.0.0
UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
Interrupt:4 Base address:0x1000
lo        Link encap:Local Loopback
inet addr:127.0.0.1  Mask:255.0.0.0
UP LOOPBACK RUNNING  MTU:16436  Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

wifi0     Link encap:Ethernet  HWaddr 00:18:84:18:0A:71
UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
RX packets:2119 errors:0 dropped:0 overruns:0 frame:128
TX packets:280 errors:116 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:199
RX bytes:124155 (121.2 KiB)  TX bytes:31857 (31.1 KiB)
Interrupt:3 Memory:b0000000-b00ffffc

Do you see any­thing strange? Sure? Did you look at the MTU value in ath1? Yes, it’s 2290. And it’s so damn high. For an eth­er­net con­nec­tion such value should be between 1000 and 2000 but usu­ally for wire­less con­nec­tion it is set to 1492. Well change it to 1492 with:

root@OpenWrt:~# ifconfig ath1 mtu 1492

And you’ll get every­thing work­ing. Obvi­ously, you should dis­able the auto­matic firmware update, oth­er­wise as soon as the Fonera updates its firmware you’ll get your wire­less con­nec­tion not work­ing again. This is done by com­ment­ing the last line in /bin/thinclient (there’s writ­ten “. /tmp/.thinclient.sh”, just put a # in front of it). And now you can use the Fonera.

  1. I’ve got the same prob­lem, and I’ve noticed some­thing inter­est­ing: My Fonera sits on a window board, very close to the radi­a­tor. Now when I turn the heat of the radi­a­tor on, this causes the “stuck beacon” mes­sages to appear - when I move the Fonera away from the radi­a­tor (about 20 cm are enough), it stops alto­gether. This can be repro­duced.

    As for the MTU: it’s true that an MTU should not be higher than 1492 when using PPPoE, because 1492 + 8 (length of PPPoE header) = 1500, which is the max­i­mum allowed TU. If your packet size exceeds 1500, your pack­ets can (and will) get dropped by cer­tain hosts in the inter­net.

    The inter­face ath1, how­ever, is the pri­vate WLAN inter­face. No inter­net hosts involved (actu­ally, no other hosts involved at all for the beacon stuff), so this should not be a prob­lem.

    Bea­cons are really small pack­ets anyway, so I wonder if or why they should be influ­enced by the MTU.

    Don’t get me wrong here - I did some googling for “stuck bea­cons”, and the causes seem to be quite com­plex and not well under­stood. I’m just pretty sure that in *my* case, heat was the prob­lem.

Leave a Comment


NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="" highlight="">