Kernel 2.6.28 already has network namespaces indeed, however they do not support sysfs. Thus, it is not usable as is in Fremantle. In theory, you could back-port sysfs namespaces patches from 2.6.29. This would imply flashing a new kernel image, and possibly breaking the kernel module ABI, thus flashing a new rootfs as well. In other words, it would be a usability nightmare.

In my humble but informed opinion, you're much better off doing TCP/IP in userspace for the MMS GPRS context. The kernel pieces are already in place for this: the pn_pep kernel module can provide either a virtual network device, but also a plain sequenced packets socket. In the latter case, you can read and write raw IP packets in isolation.

I think that this is the best way to implement for current kernel limits. It looks like ESOCK server at Symbian. Application selects network profile want to use.
From my point of view the network spaces concept has other goals as running tasks at another networking space without modifying its source code. In our case the code yet to be developed, so that a decision may take requirement of network management in userspace.

Just an idea.. using the route iptables module (which is marked experimental in the netfilter repository.. but it still

the MMS collector is run as a different UID (this might be problem, it might not)

iptables -t nat -A POSTROUTING -d $remote_mmsc \
-m owner --uid-owner mms-service \
-j SNAT --to-source $my_local_mms_ip

iptables -t mangle -A OUTPUT -d $remote_mmsc \
-m owner --uid-owner mms-service \
-j ROUTE --oif $my_local_mms_if --continue

ip addr flush dev $my_local_mms_if
ip addr add 127.127.127.127/32 dev $my_local_mms_if

• $my_local_mms_ip = the IP address the device gets when connecting to the MMS apn
• $my_local_mms_if = the device connected to the MMS APN
• $remote_mmsc = IP address of MMSC (wapgw whatever)

When running as user mms-service, I can reach $remote_mmsc via the interface $my_local_mms_if and appear to come from ip address $my_local_mms_ip

When running as any other user, I can connect to $my_local_mms_ip and $remote_mmsc via conventional routes.. EVEN if those ip addresses are local (say if wlan0 has the same IP address as $remote_mmsc it still works!)

The issue I have, (and I can't test because I've not got access to a device at the mo) is if the MMS APN connection is point2point:

it has a local address and a remote peer address.. The remote peer address still overlaps.. I think this might need another NAT mangle rule to convince traffic to go via the default gateway.. perhaps something alone the lines of :

iptables -t mangle -d $remote_p2p_ip \
-m owner ! --uid-owner mms-service \
-j ROUTE -- gw $my_default_gw --oif $my_internet_if

either that or a better route..

I've been playing with eithernet interfaces (so the italics bit is slighty different, I've been specifying a gw too) If the rules could be inserted prior to bringing the MMS apn connection live, it might work provided the ppp connection is not UP before its addresses are flushed and replaced (with someting private)

Just a thought.. and obviously a horrible hack.. but it doesn't require a software stack and it works apparently quite happily on 2.6.24.x

dunno, just throwing that out there..

forgot to mention, wouldn't work with IPv6 as I believe the ipv6 version of the ROUTE iptables module requires a main kernel change.. but I'm guessing that's not too much of a problem if the MMS connection is limited to ipv4 for the moment

IPv6 is of no concern if the workarounds are e.g. 1) "I'm sorry, I cannot read your MMS, can you send it by e-mail?" 2) Switching SIM to e.g. S60 device with MMS support.

For a quick, dirty hack IPv6 is of no concern because no Nokia N900/Maemo 5 user uses native IPv6, and even if there are such users they're minuscule minority.

BTW, i also don't understand why you'd want to use IPT for this. All you need to do is route all traffic to the MMSC over PPP1. So if the user defined mmsc.mms.vodafone.nl as MMSC then you'd use # route add -host mmsc.mms.vodafone.nl dev ppp1 after you bring up PPP1, which can be done via some scripting. Then when application tries to talk with MMSC it will take the correct route; no IPT is necessary. Thanks for thinking with us though

Because this is a returning trend I added 'MMS / rough roadmap' in the wiki. This shows the possible roadmaps this project can follow. This is important because every possible solution to the problem has its +/- and follows one of the outlined roadmaps, but if someone replies tothe proposed solution with a different roadmap in mind this blurs the discussion!! Feel free to contribute.

IPv6 is very unlikely to be a problem since I doubt that all handsets that support MMS support ipv6, but thought I should point it out!

in your example, what if the mmsc is 192.168.1.1?
What if it clashes with a local wlan address? what if the mmsc has the same IP address as wlan0?
what if the ppp interface obtains an IP address that matches a local wlan IP or host?
Overlaps are very bad.. I think this idea might solve many overlap problems..

I'll try to explain my thinking behind using netfilter.

wlan0 192.168.1.10/24 default gw 192.168.1.1

Now we connect to the MMS APN..

pppX 192.168.1.200 <=> 192.168.1.50
MMSC: 195.92.248.7

It *could* happen..
first problem. If the device is currently talking to 192.168.1.200 or 192.168.1.50 via WLAN, those two IP addresses are now present on two interfaces..
If the device is talking to www.orange.co.uk (which happens to have the same IP as the MMSC) which route does it use?

If we use the ipt_ROUTE module, we can direct traffic out of specific interface based on ipt matching.. which is fairly good..

With the suggesting I posted we've essentially given a partial split..
the phone is able to connect to 192.168.1.200, even though the ppp interface has this IP address. the phone is able to connect to the MMSC IP address via wlan0. I think with the additional rule, the phone could even talk to 192.168.1.50 via wlan0 EVEN though it is at the other end of pppX..

Now, for the MMS service (running as user mms-service) when it tries to connect to the MMSC, it is directed out of ppp0.. infact it is the only way to reach the mmsc via ppp0..

this is like a namespace solution, but hacky..

The overhead is low and it is using modules that can be added to Maemo with out changing the kernel!

Essentially, this technique might be a good basis for ensuring that specific processes are able to route and reach the mmsc via ppp0 whilst ALL other traffic, especially traffic that overlaps in IP address space routes via the default device (wlan0 or another ppp interface)

The vital thing here is to avoid clashes and since home networks use rfc1918 and operators use rfc1918 the chances are real.

Using namespaces would solve the problem. A new instance of pppd could be started in its own space then the sms service could attach to that pppd's namespace thereby inheriting its access (ip routes everything) whilst loosing any existing network access.. completely isolated.. but unless the maemo kernel is bumped to 2.6.29, that seems out of scope.. fingers crossed for maemo 5.1?

What I'd like to see is process A(all) can access all IP addresses via the internet connection.. process b) can access the MMSC via the MMS APN and even if the same ip address is used in both realms, it still works..

I think my idea is heading in that direction.. So far I have some vmware machines talking.. was quite nifty though.. in one window I could connect to 1.2.3.4 and it would leave via one interface and in the other window connecting to 1.2.3.4 left via a different interface.. what was even "cooler" was that if 1.2.3.4 was actually defined as an interface (lo:1, eth2 whatever) the first window would still connect out bound via the fake MMS APN interface where as all other windows would connect to localhost!! That is pretty close to what I think is needed..

I can mock something up, maybe some JeOS vmware images..

I think the long term I think the solution is namespacing, it is very neat and allows the MMS service to be completely isolated from all other networks. It would be neat to potentially improve icd2 to support starting an interface in its own namespace..

hAre there any phones which use IPv6 native? AFAIK not. Anyway...

Ok...

Lets say the user is connected to GPRS and has a default route to there. Then, the user comes home and connects to WLAN which tells it to add a default route to WLAN. You can then do 2 things: you can either keep the original route or you can replace it. What will happen is that the WLAN gets priority over the GPRS. If you then want to use GPRS then you fire up PPP which will give you IPv4/32 PPP local, IPv4/32 PPP remote, and IPv4/32 PPP gw. The gw you add to be routed over PPP interface. If there is already a /32 routed as gw then you give your own gw priority over that one. Because it works in the order they're added you delete current, then add your own, and add the one deleted again although I believe iproute2 can handle this more elegant its not part of Maemo 5. Because the MMSC_IP will match default route you must add a route source MMSC_IP/32 destination IPv4/32 PPP gw. Then we do business with MMSC. Afterwards, you shut down the PPP interface everything will be as before you used PPP interface. The very same principle applies to your example!

Because you're either changing the route and changing it back again or deleting the route, adding the one we want to use for MMSC, and then adding the one we just deleted the current connection to IPv4 address which happens to be same as MMSC_IP will be temporarily routed over the PPP interface to the MMSC.

Same as above. Default route changes temporarily to be used over PPP interface, and current connections to gw 192.168.1.1 will not work anymore. That means everything would be routed to MMSC. But we can make some sanity checks against this. Its unlikely this happens btw.

The PPP /32 comes first before the WLAN /24. If there are connections to this WLAN address they'll be disconnected and sent to an IP address binded to PPP interface.

Bring wlan0 temporarily down.

The PPP /32 comes first before the WLAN /24. If there are connections to this WLAN address they'll be disconnected and sent to an IP address binded to PPP interface.

For all of 3 cases sanity check is needed and in all of 3 cases this happens in a split second because the MMS is max 300 kB which will be downloaded quickly over GPRS. You could use ARP for sanity checks.

Collisions happen, simple as that. There is always a chance they happen when you play with privately assigned IPv4 over several interfaces.

Well right now we use dev option in route:

Which will work in almost all cases.

Yes, true, but always existed, and happens too e.g. with VPN or even in the case of GPRS and WLAN. If this happens customers will be pissed. But the chance this happens is small.

If you're scared it happens, and inappropriate traffic passes, you can use pass-filter in PPPD to only allow MMSC_service which has certain characteristics such as source IPv4 and source port. One could even use add 127.0.0.2 to lo and only allow 127.0.0.2 to pass. Really, these collisions sometimes unfortunately happen and that sucks but it happens. And even if you want to prevent them there is no need for IPT or experimental IPT options although what you state does work.

Hi again,

The difference between ipt_route and iproute2's dev flag is that iproute2 cannot direct an IP to a route if the IP is assigned to a local interface.. if eth0 is 1.2.3.4, you cannot route 1.2.3.4 via a gateway.. with ipt_route you can effectively do this..

My thoughts were that using that technique would minimise disruptions to other connections (ppp or wlan). I appreciate adding static host routes using iproute2, but the danger of local Ip and router gw and destination ip collisions means, as you said, you'd have to down the other active connection.. I was thinking of a way to avoid that..

Yeah but that module is experimental for a reason, its actually removed, because it duplicates features of policy routing. The only feature interesting is the --tee flag which got its own xtables module now based on ipt_ROUTE, called xt_TEE. You will find ipt_ROUTE in pom-ng in 3rd party plugins but pom-ng is deprecated in favor of xtables (kernel-bind for user-space filtering so not have to !@# recompile whole time). I managed, with a few modifications, to apply the patches, but it doesn't compile cleanly. So, while for us it may work, for Nokia this is not a serious solution. I will look into to check the alternative with policy routing, and otherwise xt_TEE would actually work too. One also can run MMSC_SERVICE as privsepped under user account, like you put, and (fw)mark this owner, then apply the same rules you made but then just specifying PPP as output device. Also, if you going to side with ipt_ROUTE at least test it very well on ARMEL because on reason for xtables is that IPT kernel modules (3rd party) were written for x86-32 and not working well on other architectures. xt_TEE I got compiled easily btw.

I must admit, there were two minor api changes in the module.. however.. and this is a big difference

eth0 1.2.3.4
ppp0 192.168.1.1 <-> 192.168.1.254

If the MMSC ip address is 1.2.3.4 you cannot (afaik) use iproute2 to instruct the system to route via 192.168.1 254 as it is treated locally. With the ipt_route module, you can.

You're right about avoiding experimental modules, but the module itself is quite simple. Without (usable) namespace support in the kernel it is a nasty hack any which way.. I was aiming for something that could run in paralell to a wifi connection or a different ppp connection and be totally unnoticable from a user perspective. I do see you point though, but making it transparent to the user is important too.. imho

This weekend I'll try and get something working with my N810 You're right, working on x86 is one thing, but it must be thoroughly tested on arm!

Doing it through userspace as you mentioned could be a viable alternative.. netfilter lets you attack a packet *almost* prior to routing which means you can hit things that would resolve locally without serious routing.. iproute2 is pretty focused on the routing layer..

As I said, it was just a suggestion, but I'm more than happy to do some serious leg work here!