(01-01-2021, 12:43 PM)kent Wrote: 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.

Quote:(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?

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

(01-01-2021, 01:04 PM)kop316 Wrote: 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?

(01-01-2021, 05:05 PM)kent Wrote:

(01-01-2021, 01:04 PM)kop316 Wrote: 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?

(01-01-2021, 12:43 PM)kent Wrote:

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

(01-02-2021, 08:10 AM)kop316 Wrote: 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

(01-02-2021, 05:43 PM)kent Wrote:

(01-02-2021, 08:10 AM)kop316 Wrote: 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