Beta support: MMS on chatty/mmsd on Modem Manager - help/testing wanted!

[kop316]

Hi, I've been following the conversations on this over at the Purism site. You guys are doing great work. I'm trying to test this on Manjaro/Phosh - but not entirely sure what I'm looking for or how to be helpful. 

Following the instructions, everything seems to compile and install. To test, I directed two MMS messages with image attachment to the PP from an AT&T device. Here's what happened:

-The SMS quickly came in as expected and appeared under the AT&T inbound phone #.
-A reference to the MMS attachment appeared quickly, but appeared under a seemingly arbitrary inbound #.
-The MMS entries in Chatty all display the text "plication/vnd.wrap.mms-message" rather than the file information in your screen shot.

Also, I removed the Chatty auto-run entry and launched manually as described in the instructions (but have not built from sources). Interestingly, after exiting Chatty for a bit and re-running, Chatty detected both test messages for a second time and downloaded them again.

(I learned later that it is a good idea to build chatty from source if you want to debug issues. This way you can build in the debug symbols)

What is the source repo location?

It would be great to integrate it into mobile-broadband-provider-info  ( [https://gitlab.gnome.org/GNOME/mobile-br...vider-info), and provide a way to provide a setting to provide the MMSC settings.

Bearing in mind I've never encountered an .XSL document before and am not at all sure how these pieces fit together, I did some poking around and the fields we need appear to have already been integrated/implemented.

There is a conditional in apns-conf.xsl on the usage field of an APN entry (provider>gsm>apn). When usage is set to "mms", the logic integrates the mmsc and mmsproxy fields. The mmsproxy field is parsed to derive mmsport (from mmsproxy:port, or default to 8080).

In serviceproviders.xml, many of the carriers already have MMS apn entries defined, which appear include needed fields to set up the internet connection. I don't see obvious changes needed at this level. It looks like everything is there.

So If you can, please download a later version of purple-mm-sms. What is going on is that when you get an MMS, it first downloads what is called an "SMS WAP". This is a notification to go to a link and download the actual payload. I made that a bit clearer in a newer version of purple-mm-sms (and i cleaned upquite a bit of the code too):

https://source.puri.sm/kop316/purple-mm-sms/-/tree/mmsd

Also, are you running mmsd?

And the repo for chatty is:

https://source.puri.sm/Librem5/chatty

without a more detailed log of mmsd or chatty, I am not sure i can help?

[kent]

So If you can, please download a later version of purple-mm-sms. What is going on is that when you get an MMS, it first downloads what is called an "SMS WAP". This is a notification to go to a link and download the actual payload. I made that a bit clearer in a newer version of purple-mm-sms (and i cleaned upquite a bit of the code too):

https://source.puri.sm/kop316/purple-mm-sms/-/tree/mmsd

Also, are you running mmsd?

And the repo for chatty is:

https://source.puri.sm/Librem5/chatty

without a more detailed log of mmsd or chatty, I am not sure i can help?

The link for purple-mm-sms here will not directly clone w/ git. I'm cloning from https://source.puri.sm/kop316/purple-mm-sms/.

Is this the correct version?

[kop316]

So If you can, please download a later version of purple-mm-sms. What is going on is that when you get an MMS, it first downloads what is called an "SMS WAP". This is a notification to go to a link and download the actual payload. I made that a bit clearer in a newer version of purple-mm-sms (and i cleaned upquite a bit of the code too):

https://source.puri.sm/kop316/purple-mm-sms/-/tree/mmsd

Also, are you running mmsd?

And the repo for chatty is:

https://source.puri.sm/Librem5/chatty

without a more detailed log of mmsd or chatty, I am not sure i can help?

The link for purple-mm-sms here will not directly clone w/ git. I'm cloning from https://source.puri.sm/kop316/purple-mm-sms/.

Is this the correct version?

Yes it is, just make sure you check out the mmsd branch.

[kent]

OK. I got mmsd running with debug output and have a bit more info.

I think the issue is that in addition to MMSC url, my carrier indicates an MMS Proxy and MMS Port.  Is there a way to handle that yet?

[kop316]

I see what you are saying:

https://www.att.com/support/article/wireless/KM1062162

I'm not sure? Without a) the debug out and b) without a device for me to test on at&t, I can't do much to see if there is a way.

I would assume it wouldn't be too difficult to handle though.

[kop316]

So looking to it more, this may be an issue with our interface with Modem manager in mmsd. The one that exists now is extremely simple (hence the title "simple.c"). One of the things that looks needing to be done is set up  the ability to do the proxy service from within mmsd.

At a quick glance, this may need to be done from within "bearer handler"? But I have not looked too much into this.

However I would say, if you have the know how, this would be a great way to help get MMS, if you could get the MMS proxy integrated into the mmsd plugin.

EDIT:

So looking at this a bit more, I am seeing a couple of functions that look promising:

mms_service_bearer_notify() and mms_service_set_bearer_handler().

mms_service_bearer_notify() looks like it has references to setting a proxy, and it's pretty straight foward to integrate it into simple.c (in line 82 where it says:

Code:

mms_service_bearer_notify(service, TRUE, "wwan0", NULL);

Change the "NULL" to the proxy service and see how that works.

mms_service_set_bearer_handler() may have to be set, but I am not sure what it does. Perhaps look at the ofono.c plugin and see how it sets up the proxy too? This is how the debug looks for me:

Code:

mmsd[3297]: src/service.c:mms_service_create() service 0x55abbb9dc0
mmsd[3297]: src/service.c:mms_service_set_identity() service 0x55abbb9dc0 identity any
mmsd[3297]: src/service.c:mms_service_set_mmsc() service 0x55abbb9dc0 mmsc http://mms.msg.eng.t-mobile.com/mms/wapenc
mmsd[3297]: src/service.c:mms_service_bearer_notify() service=0x55abbb9dc0 active=1 iface=wwan0 proxy=(null)
mmsd[3297]: src/service.c:mms_service_bearer_notify() interface wwan0 proxy (null)
clearing proxy

[kop316]

It would be great to integrate it into mobile-broadband-provider-info  ( [https://gitlab.gnome.org/GNOME/mobile-br...vider-info), and provide a way to provide a setting to provide the MMSC settings.

Bearing in mind I've never encountered an .XSL document before and am not at all sure how these pieces fit together, I did some poking around and the fields we need appear to have already been integrated/implemented.

There is a conditional in apns-conf.xsl on the usage field of an APN entry (provider>gsm>apn). When usage is set to "mms", the logic integrates the mmsc and mmsproxy fields. The mmsproxy field is parsed to derive mmsport (from mmsproxy:port, or default to 8080).

In serviceproviders.xml, many of the carriers already have MMS apn entries defined, which appear include needed fields to set up the internet connection. I don't see obvious changes needed at this level. It looks like everything is there.

That's really good info! I will have to look at that and see if I can do some integration then (or alternatively, if you see how to integrate this, it would be welcome to have the help too!)

[kent]

So looking to it more, this may be an issue with our interface with Modem manager in mmsd. The one that exists now is extremely simple (hence the title "simple.c"). One of the things that looks needing to be done is set up  the ability to do the proxy service from within mmsd.

At a quick glance, this may need to be done from within "bearer handler"? But I have not looked too much into this.

However I would say, if you have the know how, this would be a great way to help get MMS, if you could get the MMS proxy integrated into the mmsd plugin.

EDIT:

So looking at this a bit more, I am seeing a couple of functions that look promising:

mms_service_bearer_notify() and mms_service_set_bearer_handler().

mms_service_bearer_notify() looks like it has references to setting a proxy, and it's pretty straight foward to integrate it into simple.c (in line 82 where it says:

Code:

mms_service_bearer_notify(service, TRUE, "wwan0", NULL);

Change the "NULL" to the proxy service and see how that works.

mms_service_set_bearer_handler() may have to be set, but I am not sure what it does. Perhaps look at the ofono.c plugin and see how it sets up the proxy too? This is how the debug looks for me:

Code:

mmsd[3297]: src/service.c:mms_service_create() service 0x55abbb9dc0
mmsd[3297]: src/service.c:mms_service_set_identity() service 0x55abbb9dc0 identity any
mmsd[3297]: src/service.c:mms_service_set_mmsc() service 0x55abbb9dc0 mmsc http://mms.msg.eng.t-mobile.com/mms/wapenc
mmsd[3297]: src/service.c:mms_service_bearer_notify() service=0x55abbb9dc0 active=1 iface=wwan0 proxy=(null)
mmsd[3297]: src/service.c:mms_service_bearer_notify() interface wwan0 proxy (null)
clearing proxy

I'll play with the proxy settings and see what happens.

What does T-Mobile send in the CONTENT_LOCATION header? AT&T is sending:

Code:

mmsd[4645]: src/mmsutil.c:mms_parse_headers() saw header of type 3
mmsd[4645]: src/mmsutil.c:mms_parse_headers() running handler for type 3
mmsd[4645]: src/mmsutil.c:decode_text() claimed len: 54
mmsd[4645]: src/mmsutil.c:decode_text() val: http://166.216.198.5:8009/Y/0102054534500019000010000
mmsd[4645]: src/mmsutil.c:mms_parse_headers() handler for type 3 was success

[kop316]

So looking to it more, this may be an issue with our interface with Modem manager in mmsd. The one that exists now is extremely simple (hence the title "simple.c"). One of the things that looks needing to be done is set up  the ability to do the proxy service from within mmsd.

At a quick glance, this may need to be done from within "bearer handler"? But I have not looked too much into this.

However I would say, if you have the know how, this would be a great way to help get MMS, if you could get the MMS proxy integrated into the mmsd plugin.

EDIT:

So looking at this a bit more, I am seeing a couple of functions that look promising:

mms_service_bearer_notify() and mms_service_set_bearer_handler().

mms_service_bearer_notify() looks like it has references to setting a proxy, and it's pretty straight foward to integrate it into simple.c (in line 82 where it says:

Code:

mms_service_bearer_notify(service, TRUE, "wwan0", NULL);

Change the "NULL" to the proxy service and see how that works.

mms_service_set_bearer_handler() may have to be set, but I am not sure what it does. Perhaps look at the ofono.c plugin and see how it sets up the proxy too? This is how the debug looks for me:

Code:

mmsd[3297]: src/service.c:mms_service_create() service 0x55abbb9dc0
mmsd[3297]: src/service.c:mms_service_set_identity() service 0x55abbb9dc0 identity any
mmsd[3297]: src/service.c:mms_service_set_mmsc() service 0x55abbb9dc0 mmsc http://mms.msg.eng.t-mobile.com/mms/wapenc
mmsd[3297]: src/service.c:mms_service_bearer_notify() service=0x55abbb9dc0 active=1 iface=wwan0 proxy=(null)
mmsd[3297]: src/service.c:mms_service_bearer_notify() interface wwan0 proxy (null)
clearing proxy

I'll play with the proxy settings and see what happens.

What does T-Mobile send in the CONTENT_LOCATION header? AT&T is sending:

Code:

mmsd[4645]: src/mmsutil.c:mms_parse_headers() saw header of type 3
mmsd[4645]: src/mmsutil.c:mms_parse_headers() running handler for type 3
mmsd[4645]: src/mmsutil.c:decode_text() claimed len: 54
mmsd[4645]: src/mmsutil.c:decode_text() val: http://166.216.198.5:8009/Y/0102054534500019000010000
mmsd[4645]: src/mmsutil.c:mms_parse_headers() handler for type 3 was success

This is what I get:

Code:

mmsd[2614]: src/mmsutil.c:decode_text() claimed len: 81
mmsd[2614]: src/mmsutil.c:decode_text() val: http://polmmsget.msg.eng.t-mobile.com/mms/wapenc?T=mavodi-6-13b-361-3-7b-27066cb
mmsd[2614]: src/mmsutil.c:mms_parse_headers() handler for type 3 was success
mmsd[2614]: src/service.c:mms_service_push_notify() did decode message
mmsd[2614]: src/service.c:mms_service_push_notify() is type NI?
mmsd[2614]: src/service.c:mms_service_push_notify() type is NI
mmsd[2614]: MMS transaction id: mavodi-6-89-441-1-7b-6-361-3-7b-27066cb
mmsd[2614]: MMS version: 1.2

[kent]

Getting closer ... but not quite there. Chatty now creates a conversation with a message indicating a MMS notification has arrived via sms which Chatty is working to download and parse.

Based on the mmsd output, it looks like the request never actually goes out though.

Code:

mmsd[6172]: src/service.c:mms_service_push_notify() did decode message
mmsd[6172]: src/service.c:mms_service_push_notify() is type NI?
mmsd[6172]: src/service.c:mms_service_push_notify() type is NI
mmsd[6172]: MMS transaction id: A20103012201500004000000000
mmsd[6172]: MMS version: 1.0
mmsd[6172]: From: +15555555555/TYPE=PLMN
mmsd[6172]: Subject:
mmsd[6172]: Class: Personal
mmsd[6172]: Size: 32768
mmsd[6172]: Expiry: 2021-01-06T01:22:04+0000
mmsd[6172]: Location: http://166.216.198.5:8004/Y/0103012201500004000000000
mmsd[6172]: src/service.c:mms_service_push_notify() about to store_meta_open 2
mmsd[6172]: src/service.c:mms_service_push_notify() did store_meta_open 2
mmsd[6172]: src/service.c:mms_service_push_notify() did create_request
mmsd[6172]: src/service.c:activate_bearer() service 0xaaab0c023bf0 setup 0 active 1
mmsd[6172]: src/service.c:process_request_queue() service 0xaaab0c023bf0
mmsd[6172]: src/service.c:process_request_queue() location http://166.216.198.5:8004/Y/0103012201500004000000000
request http://166.216.198.5:8004/Y/0103012201500004000000000
address proxy.mobile.att.net
port 80
host 166.216.198.5:8004
flags 0
request http://166.216.198.5:8004/Y/0103012201500004000000000
mmsd[6172]: Cannot process request (request type: 0)

The problem tracks back to the do_request() function call in gweb.c. There is a getaddrinfo() command failing with a "Name or service not known" error code trying to resolve the proxy host information, but I can't figure out exactly why (~line#1320) . I verified the values being passed for the name and port inputs look correct, and verified "proxy.mobile.att.net" host resolves fine with a manual ns lookup.

I'm stumped for the moment.