Handling multiple connections
laforge at openmoko.org
Sun Apr 29 09:18:46 CEST 2007
On Sat, Apr 28, 2007 at 08:48:26PM +0200, Andreas Kostyrka wrote:
> Just wondering, how do we currently plan to handle multiple data
> connections. I've got the impression that this hasn't been given much
> of a thought.
this is more or less true, at least that thought is under flux and will
certainly not be documented before there is any code, leading to more
We seriously have tons of more important issues right now. As soon as
the higher priority issues have been implemented, we can always think of
more advanced features and look on their implementation.
> a) multiple APNs: Internet, MMS, other apps (guess we won't get a
> blackberry client that fast, but still it might happen)
well, so far this is not on our list of requirements. so far, we do not
intend to support MMS or WAP, e.g.
> b) VPNs.
how does that related to a more or less physical connection? Also,
there are many technologies (openvpn, ipsec, vtun, cipe, to name a few)
and they all have their own properties and ideas on how to express
> c) CSD dialup connections.
What I think is actually more important and missing from your list :
d) bluetooth BNEP
e) usb ethernet emulation
> The important property here is, that openmoko needs to understand
> first of all that there are different destinations: e.g. Internet, MMS
> service, private networks (via CSD, via VPN).
who needs to understand that? libmokonet and the preferences app needs
to understand it, true. but the applications certainly not.
> The second thing here is, the framework needs to offer at least an
> opportunity for the user to decide how to handle every connection
> manually, or potentially allow it to remember policy (and that one
> should probably be save-able/restore-able and/or linked to a given SIM).
> The point is, I've got basically flatfees for Internet access in
> Austria/Germany. Ok. Other people pay fabulous amounts per MB.
> I don't much care what apps on the Neo access the Internet, and how
> much. For the poor soul paying $20 or more per MB, every byte transported
> counts. So one policy (e.g. everything goes over GPRS by default)
> doesn't fit all users.
> Furthermore we have a need also to allow situations like:
> *) my chat app goes over GPRS to keep a long running TCP connections
> *) my web browser prefers strongly BT/Wifi.
oh, you want to do per-application based policy routing? that's
certainly a non-trivial task to do. Nothing that I think openmoko would
be able to look into for at least the next six months.
> We should intercept connect() and show a dialog, probably defaulting
> to "Internet" destinations.
no, that is ugly and would resemble the idea of personal firewalls.
which network packets to route to where, and which connections to accept
and which not is the job of the kernel network stack. We have _tons_ of
tools to do stateful packet filtering, policy routing, traffic shaping,
and combinations thereof (e.g. you can do stateful routing, selecting a
route at connection startup time).
> We should provide an openmoke_connect_tcp_socket(...) function in the
> API, where the app can finetune which connection properties it needs.
> (It might even go so far: "I need a long running connection", "I need
> a connection with maximum bandwidth", ...)
I don't think the applications should care about this. This is
non-standard and diverges way too much from the usual way how tcp/ip and
Somehow, the user-defined preferences/policies need to be translated in
policy routing and packet filtering configuration. This policy is
always present, and does not require any special application support.
If you want to interactively permit/route/... connections, then this
will most likely need to be done via NFQUEUE mechanisms. You can QUEUE
all packets that connection tracking deems NEW, and then return a
verdict into the kernel. I believe this is how e.g. the NuFW personal
firewall handles this.
Thus, I argue that any such connection policy implementation
a) does not depend on explicit application support but works with all
existing applications, without modifying them, system libraries or
b) uses existing infrastructure such as iproute2/tc/iptables/NFQUEUE
c) uses files in the filesystem to specify the policies
d) will have some userspace management daemon and/or control programs
storing the policies.
e) application packages (ipk's) just provide a policy file with the
> This can be implemented by patching the upstream libc,
sorry, but: over my dead body.
> or by making all apps override connect and using the ELF functions to
> find the connect in the libc. Alternativly, one could provide that
> functionality in a LD_PRELOAD library.
I still don't think this is the way to go, but if you really want to do
it, use LD_PRELOAD. Then it's an optional feature that can be
explicitly enabled by people who really want it.
- Harald Welte <laforge at openmoko.org> http://openmoko.org/
Software for the world's first truly open Free Software mobile phone
More information about the openmoko-devel