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

[kop316]

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.

If you have a matrix account, I generally hang out on the mobian and pmOS channels. Perhaps me helping you live would be easier?

[kop316]

I have kept working on purple-mm-sms. Group MMS is now supported for recieving (any type of attachment) and is now suppoted for sending (but only text)!

The group MMS will not show up in chatty due to this: https://source.puri.sm/Librem5/chatty/-/issues/444 but they show up in pidgin.

For the most part, adding initial MMS support in purple-mm-sms is pretty complete (but needs testing and some bug fixes). The majority of the work is now integrating both a) into chatty and b) mmsd more completely into modemmanager.

Here is also a picture of me sending a Group MMS, via pidgin, from my Pinephone!

   

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

If you have a matrix account, I generally hang out on the mobian and pmOS channels. Perhaps me helping you live would be easier?

I don't have a matrix account ... but I'll look into it. Any help is appreciated, but mostly I'm logging progress here in case something I'm coming across is useful (and I'm enough of a noob I can't quite tell the difference yet). I don't expect you to stop what you are working on to solve everything. 

I figured out what's going on. There is an addr_info() flag requiring a numeric ip address, which disables DNS lookup. The easiest solution is to just comment out that flag so addr_info() resolves a text domain name. This seems to work, but I'm not sure if that will break something else. So I've put in a hack at that level to do a dns lookup and replace if the session->address is not a valid numeric ip address.

This hack probably isn't a great final solution for production though.

Also, turns out it is possible to make a bloody mess of the mmsd request queue. There probably needs to be logic that eventually removes queue entries that can't be resolved (e.g. 404 Message not found in database).

[kop316]

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.

If you have a matrix account, I generally hang out on the mobian and pmOS channels. Perhaps me helping you live would be easier?

I don't have a matrix account ... but I'll look into it. Any help is appreciated, but mostly I'm logging progress here in case something I'm coming across is useful (and I'm enough of a noob I can't quite tell the difference yet). I don't expect you to stop what you are working on to solve everything. 

I figured out what's going on. There is an addr_info() flag requiring a numeric ip address, which disables DNS lookup. The easiest solution is to just comment out that flag so addr_info() resolves a text domain name. This seems to work, but I'm not sure if that will break something else. So I've put in a hack at that level to do a dns lookup and replace if the session->address is not a valid numeric ip address.

This hack probably isn't a great final solution for production though.

Also, turns out it is possible to make a bloody mess of the mmsd request queue. There probably needs to be logic that eventually removes queue entries that can't be resolved (e.g. 404 Message not found in database).

Sounds good! Don't worry about being a "noob", we all were there once (heck, that's how I felt about this whole thing before digging into it). I appreicate you digging in and looking at the code to figure it out!

I think the next logical place to work on is actually mmsd, and work on a more complete integration with it and modem manager (and possibly clean up the code too). So far, since I was able to send/recieve MMS, I have largely treated it as a black box (and I have made a huge mess of the request queue too). But purple-mm-sms is in good enough shape that it needs work to integrate into chatty, and I am waiting on Purism to look at the MR I sent to them.

So are you able to recieve MMS now then?

[kop316]

So I have been doing a bit of reading on the documentation of both MMSD and modem manager. Some notes that I have seen:

• Upon looking through both the mmsd and modem manager documentation/code, it looks like most of what needs to be done is impliment an mmsd plugin to allow mmsd to work with modem manager.
  
• Modem manager seems to have everything needed to be able to support an mmsd plugin, and mmsd will support having a plugin to modem manager.
  
• Many of the contexts from ofono can be "ported" over to modem manager (they seem to be roughly 1:1). However, it looks like the ofono has had a LOT of work done to it, so porting it over is not an insignificant effort (but a doable effort). Thankfully the work as been done to show that once it is done, mmsd will work with modem manager.
  
• As it is now, it looks like mmsd as a "bearer handler", and this is basically the way that you establish a data connection via modem manager.  modem manager's doc show that it can handle multiple bearers. The good news is that this means that if there is a carrier that uses a seperate MMS APN and data APN, this is entirely possible as is through modem manager! I am confirming it on https://gitlab.freedesktop.org/mobile-br...issues/227 and if so, this can be closed.
  

EDIT: Well the good news is a lot of the work for this plugin has already been done in purple-mm-sms. That makes porting mmsd to modem manager a lot easier.

[kent]

So are you able to recieve MMS now then?

I *think* so. Or at least the process has gotten farther and mmsd is getting data through AT&T's proxy now.

I cleared out the mms working folder, updated to the latest purple-mm-sms,  and sent a test mms with an image attachment. 

Now with an inbound mms, Chatty displays the sms message plus an error message indicating a file already exists; similar to the screenshot you posted near the start of the thread.

I'm not sure what the end result is supposed to look like in Chatty at this point. Is that right?

[kop316]

So are you able to recieve MMS now then?

I *think* so. Or at least the process has gotten farther and mmsd is getting data through AT&T's proxy now.

I cleared out the mms working folder, updated to the latest purple-mm-sms,  and sent a test mms with an image attachment. 

Now with an inbound mms, Chatty displays the sms message plus an error message indicating a file already exists; similar to the screenshot you posted near the start of the thread.

I'm not sure what the end result is supposed to look like in Chatty at this point. Is that right?

That is right! so what you may need to do (I have had to do this for experiementing) is delete both the .mms/ and mms/ folder in your home folder. That usually cleans up those errors.

Please let me know what you did for getting the proxy!

[kent]

That is right! so what you may need to do (I have had to do this for experiementing) is delete both the .mms/ and mms/ folder in your home folder. That usually cleans up those errors.

Please let me know what you did for getting the proxy!

I put a little hack to do_request() in mmsd/gweb/gweb.c. At ~line 1310, I inserted this:

Code:

.
.
        if (session->address == NULL)
            session->address = g_strdup(session->host);        

        /* Hack to prevent failure if proxy passed as text host name in */
        /* session->address when a numeric IP is needed in this routine */
        struct in_addr *inp; // dummy var for return
        if(inet_aton(session->address,inp) == 0){
            char *hostip;
            struct hostent *hp;
            debug(web,"session->address:%s not numeric ... trying to resolve host ...",session->address);
            hp = gethostbyname(session->address);
            if(hp==NULL){
                debug(web,"Address host look-up failed.");
                free_session(session);
                return 0;
            } else {            
                hostip = inet_ntoa( *(struct in_addr*)(hp->h_addr_list[0]));
                debug(web,"Ip lookup: %s / %s",session->address,hostip);
                session->address = hostip;
                debug(web,"New session->address:%s",session->address);
            }
        }
        /* end hack */
        
        memset(&hints, 0, sizeof(struct addrinfo));
        hints.ai_flags = AI_NUMERICHOST;
.
.

The code immediately following this populates session->addr with an addrinfo structure produced from session->address. The AI_NUMERICHOST flag requires session->address to be a numeric ip address, but whatever logic initially sets up the proxy session assigns the proxy string as provided in simple.c. So proxy would only work if the proxy host was specified as an ip address in simple.c.

My fix checks to see if session->address is in proper IP address format and if not, performs a hostname lookup and replaces the host name with the returned ip address. It works, but I don't really like the solution. If the input specifically *needs* to be a numeric ip address to correctly populate session->addr, the lookup should probably happen where the proxy information is assigned to session->address just like a non-proxy request.

If there *isn't* a specific reason the input needs to be a numeric address here, as best I can tell my fix is functionally redundant to simply commenting out the "hints.ai_flags = AI_NUMERICHOST;" line which would allow the getaddrinfo() call to resolve for either an ip address or text host name. Which, obviously, is a much cleaner solution.

Commenting out the flag did work to get mmsd talking to the proxy, but I'm not sure if changing the way that call works will break something for a different part of the system.

[kop316]

That is right! so what you may need to do (I have had to do this for experiementing) is delete both the .mms/ and mms/ folder in your home folder. That usually cleans up those errors.

Please let me know what you did for getting the proxy!

I put a little hack to do_request() in mmsd/gweb/gweb.c. At ~line 1310, I inserted this:

Code:

.
.
        if (session->address == NULL)
            session->address = g_strdup(session->host);        

        /* Hack to prevent failure if proxy passed as text host name in */
        /* session->address when a numeric IP is needed in this routine */
        struct in_addr *inp; // dummy var for return
        if(inet_aton(session->address,inp) == 0){
            char *hostip;
            struct hostent *hp;
            debug(web,"session->address:%s not numeric ... trying to resolve host ...",session->address);
            hp = gethostbyname(session->address);
            if(hp==NULL){
                debug(web,"Address host look-up failed.");
                free_session(session);
                return 0;
            } else {            
                hostip = inet_ntoa( *(struct in_addr*)(hp->h_addr_list[0]));
                debug(web,"Ip lookup: %s / %s",session->address,hostip);
                session->address = hostip;
                debug(web,"New session->address:%s",session->address);
            }
        }
        /* end hack */
        
        memset(&hints, 0, sizeof(struct addrinfo));
        hints.ai_flags = AI_NUMERICHOST;
.
.

The code immediately following this populates session->addr with an addrinfo structure produced from session->address. The AI_NUMERICHOST flag requires session->address to be a numeric ip address, but whatever logic initially sets up the proxy session assigns the proxy string as provided in simple.c. So proxy would only work if the proxy host was specified as an ip address in simple.c.

My fix checks to see if session->address is in proper IP address format and if not, performs a hostname lookup and replaces the host name with the returned ip address. It works, but I don't really like the solution. If the input specifically *needs* to be a numeric ip address to correctly populate session->addr, the lookup should probably happen where the proxy information is assigned to session->address just like a non-proxy request.

If there *isn't* a specific reason the input needs to be a numeric address here, as best I can tell my fix is functionally redundant to simply commenting out the "hints.ai_flags = AI_NUMERICHOST;" line which would allow the getaddrinfo() call to resolve for either an ip address or text host name. Which, obviously, is a much cleaner solution.

Commenting out the flag did work to get mmsd talking to the proxy, but I'm not sure if changing the way that call works will break something for a different part of the system.

Understood. Maybe just commenting the "hints.ai_flags = AI_NUMERICHOST;" is the best solution. I can test that and see if it affects something on my end too?

Other than that, did you have to change (under simple.c) the NULL in

Code:

    mms_service_bearer_notify(modem->service, TRUE, "wwan0", NULL);

and it passed the proxy?

[kop316]

That is right! so what you may need to do (I have had to do this for experiementing) is delete both the .mms/ and mms/ folder in your home folder. That usually cleans up those errors.

Please let me know what you did for getting the proxy!

I put a little hack to do_request() in mmsd/gweb/gweb.c. At ~line 1310, I inserted this:

Code:

.
.
        if (session->address == NULL)
            session->address = g_strdup(session->host);        

        /* Hack to prevent failure if proxy passed as text host name in */
        /* session->address when a numeric IP is needed in this routine */
        struct in_addr *inp; // dummy var for return
        if(inet_aton(session->address,inp) == 0){
            char *hostip;
            struct hostent *hp;
            debug(web,"session->address:%s not numeric ... trying to resolve host ...",session->address);
            hp = gethostbyname(session->address);
            if(hp==NULL){
                debug(web,"Address host look-up failed.");
                free_session(session);
                return 0;
            } else {            
                hostip = inet_ntoa( *(struct in_addr*)(hp->h_addr_list[0]));
                debug(web,"Ip lookup: %s / %s",session->address,hostip);
                session->address = hostip;
                debug(web,"New session->address:%s",session->address);
            }
        }
        /* end hack */
        
        memset(&hints, 0, sizeof(struct addrinfo));
        hints.ai_flags = AI_NUMERICHOST;
.
.

The code immediately following this populates session->addr with an addrinfo structure produced from session->address. The AI_NUMERICHOST flag requires session->address to be a numeric ip address, but whatever logic initially sets up the proxy session assigns the proxy string as provided in simple.c. So proxy would only work if the proxy host was specified as an ip address in simple.c.

My fix checks to see if session->address is in proper IP address format and if not, performs a hostname lookup and replaces the host name with the returned ip address. It works, but I don't really like the solution. If the input specifically *needs* to be a numeric ip address to correctly populate session->addr, the lookup should probably happen where the proxy information is assigned to session->address just like a non-proxy request.

If there *isn't* a specific reason the input needs to be a numeric address here, as best I can tell my fix is functionally redundant to simply commenting out the "hints.ai_flags = AI_NUMERICHOST;" line which would allow the getaddrinfo() call to resolve for either an ip address or text host name. Which, obviously, is a much cleaner solution.

Commenting out the flag did work to get mmsd talking to the proxy, but I'm not sure if changing the way that call works will break something for a different part of the system.

So I altered the simple.c plugin a bit to allow for a config file. Is there any change you could backport the changes you did in gweb.c and impliment it in simple.c? that way the proxy passed into the bearer is now the IP address and there does not have to be a change in the core code.

EDIT: Actually, on second thought, it looks like proxy is set in this function: g_web_set_proxy() . It may make more sense to put that logic there.

EDIT 2: It looks like the proxy is parsed in parse_url. How did you set the proxy? I am wondering if you may need to set it as "http://proxy.mobile.att.net" vs "proxy.mobile.att.net" or something similar like that. It may be worth playing with it a bit to see if your code is even necessary and it may be some sort of parsing error in parse_url() ?