[In development] Brainstorm: MMS Support

[frals]

I just posted a Brainstorm Idea for adding MMS Support.

Please use this thread for discussion about possible implementation options and the like and post any good solutions to the brainstorm. :)

http://maemo.org/community/brainstorm/view/mms_support/


Wiki-page: http://wiki.maemo.org/Task:MMS

[frals]

What I've found so far is two different MMSlibs, one in PHP and one in Java.

PHP: http://www.hellkvist.org/software/

Java: http://sourceforge.net/projects/mmslib/

The java option relies on a jWap class as well: http://jwap.sourceforge.net/

For testing, there's a free, open source MMS gateway downloadable at http://www.mbuni.org/downloads.shtml

I haven't had time to go through the sources and see what's really there yet, but it's a start.

[allnameswereout]

MMS Decoder (PHP) http://heyman.info/mmsdecoder.php
Messaging-MIDP (Java SE/Java ME) http://sourceforge.net/projects/freshmeat_messaging-midp/
MMSdec (C) http://projects.xplico.org/mmsdec.html <=- the one I'll try

[yerga]

python-mms: http://python-mms.sourceforge.net/

[nMIK-3]

Nokia needs to release a Maemo 5 patch with natively MMS support as soon as possible.

[frals]

EDIT: Would also need to know what the N900 does with incoming MMS, i.e. discards it since its invalid as an SMS or not. Couldn't find any documentation on this.

EDIT2: I misread, awesome! ;)

[frals]

Some discussion on IRC about it: http://wiki.maemo.org/Mms_implemention_conversation

[chemist]

Nokia needs to release a Maemo 5 patch with natively MMS support as soon as possible.

ASAP? I still know a lot of guys who never used it and never will (/me included). BTW you are in wrong topic this is brainstorm...

[RipTorn]

Would also need to know what the N900 does with incoming MMS, i.e. discards it since its invalid as an SMS or not. Couldn't find any documentation on this.

Don't most network providers accommodate for this?

I know Vodafone in Australia and a few others in Asia would detect that you didn't have an MMS phone and sms you the details on how to download the image from their website.

Again I can only speculate from my limited need and use of MMS in different 3 Country's.

[frals]

Yeah, that's how it works here as well (in .se).

What I really was thinking about when I wrote that (I think) was how to grab the incoming MMS request from the phonestack, and if the code for that is open enough for the community to modify it

[ysss]

This is a matter of PRIDE too! For all the "mms-less iphone" comments thrown out there...

[lcuk]

hi,

this morning a conversation took place in #maemo which begun to discuss the specifics of implementing MMS in the n900
I have posted the conversation onto the wiki, but it requires extensive weeding and cleanup and converting into an outline and spec

please get involved and have a go at getting rid of the extra stuff or attempt to fill in any blanks or problems.

http://wiki.maemo.org/Mms_implemention_conversation

users ab and astorm were the key guys in this discussion and it would be really good to follow up on this :)

gary

[frals]

Added a new wiki page for the problems/solutions: http://wiki.maemo.org/MMS_implementation

[benny1967]

Just to make sure I'm on the right track here:

The fact that all of this community activity is happening - does this mean Nokia clearly stated meanwhile they would not bring MMS to Maemo 5? Not now and not in a future upgrade (within a reasonable timeline, read "before Maemo 6")?

The reason I'm asking is that - from what I read so far - I was under the impression that MMS was one of the things omitted from the initial release because there was not enough time/resources to do it... and that, of course, Nokians basically acknowledge the need for it and will bring it to the platform later as an update.

Now if they'd plan to do so, they wouldn't let this community work happen without at least stating clearly that it's doubling work already ongoing within Nokia, would they? They would tell us that whatever the outcome of a community led solution is, it would always be second best compared to a fully integrated MMS-solution by Nokia.

So because now we have this thread and wiki pages and the brainstorm entry... and nobody commented along the lines of "hey, you know we're working on it, too"... may I safely assume there's a final decision within Nokia not to support MMS on M5 via a future SSU?

[frals]

I wouldn't make any such assumptions to be honest.

They way I see it, by doing this (possible) double work we show that the community is working towards a solution of this problem - and really wants the feature.

I'll keep working on this until there's an official release note of a SSU where it says its added ;) (Unless I stop, for whatever reason ;))

The situation was somewhat similar on the first iPhones - there were 3rd party apps implementing (somewhat limited from my understanding) MMS support on the phone until Apple released their official implementation of it.


In closing - either we implement it as a community, or Nokia does it with a future SSU. Regardless, I'd say we win in the end ;)

[lcuk]

I do not see a fixed line between Nokia and the community.

there was a reply today from the -dev mailing list entry I posted which indicated a nokia engineer had discussed the matter with ab (from the original irc convo) which means the right people are at the very least talking.

connections are made, the rest will happen as it does.
nobody expects miracles and instant fixes.

[x61]

Since this is an open source device, the solution to this problem will come soon... eg.
sudo apt-get install maemo-mms

[nMIK-3]

ASAP? I still know a lot of guys who never used it and never will (/me included). BTW you are in wrong topic this is brainstorm...
chemist, this is you and your needs. In the other hand I know a lot of people that are using MMS A LOT. I even know a person that is not getting the N900 just because the lack of MMS.
I know exactly the purpose of this threat. I just comment on the MMS situation, no need to create this to a VS or anything but if you have not interest on MMS as you said then you are the one in the wrong thread. Even if you never use the service is good to have it and not using it than not having it at all.

MMS and vertical operation is by far the two most important complains the N900 suffers. Knowing Nokia sooner or later they will address those issues.

[allnameswereout]

I can only speak for my own telco, Vodafone NL. It seems they have different APNs because there are different connections configured (there are 4, in fact). But that is not the case. They have the same APN name which you can see in details: live.vodafone.com with username vodafone and password vodafone. The only difference is the default homepage. For MMS, it is http://mmsc.mms.vodafone.nl so at least in my case there is no need for a seperate ppp1 please verify in your phone settings about your case. YMMV.

[frals]

I can only speak for my own telco, Vodafone NL. It seems they have different APNs because there are different connections configured (there are 4, in fact). But that is not the case. They have the same APN name which you can see in details: live.vodafone.com with username vodafone and password vodafone. The only difference is the default homepage. For MMS, it is http://mmsc.mms.vodafone.nl so at least in my case there is no need for a seperate ppp1 please verify in your phone settings about your case. YMMV.

Same here, Tele2 Sweden. Only difference between my Internet settings and the MMS is the starting page; http://mmsc.tele2.se.

EDIT: My bad, they actually use different proxyservers.
130.244.202.030 for MMS and 130.244.196.090 for GPRS

[benny1967]

nobody expects miracles and instant fixes.

maybe this is why i'm not getting it. :)

i do expect miracles and instant fixes. unlike the community developers, nokia has all the knowledge about MMS. they've implemented it over and over again. they know the theory (what's in the specs), they know what works in real life (quirks with carrier implementations - worldwide!), they have existing source code.

but it's good to read here that my above assumptions aren't valid for everyone and that people would love working on MMS just for the fun of it, no matter what Nokia does meanwhile. I must have underestimated this community... yet again. ;)

[dart45]

Same here, Tele2 Sweden. Only difference between my Internet settings and the MMS is the starting page; http://mmsc.tele2.se.

Not the same in France (as usual...). Well, for 2 operators at least they don't have the same APN. And the point is that right now, you can only define one APN in Maemo5, at least in the release I've got.

[frals]

Right - are you using a later SW version than the guy at my-symbian? If you can disclose this information of course. He seems to be using 2009.34-15 as seen here (http://my-symbian.com/other/show2.php?pic=scr67.jpg).

Otherwise we just got another obstacle to pass :)

[tso]

Some discussion on IRC about it: http://wiki.maemo.org/Mms_implemention_conversation

heh, since my isp stopped trying to count wap traffic and other net traffic separately, i had forgotten about the insanity that is gateway and apn...

[tso]

Don't most network providers accommodate for this?

I know Vodafone in Australia and a few others in Asia would detect that you didn't have an MMS phone and sms you the details on how to download the image from their website.

Again I can only speculate from my limited need and use of MMS in different 3 Country's.

quick guess here is that they send the initial special sms (some very old phones will show it in the usual sms inbox, i have seen it myself), then if its not reacted to within some timeframe, a normal sms will be sendt, pointing the user towards a telco run web page where the mms can be accessed...

[frals]

The way I understood it, the first message asks the phone what capabilities it has, but I assume there is some kind of timeout for that response as well as you said tso.

Added the problem with only one APN available in Fremantle atm to the wiki; http://wiki.maemo.org/MMS_implementation

[allnameswereout]

Given the data received from sender is merely a MIME encoded SMS pointing to URI to download message if you have the same APN all you have to do [as proof of concept] is decode the SMS and download the data from the URI. URI can be WAP 2.1 or HTTP. Then you need to decode that data. For convenience all of this must be automated for end-users, and a second PPP connection must be made only if APN are not same IOW this should be checked. I'm not sure most providers require a seperate APN. I find this a bold statement which requires a lot of recent experience with many international telcos while this might very well be a legacy statement.

If providers have a list of smartphones which supposedly support MMS then this might destroy the opportunity for community-supported MMS.

Indeed Nokia has the inside knowledge of MMS support, but those who implemented it in S60 did this long time ago and are not from Maemo dept. I think if Nokia would do it then need to implement full WAP because sometimes WAP is required instead of HTTP and they can't implement a half-working WAP since they have to respect standards. If community supports MMS it may or may not work completely, and it may or may not completely respect respect standards but if Nokia does it they have to completely respect standards.

The whole Brainstorm entry is about whether Nokia or community would do it, but I don't think this proposition is the only question to be asked. IMO the question should be where the priority of minimal support lies to make most users be able to use Nokia N900 as their phone. My answer to that is: a community project to provide support to receive and read a MMS. As quickly as possible. If 5% of providers need seperate APN I don't find such support very important, while if 95% of providers need seperate APN I do find that important. Also, is it possible to embed MicroB? Then you could use the WAP plugin to download the MMS.

[bob77]

Would sending MMS not be the biggest priority? Most telco send a txt msg with a link to a web page where an MMS picture can be viewed/downloaded. This is a simple task on a phone with a high quality browser such as the N900.

However on a dumb phone with little or no browser viewing an email isnt possible whereas MMS msgs work well. So would the main use case for MMS msgs not be sending pictures to dumb phones or people who dont check email/social networking sites often/not at all?

Just my 2c.

[dart45]

Added the problem with only one APN available in Fremantle atm to the wiki; http://wiki.maemo.org/MMS_implementation

Just to clarify the "only one APN problem": nothing forbids the MMS application to open its own apn. It's a simple AT command to initialize the modem. However, I haven't tested if the N900 can open 2 PDP contexts at the same time.
If this is not the case, it means you cannot retrieve the MMS while already connected to the internet (as long as you need to use 2 separate apns).

[tso]

and that sounds to me what the nokia people where talking about, that the kernel could not handle multiple connections at the same time, or something...

[romanianusa]

I don't know what's the big deal and why it's so hard to have MMS on a phone. My sorry 5 yrs old phone even got an MMS!! So when i heard story that iPhone doesn't have MMS for yrs and N900 doesn't have MMS....man that is rediculous.

[sjgadsby]

I don't know what's the big deal and why it's so hard to have MMS on a phone. My sorry 5 yrs old phone even got an MMS!

Fifteen years ago, my desktop computer could transmit Morse code over a phone line. ATD;-.-./--.--H0 Somehow, that feature is hard to find in computers today.

More seriously, Wireless Application Protocol (WAP) is the problem. MMS support requires WAP support.

Older phones (and new phones that run operating systems with some history in the mobile space) support WAP because once upon a time, WAP + Wireless Markup Language (WML) were the Big Things that were going to bring the web to small screens on underpowered mobile devices. Mobiles had to support it. It was unlocking the web. It was the future!

Then web developers, by and large, skipped making their sites available in WML because doing so was a pain. Meanwhile, the screens and processors on mobile devices both continued to improve, and bringing real web browsers that could use the real web to mobile devices became the new Big Thing.

Mobile operating systems that lived through the time when WAP was king kept it around afterward, of course. However, iPhone OS and Maemo came later.

In both cases, the development teams had to decide which features were important enough to warrant the investment of limited resources--time, money, and talent--during that hectic rush to meet deadlines. In both cases, legacy technologies such as WAP, now with limited use, didn't make the cut.

Thankfully, the Maemo community is already working out what will be necessary to add WAP and MMS support to Maemo 5 though, so barring any towering, unforeseen barriers, you shouldn't be without MMS on your N900 for long.

[allnameswereout]

and that sounds to me what the nokia people where talking about, that the kernel could not handle multiple connections at the same time, or something...The Linux kernel can handle 2 PPP interfaces just fine :confused: Do you have a link to this discussion you're referring to?

[tso]

The Linux kernel can handle 2 PPP interfaces just fine :confused: Do you have a link to this discussion you're referring to?
i think it showed up in one of the massive N900 threads that spawned when the "bomb" dropped right before nokia world...

[sjgadsby]

My pet theory on the "no-MMS on the N900 is due to a Linux kernel issue" meme:

A recent batch of Memory Management Subsystem commits leads someone to comment that MMS in Linux OMAP is seeing drastic improvements just in time for Maemo 5. Someone else with a less kernel-oriented mindset misunderstands that "MMS" to be Multimedia Messaging Service, and away we go.

[daperl]

For translating a client application to C, I would start here: Android MMS App (http://android.git.kernel.org/?p=platform/packages/apps/Mms.git;a=summary)

If changes are needed in the kernel, I would do some Fremantle kernel diffs

here: Android kernel OMAP (http://android.git.kernel.org/?p=kernel/omap.git;a=summary)

and here: Android kernel common (http://android.git.kernel.org/?p=kernel/common.git;a=summary)

I'm assuming of course that MMS works on Android phones. And if MMS has worked on Android phones from the beginning, the information needed should be somewhere in these Android projects (http://android.git.kernel.org/).

[lma]

The Linux kernel can handle 2 PPP interfaces just fine

It can, but routing and DNS are going to be "interesting".

[frals]

For translating a client application to C, I would start here: Android MMS App (http://android.git.kernel.org/?p=platform/packages/apps/Mms.git;a=summary)

If changes are needed in the kernel, I would do some Fremantle kernel diffs

here: Android kernel OMAP (http://android.git.kernel.org/?p=kernel/omap.git;a=summary)

and here: Android kernel common (http://android.git.kernel.org/?p=kernel/common.git;a=summary)

I'm assuming of course that MMS works on Android phones. And if MMS has worked on Android phones from the beginning, the information needed should be somewhere in these Android projects (http://android.git.kernel.org/).

Nice stuff!

EDIT: Finding stuff now.
The MMS pdu's are at http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=core/java/com/google/android/mms/pdu;h=c0c2a77bd8abc7cb861fdb4a49961c23dba24d2d;hb= HEAD
Context packages are at http://android.git.kernel.org/?p=platform/frameworks/base.git;a=tree;f=core/java/android/content;h=0863793db3823f4ff69124a1a66b5b8596297ab6 ;hb=HEAD

EDIT2: It seems they do all MMS send/recv over HTTP - or did I miss some vital part?

[frals]

The wiki has been updated some.


If someone got the time, please extract the knowledge from http://mg.pov.lt/maemo-irclog/%23maemo.2009-10-03.log.html#t2009-10-03T16:23:59 and add it to http://wiki.maemo.org/Mms_implemention_conversation for future reference, thank you! :)

[marcinw]

I added info about another MMS decoder implementation (C++) into http://wiki.maemo.org/MMS_implementation. This one can be compiled in standard Debian and some other systems. If you need help in understanding it/understanding decoding MMS files at all/sending MMS push over SMS, I can help a little - please contact me only.

[frals]

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

[allnameswereout]

It can, but routing and DNS are going to be "interesting".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.

[frals]

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.

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

[frals]

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

[yerga]

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

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

[frals]

Cool, thanks! :)

Just realised there's a talk on telepathy and how it's used for SMS (http://wiki.maemo.org/Maemo_Summit_2009/Schedule/Day_3#Telepathy_on_Maemo) 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. :)

[frals]

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?

[frals]

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.

[mohannad]

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.

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)

[frals]

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

[Performer]

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.

[allnameswereout]

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?

All that all of you talking about implementation MMS support is dirty hack.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.

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

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

[Performer]

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 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/cdmaseminar/2003_Tech_Forum/Qualcomm.pdf
Current specs also supports BCAST.
You can find all specs here (http://member.openmobilealliance.org/ftp/public_documents/mwg/MMS/).


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.


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 (http://en.wikipedia.org/wiki/GPRS_Roaming_Exchange) 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.

[abbra]

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?

[Performer]

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?

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.

[frals]

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

[Performer]

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

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.

[Framstag]

The way I understood it, the first message asks the phone what capabilities it has, but I assume there is some kind of timeout for that response as well as you said tso.


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

[Framstag]

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

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 (http://en.wikipedia.org/wiki/GPRS_Roaming_Exchange) by reasons of security and stability.


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

[Performer]

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

[Performer]

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.
It we talking about feature development of the platform we should bear in mind. See requirements of 3GPPr6.

MMS for the device is TCP/IP for retrieval and PUSH (IP, SMS but possibly also SIP in future) for sending.
Just the opposite: SMS and HTTP for the reception, HTTP for the transfer. For IMS-solutions - SIP in both cases.

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.

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.

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.

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.

[Framstag]

It we talking about feature development of the platform we should bear in mind. See requirements of 3GPPr6.


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.

Just the opposite: SMS and HTTP for the reception, HTTP for the transfer. For IMS-solutions - SIP in both cases.


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.

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.


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.

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:
[...]

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

[cpitchford]

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.

[Framstag]

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

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

[Performer]

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

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.

[abbra]

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.

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.

[allnameswereout]

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.Perhaps the feature/patch can be backported to Linux kernel 2.6.28? Minimal changes, community can test, Nokia can roll out stable later.

[Performer]

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.

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.

[abbra]

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.

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.

[abbra]

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

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

[redenisc]

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.

[Performer]

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.

[cpitchford]

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

[cpitchford]

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

[allnameswereout]

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 (http://wiki.maemo.org/MMS_implementation#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.

[cpitchford]

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

[allnameswereout]

hIPv6 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!Are there any phones which use IPv6 native? AFAIK not. Anyway...

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

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

in your example, what if the mmsc is 192.168.1.1?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.

What if it clashes with a local wlan address?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.

what if the mmsc has the same IP address as wlan0?Bring wlan0 temporarily down.

what if the ppp interface obtains an IP address that matches a local wlan IP or host?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.

Overlaps are very bad.. I think this idea might solve many overlap problems.. Collisions happen, simple as that. There is always a chance they happen when you play with privately assigned IPv4 over several interfaces.

If we use the ipt_ROUTE module, we can direct traffic out of specific interface based on ipt matching.. which is fairly good..Well right now we use dev option in route:

[...]

dev If force the route to be associated with the specified device, as the kernel will otherwise try to determine the device on its own (by checking already existing routes and device specifications, and where the route is added to). In most normal networks you won't need this.

[...]Which will work in almost all cases.

The vital thing here is to avoid clashes and since home networks use rfc1918 and operators use rfc1918 the chances are real.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.

[cpitchford]

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

[allnameswereout]

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.

[cpitchford]

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!

[allnameswereout]

OK, I have policy routing working. Although I use Linux kernel 2.6.31 on x86-64 and am using policy routing on 2 interfaces: 1 WLAN (to DSL) 1 PPP (to Bluetooth DUN to GPRS).

secret_ip is the box I'm connecting to (could be the MMSC), and secret_host is its hostname (irrelevant though).

$ sudo vconfig add lo
Added VLAN with VID == 0 to IF -:lo:-

$ sudo ip addr ls dev vlan0
17: vlan0@lo: <LOOPBACK> mtu 16436 qdisc noop state DOWN
link/ether 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 10.0.0.1/32 scope global vlan0

$ sudo ip route ls
10.6.6.6 dev ppp0 proto kernel scope link src 10.15.96.83
192.168.178.0/24 dev wlan3 proto kernel scope link src 192.168.178.33
169.254.0.0/16 dev wlan3 scope link metric 1000
default via 192.168.178.1 dev wlan3 proto static

$ grep voda /etc/iproute2/rt_tables
200 voda

$ sudo ip rule ls
0: from all lookup local
32765: from 10.0.0.1 to secret_ip lookup voda
32766: from all lookup main
32767: from all lookup default

$ sudo ip route ls table voda
default via 10.6.6.6 dev ppp0

$ sudo iptables -L POSTROUTING -t nat -n
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 10.0.0.1 0.0.0.0/0 to:10.15.96.83

$ sudo ip route get secret_ip from 10.0.0.1
secret_ip from 10.0.0.1 via 10.6.6.6 dev ppp0
cache mtu 1500 advmss 1460 hoplimit 64

$ sudo ip route get secret_ip from any
secret_ip via 192.168.178.1 dev wlan3 src 192.168.178.33
cache mtu 1500 advmss 1460 hoplimit 64

$ sudo ping -c 8 -I 10.0.0.1 secret_ip
PING secret_host (secret_ip) from 10.0.0.1 : 56(84) bytes of data.
64 bytes from secret_host (secret_ip): icmp_seq=1 ttl=47 time=2241 ms
64 bytes from secret_host (secret_ip): icmp_seq=2 ttl=47 time=1269 ms
64 bytes from secret_host (secret_ip): icmp_seq=3 ttl=47 time=270 ms
64 bytes from secret_host (secret_ip): icmp_seq=4 ttl=47 time=176 ms
64 bytes from secret_host (secret_ip): icmp_seq=5 ttl=47 time=225 ms
64 bytes from secret_host (secret_ip): icmp_seq=6 ttl=47 time=207 ms
64 bytes from secret_host (secret_ip): icmp_seq=7 ttl=47 time=212 ms
64 bytes from secret_host (secret_ip): icmp_seq=8 ttl=47 time=224 ms

--- secret_host ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7009ms
rtt min/avg/max/mdev = 176.667/603.478/2241.316/708.549 ms, pipe 3

$ sudo ping -c 8 secret_ip
PING secret_host (secret_ip) 56(84) bytes of data.
64 bytes from secret_host (secret_ip): icmp_seq=1 ttl=57 time=14.0 ms
64 bytes from secret_host (secret_ip): icmp_seq=2 ttl=57 time=13.8 ms
64 bytes from secret_host (secret_ip): icmp_seq=3 ttl=57 time=13.6 ms
64 bytes from secret_host (secret_ip): icmp_seq=4 ttl=57 time=13.2 ms
64 bytes from secret_host (secret_ip): icmp_seq=5 ttl=57 time=13.7 ms
64 bytes from secret_host (secret_ip): icmp_seq=6 ttl=57 time=13.3 ms
64 bytes from secret_host (secret_ip): icmp_seq=7 ttl=57 time=14.5 ms
64 bytes from secret_host (secret_ip): icmp_seq=8 ttl=57 time=13.6 ms

--- secret_host ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7010ms
rtt min/avg/max/mdev = 13.260/13.761/14.504/0.386 ms

$ ssh -b 10.0.0.1 secret_ip
[..]

$ ssh secret_ip
[..]

$ sudo ping -c 8 -I 10.0.0.1 talk.maemo.org
PING forums.internettablettalk.com (74.86.202.247) from 10.0.0.1 : 56(84) bytes of data.

--- forums.internettablettalk.com ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7008ms

$ sudo ping -c 8 talk.maemo.org
PING forums.internettablettalk.com (74.86.202.247) 56(84) bytes of data.
64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=1 ttl=53 time=134 ms
64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=2 ttl=53 time=133 ms
64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=3 ttl=53 time=133 ms
64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=4 ttl=53 time=133 ms
64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=5 ttl=53 time=136 ms
64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=6 ttl=53 time=133 ms
64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=7 ttl=53 time=133 ms
64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=8 ttl=53 time=133 ms

--- forums.internettablettalk.com ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7009ms
rtt min/avg/max/mdev = 133.269/133.879/136.043/0.981 ms
jfdh@entheogen:~$ sudo ping -c 8 -I 10.0.0.1 talk.maemo.org
PING forums.internettablettalk.com (74.86.202.247) from 10.0.0.1 : 56(84) bytes of data.

--- forums.internettablettalk.com ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7008msAll thanks to this great howto! (http://lartc.org/howto/lartc.rpdb.html#LARTC.RPDB.SIMPLE)

I'll use this with OpenVPN and will then play with -m owner. I'll try to get rid of using eth0 (because N900 doesn't have). This setup is on Linux 2.6.31 x86-64.

[allnameswereout]

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.I've done a lot of reading and testing and have come to the conclusion you're right. This means the removal of ipt_ROUTE was wrong.

Also found another alternative: RAW?NAT (xt_RAWDNAT & xt_RAWSNAT). It is also ugly though. Here is an example:

$ host -t a talk.maemo.org
talk.maemo.org is an alias for forums.internettablettalk.com.
forums.internettablettalk.com has address 74.86.202.247

$ ip route get 74.86.202.247
74.86.202.247 via 192.168.178.1 dev wlan3 src 192.168.178.33
cache mtu 1500 advmss 1460 hoplimit 64
$ sudo ping -c 3 74.86.202.247
PING 74.86.202.247 (74.86.202.247) 56(84) bytes of data.
64 bytes from 74.86.202.247: icmp_seq=1 ttl=53 time=141 ms
64 bytes from 74.86.202.247: icmp_seq=2 ttl=53 time=138 ms
64 bytes from 74.86.202.247: icmp_seq=3 ttl=53 time=134 ms

$ sudo ifconfig wlan3:0 74.86.202.247 netmask 255.255.255.255
$ ip route get 74.86.202.247
local 74.86.202.247 dev lo src 74.86.202.247
cache <local> mtu 16436 advmss 16396 hoplimit 64
$ sudo ping -c 3 74.86.202.247
PING 74.86.202.247 (74.86.202.247) 56(84) bytes of data.
64 bytes from 74.86.202.247: icmp_seq=1 ttl=64 time=0.093 ms
64 bytes from 74.86.202.247: icmp_seq=2 ttl=64 time=0.073 ms
64 bytes from 74.86.202.247: icmp_seq=3 ttl=64 time=0.073 ms

$ ip addr ls ppp0
7: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
inet 10.67.147.187 peer 10.6.6.6/32 scope global ppp0
$ sudo route add -host 10.67.147.188 gw 10.6.6.6
$ ip route ls dev ppp0
10.67.147.188 via 10.6.6.6
10.6.6.6 proto kernel scope link src 10.67.147.187

$ sudo iptables -F -t raw ; sudo iptables -F -t rawpost ; sudo iptables -F -t nat ; sudo iptables -F -t mangle ; sudo iptables -F
$ sudo iptables -t raw -A PREROUTING -i ppp0 -s 74.86.202.247 -j RAWSNAT --to-source 10.67.147.188
$ sudo iptables -t raw -A OUTPUT -d 10.67.147.188 -j RAWDNAT --to-destination 74.86.202.247

$ ip route get 74.86.202.247
local 74.86.202.247 dev lo src 74.86.202.247
cache <local> mtu 16436 advmss 16396 hoplimit 64
$ sudo ping -c 3 74.86.202.247
PING 74.86.202.247 (74.86.202.247) 56(84) bytes of data.
64 bytes from 74.86.202.247: icmp_seq=1 ttl=64 time=0.090 ms
64 bytes from 74.86.202.247: icmp_seq=2 ttl=64 time=0.070 ms
64 bytes from 74.86.202.247: icmp_seq=3 ttl=64 time=0.077 ms

$ ip route get 10.67.147.188
10.67.147.188 via 10.6.6.6 dev ppp0 src 10.67.147.187
cache mtu 1500 advmss 1460 hoplimit 64
$ sudo ping -c 3 10.67.147.188
PING 10.67.147.188 (10.67.147.188) 56(84) bytes of data.
64 bytes from 10.67.147.188: icmp_seq=1 ttl=42 time=403 ms
64 bytes from 10.67.147.188: icmp_seq=2 ttl=42 time=452 ms
64 bytes from 10.67.147.188: icmp_seq=3 ttl=42 time=431 ms

$ sudo -s
# echo 10.67.147.188 talk.maemo.org >> /etc/hosts
# exit
$ grep hosts /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
$ lynx -source talk.maemo.org | grep "meta name"
<meta name="generator" content="vBulletin 3.8.2" />
<meta name="keywords" content="internet tablet, nokia 770, nokia, 770, n800, n810, n900, maemo, maemo.org, linux, wifi, bluetooth" />
<meta name="description" content="talk.maemo.org" />Using -t rawpost and -A POSTROUTING instead of -t raw -A OUTPUT did not make any difference for me.

This works even if you use your ppp0 IPv4 endpoint (but if IPv4 address exists local then it will not work if local IPv4 address already exists. Then you must use ip to add the route because route will give error SIOCADDRT: No such process maybe this can be overriden. If IPv4 address is added to local afterwards it won't matter.).

The only conflict is when ppp0's local IPv4 conflicts with something. If this is something local it won't matter. If its something remote it won't matter either (for us, that is) except it won't be reachable anymore. We could apply the same trick above (or -j ROUTE) as fix, but then on ppp0 and with an ISNOT statement on -m owner.

You provided an example (about tunnel endpoint) but tunnel endpoint is never reachable on PPP; you cannot ping it or access it.

You also forgot to specify -A, you put a space between -- and gw. Hence, what you intended to state was:

iptables -t mangle -A OUTPUT \
-m owner ! --uid-owner mms-service \
-j ROUTE --gw $my_default_gw --oif $my_internet_ifHowever you don't know for sure intended gw is default_gw. Given ppp0 and ppp1 is from same provider its more likely to conflict with wlan0 which may or may not be connected to Internet.

I don't think this rule would match tho. Remember PPP is tunnel between 2 addresses. Example:

$ ip route ls dev ppp0
10.6.6.6 proto kernel scope link src 10.66.15.69

If the source is not ppp_local_IPv4 then it won't fly over ppp0, and given only owner of MMS service will be routed and _nothing_ else it will work

All that said I don't see any advantage from -j RAW?NAT solution over -j ROUTE except that RAW?NAT is not experimental and is part of xtables.

Personally, I prefer your solution, and I'm sad -j ROUTE is deprecated because its clear it has its use.

[...]

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.. xtables are target extensions.

I'm doing exact opposite as you do: hitting after routing (output), and before routing (input).

BTW,

iptables -t nat -A POSTROUTING -d $remote_mmsc \
-m owner --uid-owner mms-service \
-j SNAT --to-source $my_local_mms_ipAlthough PPP script knows the $my_local_mms_ip if --to-source is dynamic hence one should use -j MASQUERADE so it'd become

iptables -t nat -A POSTROUTING -d $remote_mmsc \
-m owner --uid-owner mms-service \
-j MASQUERADE

[cpitchford]

I'm disappointed iproute doesn't do it.. its so powerful.. close, but not cigar!

It turns out you could almost do it with policy routing if you moved the ppp / wlan interface definitions from table 255 (local) or inserted a rule with priority -1.. either way it just won't let you do it.. and frankly what we'd like to achieve is a bit counter-intuitive.. so I can't really blame it :)

As for the ipt_route code, it is actually really very simple. It wasn't dropped for reliability problems, it was dropped because iproute2 should be used instead.. and I agree.. however, what we want is REALLY out of the ordinary..

What I propose is porting ipt_ROUTE to xtables module. I think this is trivial and should take an afternoon.

Plus side
no kernel changes
iptables will work with the new module without a recomile (I think)
it is a single, small module

down sides:
It *is* a module
It *IS* a unsupported kernel module!
It *IS* an unsupported kernel module that is unlikely to make it back into the kernel as namespaces would probably be the way forward :P

If I can clean up the code and get a copy running on my N810 some time today (ARM testing first) there is one more thing to think about..

When ppp0 is brought up, it can either obtain local peer IPs automatically, OR they can be set manually.. what would be great is if they could be set manually.. but.. report what the remote end wanted them to be set too..

This means we can use that information to create/customise NAT rules.. and we can hard code our interface to non-clashing addresses. I'll look at that too..

You've raised some great points.. and its the weekend and I enjoy a good challenge! :)

I'm going to throw about some VMs and see if I can make something work..


MMSC --- RTR --- [PPP0 DEV WLAN0] --- WIFI --- HOST

Each is an IP and I'm hoping I can make any on the left match with any on the right and it'll all keep working.. I'll get to work

[cpitchford]

More working.. pppd doesn't as it stands offer a way of obtaining the allocated local and peer IP address without setting the ppp interface. This means ppp0 could be set to a clashing IP addresss the moment a link is established between the device and the apn..

Even if pppX is down, the fact the local address has been defined could screw up a wlan connection. For example.. if wlan0 is talking to 192.168.1.200, then ppp0 is started and receives a local address 192.168.1.200, even if ppp0 is never brought "up", the clash still takes effect and the established connection to 192.168.1.200 will fail.

This creates a race condition..

Also, the TEE module is a pain. 2 problems.

First, it insists on directing the duplicate to a gateway. This is unnecessary with PPP. The packet only needs to be sent to the ppp interface, there is no gateway involved. ip route add default dev ppp0 is completely valid. Second, it is not possible to drop the duplicate packet reliably. This is something the ipt_ROUTE module does do..

So.. where am I now..

I'm trying to create an xtable version of IPT_ROUTE.. that's coming on nicely :)

I've created a couple of scripts that will tie into PPPD. First is /etc/ppp/ip-pre-up . This script is run when pppX is configured, but before it is brought up. The problem is, it has its local and remote IP address defined, things would be great if ppp0 was left unconfigured.. but there you go.. I can work on that..

It uses the ipparam option to PPPD to pass the MMSC IP address into the script.. ipparam "mmsapn-1.2.3.4" for example.

It then brings up some policy routing and the IP tables rules to do the mangling..

Without a patch to pppd, I'm not sure it is possible to leave ppp0 unconfigured whilst still using ipcp to negotiate what they should be. This could be tricky..

Preliminary work is available at http://mms.fixitfixitfixit.com/mms-20091025.tar.bz2

[allnameswereout]

It turns out you could almost do it with policy routing if you moved the ppp / wlan interface definitions from table 255 (local) or inserted a rule with priority -1.. either way it just won't let you do it.. and frankly what we'd like to achieve is a bit counter-intuitive.. so I can't really blame it
At startup time the kernel configures the default RPDB consisting of three rules:

1. Priority: 0, Selector: match anything, Action: lookup routing table local (ID 255). The local table is a special routing table containing
high priority control routes for local and broadcast addresses.

Rule 0 is special. It cannot be deleted or overridden.

2. Priority: 32766, Selector: match anything, Action: lookup routing table main (ID 254). The main table is the normal routing table contain‐
ing all non-policy routes. This rule may be deleted and/or overridden with other ones by the administrator.

3. Priority: 32767, Selector: match anything, Action: lookup routing table default (ID 253). The default table is empty. It is reserved for
some post-processing if no previous default rules selected the packet. This rule may also be deleted.
There should be a way to override this ;)

I wonder, PPP0 lies inbetween PPP1 and lo/wlan0/etc. So the tunnel PPP1 is isolated inbetween MMS APN and PPP0. If you stop the stuff at PPP0 already, it should work. Maybe it is possible to make PPP1's local endpoint non-local. This is something which one can do on VLANs (making them actually global, giving them ethernet address, etc).

More working.. pppd doesn't as it stands offer a way of obtaining the allocated local and peer IP address without setting the ppp interface. This means ppp0 could be set to a clashing IP addresss the moment a link is established between the device and the apn..

Even if pppX is down, the fact the local address has been defined could screw up a wlan connection. For example.. if wlan0 is talking to 192.168.1.200, then ppp0 is started and receives a local address 192.168.1.200, even if ppp0 is never brought "up", the clash still takes effect and the established connection to 192.168.1.200 will fail.This is normal/correct behaviour. This would happen too on other interfaces like eth0 and wlan0.

I've created a couple of scripts that will tie into PPPD. First is /etc/ppp/ip-pre-up . This script is run when pppX is configured, but before it is brought up.Here is where you put your ISNOT -m mms-service -j ROUTE wlan0, or use RAWSNAT/RAWDNAT. If -j ROUTE works when there is local IPv4 on wlan0 which is required to be used somewhere on ppp0 then why would it not work the other way around?

Even if ROUTE not work, for UDP or IMCP this would make no problem (assuming RAW*NAT works). For TCP, a timeout should not immediately occur, but probably the state is lost if using RAW*NAT, because the packets need a new source IPv4 which is routed to default_gw on wlan0. This triggered local on the fly.

PS: Have you taken a look at /usr/src/linux/Documentation/networking/ip-sysctl.txt ? I find ip_nonlocal_bind and ip_dynaddr interesting options.

[cpitchford]

Fixed link to snapshot.. DNS error.. :
http://mms-maemo.fixitfixitfixit.com/mms-20091025.tar.bz2

Back to the point..

The problem with negative routing (if NOT mms, then route wlan0) is what happens if wlan0 is missing or wlan0 goes down and comes back up as pppX..

The script I've tested (vmware x86) which plugs into pppd's ip-pre-up doesn't touch any current config. By this, I mean it doesn't redirect stuff to the current internet connection, because that connection may not be there yet, or worse still.. may change!

All the ip policy rules/routes only apply to MMS traffic.. If you remove them, you're left with the default system.. This means an internet connection can be started and changed whilst connection to the APN is active.. I don't think it is safe to have a rule like "redirect non mms traffic to wlan0" because that might change to ppp1, or maybe wlan0 again.. or it might disappear

That is a key thing here.. if we never have to add a rule (ip or iptables) that says "if not-mms do the default action" then we don't need to worry if the default connection comes up, changes or goes down.. otherwise we'd have to add new / different rules if the internet connection changes..

To solve the local down interface clash (where ppp0 has an IP address that clashes with a remote connection) was a simple patch to PPPD.

PPPD allows you to set the local and remote IP address. It also allows you to use ipcp to negotiate a local and/or remote address with the remote system. An option exists to allow the specified local/remote address to be used if one can't be negotiated.. What we want is a hybrid. We want to negotiate a local and remote IP addresses BUT apply local-127 addresses to ppp0. This patch should be dead simple. An alternative pppd binary could be used just for MMS connections to keep it separate, but it is a possibility..

This way, we get to know the local and remote pppd addresses BUT they will absolutely never clash with a local or remote address!

With this patch in place, the script should work quite well. It also won't interfere OR reference any other internet connection (wlan0 or other pppX interface or default route) it is totally separate.

This is a super mega cludge.. but the foot print is remarkably small for what we're trying to do.. an alternative pppd (may only be used for mms), an almost custom kernel module to force local address routing to an interface (which is the only thing iproute2 can't really do) and a script to initialise the firewall and ip policy routing..

I think we're getting close to something work-able.. but this type of thing is really bending the rules..

So, things I would like to get finished:

1) xt_route.. test, test, document and test.. I'd like to submit upstream stating that it could be used to redirect local addresses
2) pppd from the maemo source, patch to negotiate IP but apply hard coded values

I think, with those two items sorted, this might work..

I'll have a look at the ip sysctl stuff too, there is always neat stuff in there! The ip_nonlocal_bind is very neat! though it comes with a warning :)

[cpitchford]

Hmmm.. pppd not open in fremantle? That sucks (wish it was GPL rather than BSD).. but I suppose that's to allow it to operate with phonet or some such.. Ok, might need to think a bit harder about this..

mind you.. maybe they'd be willing to produce a one-off pppd binary with a patch applied.. especially if the patch was hard coded to disable address setting, rather than making it configurable..

sigh..

[frals]

WAP Push message handling is handled by a daemon, to take control of this one is required to register itself via a D-BUS API - this API is not final yet but if you want to play with it, I have the alpha version and can send it to you. :)

[cpitchford]

I'd be interested (particularly after I got my hands on an N900 today.. hmm.. nice.. pitty there is no ALS/line-2 support.. booo Nokia!!!)

I have a working ppp patch that meets my requirements, and a working iptables module.. All this to allow a PPP interface to overlap with another interface.. grrr

The WAP push stuff isn't actually that important from my perspective.. the most important bit for is to allow a connection to be made to the MMS APN with compromising any existing connections (be they PPP or WiFi) it works in a lab situation with a special iptables module AND a patch to pppd.. but the pppd in maemo looks like it is closed source.. so there is a SLIM chance it would clash and cause a service disruption.. slim chance, but a real chance.. and that imho is unacceptable .. If you're going to use a nasty hack, it has to at least work properly :)

[allnameswereout]

The problem with negative routing (if NOT mms, then route wlan0) is what happens if wlan0 is missing or wlan0 goes down and comes back up as pppX..Yeah then we work with something akin to CNAME.

All the ip policy rules/routes only apply to MMS traffic.. If you remove them, you're left with the default system.. This means an internet connection can be started and changed whilst connection to the APN is active.. I don't think it is safe to have a rule like "redirect non mms traffic to wlan0" because that might change to ppp1, or maybe wlan0 again.. or it might disappearGood point, then it should just care about the routes. It won't change to ppp1 btw. ppp0 is always the 3G connection because of /etc/udev/rules.d/70-persistent-net.rules but its much more cleaner to solve problem in PPPd IMO...

2) pppd from the maemo source, patch to negotiate IP but apply hard coded valuesPerhaps you can ask Nokia to provide a binary with your patch included? If it is a simple patch, a binary patch may be suitable.

[Cherrypie]

Ok first of all, I never really used MMS, maybe once or twice for testing, when we had no email and 3g internet on mobile phones (good ol' days, ye).

But seriously, if the majority of the community really needs this feature, (what I heavily doubt) it should be implemented by Nokia nativly. An additional MMS app is crap & you all know that. =p

[cpitchford]

in the good ol' days phones didn't have 3g, colour screens (never mind touch screens) or phones with installable applications and (further back) used analog signaling and (further back) were wired into walls..

That doesn't detract from the need to implement this feature.

MMS has significant usage. Nokia have probably dropped the ball a bit with ommiting this feature.. (compare it to video 3g calls and I think it is safe to say MMS is required) Most importantly operators charge loads of cash for MMS messages.. so failing to support it will "cost them money" on this device..

Anywho.. poking around the Message stuff, I'd like to implement MMS as a service, not an application. I was looking at converting MMS messages into HTML and storing them as openable objects in the message database.. render them with the browser perhaps.. dunno.. but I appeciate your "additional app is crap" but the front end is actually only half the struggle..

Besides, it is a hackable platform.. I'm looking forward to having a go even if I know Nokia will only release a firmware update next year or some such that makes it all a bit pointless!

[jjx]

All these clever hacks to prevent IP address clashes - or at least stop them from being a problem.... I've done similar things myself on other devices - which need to connect to a wired and wireless network at the same time, with each network having it's own independent DHCP.

So what does the N900 do when you're on a WLAN, 3G, or Bluetooth PAN at the same time?

That can clash too. Easily: I've had 192.168.x.y addresses assigned when connected over 3G on other phones. The same ranges are often used for WLANs, and on PANs (I mean for local file transfer among Bluetooth devices, not providing an uplink).

That must have been solved somehow. How's it done, and why can't the MMS gateway use the same method?

Please don't tell me you can only have one of WLAN, 3G or PAN running at once!

[abbra]

Default connectivity setup indeed supports only one access point working out of defined ones. So this problem of WLAN, 3G, or Bluetooth PAN at the same time is not existing for standard N900 setup.

[cpitchford]

If I remember correctly, the device uses icd2 for managing its internet connection. An application requests internet access via dbus and icd2 brings a connection up according to what is available.. however, it supports only one connection.

This is a bit different to Symbian's approach and eventually, to support MMS, I guess icd might need to support multiple connections.. (bring up the MMS connection, bring up a VoIP connection, bring up the internet) but currently that's not possible..

I could be wrong.. I'm eager to get one of these devices so I can try out some techniques, but being in the UK it's all a bit hit and miss at the moment :(

[TheJesus]

First off, I lack alot of coding skills as I have had about a year of class in Java (I don't like it, but whatever), so I can only provide text to coding ideas. Something I just thought of a couple minutes ago, not sure how well it will run (if it will :P )

You're gonna have to follow my rough outline of how the messages will travel (feel free to explain any shortcomings of this).

A few programs that will make it run: Web Server run locally (pretty sure I saw it on the extras-devel depository), MMS program that processes the messages and turns them into plain .jpg/jpeg files to run on the web server, and alot of clever coding.

1.Original Phone: Sends MMS to destination phone number.
2.Destination Phone: Identifies it is not SMS, sends to local web server MMS program.
3.MMS Program: Takes MMS, converts to Jpg/Jpeg, sends report to messaging (not sure how yet, maybe a notification or SMS?).
4.Destination Phone: Opens web browser to local server to image folder or file manager to images or just straight to Images app (could be used instead of notification, just open Images app).

Now to do that in reverse, I have no idea :\

Anyone?

EDIT: By the way, I presume that you can steal the SMS/MMS incoming messages (hopefully they aren't just discarded).

[frals]

You can cut the webserver part out as I said on irc earlier today. ;)



Progress report on my efforts: Am now receiving MMS (as long as the WAP Push is over SMS, haven't tried IP as it seems I'm only getting SMS Push) - gets the MMS from the mmsc as long as there is no other connection open. Otherwise the SMS Push is saved so you can get the MMS whenever (as long as it's still on the server I guess).

No integration with conversations or whatever, basically just a proof-of-concept sort-of hack. Have to clean up the code and make sure the python mms lib I use got a decent license before posting

[RevdKathy]

Saw you tweet this. Wow! just... Wow!

[pretty]

bleh took me time to figure that u cant register with the upright register button to speak there... but im here...

Ok so basicly,
from what i read, we have 2 kind of solution writen there,
Both are push to mail like (one is getting the info itself, second respond to sms by getting the info)

So both should be background task running,

1st one should check like 30min all that will be needed is to taskmanage this,
(guys u dont need MMS more than once a day so 30min sounds good and no power hungry) could even add a small synchronise now button (say with battery ones)

The other one is going to run also in background but dont have to synchronise time based, the only PB i see there is that we have some provider that are quite lazy at sending the SMS... (mean i heard about 2 days...) but fact is there whatever is the way... u still get ur MMS.

[frals]

Progress update: Just sent myself an MMS from the N900, it arrived but I *think* it's a bit borked as my decoder failed... It did send something at least! :)

Note: This has only been tested on my specific setup, no idea how it works on any other setups - gonna start the cleanup work now and hope I don't break anything ;)

[frals]

So yeah, some source code... http://irc.frals.se/maemo/fmms/fmms.zip

NOTE: THIS IS A MORE OF A PROOF OF CONCEPT THEN ANYTHING ELSE, IT NEEDS _A LOT_ OF POLISH BEFORE IT'S READY

also, it doesnt send confirmation/anything so whoever sends you the message wont get a delivery report etc.. basically it breaks the standard in most ways atm

with that said, feel free to try it out, theres a (very limited) readme in there... and uh, feel free to catch me on irc/here if you got any questions/comments

a big thanks to the kind Nokian who developed wappushd and shared the dbus interface with me as well as helping me get it all sorted

[tomaszf]

First thoughts:

1) N900 is having hard times with your name mentioned in first lines of a source files :) Errors about encodings etc. I had to remove special chars.

2) Add info about python-conic dependency to README.

[tomaszf]

OK, I followed instructions, but it seems that push messages are not saved to my N900. Here's what I get:

[DEBUG] handle_dbus_message: incoming SMS push.
[DEBUG] handle_push: registered listener for `x-wap-application:mms.ua' is at `se.frals.mms//se/frals/mms'

No files in mms/INCOMING after that.

After manually creating .fmms/push I was able to run GUI, but the list is empty.

Any thoughts? :)

[frals]

kill service.py if its running then run it in a terminal (python service.py) when someone sends you an MMS, it should print some debugging info to the terminal


edit: do you get the notification "Incoming SMS PUSH"?


edit2: basically, the mms/INCOMING file is the last data that the dbus-service caught, and after its been parsed in wappushhandler it saves it to .fmms/push/[TRANSACTION_ID]

[tomaszf]

After starting manually service.py I started getting INCOMING files.

Ok, I figured it out.
After changing line 92 in wappushandler.py:

file = open("/home/user/.fmms/push/" + transaction, 'w')

to:

myfile = open("/home/user/.fmms/push/" + str(transaction), 'w')

it works :) Push SMSes are saved now.

[tomaszf]

File gui_browser.py, lines 191 - 192. Something wrong here:

sndr = list[1]
url = list[2]

Should be url=list[1].

Probably I received a mms :) Not sure yet, because I sent to myself multiple blank mmses. I will verify it soon.

[tomaszf]

Frails, good work. I'm able to receive MMSes.
Here's the proof :)

http://img502.imageshack.us/img502/1199/attachmentbiqr5u.png (http://img502.imageshack.us/i/attachmentbiqr5u.png/)

Message was sent from Nokia N80 (network operator: Play, PL) to N900 (Plus GMS, PL).

[frals]

what fun is receiving if you cant send?

http://irc.frals.se/maemo/fmms/send.py

change line 60 to the proxy you use and it *should work* :)

note: you have to be connected to the correct apn when running this script

[bsving]

Frails, good work. I'm able to receive MMSes.
Here's the proof :)


Proof? It is impossible to see what yor image is about, other than some (unreadable) text on the display :confused:

[qwerty12]

Proof? It is impossible to see what yor image is about, other than some (unreadable) text on the display :confused:

It clearly says: "Showing MMS"...

It may be an elaborate and very carefully planned hoax (:rolleyes:), but I'd think not considering anyone is free to try out frals' program and the fact that the source is available...

[tomaszf]

I'm testing your script frals :)

Trying to send mms, but no luck.
I invoke send.py with mmsc set to http://mms.plusgsm.pl:8002 (should be ok) but script fails with message "Temporary failure in name resolution". DNS problem? Proxy address is set.

[michaelh]

I'm testing your script frals :)

Trying to send mms, but no luck.
I invoke send.py with mmsc set to http://mms.plusgsm.pl:8002 (should be ok) but script fails with message "Temporary failure in name resolution". DNS problem? Proxy address is set.

did you include the http:// bit? it should just be 'mms.plusgsm.pl:8002', not 'http://mms.plusgsm.pl:8002'.

[lcuk]

Proof? It is impossible to see what yor image is about, other than some (unreadable) text on the display :confused:

stop looking at the picture of the n900, look at the UI border around the picture.

the mms itself *was* just a random picture, but the app its being displayed in..

[tomaszf]

@michaelh I tried both ways - with and without http. Script is ok - I guess it's a network-specific issue.

[frals]

right ive added some polish and well... http://mms.frals.se/

afraid it wont help tomaszf with his problem sending thou :(

[tomaszf]

Just installed. Sender with GUI, nice :)

[frals]

right i released a new package of it earlier today after some feedback from tomaszf (thanks!)

short guide:

setup a APN for fetching MMS - see your carriers homepage for details - I assume you know how to set it up in internet connections

launch fMMS and hit the app menu and bring up "Configuration"

in APN you enter the name of the connection you want to use, in my case Tele2 MMS. note: enter it exactly like it is in internet connections

in the mmsc field enter the url to your providers MMSC (get from carriers homepage), including http://. in my case: http://mmsc.tele2.se

rest of instructions are on the link below

http://mms.frals.se/

if you try it, please drop me a PM or email saying if it worked/if it didnt :)

[twaelti]

Large list of MMS Service Providers (MMSC) to find out your settings:
http://www.activexperts.com/xmstoolkit/mmsclist/

[romanianusa]

I am not able to install or uninstall... what's going on?? How do i get rid of this shyt. This is the message...


~ $ sudo dpkg -r fmms
dpkg: error processing fmms (--remove):
Package is in a very bad inconsistent state - you should
reinstall it before attempting a removal.
Errors were encountered while processing:
fmms
~ $ sudo -i


BusyBox v1.10.2 (Debian 3:1.10.2.legal-1osso26+0m5) built-in shell (ash)
Enter 'help' for a list of built-in commands.

Nokia-N900-42-11:~# dpkg -i /home/user/MyDocs/.images/Irina/fmms.deb
Selecting previously deselected package fmms.
(Reading database ... 31605 files and directories currently installed.)
Preparing to replace fmms 0.0.1 (using .../MyDocs/.images/Irina/fmms.deb) ...
Unpacking replacement fmms ...
Error com.nokia.wappush.error.not_registered: Application ID is not registered.
dpkg: warning - old post-removal script returned error exit status 1
dpkg - trying script from the new package instead ...
Error com.nokia.wappush.error.not_registered: Application ID is not registered.
dpkg: error processing /home/user/MyDocs/.images/Irina/fmms.deb (--install):
subprocess new post-removal script returned error exit status 1
Error com.nokia.wappush.error.not_registered: Application ID is not registered.
dpkg: error while cleaning up:
subprocess post-removal script returned error exit status 1
Errors were encountered while processing:
/home/user/MyDocs/.images/Irina/fmms.deb

[romanianusa]

Thanks God i am able to get rid of this dumb program. First of all, why the HELL would i want to use this program to send picture when i can do it with my email?? It is similar...when u click on the program ...it opens up and there is the TO: button and "ATTACHMENT"...why the HELL I WANT THAT?? It is similar to an email. I thought this shyt is going to integrate with my sms messenger or something where i can chat and send pictures at the same time.

[lcuk]

its called a prototype.
commonly known as a proof of concept.

[rlinfati]

/opt/fmms/send.py http://mms.wind.it 1234567890 asunto cuerpo /home/user/MyDocs/.images/blur4.jpg

http://mms.wind.it 1234567890 asunto cuerpo /home/user/MyDocs/.images/blur4.jpg
image/jpg
conecting
enconding well know charset: iso-8859-1
200 OK
41612 message-format-corrupt

:(

[frals]

/opt/fmms/send.py http://mms.wind.it 1234567890 asunto cuerpo /home/user/MyDocs/.images/blur4.jpg

http://mms.wind.it 1234567890 asunto cuerpo /home/user/MyDocs/.images/blur4.jpg
image/jpg
conecting
enconding well know charset: iso-8859-1
200 OK
41612 message-format-corrupt

:(

Thanks for testing!

I'm aware of this - currently trying to get it fixed - seems like my MMSC is a lot less picky then others :)

Do you manage to receive ok?

[mohannad]

Thanks God i am able to get rid of this dumb program. First of all, why the HELL would i want to use this program to send picture when i can do it with my email?? It is similar...when u click on the program ...it opens up and there is the TO: button and "ATTACHMENT"...why the HELL I WANT THAT?? It is similar to an email. I thought this shyt is going to integrate with my sms messenger or something where i can chat and send pictures at the same time.


maybe that will teach you to read the developer's comment's before you try out an application.

keep up the great work frals! Will test this tonight.

[rlinfati]

@frals

if i can not auto send me a mms.... i can not recive :(

[claesbas]

Here's a video of it in action:
http://www.maemosweden.com/alla-bloggar/maemobloggen/70-skicka-och-ta-emot-mms-med-nokia-n900

sorry for the swedish, it should be watchable anyway...

[labra]

Nice work! It really did not take long time for you guys to make the working poc! Good!

[rlinfati]

@romanianusa

do as root

echo >> /var/lib/dpkg/info/fmms.postrm
echo exit 0 >> /var/lib/dpkg/info/fmms.postrm
dpkg -P fmms

[romanianusa]

@romanianusa

do as root

echo >> /var/lib/dpkg/info/fmms.postrm
echo exit 0 >> /var/lib/dpkg/info/fmms.postrm
dpkg -P fmms

I get "Removing fmms...
Purging configuration files for fmms...
Error com.nokia.wappush.error.not_registered: Application ID is not registered.
dpkg: error processing fmms (--purge):
subprocess post-removal script returned error exist status 1
Errors were encountered while processing: fmms


How the hell do i get remove fmms?? Is this the reason my friend can't normally txt me anymore using Yahoo messenger to phone? I mean she can txt using normal mobile to mobile but now can't do it with Yahoo Messenger to mobile. She used to be able to do that?? Is this program screwing it up or what?? I am pissed!!

[claesbas]

I get "Removing fmms...
Purging configuration files for fmms...
Error com.nokia.wappush.error.not_registered: Application ID is not registered.
dpkg: error processing fmms (--purge):
subprocess post-removal script returned error exist status 1
Errors were encountered while processing: fmms


How the hell do i get remove fmms?? Is this the reason my friend can't normally txt me anymore using Yahoo messenger to phone? I mean she can txt using normal mobile to mobile but now can't do it with Yahoo Messenger to mobile. She used to be able to do that?? Is this program screwing it up or what?? I am pissed!!
please.. if you install some clearly alpha-state-prototype-proof-of-concept there is a big chance things might go wrong. There is no reason to be pissed off. If you were willing to risk this and install it please report the bugs you find to frals and he will fix it.

[romanianusa]

please.. if you install some clearly alpha-state-prototype-proof-of-concept there is a big chance things might go wrong. There is no reason to be pissed off. If you were willing to risk this and install it please report the bugs you find to frals and he will fix it.

Nevermind about the bug...how do i get rid of the program or undo it?? How do i uninstall it based on what the error messages displayed above?

I don't know Linux..still new here. I wish the new firmware come out and fix all these bugs.

[frals]

No, this has nothing to do with your friends inability to IM you.

Run the following in a terminal and then try to remove it again:
/usr/bin/dbus-send --print-reply --system --type=method_call --dest=com.nokia.wappush /com/nokia/wappush com.nokia.wappush.register string:'x-wap-application:mms.ua' string:'se.frals.mms' string:'/se/frals/mms'

Next time when you decide to install something that the developer say is higly unstable and likely to break stuff, please don't do it - or if you do, ask *politely* for help.

------------

In other news I hope to have a new package up later tonight - hoping it fixes the "message corrupt" issues

[frals]

new package released 0.0.1-5 http://mms.frals.se/fmms.html

i *hope* i fixed the message-corrupt-issue now :)

[rlinfati]

~ $ sh mms-loop
http://mms.wind.it +39327749xxxx asunto cuerpo /home/user/MyDocs/.images/blur4.jpg
connecting
done connecting
MMSC STATUS: 200 OK
MMSC RESPONDED: ���37160�����message-format-corrupt

[frals]

crap, back to the drawing board :P

[romanianusa]

No, this has nothing to do with your friends inability to IM you.

Run the following in a terminal and then try to remove it again:
/usr/bin/dbus-send --print-reply --system --type=method_call --dest=com.nokia.wappush /com/nokia/wappush com.nokia.wappush.register string:'x-wap-application:mms.ua' string:'se.frals.mms' string:'/se/frals/mms'

Next time when you decide to install something that the developer say is higly unstable and likely to break stuff, please don't do it - or if you do, ask *politely* for help.

------------

In other news I hope to have a new package up later tonight - hoping it fixes the "message corrupt" issues

I run those code..not sure if i did it right. It gives me "method return sender=:1.19 --> dest=1.589 reply_serial=2"

Then I try to uninstall it and it gives me the same ERROR messages as before.

Can you tell me exactly what i need to type on Xterminal..i am still new to this. I was able to gain root access with sudo -i

[frals]

Could try:

mv /var/lib/dpkg/info/fmms.postrm /var/lib/dpkg/info/fmms.postrm-DISABLED

dpkg --force-all --remove fmms

Otherwise you can always reflash ;-)

[romanianusa]

Could try:

mv /var/lib/dpkg/info/fmms.postrm /var/lib/dpkg/info/fmms.postrm-DISABLED

dpkg --force-all --remove fmms

Otherwise you can always reflash ;-)

I get "dpkg - warning: ignoring request to remove fmms, only the config files of which are on the system. Use --purge to remove them too."

If i use --purge, i get same previous ERROR like "Error com.nokia.wappush.error.not_regisitered: Application ID is not registered."

[frals]

romanianusa: I'm sorry but I have no idea how to solve your dpkg-issues.


IN OTHER NEWS:

0.0.1-8 IS UPLOADED AT http://mms.frals.se/fmms.html

GOT CONFIRMATION FROM A BUNCH OF PEOPLE ITS WORKING TO SEND NOW! :DDD

[jarim]

frals, as I already said; KEEP UP THE GOOD WORK! :)

Version fMMS-0.0.1-8 verified to be working in Elisa network (Finland). :)

[Texrat]

frals rocks.

[twaelti]

setup a APN for fetching MMS - see your carriers homepage for details - I assume you know how to set it up in internet connections
No, I don't know :o When I try to add a 2nd packet connection in my settings, I can only add WLAN connections ?!?
EDIT: OK, found out how - it's a bug in Maemo5 (https://bugs.maemo.org/show_bug.cgi?id=5791)and you must manually do it through gconf...

(PS: One small enhancement request: Warn if attachements are over 300 kB in size, as this might well cause problems on the mms server or with the recipient. It might also be nice to indicate the size of the attachement in general after it has been selected)

[frals]

No, I don't know :o When I try to add a 2nd packet connection in my settings, I can only add WLAN connections ?!?

(PS: One small enhancement request: Warn if attachements are over 300 kB in size, as this might well cause problems on the mms server or with the recipient. It might also be nice to indicate the size of the attachement in general after it has been selected)

https://bugs.maemo.org/show_bug.cgi?id=5791#c16 workaround ;-)

Oh, seems I've lost that somewhere... I know I *had* it at some point, I'll add it right now (showing size at least ;)).


Texrat, jarim: Thanks, this community rocks (and everyone who have helped me test it so far :))

[rlinfati]

it's WORK!!!!!!

[frals]

Right, uploaded a new version now - it *should* be a bit more user-friendly: http://mms.frals.se/

Comments, suggestions etc welcome :)


(I should probably create a new thread announcing this application?)

[rlinfati]

and upload to extras-devel please....

[lardman]

I get "dpkg - warning: ignoring request to remove fmms, only the config files of which are on the system. Use --purge to remove them too."

That indicates that the binaries are gone anyway.

I suppose it might well be possible to edit the postrm script to make it run successfully to get the package to remove itself correctly: You might try editing the postrm script which should be here: /var/lib/dpkg/info/fmms.postrm

Edit is so it has nothing in it but the hash bang stuff ("#!/bin/sh")

I think that should then return correctly and hopefully be removed.

[in-effect]

Otherwise you can always reflash ;-)

how about reflashable people - now that would solve a problem or two.

[bguzmanz2]

keeps asking if i entered correct apn settings, but i know they are right because thats why i always use with tmobile. any ideas? great app by the way, even better if i can get it to take my info =)

[twaelti]

Right, uploaded a new version now - it *should* be a bit more user-friendly: http://mms.frals.se/

Thanks, the sender number saved is much appreciated for someone experimenting like me :D

You wrote "limitations: ... wont send via apn requiring user/pass yet (i think)". Why? I do put user/pass into the connection settings, and guess this is ok.

My problem is that I'm unable to correctly setup the configs. For Android, on my provider it would have been:

Name: Sunrise MMS
APN: mms.sunrise.ch
Proxy
Port
Username: mms
Password: mms
Server
MMSC: http://mmsc.sunrise.ch
MMS proxy: 212.35.34.75
MMS port: 8080

IMHO, this means that while I don't have to set a general proxy (HTTP) in the connection, I have to set a MMS proxy with a port somewhere... but haven't found a place to do that in fMMS.

(MMS proxy = a.k.a. Provider WAP Gateway)

Well, it's a fun trip anyway, thanks for the ride!

[frals]

you have to manually connect to the apn before sending the message


also, seems ive introduced a bug in 0.1.0-1 where it wont receive MMS properly, working on fixing it


You wrote "limitations: ... wont send via apn requiring user/pass yet (i think)". Why? I do put user/pass into the connection settings, and guess this is ok.

i hadnt tested it where it was required, guess it works :)


Name: Sunrise MMS
APN: mms.sunrise.ch
Proxy
Port
Username: mms
Password: mms
Server
MMSC: http://mmsc.sunrise.ch
MMS proxy: 212.35.34.75
MMS port: 8080

IMHO, this means that while I don't have to set a general proxy (HTTP) in the connection, I have to set a MMS proxy with a port somewhere... but haven't found a place to do that in fMMS.

(MMS proxy = a.k.a. Provider WAP Gateway)

Well, it's a fun trip anyway, thanks for the ride!

I *think* you can just use the MMS proxy/port as proxy - not sure though

[frals]

Right 0.1.0-2 posted now, it should be working properly again... http://mms.frals.se

Just to be sure, remove previous version (dpkg -r fmms) and rm -rf /opt/fmms, kill fmmsd if its running (ps|grep fmms, kill <pid>) and then install the new package ;)

[qole]

This community continues to rock. Other platforms can only whine about missing features. Here, some awesome developer steps up and hacks something together for us.

The next step is to make this into a telepathy or sharing plugin so you can integrate it with the rest of the system (because some people are never happy).

Too bad I have no use for MMS in my own life.

[claesbas]

for some weird reason alot of people in Sweden still use MMS all the time..

its quite amazing I recive mms now as it almost was a supported feature.. :D great job frals

[DaveQB]

Right 0.1.0-2 posted now, it should be working properly again... http://mms.frals.se

Just to be sure, remove previous version (dpkg -r fmms) and rm -rf /opt/fmms, kill fmmsd if its running (ps|grep fmms, kill <pid>) and then install the new package ;)

Or
killall fmms
Assuming that's the executable binary/script's name.

[freppas]

OT: Interesting to note that Frals site is actually blocked in china :) Are you involved in some activities against the wonderful PRC, or is it just a blog? ;)

[frals]

OT: Interesting to note that Frals site is actually blocked in china :) Are you involved in some activities against the wonderful PRC, or is it just a blog? ;)

Wow, that's really strange, I guess its my blog at blog.frals.se ;) (with a grand total of _one_ post) - on the other hand frals.se used to belong to the Swedish Salvation Army :)

Most builds are also posted on https://garage.maemo.org/projects/fmms

I'll work on getting a package up in -devel today :)

[holox]

When trying to configure settings I am getting error message:

" Could not save. Did you enter a correct APN?"

Really does not matter what i type in there because i get same error message everytime. In latest version at least i dont have reboot phone anymore to get away from menu :D

One of the installations got f*cked up so there must be some
old file(s) laying somewhere or permission set problem?

-Jake

[frals]

When trying to configure settings I am getting error message:

" Could not save. Did you enter a correct APN?"

Really does not matter what i type in there because i get same error message everytime. In latest version at least i dont have reboot phone anymore to get away from menu :D

One of the installations got f*cked up so there must be some
old file(s) laying somewhere or permission set problem?

-Jake

What it tries to do when you enter a APN is go through gconf looking for a APN with the same name as you entered (/system/osso/connectivity/IAP/*/name == entryfieldvalue)

What that means is that the APN you enter here must match the name of the APN in "Internet Connections" *exactly* or it will fail to save

If you'd like, please message me on #maemo on irc (nick: frals) or drop me a email/PM and I can help you track down a solution :)

Thanks for testing!

[frals]

For further discussion around fMMS I've decided to create a new thread; http://talk.maemo.org/showthread.php?p=459426#post459426

[RevdKathy]

Orange UK settings posted over in the other thread. Huge thanks to frals for his time, effort and patience with me!

[pippomu]

MMS configuration H3g Italy - Tre Italia

after installing fMMS (http://mms.frals.se/) and fAPN - GUI for adding a new GPRS APN (http://mms.frals.se/fapn.html)
here the steps:

with fAPN
add anew apn named mms (important: respect cases - mms is different than Mms). You can close.
go to main settings and then, connection settings and edit the apn just named "mms":
access point name: tre.it
user name: (empty)
password: (empty)
ask for password: leave unchecked
go on and click on advanced
use proxy: check the box
proxy HTTP: 62.13.171.3 or wsb.treumts.it
port: 8799
in the tab IP address leave everything automatic

save and close.

with fMMS
click on configurations
APN: mms [/B](remember: respect cases - mMS is different than mmS);
MMSC: "http://10.216.59.240:10021/mmsc"
Resize image width: 300 (Tre Italia guarantees up to this dimension);
Your phonenumber: write your number in format +39xxxyyyyy

Hope it's usefull

[qgil]

http://maemo.org/community/brainstorm/view/mms_support/ moved to In Development.

[ReemZ]

I can only speak for my own telco, Vodafone NL. It seems they have different APNs because there are different connections configured (there are 4, in fact). But that is not the case. They have the same APN name which you can see in details: live.vodafone.com with username vodafone and password vodafone. The only difference is the default homepage. For MMS, it is http://mmsc.mms.vodafone.nl so at least in my case there is no need for a seperate ppp1 please verify in your phone settings about your case. YMMV.

I've not read the entire thread just yet, so I'm not sure if you might have had to answer this question before and I'm sorry if I'm causing a problem now, but I found your post through a search on "mms vodafone". I'm with Vodafone NL too and I'm having trouble finding the right settings.
The Vodafone site (http://www.vodafone.nl/prive/help/aanvragen_en_wijzigen/toestel_instellen/Algemene_instellingen) mentions a proxy port number (8799) but I'm not sure if I'm to include this in the proxy url or not, and I'm at a complete loss as to the 'advanced' settings, where I'm to enter the IP address and DNS addresses.
Needless to say I can't send or receive MMS messages at this point.
Any chance you could help a fellow Dutchman out here? ;)