Re: netfix testers?
On Thu, 23 Oct 2008 14:48:08 -0400, Stefan Monnier <[EMAIL PROTECTED]> wrote: >> 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) > > FWIW, on my Om2008.9 distribution, resolvconf was indeed installed, but > it was disabled and the installation was incomplete (missing > the /lib/resolvconf part IIRC). > > > Stefan Exactly right - I included /lib/resolvconf/list-records and /etc/resolvconf/run/enable-updates in my tarball for that reason. :) j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: netfix testers?
> 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) FWIW, on my Om2008.9 distribution, resolvconf was indeed installed, but it was disabled and the installation was incomplete (missing the /lib/resolvconf part IIRC). Stefan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: netfix testers?
> So it sets up route metric of 20 for Wifi, 30 for USB (host or device mode > possibilites) and 40 for ppp0 (GPRS). Oh yeah, I am using the iproute2, by this reason. Wifi is cheaper for me. > 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. This type of interface would be very cool. The power for the user choose, the metric directly from GUI. >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. Thank you for your efforts, I will test and report bugs. Levy 'Lewis' S. Google Talk! [EMAIL PROTECTED] ICQ 12913566 MSN [EMAIL PROTECTED] ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
DNS caching (was Re: netfix testers?)
On Wed, 22 Oct 2008 11:00:59 +0100, Alastair Johnson <[EMAIL PROTECTED]> wrote: > Joel Newkirk wrote: >> 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. I've not used dnsmasq. Build complications with djbdns revolve mostly around his approach to a makefile. It assumes it's being compiled on the destination machine directly, and builds test programs and scripts on the fly. I've no doubt someone could distill it to a briefer makefile that would successfully build dnscache for the FR, but I suspect a proper bitbake recipe would prove more challenging, and really ought to encompass the whole package, not just one component. I wrote a script to automate the build. It's fairly ugly, builds djbdns plus daemontools plus tcpserver. Of that all, only one component of djbdns is of immediate interest to me, dnscache, so the rest is superfluous. (I started with a full proper djbdns installation on my FR and trimmed it back step by step - for purposes as a local cache on a handheld device I decided that TCP support [rarely used in such a situation] and the daemontools service management weren't vital) j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: netfix testers?
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
Re: netfix testers?
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. Google Talk! [EMAIL PROTECTED] ICQ 12913566 MSN [EMAIL PROTECTED] 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
Re: netfix testers?
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
Re: netfix testers?
On Wednesday 22 October 2008 05:44:08 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 ;) Still yet to try, my apologies. om2008 testing died on me recently so I'm giving a few days until I chroot in and update again. I have nothing but respect for djb's tools, it hadn't twigged when you first mentioned dnscache, as it's been ... a while :) ... I'd say you've made the appropriate selection :) Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: netfix testers?
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 ;) j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: netfix testers?
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. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: netfix testers?
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. j On Sun, 19 Oct 2008 22:05:33 -0400, Joel Newkirk <[EMAIL PROTECTED]> wrote: > On Mon, 20 Oct 2008 11:46:12 +1100, [EMAIL PROTECTED] wrote: >> Joel Newkirk wrote: >>> I've posted a tarball of my networking fixes to >>> http://newkirk.us/om/testing/netfix-j1.tar.gz, and a writeup on it at >>> http://jthinks.com/better-freerunner-networking for anyone interested. >> Wiki >>> seemed inappropriate (at least at this time), and the writeup is too >> long >>> to post on the ML, IMHO. >> >> Awesome. I'll upgrade/backup/test at my earliest convenience (prolly a >> couple of days at this point). >> >> I'll let you know how I go. >> >> Sarton > > Thanks! > > I have to apologize - I just flashed to SHR to test this and > (re)discovered > that busybox's substitute for 'ip' doesn't support route metrics - I've > been installing my own from > http://newkirk.us/om/iproute2_2.6.26_armv4t.ipk > in my setup script I usually run after flash and forgotten that important > factor. I'm pretty sure the older 'route' command substitute in busybox > supports metric, will give it a test run. > > So this solution currently depends on both resolvconf and full > (non-busybox) iproute2. Angstrom only has iproute2 packaged for Arm9 > IIRC. > The resolvconf package (included with 2008.x but not SHR or Raster) is > available from the OM repository. > > Also, if you power up with USB already plugged in, it doesn't bring usb0 > up > automatically at first, since udev doesn't emit a 'power plugged in' > signal > - it's necessary to unplug and plug back in. I'll look into triggering at > startup as well. > > j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: netfix testers?
On Mon, 20 Oct 2008 11:46:12 +1100, [EMAIL PROTECTED] wrote:
> Joel Newkirk wrote:
>> I've posted a tarball of my networking fixes to
>> http://newkirk.us/om/testing/netfix-j1.tar.gz, and a writeup on it at
>> http://jthinks.com/better-freerunner-networking for anyone interested.
> Wiki
>> seemed inappropriate (at least at this time), and the writeup is too
> long
>> to post on the ML, IMHO.
>
> Awesome. I'll upgrade/backup/test at my earliest convenience (prolly a
> couple of days at this point).
>
> I'll let you know how I go.
>
> Sarton
Thanks!
I have to apologize - I just flashed to SHR to test this and (re)discovered
that busybox's substitute for 'ip' doesn't support route metrics - I've
been installing my own from http://newkirk.us/om/iproute2_2.6.26_armv4t.ipk
in my setup script I usually run after flash and forgotten that important
factor. I'm pretty sure the older 'route' command substitute in busybox
supports metric, will give it a test run.
So this solution currently depends on both resolvconf and full
(non-busybox) iproute2. Angstrom only has iproute2 packaged for Arm9 IIRC.
The resolvconf package (included with 2008.x but not SHR or Raster) is
available from the OM repository.
Also, if you power up with USB already plugged in, it doesn't bring usb0 up
automatically at first, since udev doesn't emit a 'power plugged in' signal
- it's necessary to unplug and plug back in. I'll look into triggering at
startup as well.
j
PS - just checked, and busybox-as-'route' DOES support route metric
setting, so I'm going to alter my scripts to use 'route' instead of 'ip
route' and make sure it behaves as expected. Update tomorrow.
**separately: I think the full iproute2 package should be in the OM build
tree - apart from allowing far more advanced routing controls than
busybox's poor substitute, it includes the 'tc' traffic control command to
give access to the full breadth of the kernel's IP traffic management - of
little direct use on FR as a terminal, much more useful if it's a gateway -
they build bridge-utils, iproute seems more generally useful. It builds
cleanly under dev toolchain.
busybox 'ip':
Usage: ip [OPTIONS] {address | route | link | tunnel | } {COMMAND}
iproute2 'ip':
Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
ip [ -force ] [-batch filename
where OBJECT := { link | addr | addrlabel | route | rule | neigh | ntable
|
tunnel | maddr | mroute | monitor | xfrm }
OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
-f[amily] { inet | inet6 | ipx | dnet | link } |
-o[neline] | -t[imestamp] }
iproute2 'ip route help':
Usage: ip route { list | flush } SELECTOR
ip route get ADDRESS [ from ADDRESS iif STRING ]
[ oif STRING ] [ tos TOS ]
ip route { add | del | change | append | replace | monitor } ROUTE
SELECTOR := [ root PREFIX ] [ match PREFIX ] [ exact PREFIX ]
[ table TABLE_ID ] [ proto RTPROTO ]
[ type TYPE ] [ scope SCOPE ]
ROUTE := NODE_SPEC [ INFO_SPEC ]
NODE_SPEC := [ TYPE ] PREFIX [ tos TOS ]
[ table TABLE_ID ] [ proto RTPROTO ]
[ scope SCOPE ] [ metric METRIC ]
INFO_SPEC := NH OPTIONS FLAGS [ nexthop NH ]...
NH := [ via ADDRESS ] [ dev STRING ] [ weight NUMBER ] NHFLAGS
OPTIONS := FLAGS [ mtu NUMBER ] [ advmss NUMBER ]
[ rtt TIME ] [ rttvar TIME ]
[ window NUMBER] [ cwnd NUMBER ] [ initcwnd NUMBER ]
[ ssthresh NUMBER ] [ realms REALM ] [ src ADDRESS ]
[ rto_min TIME ]
TYPE := [ unicast | local | broadcast | multicast | throw |
unreachable | prohibit | blackhole | nat ]
TABLE_ID := [ local | main | default | all | NUMBER ]
SCOPE := [ host | link | global | NUMBER ]
FLAGS := [ equalize ]
MP_ALGO := { rr | drr | random | wrandom }
NHFLAGS := [ onlink | pervasive ]
RTPROTO := [ kernel | boot | static | NUMBER ]
TIME := NUMBER[s|ms|us|ns|j]
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: netfix testers?
Joel Newkirk wrote: > I've posted a tarball of my networking fixes to > http://newkirk.us/om/testing/netfix-j1.tar.gz, and a writeup on it at > http://jthinks.com/better-freerunner-networking for anyone interested. Wiki > seemed inappropriate (at least at this time), and the writeup is too long > to post on the ML, IMHO. Awesome. I'll upgrade/backup/test at my earliest convenience (prolly a couple of days at this point). I'll let you know how I go. Sarton ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
netfix testers?
I've posted a tarball of my networking fixes to http://newkirk.us/om/testing/netfix-j1.tar.gz, and a writeup on it at http://jthinks.com/better-freerunner-networking for anyone interested. Wiki seemed inappropriate (at least at this time), and the writeup is too long to post on the ML, IMHO. What it does: Default route out eth0 (wifi) if present, out usb0 (via host computer) if eth0 NOT usable and usb0 IS usable, try ppp0 (GPRS) if both fail. And have nameserver lookups transparently adjust to match default route. What it is: Alterations (from slight to severe) of several existing config files and networking scripts, and several additions. Not a network manager (it's just config files and shell scripts), it doesn't bring interfaces up or down, it just ensures that regardless of which interfaces are up at any given time, which have gone down, which are just coming up, that default route and DNS nameserver lookups "just work". I'm hoping for a few good folks willing to test out the changes on various setups/images to help ensure this works on all. While you /can/ just untar to / on the FR and replace everything, I'd suggest doing it by hand, file by file, so you know what's changed (seven files, in /etc/network/ /etc/udev/ /etc/ppp/ /etc/udhcpc.d/ /etc/resolvconf/ and /etc/resolv.conf itself) and can backup present files. (don't rename inside current folders, though, as some of these are hit by run-parts, meaning every script in the folder gets executed - put backups in /home/root/netback or wherever) It'd also be nice to have extra sets of eyes and brains look this all over and see what I've missed. It currently requires that the default route for ppp0 be via the ppp peer, this should usually be the case I believe. (let me knwo if you see otherwise on your GPRS) It's also untested in setups with ethernet or wifi via USB (host mode) or VPN. (the former should work, the latter will probably need alterations of vpn config to play nice) j ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
