2.3.8.0 beta 1 testing release

October 9th, 2014 by Matthijs

After a lot of work on the 3G support in the Fonera firmware, it’s finally time to share some of this work with you in the form of this beta release. As the name suggests, this release should be considered a testing release – it’ll probably not eat your data, but don’t be surprised if your internet connection breaks at some point. Having said that, we welcome you to try this release and provide feedback about any issues you encounter. You can always downgrade back to the latest stable firmware if there is a problem that is a showstopper for you.

3G improvements
As mentioned, improved 3G support is the biggest change in this release. By itself, this release does not magically add support for more 3G devices (though it’s likely that some devices that didn’t work before now do due to usb-modeswitch updates and kernel fixes), but it mostly cleans up the 3G support and makes it easier to debug issues with 3G devices.

For some more details about how the new 3G interface works and how to go about getting your device working, a separate blogpost is available. Please carefully read that post if you run into 3G problems.

Note that 3G devices no longer automatically connect when plugged in. By default, you’ll have to connect by clicking a button in the webinterface, though you can still configure the old behaviour of automatically connecting on device insertion by going to 3G -> Configure and then select “On device insertion: connect automatically”.

3G dongles and hubs
One change to point out specifically is that 3G devices in combination with USB hubs should not cause any problems anymore. Previously, using an USB hub would break connectivity for some 3G dongles. It turned out there were two unrelated bugs in the kernel USB driver that both caused problems with hubs under different circumstances. After extensive debugging, these issues have been found and fixed.

If you still find an issue with a hub (i.e., your dongle works without a hub, but doesn’t when connected through a hub) please report it.

Debug application
Another new addition in this release is the debug application. It’s not very powerful yet, but allows collecting some debugging information through the webinterface, as well as increasing the log buffer size. This should help us to collect debug information from users that are not comfortable with using the SSH interface.

To install this application, just head over to the “Applications” page on your dashboard – it should be listed there.

So, how do I upgrade?

Download the web upgrade tarball below, navigate to your Fonera’s dashboard through “Settings” and then “System” and upload the tarball there (under “Firmware update”). Note that you should not unpack the file you download (and make sure your browser doesn’t automatically unzip the file either, it should remain a .tgz file).

Note: On 2.0g, the firmware update might fail due to insufficient memory. If you upload the firmware through the webinterface, but that page keeps loading indefinitely (and you do not get the updating countdown), you’re probably seeing this issue as well. As a workaround, you can disable windows file sharing (“Settings” -> “Fileserver” -> “Windows Network Shares”) and/or the public Fonspot (“Settings” -> “FONSpot”) to free up some memory. This should allow the 2.0g to successfully unpack the firmware and start flashing it.

This firmware is available for the following hardware. Be sure to pick the version for your hardware. If you pick the wrong one, the firmware update will silently bail out and no upgrade will happen (no error will appear either).

Since this is a beta release, only developer’s versions are available. For the .img version (which can be installed through SSH), you can look in the 2.3.8.0_beta1 directory on the download server.

If the upgrade somehow fails and you need to recover, the FAQ section has recovery instructions.

Have fun!

Debugging 3G dongle support

October 9th, 2014 by Matthijs

In our latest firmware release for the 2.0n and 2.0g, 2.3.8.0 beta1, we introduced completely rewritten support for 3G devices. This new code should work with more devices out of the box, but the main feature is improved debugging support. This means there are some knobs and switches that allow you to tweak how the Fonera talks to your 3G device.

If you want to make your 3G device work with the Fonera, be sure to read this post carefully. It contains a lot of info, so it’s easy to miss a detail or skip over some important instructions. Especially if you file a bug report, read carefully to prevent duplicate reports and a lot of extra work…

This post will detail these knobs and switches and documents when to use which. It’s not guaranteed that you can actually make any 3G device work using these instructions, but they should help you make it work if possible and if not, collect enough information for us to have a look at it. But first, I’ll provide a bit of background on how a 3G device typically works.

3G devices background
When you connect a 3G device, it will tell the Fonera what kind of device it is so the Fonera can load the appropriate drivers for it. However, most 3G devices will initially lie and say they are a a read-only storage device (like a USB cd-rom player). This storage devices then contains the Windows drivers for the 3G device, so Windows users can easily install those.

After installing the driver on Windows, it will send a special command to the 3G device, telling it to switch into modem mode. In response to this command, the modem will (virtually) disconnect and then represent itself to the Fonera as a brand new device that supports a number of modem ports. On Linux (and on the Fonera), this part is handled by the USB modeswitch software automatically.

Each of the modem ports exposed by the 3G device have some specific function. Commonly there is one control port, over which commands can be sent to set up the device and get status information and one data port, over which the actual data transfer happens. Sometimes there are additional ports, used for diagnostics or different modes of operation). Unfortunately, there is no universal automatic way to find out which port is which. Some manufacturers offer some way to detect this, but these ways usually don’t work with all devices.

Even though there some standards for (3G) modem devices, not all devices and manufacturers implement them in exactly the same way and some devices have specific quirks in the order they need to receive commands, etc. For doing the modeswitch, every device needs some magic command for which there are no standards at all. On Windows, these quirks are handled by giving each device its own driver (or some manufacturers uses a single driver that knows about all the quirks for its own devices). On the Linux desktop, there is software available (modem-manager) that knows about a lot of these quirks and can talk to most 3G devices. However, this software (and mostly its dependencies) is way too complex and big to run on the Fonera, it wasn’t written with embedded devices in mind. Instead, we’ve written a new piece of software, called udiald (and made the source available under the GPL license), which aims to support as much devices as possible using only a small bit of code.

Debug application
To assist in debugging (3G) issues, we’ve created a small debug application that makes it easier to collect debuging info through the webinterface (instead of having to run commands through SSH). Right now, it allows collecting log output and USB device info.

You can install this debug application through the “Applications” page on your dashboard. For now, it’s only available for this beta release. After a bit more testing, we will probably make it available for the 2.3.7.x stable release as well.

Configure provider info
Before you click the “connect” button for your device, you’ll have to tell the Fonera about your 3G provider. You can do this by clicking the “Configure” icon below the list of devices.

For the connection to be made, your device needs to know the “access point name” (apn) to connect to. Using the wrong or no apn usually breaks the connection, or can cause the wrong payment plan to be activated, so be sure not to skip this step. Additionally, some providers require login credentials for the connection, though these are often not a personal login, but some generic one.

The other options on this page can usually be left at the default values.

Attaching your device
When you attach a 3G device, the Fonera will autodetect it and it will be listed on the “3G/UMTS” page on your Fonera Dashboard. This page lists all devices that look like a 3G device (i.e. that have modem ports), not just those which the Fonera explicitely knows about.

However, it is still possible that your device is not listed on this page, most likely because the USB modeswitch software didn’t know about it or the mode switch failed for some reason. If this happens, please file a bug report so we can have a look at what is wrong.

If your device is shown in this list, the column “Device configuration” will show which configuration the Fonera has decided to use with your device (based on the USB identifiers of the device). Looking at this configuration profile, there a few cases:

  1. It shows the brand and model number of your 3G device. This means that someone has actually tested your device model before and the Fonera has a configuration profile specifically for your device. It’s highly likely that it will work right away, so best to just try it (but don’t forget to look at the “preparing to connect” section below). If it doesn’t work, skip to the next section.
  2. It shows the right brand, but the wrong model number. This means that the device’s manufacturer has used the same USB identification numbers for two different device models. This isn’t supposed to happen, but unfortunately it does. However, it’s likely that the same profile will actually work for both devices, so just try it. If it doesn’t work, skip to the next section.
  3. It shows “Huawei 12d1:1001″ or some other number. This is a special case that occurs only for Huawei devices. Your device has not actually been tested with the Fonera, but we managed to get at least some of the settings (control and data port) out of a Linux driver created by Huawei. In this case, it’s likely that your device will work right away, so just try it (but don’t forget to look at the “preparing to connect” section below). If it doesn’t work, skip to the next section. If it works, please file a bug report to let us know.
  4. It shows “Generic ZTE”, or something else starting with “Generic”. This means that the Fonera doesn’t really know anything about your device, except the manufacturer. It selected a profile that contains some generic settings, but it’s likely that those won’t work. You could try connecting, but you’re probably better of going to the next section to look for the right settings. Whatever the outcome be sure to file a bug report with your findings.

Finding out the modem port numbers
So, if your device doesn’t work yet, you’ll have to find the proper settings for the device. As mentioned above, each modem has a number of ports (numbered starting with 0), of which one is the “data” port and one is the “control” port. To find out which is which, we’ll have to do a bit of trial and error.

To make changes to the configuration profile for your modem, click the “Modify” link in the “Device configuration” column. The page shown will allow you to change various modem settings. The “Based on” dropdown allows you to copy settings from another profile (which could help if your unsupported device is similar to another device that is supported), but you can also just specify the settings manually.

To fnd out the correct port numbers:

  1. Find out what ports respond to AT commands. 3G modems use “AT commands” (like oldschool dialup modems) to communicate through the data and control port. Since the other ports don’t usually respond to AT commands, we can quickly rule them out as candidates for the data and control ports.

    To do this, set the control port to 0, click “Save” and then click the “Probe” button for your device. This will try to probe the device on its configured control port and show you the output. If you get a lot of output, including a “Identified as …” line near the top, this port is a candidate (even if the output also shows some errors further on, since not all devices respond to all probe commands). If it shows only a few lines like “Poll timed out” and “Unable to identify modem”, then it is not a candidate port.

    Repeat this process for every supported port (e.g., every port number in the dropdown). Don’t stop when you found two candidates, since sometimes there are more than two candidates (and the first two might not be the ones you need…).

  2. Now you know which ports are candidates, you need to figure out which is which. In general, any of the candidate ports will probably work as the control port, sometimes not all of them will work as the data port. You’ll have to just try different combinations to find out which one works. Often, the data port is the lowest numbered candidate, so you’ll likely want to start with that. Also, it does not make sense to use the same port as data and control port. The interface does not forbid it currently, but it will probably not work…

The dial command
When the modem is all set and ready to make a connection, the dial command is used. Unlike the old school modems, the 3G modem doesn’t actually dial a number (I think), but it’s more a magic command to let the modem know to set up a connection.

The default dialcommand should work for most modems (in fact, it worked for all the modems we tested with), but some modems (or providers?) might require different dialing commands. In particular, EVDO or LTE modems are rumoured to need one of the other commands in the dropdown, though we haven’t had any of these to test with.

The mode commands
The last five commands are used to set a preference or force the use of the UMTS or GPRS networks. The values you set here are the commands to use for this modem, to change the actual mode used, click the “Configure” icon below the list of 3G devices.

If you test other modes than “auto” and these commands don’t work, please file a bug report about this. There’s no ready-made instructions of other commands to try, but perhaps we can figure something out for your specific device.

Filing a bug report
If your 3G device doesn’t work out of the box or at all, or the instructions above tell you to file a bug report, you’ll need to take some steps to make a proper bug report on the Fonosfera trac. Here’s how this works:

  1. Do a search on the trac to see if someone else has already filed a report about your device. It’s best to search for the model number of your device (without the brand name) here.

    If you find a report about your device, you can leave a comment to let us know you also have this device. If you fill in your e-mail address, you’ll get notified of any followup comments on the bug report as well.

  2. Collect information for your bug report. We’ll need:
    • The make and model of your device
    • A description of what is working and what is not and what you have already done to debug
    • The log output shortly after plugging in the device and doing a connection attempt (can be retrieved using the debug application, see above).
    • The detailed list of USB devices (can be retrieved using the debug application, see above)
  3. File a new report. Be sure to include your e-mail address in the “reporter” field so you get notified about comments. To include the info collected above, use the {{{...}}}” trac syntax to keep the info readable (hint: Use the preview button to see if you got it right).

    Hotfix to make Flickr work again

    October 1st, 2014 by Matthijs

    A while ago, Flickr changed their API to require HTTPS connections to be made. This causes the Flickr uploader in the Fonera firmware to break.

    As of today, there is a hotfix available for firmware 2.3.7.1 that fixes this problem and makes the Flickr uploader work again. Installing it is simple: Just head over to the “Applications” page on the Fonera dashboard and install the hotfix that’s listed there. It should work right away.

    Note that this fix is only available for the latest released stable firmware version, 2.3.7.1. If you’re running an older version, you’ll have to upgrade first. Furthermore, if you ever do a factory reset, you’ll have to reinstall the hotfix (which is also the only way to uninstall the hotfix).

    Paco Jr: small bugfix release

    December 26th, 2013 by Matthijs

    While we keep working on revamed 3G support for the next feature release, we also found some small but important bugs or regressions. To make sure you have the most stable firmware possible, we’ve collected the most important bugfixes and put them in the 2.3.7.1: Paco Jr. release.

    What changed?
    Here’s the (exhaustive) list of changes:

    • Prevent a brute-force attack on the private wifi signal when WPS is enabled.
    • Make the “Media” share work again.
    • Make file sharing on 2.0g work with Windows Vista and up without having to change the LMCompatibilityLevel registry setting.
    • Update the Twitter to the most recent Twitter API.

    Overall, we recommend all users to install this update.

    So, how do I upgrade?

    Download the web upgrade tarball below, navigate to your Fonera’s dashboard through “Settings” and then “System” and upload the tarball there (under “Firmware update”). Note that you should not unpack the file you download (and make sure your browser doesn’t automatically unzip the file either, it should remain a .tgz file).

    Note: On 2.0g, the firmware update might fail due to insufficient memory. If you upload the firmware through the webinterface, but that page keeps loading indefinitely (and you do not get the updating countdown), you’re probably seeing this issue as well. As a workaround, you can disable windows file sharing (“Settings” -> “Fileserver” -> “Windows Network Shares”) and/or the public Fonspot (“Settings” -> “FONSpot”) to free up some memory. This should allow the 2.0g to successfully unpack the firmware and start flashing it.

    In the coming weeks, we will also offer this firmware upgrade directly from the dashboard, making the upgrade even easier, but this procedure needs a bit of testing before we enable it.

    This firmware is available for the following hardware. Be sure to pick the version for your hardware. If you pick the wrong one, the firmware update will silently bail out and no upgrade will happen (no error will appear either).

    The above links point to the end user’s versions of the firmware. For different versions, like the developer’s version (which allows SSH access and custom plugins) and the .img version (which can be installed through SSH), you can look in the PacoJr directory on the download server.

    If the upgrade somehow fails and you need to recover, the FAQ section has recovery instructions.

    Have fun!

    freedns.afraid.org now working with Fonera

    July 15th, 2013 by Matthijs

    Just a quick note to let you know that freedns.afraid.org now works as a dynamic DNS provider for the Fonera. The current firmware already included this provider in the list of DDNS providers, but until today there was an incompatibility related to the way url parameters were encoded (see ticket #1300 for details).

    After reporting this problem to the adminstrators at afraid.org, they promptly replied and made a change at their end to fix this incompatbility, so the DDNS service from afraid.org is now available for use with the Fonera.

    Screenshot of afraid.org (edited for size)

    Because their DDNS update procedure is slightly different than others, I’ll expand a bit on how to use their service. freedns.org works with the concept of an update url with a single update key inside, instead of a username/password. To use their service, you create a subdomain in their Dynamic DNS panel. In that same panel, you’ll see a link called “Direct URL”, which points to something like http://freedns.afraid.org/dynamic/update.php?VWNGMEVxMzFVMVVBQxYIam1KZ0FBQUFiOjc3Mjc0NjE=. In this url, everything after the ? is the update key (including the = at the end).

    To set up the Fonera to use this DDNS provider, fill in the domain name you picked (like “example.d-n-s.name”) in the “Domain name to update” field and put the key (VWNGMEVxMzFVMVVBQxYIam1KZ0FBQUFiOjc3Mjc0NjE= in the example) in the “password” field. Leave the username field empty.

    Fonera WebUI

    Thanks to Josh at afraid.org for making this work!

    3G support progress

    March 14th, 2013 by Matthijs

    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 stable firmware release: 2.3.7.0 Paco the alpaca

    December 28th, 2012 by Matthijs

    Paco is finally here, loaded with fixes, new features and improvements! Just in time to have some holiday time to play with this new firmware.

    What changed?
    Comparing this release with the previous stable, 2.3.6.2, here’s a summary of the most important changes:

    • 2.0g now supports bridge mode (but not wifi-bridge mode, due to technical limitations).
    • The “Orange page” with the “Your internet is misconfigured” message was removed. It caused more problems than it solved, due to onlined incorrectly detecting a broken connection when it was still working.
    • Various networking and wifi fixes and improvements that can make the network more stable and a bit faster in some circumstances.
    • Wifi scans can now be performed from the web interface.
    • Status display in the dashboard is improved.
    • Large USB disks (>2TiB) are now supported.
    • Multiple Dynamic DNS providers are supported now.
    • Various software and drivers have been updated.
    • OpenVPN was made a lot more configurable.

    There are dozens and dozens of smaller changes, which are listed in detail in the changelog.

    So, how do I upgrade?

    The easy way:

    • This method works if you’re currently running firmware 2.2.5.0 (Flipper) or 2.3.6.x (Gari).
    • Go to the “Applications” page in your Fonera’s webinterface.
    • You should see the firmware upgrade listed.
      Screenshot of the firmware upgrade part of the Applications page
    • Click the “plus” icon to install the firmware. It might take a few minutes for the page to load, it should show a countdown as soon as the actual upgrade started.
    • Done!

    The manual way:

    Download the web upgrade tarball below, navigate to your Fonera’s dashboard through “Settings” and then “System” and upload the tarball there (under “Firmware update”). Note that you should not unpack the file you download (and make sure your browser doesn’t automatically unzip the file either, it should remain a .tgz file).

    Note: On 2.0g, the firmware update might fail due to insufficient memory. If you upload the firmware through the webinterface, but that page keeps loading indefinitely (and you do not get the updating countdown), you’re probably seeing this issue as well. As a workaround, you can disable windows file sharing (“Settings” -> “Fileserver” -> “Windows Network Shares”) and/or the public Fonspot (“Settings” -> “FONSpot”) to free up some memory. This should allow the 2.0g to successfully unpack the firmware and start flashing it.

    This firmware is available for the following hardware. Be sure to pick the version for your hardware. If you pick the wrong one, the firmware update will silently bail out and no upgrade will happen (no error will appear either).

    The above links point to the end user’s versions of the firmware. For different versions, like the developer’s version (which allows SSH access and custom plugins) and the .img version (which can be installed through SSH), you can look in the Paco directory on the download server.

    If the upgrade somehow fails and you need to recover, the FAQ section has recovery instructions.

    Are there any known problems with this version?
    Yes, this release is still not perfect, but we’re getting closer at every step. In any case, here’s two things that used to work, but are now broken in this release. If you depend on them, you might want to reconsider the upgrade:

    • The music plugin is no longer available on the Fonera 2.0g, due to its limited available flash memory. The firmware has grown a bit since Flipper, so now there is no longer enough free space to install the music plugin.
    • The “Media” file share stopped working. In this release, a small security / stability fix was applied, which had the unintended side-effect of breaking the “Media” share. The shares for the individual partitions still work as expected. See ticket #1243 for details.

    Special thanks go out to all of our users who have been testing the testing releases and have been providing excellent feedback and even contributed back some code and improvements!

    Have fun!

    Update 2013.03.13: The firmware can now be upgraded through the webinterface, the Wake-on-LAN plugin can now be installed through the webinterface and some known bugs were documented in this post.

    New official plugin: Wake-on-LAN

    December 5th, 2012 by Matthijs

    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.

    2.3.7.0 release candidate 2 released!

    November 15th, 2012 by Matthijs

    A small update: This second release candidate fixes two serious bugs which prevented the PPPoE and 3G/UMTS internet connection types from being useful for most people. Additionally, two small bugs were fixed as well, see the changelog for details.

    Here’s the firmware files:

    See the previous post for instructions on installing these images and what to do with any feedback you might have.

    Have fun!

    2.3.7.0 release candidate released!

    October 5th, 2012 by Matthijs

    We’re nearly there! The first release candidate is available, which contains all the changes we’ve planned for the 2.3.7.0 final release. We’ll now enter a period of more extensive testing, to find any remaining critical bugs or regressions. In the best case, we’ll not find any and the final release will be identical to to this release candidate.

    What changed?
    This release brings mostly bugfixes and a pile of Here’s a few highlights:

    • The Transmission torrent client was updated to version 2.71.
    • Wifi channels 12 and 13 are now available in countries they are allowed in
    • OpenVPN is a lot more configurable (many thanks to Jon Spriggs for contributing patches for most of these changes!).
    • USB audio devices work again (this got broken in beta3).
    • USB disk support improvements

    For the complete list of changes, see the changelog.

    What about my feedback?
    We welcome more feedback about this release, so go ahead and comment or post away. This does not just mean issues or problems: If you test a new or fixed feature and it works for you, we’d like to know as well. Feedback is welcome through various channels: comments on this blogpost, the development mailing list, IRC or by creating a ticket on our trac.

    Note that at this point, we might not fix all bugs reported, but limit to critical bugs or regressions that were introduced by the recent releases. The goal here is to make as few changes as possible, to minimize the chance of introducing new bugs again.

    So, how do I upgrade?
    To install this release candidate, download the web upgrade tarball here, navigate to your Fonera’s dashboard through “Settings” and then “System” and upload the downloaded file there (under “Firmware update”). Note that you should not unpack the file you download (and make sure your browser doesn’t automatically unzip the file either, it should remain a .tgz file).

    The following versions are available. Note that because this is release candidate, only the developer’s version is available, not the end user’s version (but you can freely switch between versions without problems). Be sure to pick the version for your hardware. If you pick the wrong one, the firmware update will silently bail out and no upgrade will happen (no error will appear either).

    It seems that in some cases, the 2.0g fails to flash a new firmware through the webinterface due to insufficient free RAM. If you upload the firmware through the webinterface, but that page keeps loading indefinitely (and you do not get the updating countdown), you’re probably seeing this issue as well. As a workaround, you can disable windows file sharing (“Settings” -> “Fileserver” -> “Windows Network Shares”) and/or the public Fonspot (“Settings” -> “FONSpot”) to free up some memory. This should allow the 2.0g to successfully unpack the firmware and start flashing it.

    If the upgrade somehow fails and you need to recover, the new FAQ section has recovery instructions.

    Have fun!

    Update: This release contains a bug breaking PPPoE mode when set to use the automatic DNS server address. If you have this configuration, either switch to a static DNS server (like 8.8.8.8 Google DNS), or see ticket #1229 for a fix.

    Update: This release contains a bug breaking the 3G settings page in all cases. See ticket #1228 for a fix for this problem.