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

kratorius — Tue, 06 Feb 2007 11:14:34 +0000

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.

Give me more penguins

kratorius — Mon, 04 Dec 2006 13:15:46 +0000

Yesterday I were bored. So I took the linux sources and I began thinking at some interesting modify I could make.

So, ehm, well… I did something unusual. I’m proud to present the really-very-most-useless-patch-of-the-year:

Add a boot option “logonum” that allow the user to choose how many penguins to show in the framebuffer at startup. If no “logonum” is specified, it shows as many penguins as the online cpus (the default behavior).

Signed-off-by: Giuliani Vito, Ivan

The patch can be found here: http://lugbari.org/~kratorius/patches/give-me-more-penguins-2.6.19.patch
This patch applies to 2.6.19 vanilla sources.

Compile your kernel with this patch and modify your grub’s menu.lst file in this way, from something like this: kernel /boot/vmlinuz-2.6.19 root=/dev/hda6 ro vga=0x318 to to something like this: kernel /boot/vmlinuz-2.6.19 root=/dev/hda6 ro vga=0x318 logonum=5 to show 5 penguins. If you don’t tell to grub how many penguins to show, it will use the default behavior (it will show as many penguins as your online cpus).

Zeta-Puppis.com » Kernel

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

Give me more penguins