netfix testers?

Joel Newkirk freerunner at
Thu Oct 23 02:44:11 CEST 2008

On Wed, 22 Oct 2008 09:04:31 -0200, "Levy Abinajm Melero Sant'Anna"
<levy.santanna at> wrote:
> Working nice for me, I was doing the same modifications manually, using
> route.
> Maybe you could use the both commands, with "if"
> Thank you,
> Levy 'Lewis' S.

The problem is that 'ip' only supports route metric if you install the full
iproute2 - the one preinstalled on the FR is a link to busybox, which
supports a minimal subset of functions from the 'real ip' - excluding route
metrics among a great many other features.  However the busybox 'route'
implementation does support 'metric', so I just went that route.  That way
there's no dependency on an iproute2 ipk that AFAIK is not in any
repository (bar Debian) at this time, and the added "peace of mind" benefit
that anyone interested only needs to install a tarball of a dozen plaintext
config files and short shell scripts, more easily audited than an ipk
binary from an unofficial source.  (it does need resolvconf, which is
preinstalled on 2007.x/2008.x/FDOM, not on Raster or SHR, don't know about
others, but is in the official feeds regardless)

We need route metrics: it's entirely possible for wifi, usb, and gprs to
all be up simultaneously, all three having default routes they configure
when they come up.  In the past you could end up with two default routes at
same priority (which one is 'right'?) or the 'newer' would replace the
'older' - which might be wrong and almost always leads to problems when
interfaces go down (IE, wifi) and the default route needs to revert to the
old device and gateway (IE, USB) and nevermind what happens if USB went
down in the meantime, which is not at all unlikely with the FR.

So it sets up route metric of 20 for Wifi, 30 for USB (host or device mode
possibilites) and 40 for ppp0 (GPRS).  All three default routes can exist
at the same time if all interfaces are up, but the kernel will choose the
'least cost routing' which is: wifi, failing that: usb, failing that: gprs,
failing that: can't route.  (smaller metric is supposed to be an indication
of 'hops to destination via this route', so lower number means it's
"closer" and so the kernel chooses this as the best route - in a sense I'm
misusing 'metric' but it works reliably, just rank the routes by 'how long'
instead of 'how far')

I'm looking for an easier means of customizing (maybe you want USB highest
instead of Wifi) because currently you'd need to edit the route metric in a
few files and also /etc/resolvconf/interface-order.  What I'd like
eventually is to have an indicator widget in the top shelf or toolbar
showing connection status and route/tech.  Tap for details balloon, tap
'more' or whatever in that to open dialog to manage GPRS and WiFi, and
offer prioritization.  But I haven't been able to do more than contemplate
that as a future project, with too much keeping me busy as it is. :(  By
the time I get a chance we'll probably be using frameworkd to manage all
the connections.  (I'm working on getting GPRS under frameworkd to work
with my changes, but frameworkd doesn't yet manage wifi)  And hopefully by
then we'll have a network manager on top of sensible defaults.


> On Wed, Oct 22, 2008 at 08:00, Alastair Johnson
> <alastair at>wrote:
>> Joel Newkirk wrote:
>> > On Tue, 21 Oct 2008 16:29:30 +0100, Alastair Johnson
>> > <alastair at> wrote:
>> >>
>> >> Joel Newkirk wrote:
>> >>> OK, I posted the updated package to
>> >>> htp:// - using 'route' instead
>> of
>> >>> 'ip' now to set up default routes.  So the only external dependency
>> >> should
>> >>> be for resolvconf on SHR and Raster (and I'm guessing FSO).
>> >>>
>> >>> Please test and post results or problems to this thread.
>> >> Sounds good. I'll give it a try when I get the chance. It sounds like
> it
>> >> should combine well with dnsmasq or similar.
>> >
>> > I've been using djbdns dnscache.  You just need the cache startup to
> also
>> > invoke "echo 'nameserver' | resolvconf -a lo" and it always
>> uses
>> > local cache first, drops to next priority if cache is broken or
> stopped.
>> > You can also stuff a custom script in /etc/resolvconf/update.d that
> will
>> be
>> > able to take the prioritized nameservers and update your cache to use
>> them
>> > as upstream caches.  (I've an example script for dnscache, but it
> expects
>> > it to be running under the full daemontools+tcpserver setup whereas I
> run
>> > it as a simple standalone service)
>> >
>> > ;)
>> I couldn't see dnscache in OE but it sounds like the configuration to
>> work with resolvconf is similar. dnsmasq is already available in OE
>> which may make integration with the standard images easier. It also
>> serves dhcp which would be useful when hooking up to a random laptop to
>> provide GPRS access. I don't have any experience with either dnsmasq or
>> dnscache other than looking at the docs, so I'm interested in hearing
>> experience of their relative merits. IIRC someone (you?) mentioned a
>> peculiarity of the djbdns build that may make it hard to include in OE.
>> _______________________________________________
>> Openmoko community mailing list
>> community at

More information about the community mailing list