[FSO] GPRS

[Joel Newkirk]

I successfully followed the process outlined at
http://wiki.openmoko.org/wiki/GPRS_FSO and got GPRS working through
T-Mobile.  (internet3.voicestream.com)  (this is on Raster+FSO)

But there's a few things...

first up, the page states "The implementation should not interfer with
other phone functionality, such as placing calls. In other words: you can
use GPRS while talking on the phone without hanging up.".  This is NOT in
fact true.  GPRS functionality is suspended while GSM is in active use. 
IE, the following is an excerpt from a running ping routing over GPRS, with
an incoming call ringing through (well, figuratively since I still get no
ringtone ;) at the 21-second mark:
64 bytes from 209.85.171.99: seq=17 ttl=240 time=565.898 ms
64 bytes from 209.85.171.99: seq=18 ttl=240 time=540.926 ms
64 bytes from 209.85.171.99: seq=19 ttl=240 time=555.915 ms
64 bytes from 209.85.171.99: seq=20 ttl=240 time=530.902 ms
64 bytes from 209.85.171.99: seq=21 ttl=241 time=55850.922 ms
64 bytes from 209.85.171.99: seq=22 ttl=241 time=54926.202 ms
64 bytes from 209.85.171.99: seq=23 ttl=241 time=54160.914 ms
64 bytes from 209.85.171.99: seq=24 ttl=241 time=53276.906 ms
64 bytes from 209.85.171.99: seq=25 ttl=241 time=52330.892 ms
64 bytes from 209.85.171.99: seq=76 ttl=241 time=1165.942 ms
64 bytes from 209.85.171.99: seq=77 ttl=241 time=800.850 ms
64 bytes from 209.85.171.99: seq=78 ttl=241 time=715.924 ms
64 bytes from 209.85.171.99: seq=79 ttl=241 time=690.908 ms

The pings from 21-25 don't actually respond until the call is ended
(evidenced by the 52-56 second ping times, matching the 56 second duration
from call ringing to call hangup), and everything after those five until
call end is lost.

I understood from previous discussions on the mailinglist that this is the
nature of the beast, that we won't get GPRS working DURING a GSM call - at
least not with this GSM hardware.  Is that correct or not?  (I'd dearly
love to be able to push a few packets when an incoming call starts ringing
through - callerid name lookups)  The muxer lets us keep both connections
configured, but GSM voice trumps GPRS data in an XOR.


Second, where is it performing /etc/resolv.conf replacement, and how do I
stop it?  because the current behavior is very undesirable for me.  I've
got local dns caching on my FR, so /etc/resolv.conf should ALWAYS point at
127.0.0.1, but it's deciding to alter it, and it's doing so by overwriting
the contents of /etc/resolv.conf.  If nothing else, the hardcoded behavior
should be more like 'echo "nameserver a.b.c.d" | resolvconf -a ppp0'
(obviously depends on resolvconf being installed - standard on 2008.x,
don't know about FSO image) or replacing the contents in
/var/volatile/run/resolv.conf, rather than 'echo "nameserver a.b.c.d"
>/etc/resolv.conf' - though ideally there should be the capability if
desired of bringing up the interface, then querying what route and DNS were
provided and acting on that information outside the actual ppp0 activation.


Third, where is it doing the replacement of the default route?  I'm also
working on more robust and reliable handling of default routes, to support
multiple prioritized default routes instead of what we currently have, IE
eth0 adding a second default route on top of the one from usb0, ppp0 (via
FSO) REPLACING default route, etc.  In addition, I would assume that any
network manager worth using will need to control routes and DNS itself, NOT
have them handled atomically as part of the act of activating an interface.


When gprsoff.sh is invoked, it restores the previous /etc/resolv.conf
contents, and restores the previous default route, though it does NOT
restore the previously-specified route metric.

Also, when gprson.sh is invoked and it 'replaces' the default route, it
does so by removing the first default route seen.  If the desire is for it
to atomically replace default route(s) with one out GPRS, then restore on
GPRS off, then it's necessary to remove and store ALL default routes,
including metrics.  (I've not even explored what it does if additional
routing tables ave populated and rules defined, I'm assuming that's
entirely beyond its comprehension at this point, though I've utilized such
arrangements on my FR in the past and likely will again)


And finally, is there any support, or intended support, for demand-dial
PPP/GPRS?  That, combined with route metrics and local DNS caching, (plus
proper hotplug enable/disable of usb0) may be able to circumvent the
present need for genuine network manager oversight.  I've been working
toward a usable arrangement without such management, wherein usb0 is the
lowest-priority route,  ethernet via USB ethernet adapter (eth2) next up in
priority if available, wifi is next up if it's been manually activated, and
GPRS demand-dial otherwise.  (so the effect in action would be that if wifi
is active it uses that, if not but eth2 wired ethernet is available use
that, if not then try usb0, failing that dial GPRS)

Then the next step is dealing with VPN(s) - routing the VPN connection as
well as routing through it...  I've back-burnered that aspect for now...

j