Re: Brainstorm: MMS Support
 

Since the final SDK is out now, I've been browsing through the packages included and it seems hard to get this in to the messaging ui as this seems to be closed (http://maemo.org/packages/view/rtcom-messaging-ui/).

I assume the other package which is interesting for us would be libtelcommon0 (only reference I've found so far to telephony) http://maemo.org/packages/view/libtelcommon0/ (closed as well).

On the other hand the rtcom-eventlogger does contain MMS as one of its default services...

Re: Brainstorm: MMS Support
 

Why? You'd check A record of the defined MMSC, bring up ppp1, add a route to the resolved IPs (and keep default route as is; e.g. ppp0), and voila.

Frals, but for making a dirty hack, the SMS data is saved somewhere on the device I suppose? If you can grab the encoded SMS (containing URI) then you can decode the MMS, use wget (for HTTP; or something which supports WAP) to grab the data, and then decode the data using MMS decoder. If we have a dirty hack to get it working, maybe Nokia will do the rest or fix the proprietary aspect to allow us to get it working prettier integrated. Because for Nokia to include MMS they'd have to implement full standards & protocols like WML/WAP while we can hack something which works for this particular MMS use-case.

Re: Brainstorm: MMS Support
 

Good idea! Can't wait to get my hands on a device to test something like this... :)
I'll do some digging to see where received SMS is stored (hopefully even the non-standard-text SMS's are stored there as well), or what happends to "discarded" messages.
Also worth to have in mind is this might break the MMS transaction as you are suppose to acknowledge getting the MMS etc, but that's a problem to solve later. :-)

Re: Brainstorm: MMS Support
 

Been digging around the final SDK and reading the final API docs and haven't really found anything about where SMS are saved/how to hook in to it.
I've have, however, found quite a few rtcom calls that would be nice to have some documentation on, but those libs are closed.

Could anyone with a device check where the SMS's are stored (and possible try and receive an MMS and see what happens - I'd assume you end up with a webblink for it though)?

Re: Brainstorm: MMS Support
 

The SMS are stored in a sqlite database in /home/user/.rtcom-eventlogger/el.db (and all calls, etc).


I can't send me a MMS right now but I'll try later today (if someone here want send me one before would be nice, PM me for details).

Re: Brainstorm: MMS Support
 

Cool, thanks! :)

Just realised there's a talk on telepathy and how it's used for SMS and how to use telepathy from your own application. Hopefully someone can record it / get the slides or something as I'm sure it will be some help in that presentation. :)

Re: Brainstorm: MMS Support
 

Waiting for slides/video of the telepathy on maemo presentation as that will hopefully provide us with some valuable information.

Until then, since there is ~300 more N900s in the wild - could anyone with a device check with dbus-monitor if there's a dbus-signal on incoming SMS(/MMS)?
And/or if the SMS control messages for the MMS ends up in ~/.rtcom-eventlogger/el.db?

Have been searching through the documentation and have not yet found anything on this, or have I just missed the right doc so far?

Re: Brainstorm: MMS Support
 

Just discussed this on IRC, appearently this was discussed at the summit.

To implement sending/receiving somewhat properly appearently we are going to need some kernelwork. (I'm still unclear exactly what's needed - I assume it's the different routing and stuff discussed on the wiki page.)

The workaround for sending would be a sharing plugin (and a free MMS-gateway service, I assume).
Receiving... Hopefully your carrier sends you an SMS with a weblink to get the MMS.

I still think its possible to implement MMS sending/receiving with the limitation of having to tear down the current connection and opening a new one to the MMSC. Which would somewhat limit the functionality as true push MMS as it wouldn't function when using the connection, but better than nothing ;)

EDIT: The kernel issue is with establishing a network connection to the carriers MMSC.

Re: Brainstorm: MMS Support
 

Does that mean that for now there is no way of getting 'real' MMS Support on the N900?

Like someone else mentioned here, this is not only a useful function for a lot of us but also a pride thing. Im a developer and ill be more than happy to help if someone has already started working on this (ie. is in the process of writing code)

Re: Brainstorm: MMS Support
 

For *real* MMS support, a kernel patch is needed afaik.

I do however still think that it should be possible to implement some pseudo-real way of doing it, and am still working to find out more on how to actually do it. Feel free to help anyway you can :-)

Re: Brainstorm: MMS Support
 

All that all of you talking about implementation MMS support is dirty hack.
Just look the truth. In real situation to implement it we should consider next requirements:
1. MMS is not unique service that requires separate interface. Just see the OMA and 3GPP's R5 requirements. All operator's services should be provided thru IMS. MMS is one of. So, the MMS feature is SIP.
2. IP-address spaces of Internet's connection (Inernet's PDP or Wi-Fi) and operator's PDP could be the same. There is collision.
3. MMS PDP usualy have separare DNS (if used to resolve HTTP Proxy / WAP 1.2 Gateway address).
4. 3G network and GSM supports up to 2 separate PDP-conexts at the same time.
5. WAP-Push indicators has specific message type and i'm not sure that messages of that type will be stored at the event database.
So the best idea is to implement multi-instanced TCP-stack like it's implemented at Symbian and qualified support of WAP-Pushes. After that we could speak about MMS frond-end and rendering.
I know nothing about implementation of multi-PDP at Android but the Windows Mobile implementation is too dirty. As i understood the iPhone implementation has second TCP stack for MMS.

Re: Brainstorm: MMS Support
 

At least for some folks an additional PPP connection isn't necessary. But I don't understand something. Its been long possible to have multiple PPP interfaces. What is exactly the issue of it not working?

Yes, my primary goal would be to be able to read a received MMS in some way. In my case, this may involve some command line work. That is OK with me because I won't receive many MMS anyway. This way, you at least are compatible receiving the content instead of not being able to read it at all.

SIP? Some comments in this thread point out that in some cases a seperate connection is required. I'm not sure on the statistics though, thats quite foggy.

In my case MMSC has public IPv4. If you'd sent the MMS and then give target device the link to the content you'd need to give a public IPv4. So the MMSC must have at least one public IPv4. If operators use a private IPv4 for their MMSC that is their stupidity because there is no need for that.

Thanks for your contribution.

Re: Brainstorm: MMS Support
 

In IMS infrastructure MMS agent shoud request service thru SIP before applying MM1. Just check specs of MM1st3.

I found an simple presentaion about MMS feature - http://www.cdg.org/news/events/cdmas...m/Qualcomm.pdf
Current specs also supports BCAST.
You can find all specs here.

Sorry, but my experience shows that most of operators uses private IP-networks for their services. I'm employee of one of them who has about 70 million of subscribers. Most parts of data-interchange between operators performs thru private networks like GRX by reasons of security and stability.
So if you are not part of them you can't discuss what is stupid because you know nothing about operator's infrastructure.
If we are talking seriously MMS support requires separate TCP-stack and HTTP Proxy support because most operators supports WAP 2.0 devices and WAP 2.0 Gateway is a classical HTTP proxy with some extensions.

Re: Brainstorm: MMS Support
 

Performer, the things you are describing are same we have been discussing internally already. Dirty hacks could help right now but probably will not work for all cases. Separate TCP-stack is something you can get with Linux 2.6.30+ (separate networking namespaces). Maemo 5 is on 2.6.28 baseline where networking namespaces are not available, thus all this discussing with hacks.

As you are representing an operator business, would you be able to reflect on how important MMS is to operators? I know from statistics that generally users utilize MMS at a rate about 2-4% of SMS use, which is definitely very low and being replaced by alternative options -- email, direct social services communications, etc -- over time. But how important whole MMS business to operators?

Re: Brainstorm: MMS Support
 

MMS has little part in VAS share of operations. Primary parts are GPRS Internet and SMS. By Nokia's public plans the market of Maemo 5 enabled devices is small and the target of launch series is market research. So I am not sure that operators are ready to invest in technology and changes in the modification of infrastructure.
The process of sending MMS is specific and has a number of features. In my last post, I talked about that WAP 2.0 Gateway is the HTTP Proxy with some extensions. The main extension - a recognition of the subscriber, it does not make it impossible to use public addresses.
With a large number of online subscribers, the operator uses a private address on the Internet PDP given the extremely scarce resources networks IPv4. These networks are isolated through NAT and Firewall.
Unfortunately, there is only one way to identify the subscriber in the IP-based network is to get a bunch of IP-address + MSISDN via RADIUS Accounting-Start message from the GGSN to the WAP Gateway. In turn, WAP Gateway provides MSISDN in the HTTP Header request. Thus MMSC recognizes subscriber.
Such insecure channel necessitates placement MM1 of MMSC in an isolated network. At the same time it makes no sense to install WAP Proxy on the Internet PDP because this decision will reduce the availability of Internet services for the entire subscriber base.
In other words, the operators does not make sense to change their infrastructure for one device with low sales.
For the discussed work-around I have no confidence that the solution will work fully with Vodafone NL, or any other network.
Just look at Apple. they did a full-fledged support for MMS when it is really needed and exactly when it became possible. I think we should wait Maemo 6 or new kernel with a full support of Network Namespaces.

Re: Brainstorm: MMS Support
 

Thanks for the great input, glad to see we got someone working for an operator in here to tell us how they look at it :)

While I do realise fullfledged MMS support is impossible with the current kernel, I do still have a question.
Is it possible to implement it and get it working to such a degree you would be able to receive MMS only when there is no other connection active (and then open a connection to the MMS APN)? Assuming of course we can somehow read the WAP Push messages (if they don't show up in the el.db).

Re: Brainstorm: MMS Support
 

Glad to help and some participate in the development process.
Course possible to rise the connection to the MMS PDP and work fully with it, when other connections are inactive. This solution gives assurance of no collisions. Far as I know this is exactly the path that runs Windows Mobile. But that will have to make application, expected for continuous on-line Internet connection? Telepathy in particular. I think that it is single possible way for current situation.
Now the main effort in my opinion should be given to the study receiving WAP-Push. Without this, nothing will work.

Re: Brainstorm: MMS Support
 

The MMSC of my former employer marked an user/device as MMS capable as soon as the device send an MMS on its own. Part of the MMS submit request also can be a device id (string) and a profile URL (XML file), which in turn can be used for getting device capabilities and content conversion when sending an MMS to a device.

Yes, I timeout for retrieval could be used, too.

Gruß...Tim

Re: Brainstorm: MMS Support
 

It's about 1 1/2 ago I looked at MMS/IMS integration. But I'm sure that the provider will want all the old devices out their to still work - and their definitely do not SIP. So if we assume that legacy device support will continue for 5-10 years we should not care about SIP now.

MMS for the device is TCP/IP for retrieval and PUSH (IP, SMS but possibly also SIP in future) for sending.

GRX is something that is not relevant for the device. GRX is used (as above mentioned) for inter-operator communication between providers, in the MMSC case communication between MMSC.

From the view of the device it does use SMS and IP roaming.

AFAIK there is no device lock-out. Every device that can handle the procotol should be able to do MMS.

I personally based on my work for my former employer only know the communication after WAP gateway and similar network elements and thus cannot tell you anything about APs and kernel requirements. But I can help if it comes to MMS protocol/messsage/PDU handling.

Feel free to ask.

Gruß...Tim

Re: Brainstorm: MMS Support
 

The MMS capability mark as resoult of sending initial SMS is most popular case but it's still work-around. The right way is to provision MMS subscription from CCBS. In fact this method minimizes invocations from CCBS.
It's just for information.

Re: Brainstorm: MMS Support
 

It we talking about feature development of the platform we should bear in mind. See requirements of 3GPPr6.
Just the opposite: SMS and HTTP for the reception, HTTP for the transfer. For IMS-solutions - SIP in both cases.
Course GRX and the device does not interact directly. Subject GRX mentioned in the explanation of the need to use private IP-based networks. Please read carefully.
Realy? But what you will say about MMS notification by WAP-Push indicators and MMS transmission in roaming?

For example the typical high-level use-case of MMS delivery in roaming:
1. MMSC has MMS for subscrier B. MMSC sends WAP-Push indicator by SMS to UA.
2. UA receives WAP-Push and asks subscriber to retreive MMS.
3. Subscriber accepts UA-request.
4. UA initiates PDP-context to MMS APN.
5. SGSN of guest network opens Gn tunnel thru GRX to GGSN of home network responsible for MMS APN
Now UA has IP from IP-space of home MMS pool.
6. GGSN sends the pair of MSISDN and IP to WAPGW by RADIUS Accounting-Start message.
7. UA sends HTTP-request for MMSC using message URL from WAP-Push indicator. UA uses WAPGW as proxy and open PDP-context as interface.
8. WAPGW transmits request to MMSC. WAPGW puts additional HTTP-header with MSISDN to request.
9. MMSC receives request and sends message content as response. If MMSC has content adaptation feature MMSC adapts content of the message to UA capable format using HTTP-header User-Agent form HTTP-request to determinate parameters of adaptation/transcoding.

Re: Brainstorm: MMS Support
 

Yes. OK. Why not. But put it somehwere down the roadmap, since currently it is technically not required to support this. How many MMS capable devices are out that cannot handle SIP in any way and stlll work and will work in future. For "getting MMS somehow to work" we can just do as they do. SIP based communication in an IMS network is still (mostly) future. Most important things first.

The device receives notification in the form of SMS and/or IP pushes (or other means). It sends messages and other PDU by doing HTTP POST (and not PUSH, you are right). And it retrieves message content by doing HTTP GET.

For writing an MMS client it is therefor necessary to get access to binary SMS and do not make them appear in the normal SMS inbox (useability requirement). And we must be able to get IP access to the MMSC. This was found out by other participants before.

Sorry, this was possibly lax quoting. As *you* told GRX is for inter MMSC operation. I just stated that *you* were right. But I also stated that while you are right, mentioning GRX in "MMS device support" adds no technical requiremnts for the MMS client.

What I meant is, that if we get a MMS client working that behaviour likes the specification requires we can assume that providers will not block out devices with our client installed. They may block users/SIM cards because of user belonging to foreign provicers and other reasons, but that are different stories.

Please let us not discuss about thinks that do not directly help for the next step (even if they are correct and true). The next step is above cited problems:

Getting access to the SMS and getting IP access to the MMSC.

If that is not solved everything else is not important anymore :-/ Sadly I cannot help with that. I can help writing the actual client though if it ever comes to that.

Gruß...Tim

Re: Brainstorm: MMS Support
 

Out of interest, I was wondering about the URI used to reach the MMSC
if the host component is a name, it would need to be resolved.

if multiple connections are made to different APN (or even wifi + MMS APN) split DNS would need to be taken into account. To me it would seem reasonable that the host name of the MMSC may only be resolvable when using the DNS server presented when connecting to the MMS APN.

I guess that rules out using the system resolver. I guess but it it complicates the idea of using NAT or some other IP translation and routing manipulation since multiple DNS server entries may also need to be taken into account. And the HTTP client would need to rely on custom DNS code.

Re: Brainstorm: MMS Support
 

Wouldn't it be a possible work around to just use the (before somehow found out :-/) IP adress of the MMSC instead of the hostname? This is of course not a end-user solution but could help to get past this barrier to analyse further problems and get to a proof of concept...

Gruß...Tim

Re: Brainstorm: MMS Support
 

May be you mean IP-address of WAPGW?? The resolving IP of MMSC fully implemented at WAPGW side. Most operators declares to end-users the IP address of WAPGW instead of hostname to make setting capable with old terminals which supports WAP 1.2.
In this case DNS resolving is not a problem. The main problem in my opinion is possible address-spaces collisions between MMS PDP and fo example subscriber's WLAN.

Re: Brainstorm: MMS Support
 

Thanks. When talking about kernel changes and need for networking namespaces I was talking about the device side, not an operator's side. All other comments from you still apply but it is purely an issue on the client side (Linux kernel without networking namespaces).

That's why we are talking about "hacks" which mostly directed towards overcoming this client-side limitation without kernel changes.

Re: Brainstorm: MMS Support
 

Perhaps the feature/patch can be backported to Linux kernel 2.6.28? Minimal changes, community can test, Nokia can roll out stable later.

Re: Brainstorm: MMS Support
 

Are you sure? You want to use operator's service but you want to know nothing about it. Just for your information: If Maemo would have significant market share, there would not be necessary to develop this "hack", the operators would have changed the infrastructure. Any service should be perceived as a mutually beneficial agreement.

Re: Brainstorm: MMS Support
 

I'm not sure where did you get "want to know nothing about it". I never stated it and all I was saying about "hacks" is that they are discussed for the device side to cope with insufficient support in kernel side of the N900 to handle simultaneous TCP connections to both operator's PDP and public PDP in case those networks have overlapping TCP spaces. If operators would change their infrastructure, that is fine, but reallistically any MMS implementation on client side would need to support any server-side configuration.

Re: Brainstorm: MMS Support
 

Not so easy. Even though basic network namespaces are support in Linux kernel since 2.6.24, up until 2.6.30 or so it was not stable enough and required additional patches. You can read more about networking namespaces at http://lxc.sourceforge.net/network.php

Re: Brainstorm: MMS Support
 

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.

Re: Brainstorm: MMS Support
 

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.

Re: Brainstorm: MMS Support
 

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..

Re: Brainstorm: MMS Support
 

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 ;)

Re: Brainstorm: MMS Support
 

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.

Re: Brainstorm: MMS Support
 

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..

Re: Brainstorm: MMS Support
 

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.

Re: Brainstorm: MMS Support
 

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..

Re: Brainstorm: MMS Support
 

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.

Re: Brainstorm: MMS Support
 

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!