On Wed, 22 Oct 2008 09:04:31 -0200, "Levy Abinajm Melero Sant'Anna" <[EMAIL PROTECTED]> wrote: > Working nice for me, I was doing the same modifications manually, using ip > 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. j > On Wed, Oct 22, 2008 at 08:00, Alastair Johnson > <[EMAIL PROTECTED]>wrote: > >> Joel Newkirk wrote: >> > On Tue, 21 Oct 2008 16:29:30 +0100, Alastair Johnson >> > <[EMAIL PROTECTED]> wrote: >> >> >> >> Joel Newkirk wrote: >> >>> OK, I posted the updated package to >> >>> htp://newkirk.us/om/testing/netfix-j2.tar.gz - 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 127.0.0.1' | 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) >> > >> > http://newkirk.us/om/dnscache_2.1.5_armv4t.ipk ;) >> >> 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@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> _______________________________________________ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community