Archive for the 'WiP' Category

3G support progress

Thursday, March 14th, 2013

As soon as the Paco release was out last christmas, we’ve started working on the next firmware release. The focus of this release will be on improving the 3G experience, which is the topic of this post. I’ll detail a few of the things we’ve be working on, to give you an idea what’s coming up and to get an idea of all the different components that are involved in getting a 3G connection up and running.

Changing the connection manager daemon
The current firmware uses “umtsd.lua”, which is a simple connection manager written in lua. It was a first attempt at something back when the 2.0g and 2.0n were being released, and that shows. Its internals are a bit messy and it is hard to debug any 3G problems due to limited feedback.

To solve this, a new daemon was written, named “udiald” (originally it was called “umtsd2″). This daemon has been released by Fon under an open source license and its sources can be found on github. This new daemon is written in C, has a cleaner structure and makes it a lot easier to change device-specific configuration and get debug output. We expect we can support more 3G devices in the future because of udiald, though in the short run some devices might stop working when switching to udiald (because they just worked “by accident” in umtsd.lua and now need some specific tweaking applied, for example).

At some point, this udiald (or probably something based off it) might also be integrated into the main OpenWRT repository, to improve 3G support in general OpenWRT as well.

Rewriting the 3G webinterface
Managing the 3G connection is a bit of a challenge in the current firmware. When you plug in a device, it automatically connects and having two 3G dongles connected at the same time is asking for trouble. If you’re running into problems, most of the time you’ll only see that the Fonera is stuck “Dialing…”, but there is no indication of any error message.

We’ve revamped this webinterface now, making it easier to see what 3G dongle is connected and what its status is. We’re making automatically connecting on plugin optional (and disabling it by default), so you have more control over how your Fonera connects to the internet.

2.0n USB driver improvements
One of the long-standing issues with 3G devices on the Fonera 2.0n is that most of them would not properly operate when connected through an USB hub. Devices that work correctly when directly connected to the Fonera fail when connected through an USB hub, even when no other devices are connected.

We’ve been diving into this issue for the last month or so and slowly started to unravel the causes for this issue. When communicating with the Fonera, the 3G devices offer virtual “serial ports”, which can send and receive data. When the Fonera is receiving data from the 3G device, it often occurs that the device has no data to send. In this case, the 3G device will send a USB “NAK” message back to the Fonera to let it know there is no data. The (USB controller in the) Fonera can then knows there is no data yet and it should just keep trying until there is data. These NAK messags were the root cause of the problem, but the actual problem differed depending on the USB version of the 3G device:

  1. For USB 1.1 3G devices, which use so-called “split transactions” to translate from USB 2.0 to 1.1, every NAK message received caused the Fonera to receive an interrupt, process the NAK message and resubmit the original message for a retry. Apparently, these NAK messages would occur so often that the Fonera’s CPU would be busy only with processing these interrupts, leaving no time for any other useful work and eventually causing a reboot.

    We managed to fix this issue by only retrying these NAK’d messages once per USB frame (millisecond), a fix that was inspired by a similar fix found in the Raspberry Pi Linux version (which uses a very similar USB controller). This makes the USB 1.1 3G devices we tested work properly through an USB hub.

  2. For USB 2.0 3G devices, the USB hardware takes care of all these retries, so the interrupt overload issue does not occur. However, here we were running into a hardware limitation: The USB hardware uses “Host Channels” (HC) to communicate with USB devices. The Fonera 2.0n has four of these HCs available, and a host channel can be used to send a message to one specific USB “endpoint”, meaning we can send message to four different endpoints at the same time (but once a message is sent, a HC can be reconfigured to send a message to another endpoint if needed).

    Now, for each “periodic endpoint” (isochronous and interrupt), a dedicated HC is needed. These periodic endpoints need to have messages sent at regular intervals, and once the time for such a periodic message comes, it must be certain that a HC is availalbe, so the driver reserves one HC for each of these periodic endpoints. This allows up to three HCs for periodic transfers, leaving at least one HC available for non-periodic transfers.

    This is what happens when you connect a 3G device through an USB hub. The USB hub and the 3G device both have an interrupt endpoint, which takes up two of the four HCs. Now udiald connects to two of these “virtual serial ports”, one to transfer control messages and one to transfer data. Receiving data from these virtual serial ports takes up two more HCs. These latter two are expected to be used only shortly, but because the 3G device often does not have data to send for some time (a few to a few dozen seconds, typically), all of the host channels are taken up. Now, when udiald wants to send something to the device (either some network data or a control command), it needs one more HC (since input and output are different endpoints in the USB protocol). The outgoing data is queued, waiting for a host channel to become available, which doesn’t happen, so the connection times out before it even started.

    To fix this, we’re trying a workaround where these “blocking” HCs (which keep getting NAK replies from the device and keep getting retried by the hardware) are interrupted when the driver runs out of available host channels, so these host channels can be used for other transfers for a while and then resume retrying the blocking transfers. This is now working fairly well in our development environment, though there might be one or two corner cases left to tackle.

In summary: We’ve managed to improve this third-party USB driver in order to better support blocking transfers typically used by 3G devices. This helps to get the 3G devices we have here working, but of course it is no guarantee that all devices will start working with USB hubs: there might be other problems we simply did not observe yet. However, the problems we solved are fairly fundamental, so they will have affected most if not all 3G devices out there.

If you’re interested in the details about this USB driver problem, I can recommend the USB made simple and USB in a nutshell article series, which properly explain the terms and logic of the USB protocol.

Remaining USB limitations
Even though the above should make 3G devices work with USB hubs, it is expected that the performance is somewhat reduced by this approach, because of the way a channel must now be time-shared between multiple transfers.

Furthermore, this approach does not mean there is no limited number of host channels all of the sudden. Now, multiple (blocking) non-periodic transfers can succesfully share a single host channel, but there is still only room for three different periodic endpoints. Fortunately, USB storage devices typically do not use a periodic endpoint, so this limit should be sufficient in most cases (e.g., you can add one hub, a 3G stick and an USB sound card, each of which typically has one periodic endpoint and a number of USB disks or flash drives without problems).

Backporting parts of the serial drivers
When a 3G device is plugged in, its virtual serial ports are handled by an usb serial driver in the Linux kernel. This driver needs to know which devices it should handle (usually based on the usb “vidpid”, vendor id and product id, as advertised by the device) and for some devices, which workarounds or special quirks to apply. The driver most commonly used for 3G devices is called the “option” driver, which we’ve improved by taking the list of USB devices and some of the workarounds from a newer kernel version and backporting them to the Fonera kernel versions. This should allow more 3G devices to be supported by both Foneras, since now udiald can actually talk to these devices.

This change should remove the need to mess with the new_id files in /sys, which was sometimes needed to get a 3G device recognized by its driver.

Updating usb-modeswitch
usb-modeswitch is the software responsible for getting 3G devices into “modem mode”. A lot of 3G devices start out in “storage mode”, where they pretend to be a read-only CD drive or card reader, offering the Windows drivers for the device on a virtual disk. To get these devices to offer their virtual serial ports used for the 3G connection, they need to be sent a special message (which is normally done by Windows driver installed from the virtual disk) to switch them to modem mode.

By updating usb-modeswitch and the associated database of 3G devices and the messages they need to be sent to make them switch, more 3G devices can be supported that were previously not accessible to udiald.

Updating pppd
pppd is the daemon that is responsible for setting up the actual IP connection once all the dialing and configuration is complete. It handles negotiations about IP addresses and DNS servers, using standardized PPP (Point-to-Point Protocol). Even though PPP is an old and standardized protocol, we were still running into some problems with 3G devices that would confuse pppd with particular (IIRC not entirely standards-compliant) negotiation sequences, causing the connection to fail. Newer pppd version turn out to handle these devices more gracefully, making this particular problem (and possibly others) go away.

All of the work above is ongoing in our development trees. We’ll start pushing out these changes into the fon-ng Subversion repository over the coming weeks and once we’re satisfied that this produces a firmware image suitable for testing, we’ll be releasing the first 2.3.8.0 beta release. The goal of this release will be mostly to gather information about the support for different 3G devices: which devices work right away, which need some configuration tweaks, are there still more fundamental problems with devices?

New official plugin: Wake-on-LAN

Wednesday, December 5th, 2012

As of this week, the Fonosfera repository contains an brand new plugin: The Wake-on-LAN plugin, which can be used to remotely power on Wake-on-LAN capable machines on your local network, using the Fonera webinterface.

This plugin was inspired by a previous Wake-on-LAN plugin, created by one of our users and amended by a few others. Due to technical reasons (the user interface code did not use cbi), this plugin does not share any code with the original plugin, but it did inspire us to create this new plugin.

Wake-on-LAN interface

This is still a first version of this plugin, so we welcome people testing it and providing feedback. The plugin can be installed by downloading it from our firmware autobuilder and uploading it again through the Applications page of the Fonera webinterface. The plugin can be downloaded here:

Installing an application like this requires a DEV firmware. This plugin has been tested on 2.3.7.0 rc2, but I expect it will work on 2.3.6.x as well. After the 2.3.7.0 final release is out and this plugin is tested well enough, it will become available on the Applications page for a one-click install, just like the other official plugins.

Note that the plugin is still missing a proper icon, so it now has a temporary (ugly) icon instead.

Update 2013.03.13: Version 1.0.2 adds a proper icon and is now listed in the “Applications” page of the Fonera 2.0 dashboard and can be installed automatically by just clicking the “plus” icon. You’ll need at least firmware 2.3.7.0 for this, but it should work both in DEV and normal mode.

Setting up computers
To wake up a computer, it needs to support Wake-on-LAN (also known as “Magic Packet”) and have it enabled as well. Most modern computers support WOL, but it is often disabled by default. Often, a BIOS option named “Wake-on-LAN”, “Magic Packet”, or “PCI device wakeup” needs to be enabled, but usually you’ll also need to change some settings within your operating system. See this posting for some details on what to change. Rumour has it that Windows 7 needs some additional changes, see this posting for details.

Setting up the Fonera
After installing the application through the Applications page, you can access the WOL interface through the icon on the dashboard. To power on a computer, you’ll need to know its MAC address. You can add the MAC address to the top list, choose an arbitrary name so you can keep the various MAC addresses apart and click “Power On” to send the Magic Packet. If you already set up a static (DHCP) address assignment for the computer, you can directly click “Power on” in the bottom list (go to Settings -> Network to edit the bottom list).

If you test this plugin, let me know if it works for you, or if you have problems!

Update: I’ve updated the links above to point to version 1.0.1 of this plugin. This version should now also work on 2.0g and fixes a bug where your list of MAC addresses would be deleted when uninstalling the plugin or overwritten during plugin install. If you have the first version (1.0) installed and have a big list of MAC addresses that you want to preserve, you should make a backup of the /etc/config/luci_wol file manually before upgrading to this new version.

Elan the Elk is coming soon for Fonera 2.0g. Meanwhile, test 2.3.0.1 RC1

Tuesday, September 29th, 2009

Hi

After a looooooong time of silence (forced silence… we were working, not playing XD) We’re coming with great news for you. The 2.3.0.0 version of the firmware will be soon available for your foneras 2.0g!!

No, we haven’t forgot or let down our loyal fonera 2.0g users. We want to make them as happy as possible and we’re doing 2 things for them:
1) Improve the firmware as much as possible. This 2.3.0.0 has all the improvements we’ve developed during these months. The Fonera 2.0g will have as much as possible the same firmware as the Fonera 2.0n.
2) Give discounts for those who are willing to upgrade their 2.0g to 2.0n. We know you spent money on the 2.0g and now we have a new device that is more powerful (and also more expensive). This is not common in all companies, but hey, we try to make you happy, you help us with the feedback too, after all. So we have announced great discounts (we mean great, not small) for those who have bought a Fonera 2.0g and are willing to upgrade it! Please stay tuned to your mail!
New features:

  • The web interface over WAN has been moved to port 443 for security
  • Transmission has been integrated into the FON WebUI. You can still access it in the traditional way!
  • Added QoS support!! Make sure you set realistic up and download values of your line on the configuration. Otherwise it doesn’t work…
  • Twitter!!! Yes, your fonera will tell you when it has finished uploading videos or someone connects to your signal and much more! (Not available for Torrents yet, sorry)

So, what is the bugfix list for this RC1? Here it goes (hold to your chair):

  • Optional Manual DNS server on DHCP mode.
  • Pop up to prevent unwilling reset/rebooting on the systems menu.
  • ALL configurations are saved now from upgrade to upgrade (except for firewall, coming in the next!).
  • Sending files to the correct folder over samba triggers the upload to the corresponding service.
  • Samba works fine now on Windows XP.
  • NTFS is handled slightly better now. Actions won’t happen till the disk is properly mounted (source of many bugs).
  • More robust upload management.
  • Filenames starting with ‘.’ are ignored by the service uploades (picasa, flickr etc). Good for Macs ;)
  • Both \\fonera\Media and \\fonera\disc-a1 work now (better use the first)
  • Many, many, many, many more bug fixing. All boring and internal, but will improve the overall experience!

Please, test it and report back. We are only looking for compatibility bugs.

*IMPORTANT NOTE* This is a Release Candidate. It is not an stable firmware. Most of the things should work fine and it’s probably safe to install. But if you are not very skillful or feel not confident about it… please wait for the release or until you read enough feedback from other users. We are happy to help everybody with any problems they experience but sometimes are overloaded of work… ;)

*ANOTHER ONE* After upgrading, the torrent application might be broken. This is due to changes in the very interior of the fonera. The way to fix it is to remove the “FoneraApps” from the disc where it is installed and reinstall.
Enjoy!

Web upgrade image (do NOT uncompress):
Enduser
Developer

RedBoot / Ssh upgrade image:

Md5sum: 5d43a2ba405627975f09741e3d506681

http://download.fonosfera.org/RC/20090922_FON2202_2.3.0.1_RC1.image

Use your webcam as a security camera with Motion4fon

Monday, September 7th, 2009

OldMan released a pre-beta version of his plugin. He ported Motion software to the Fonera 2.0!

With the application installed and a webcam connected to your Fonera 2.0, you will be able to trigger events when motion is detected. A built in functionality is for example to save the images captured by the webcam when motion occurs. Needless to say with a bit of scripting the possibilities are endless.

Download the plugin Motion4fon_0.1beta.tar.gz
Draft version of the manual page on FON Wiki

Screenshot:

Motion4fon screenshot

Here it is! the long awaited RC3… Ehr… RC4!!!!

Wednesday, July 8th, 2009

Hello all!

after a veeeeeery long time, we’re happy to announce a new Release Candidate: 2.2.6.0 RC4! Yes, we know the 3 comes after the 2 and not the 4, but RC3 was an internal release :P

Why did it take us so long to make a new release? Phew… LOTS OF CHANGES!!! Really, L O T S. And we hope this is going to be all for the good.

This is not a stable release or better said, not an official release, just a Release Candidate, but we think it’s much more stable and usable than previous versions. We’re closer and closer to the perfect device! LOL

Ok, no more boring info, here’s the Changelog:

  • Upload service queuing: if you plug a disk with media to upload to different services (YouTube, Flickr, Picasa or Facebook) they will now be queued and uploaded serially and not in parallel (which caused the fonera to run out of memmory and crash).
  • Applications know when another upload is in progress: if you’re uploading videos to Youtube and there are queued pictures for Flickr, the Flickr page will tell you: “Waiting for YouTube to finish the upload”. How about that? ;)
  • Send files from samba and they will be uploaded to your applications. No need to unplug and replug the disk! More and more user friendly every time :P
  • Prorgess bars for uploaders: so you konw when it’s gonna be finished. It also helps show that the fonera is working on something ;)
  • Save configuration from flash to flash: no need to reconfigure all the settings again! Well, WPA password will be lost and the plugins you installed too… sorry. We’re working on it. But it’s already good progress, isn’t it? (this feature only works on web upgrade)
  • Save and restore configuration: what’s this? well, some users like to have backups of their configuration. Now you can download it from the fonera and upload it again if you want to restore safe values… It’s not very tested yet, test it and let us know if it works fine!
  • Better memmory management (processes stopped if unnecessary, less services running by default etc): ok ok, this is not a feature but an enhancement, but it’s important!
  • More image and video types supported. every application is aware of what it can upload. They even check filesizes depending on the service. If a picture is too big for Picasa it will tell you ;)
  • Videos are now supported on picasa and flickr too!
  • Classic youtube accounts should work now: those without the @gmail.com – it’s not valid to have a gmail.com like account and just ommit it in the user field! Please, someone test it…
  • Additional info on the dashboard: shows uptime, shows release candidate number…
  • Disable FONSpot: yes… you can now disable the FON service. Why, you wonder. Well, we want to build the biggest wireless community in the world, but well, everybody is free to do whatever they want with their fonera, they payed for it after all. So, you don’t want to share? don’t share… but you are evil! mwahahahaha!
  • And much more…

And let me finish with the most awaited the most critisized, the most conflictive, the most difficult bug we ever had… (NO IT IS NOT BRIDGING! LOL)… TORRENTS!!!

We removed the unworkable (thanks unworkable folks, it was a good try but didn’t fit our needs) and it’s been replaced with… TRANSMISSION! Transmission is the best torrent client out there and it’s opensource! It works really well and it’s been veeeery smooth to integrate in the fonera.

Thanks to pablo and john form FON and Charles from transmission and others, we have our first Transmission plugin for you guys to enjoy! It’s still the first version, we are already working on some improvements that will come in the future, but for now, it’s usable.

Don’t abuse… the Fonera 2.0 is still a limited device in memory and CPU. Please follow this recommendations:

  • We suggest to limit download speed to 150KB/s-200KB/s for stability and responssiveness of the interface. This is the values we set by default, we know it’s not very high, but it’s kind of stable.
  • Also, sometimes the interface seems to be freezed… it’s not common but sometimes it takes up to 30min to give a response, still it’s working in the background. If Transmission has proved something is that it’s very stable and very reliable, so just be patient. Really, be patient. Especially when starting or connecting while it’s been downloading for a long while.
  • Do not add many torrents. Transmission right now does not support queueing. All torrents you upload to it will be added for parallel download and this kills la fonera. Well, it doesn’t kill it, just makes it totally unresponssive. IMPORTANT: adding torrents and pausing them does ALSO freeze the fonera, Transmission uses these files in background for something.
  • Also, be aware that it does NOT work with NTFS so… windows users, use FAT32, linux users… you don’t need advice ;)
  • DO NOT use it with a pendrive. The fonera uses the pendrive as RAM memmory (swap) and pendrives are too slow for that plus they deteriorate faster.
  • DO NOT remove the disk before “shutting down torrent” from the fonera web UI. This is very important or you will have to uninstall and reinstall transmission. To extract a disk, you need to reboot (sotfware reboot) the fonera if you ran transmission first. This is a bug that will be fixed soon.

We are already trying to work with the Transmission guys to improve these problems, so stay tuned and ready for improvements in the future. Still, this is something already usable :P
I don’t want to extend on the incredible opportunities Transmission is bringing to the fonera (bandwidth control, seeding, access from other devices – Android, iPhone, Firefox plugins). You will get to know them by yourselves :)

I also want to thank the small betatesting team we’ve built. They are in great extent responsible of many of the improvements you see now and will see in the future. A big applause for them.
Ok, I think this has been the longes release candidate post I ever wrote so now I shut up.

Web upgrade: 20090708_FON2202_2.2.6.0_rc4.tar.gz

Web upgrade – developer mode: 20090708_FON2202_2.2.6.0_rc4_DEV.tar.gz
Console upgrade: 20090708_FON2202_2.2.6.0_rc4.image – md5sum f53f98adeeac9b9b5426d8a53cbd9db3

Here is the foneradownloader Firefox plugin!

Wednesday, June 3rd, 2009

Yesterday we announced it, today, we release it!

In order to use foneradownloader-0.0.9 you need firmware 2.2.6.0-rc2 or later.

What you can do with is:

  • click on a torrent and select to send it to the fonera 2.0 for download, instead of downloading it with the PC and then upload it to the fonera. Cool huh?
  • select a set of plain text links (direct links or RS and MU links) and right click on them -> “Download with the Fonera”. YAY!!!! And you can select even normal text, it’s a smart plugin that will strip out only the proper links!!
  • See the status of all your downloads in realtime on firefox, without needing to go to the fonera UI. You can see it all in a table like this (sorry about the Spanish):
Download status
In order to install it, you need to Drag & Drop the .xpi file into a firefox window, or directly install instead of downloading. This is not a Firefox approved plugin so you will need to tell Firefox to allow the installation. Works both with firefox 3.0 and 3.5beta
Download or install it here.

Long time no see, rc2 is here!

Tuesday, June 2nd, 2009

hello

we’ve been quite busy lately. We are working on lots of things right now and soon you will know about some of them. But today, here you have a new release candidate for you to test.

As always, give us your feedback, it is very much appreciated.

Most of the changes are cleanups for the not-so-well working applications like torrent and rapidshare. So you, heavy-downloader… test it and let us know if it improved at all.  But there is a very nice new feature… the firefox plugin!!!!
You can expect

  • a better handling of the RS and MU links: links are loaded without checking so it’s faster and are checked at download time so there’s no possible variation of temporary links. Summary: should work better and fail less :P
  • torrent cleaned up: the torrent application is handled slightly differently and the different status are managed somehow better. even though the downloads won’t be perfect, it seems like you can now download some big files from time to time :)
  • other cleanups…

OK, ok, you want to know about the firefox plugin. What does it do? well, it’s in beta state (lol) but the target is to detect whether you are connected to the fonera 2.0 and if so, it helps you send tasks to it. For instance, you can:

  • click on a torrent and select to send it to the fonera 2.0 for download, instead of downloading it with the PC and then upload it to the fonera. Cool huh?
  • select a set of plain text links (direct links or RS and MU links) and right click on them -> “Download with the Fonera”. YAY!!!! And you can select even normal text, it’s a smart plugin that will strip out only the proper links!!
  • See the status of all your downloads in realtime on firefox, without needing to go to the fonera UI. You can see it all in a table like this (sorry about the Spanish):
Download status

Thanks Javier for the very good work and Steven for supporting with the APIs!

How do you install it? Unfortunately you need to wait till tomorrow so we can fix a small last minute bug :P
Enjoy and thanks!

The Firmware Team

An update on the FonHome project

Friday, May 22nd, 2009

Just got an update from our friends of the FonHome project. They made quite a lot of progress and expect to release a beta version before the end of the summer. The driver of the X10 USB controller they are using still needs a few fixes. But guess what, they have a google code repository, so you can give a hand or provide your expertise if you’d like to.

Dashboard with FonHome's icon

FonHome's control panel

FonHome Testing panel

FonHome Fonera

Noticed that they are good graphic artists too? I especially like the FonHome branded Fonera 2.0!

New Release Candidate (2.2.6.0 RC1)

Friday, May 8th, 2009

Hi all,

We are very happy to release a new RC firmware: 2.2.6.0 RC1 (the firmware will show still 2.2.5.0). We want to make clear that it is NOT a final/official firmware but an image for testing. We release it and those who dare and don’t mind having to reflash or revert it if it’s not working properly can install it and give us feedback and congratulate us for the good job. Please, no complains, it’s not a release.

Having said that, I want to thank Decodecoding for the  very exhaustive and helpful testing, debugging and reporting he has done. Thanks to him we might have found a good alternative for the buggy torrent. Yes, we have replaced our old torrent application, ctorrent with a new one “unworkable” – nice name huh? – But that’s not all, here’s the list of the features we added.

  • We added nmbd: this will basically make the fonera discoverable on your network… Both Windows and MAC will see the Fonera as a network computer by browsing your network.
  • Support for mDNS: this helps MAC and Linux discover the services a Fonera is offering (FTP, Network Disc etc) we will add more services in the future, such as printer etc. With this, things are much more easy to configure in most systems.
  • Replaced torrent: now we use “unworkable”. The interface is not fully migrated, but it will be soon. Seems to work pretty well. You can chose 3 speeds… if the high speed gives you trouble, try lower ones.
  • UPnP support: yes… we added this after so long. For us it’s a security whole but some users want it… IMPORTANT: it’s enabled by default in this image and can’t be disabled from the Web GUI. Will add that feature in coming releases. For those who don’t know UPnP, it dinamically ‘opens’ the ports of the services you are using (namely torrent, gaming etc)
  • Uptime: the dashboard now shows the uptime of the fonera. This is only refreshed when you refresh the dashboard, don’t expect it to change synchronously.
  • DDNS behind NAT: we added a script that will check the public IP of the fonera even behind NAT (this is the case for 99% of the foneras connected behind a cable/adsl router).
  • RapidShare and Megaupload fixed and improved: RapidShare downloader had a bug that made some files not be downloaded. Additionally, adding too many links in a row while it was downloading others made the fonera crash from time to time. This is handled in a different way now and should not crash anymore. Please test it.
  • Many fixes on the interface, facebook and other applications…

Please all comments to the development list or additionally IRC (#fonosfera on irc.freenode.net).

Command line image: here – md5sum 5291756e6df93e4f66f5975bb734045a

Web image: here -> untested… if the flash process fails, use the other over ssh.

Bye bye ENDUSER, welcome DEVELOPER

Tuesday, May 5th, 2009

Hi,

After lots and lots and lots of impatient requests to make the plugin to switch from ENDUSER mode to DEVELOPER mode, it is now available on the “Applications” menu of your Fonera 2.0. Yes I put it there… one by one… I got into your houses and hacked your foneras!!! muahahahaha!!!!

What does this plugin do? It will basically change one configuration file (/etc/config/registered) so the “dev” option is changed from 0 to 1. That is all. Simple huh?

The effect is nice…

  • the interface color will change,
  • the ssh access will be available after 2 reboots (don’t ask why…)

There’s one more thing the plugin will do (please don’t be paranoid): it will connect to fon.com and tell us your MAC address. Why? Because we want to know how many people switched to developer mode. We promise not to tell anybody what you did, ok? Actually we’re not even storing this info in a database, but a simple log.
What are we working on?

  • New torrent application -> we hope it will fix the issues we’re having now
  • Fix RapidShare bug: some files could not be downloaded. It’ fixed and will be pushed in the next upgrade.
  • Improved audio plugin to listen to shoutcast streams… etc.