Fonera and its MTU (and the non-working wireless connection)
February 6th, 2007
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 holidays), but he had some issues: the wireless connection wasn’t working as expected: most of the time the signal was lost and I can’t understand 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 problem was the WPA, so I changed the authentication 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 “hackable” with exploits published by several sources. But as you connect the Fonera to internet, it automatically downloads the new 0.7.1-2 firmware that apply a patch to the web interfaces so you can’t use that exploits anymore. Why do I wanted to exploit it? Well, my intentions wasn’t to exploit it to get the Fonera unlocked, I just needed a ssh connection because I wanted to understand why the wireless signal was lost.
When you exploited it (I won’t tell you how to do, google is full of this information) and finally you had access to a ssh connection, you’ll get something 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 password for ssh is “admin”. Well, we have access into the router, so where should we begin to look at? Obviously, let see what dmesg says. You’ll soon notice that the log is literally 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 anything strange? Sure? Did you look at the MTU value in ath1? Yes, it’s 2290. And it’s so damn high. For an ethernet connection such value should be between 1000 and 2000 but usually for wireless connection it is set to 1492. Well change it to 1492 with:
root@OpenWrt:~# ifconfig ath1 mtu 1492
And you’ll get everything working. Obviously, you should disable the automatic firmware update, otherwise as soon as the Fonera updates its firmware you’ll get your wireless connection not working again. This is done by commenting the last line in /bin/thinclient (there’s written “. /tmp/.thinclient.sh”, just put a # in front of it). And now you can use the Fonera.
I’ve got the same problem, and I’ve noticed something interesting: My Fonera sits on a window board, very close to the radiator. Now when I turn the heat of the radiator on, this causes the “stuck beacon” messages to appear - when I move the Fonera away from the radiator (about 20 cm are enough), it stops altogether. This can be reproduced.
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 maximum allowed TU. If your packet size exceeds 1500, your packets can (and will) get dropped by certain hosts in the internet.
The interface ath1, however, is the private WLAN interface. No internet hosts involved (actually, no other hosts involved at all for the beacon stuff), so this should not be a problem.
Beacons are really small packets anyway, so I wonder if or why they should be influenced by the MTU.
Don’t get me wrong here - I did some googling for “stuck beacons”, and the causes seem to be quite complex and not well understood. I’m just pretty sure that in *my* case, heat was the problem.
Comment by Martin — March 24th, 2007 at 16:55