Troubleshooting and Understanding MMS

[epiii2]

I'm trying to figure out what my options might be for handling incoming MMS messages, with the understanding that they're not really supported by most software at the moment but there are some workarounds in use (like jmms for example). When I try out some test messages I can see the encoded data arrive via SMS and I can extract it to a file, but I'm stuck trying to make use of it because it doesn't seem to be formatted like other examples I see online. Does anyone have any experience they can share?

For example, here's what I see for a few MMS messages I sent myself the other day:

Code:

$ mmcli --messaging-list-sms -m 4
    /org/freedesktop/ModemManager1/SMS/2 (received)
    /org/freedesktop/ModemManager1/SMS/1 (received)
$ mmcli --messaging-list-sms -m 4 -s 2
  ----------------------------
  General    |          path: /org/freedesktop/ModemManager1/SMS/2
  ----------------------------
  Content    |        number: XXXXXXXXXX
            |          data: 000603BEAF848C82983046303633443133454142373030303032413630303030313031008D908A808E0278008805810306977F83687474703A2F2F36332E35352E312E38372F736572766C6574732F6D6D733F6D6573736167652D69643D00891680XXXXXXXXXXXXXXXXXXXX2F545950453D504C4D4E00
  ----------------------------
  Properties |      pdu type: cdma-deliver
            |          state: received
            | teleservice id: wap

(Just with the sender and receiver number Xd out.) And I can also dump that data chunk to a file like so and get the binary for that hexadecimal glob:

Code:

mmcli -m 4 -s 2 --create-file-with-data message.sms

...but in any case the contents of the binary don't seem formatted the way tools like jmms expect. For example doing a hexdump on another test message:

Code:

00000000  00 06 03 be af 84 8c 82  98 30 35 30 36 33 44 35  |.........05063D5|
00000010  37 42 45 35 33 30 30 30  30 37 34 35 30 30 30 30  |7BE5300007450000|
00000020  31 30 31 00 8d 90 8a 80  8e 02 78 00 88 05 81 03  |101.......x.....|
00000030  06 97 7f 83 68 74 74 70  3a 2f 2f 36 39 2e 37 38  |....http://69.78|
00000040  2e 38 38 2e 31 30 32 2f  73 65 72 76 6c 65 74 73  |.88.102/servlets|
00000050  2f 6d 6d 73 3f 6d 65 73  73 61 67 65 2d 69 64 3d  |/mms?message-id=|
00000060  00 89 16 80 XX XX XX XX  XX XX XX XX XX XX 2f 54  |....XXXXXXXXXX/T|
00000070  59 50 45 3d 50 4c 4d 4e  00                       |YPE=PLMN.|
00000079

So... what is this weird format? The main thing I see is that URL pointing to a Verizon server where I can hypothetically get the contents of the MMS (I think?) but I don't know what these other mostly-binary chunks are, aside from the sender's phone number and /TYPE=PLMN. The Verizon server never seems to respond to me no matter what I send (via wwan0, too, as I've read about elsewhere) but maybe I don't know what I'm supposed to give for the message ID. Any tips?

[treebeard]

Chatty has supported MMS since v0.6.  The APN configured in chatty needs to match the APN selected in gnome settings.  Here's some info relevant to Mobian.  What OS are you using?

Edit 1: for Verizon, make sure you're using the "vzwapp" APN.

[brb78]

Edit 1: for Verizon, make sure you're using the "vzwapp" APN.

I think that's a recent change after some update, I had "vzwinternet" designated in my config and working for months then it stopped around end of April. Saw your comment, thought it was contrary to what I had had working, but as it turns out I can't seem to get MMS to work on "vzwinternet" any more, only "vzwapp" APN

[treebeard]

Edit 1: for Verizon, make sure you're using the "vzwapp" APN.

I think that's a recent change after some update, I had "vzwinternet" designated in my config and working for months then it stopped around end of April. Saw your comment, thought it was contrary to what I had had working, but as it turns out I can't seem to get MMS to work on "vzwinternet" any more, only "vzwapp" APN

Yeah, vzwinternet -> vzwapp is pretty recent and the documentation and various guides haven't caught-up.

[epiii2]

Aha!  Thank you both.  I'll bet this is the issue.  I had no idea Chatty or whatever else beyond the modem part would need to know about APN details for its own purposes... I guess because it goes and fetches the MMS contents for itself from the encoded URL?  (And the carrier might only respond to the HTTP request when it's arriving via the right access point?  I had no idea how MMS messages actually worked until looking into all this.  What a mess!)  I'll play around with this and see if matching up the right APN gets it going.

And for completeness' sake: this is on Manjaro + Phosh (via a recent p-boot-demo image) with Chatty 0.6.0_beta-20-g848e35e5+.  (I'm not strongly attached to any particular combination of software at the moment, just going with whatever seems to work best as I figure these things out.)

[epiii2]

A couple of clarifications while I'm reading that Mobian document and trying things out:

• I was a little off-base in what I said before: It's not Chatty itself that handles the APN details, I think Chatty just provides a pretty interface to edit $HOME/.mms/modemmanager/mms.  So that makes sense.
  
• Apparently I actually have mmsd-tng running already via /usr/bin/mmsdtng (launched from Chatty? not sure)
  
• I can't get any mobile data at all on the "vzwapp" APN, only "vzwinternet".  Maybe I just need the MMS APN config to match that, and for some reason my phone wants to be on vzwinternet instead of vzwapp (?)  These APNs are still a bit of a mystery to me.
  

I may have trashed my Manjaro install from some unrelated fiddling with packages and filling up the filesystem, so at the moment Chatty segfaults a few seconds after starting up.  I might just flash this whole card again and start with a clean slate and go from there.

[epiii2]

Getting closer.

My APN can be either vzwinternet for regular mobile data, or vzwapp for MMS.  I can't seem to get both things working at the same time on one APN.  If I'm on vzwinternet, HTTP requests for MMS contents (more on that below) hang forever.  If I'm on vzwapp, those special HTTP requests work, but regular internet traffic goes nowhere.  I think this situation might be described in the mmsd-tng README:

Please note that due to limitations of Modem Manager, mmsd-tng does not support having multiple APNs at the same time (for carriers that seperate MMS APN from Mobile Data APNs).

That seems like what I'm seeing, though I don't know why Verizon is giving me this treatment when it's working under one APN for other people.  But I'll set that aside for now.

So, when I have vzwapp selected and configured in the mms config file, Chatty launches and runs for a few seconds... and then segfaults.  I had thought that was my fault and something about package managment but it turns out it's related to the MMS situation.  I see log entries in journalctl where it looks like mmsd-tng is parsing my test messages so I'm wondering if the problem is with Chatty itself.

Trying another angle I poked around with the python-messaging package the Mobian doc links to.  It doesn't quite work due to Python version issues but it does manage to parse the headers from a message, and I can see I was 99% there with the hexdump earlier-- the only missing piece was being on the right APN.  I can fetch the actual MMS contents with curl that way, putting together the URL and the hexadecimal message ID.  That gives me a glob of binary and XML weirdness that seems to have the elusive JPEG inside it.  So I guess I have a handle on the cellular/mobile aspect and can narrow this down to a software problem with Chatty and/or mmsd-tng.  I'll keep at it and see what I can do.  Thanks again for your help you two.

[treebeard]

If I'm on vzwinternet, HTTP requests for MMS contents (more on that below) hang forever.  If I'm on vzwapp, those special HTTP requests work, but regular internet traffic goes nowhere.

Crap!  I'm seeing that same behavior.  I noticed a couple days ago that Firefox didn't seem to be working anymore and put it aside for this weekend.  I guess this was the first time using mobile data since I switched the APN to vzwapp a couple weeks ago.

Brief testing seemed to show that I could set vzwapp to autoconnect and use as the default, then switch to vzwinternet in gnome-settings if I need to use mobile data.  Any MMS messages then get stuck until I switch back to vzwapp.  I think I can live with that in the short run but in the long run I'll vote for handling the dual APNs.  I'm going to research a possible DNS problem here too.

I haven't seen any segfaults (yet) but with the general flakiness I've seen in the mobile stack, I suspect switching APNs back and forth more than occasionally will probably FUBAR the modem (or related software) and require a reboot.

[treebeard]

Using vzwapp versus vzwinternet result in their DHCP servers using different subnets, so the phone gets different ipv4 and ipv6 addresses, gateways and routes.  Both use the same DNS servers, though.  When attempting to access the broad internet via vzwapp, DNS resolution succeeds but the connection never opens. 

I'm thinking that this is working exactly as Verizon intended.  I've seen comments regarding another carrier with dual APNs that it was done to separate the free stuff from the metered stuff and that seems plausible.

One effect of using vzwapp as the default APN is that chrony is unable to sync the time.  I've lately been working on getting location services to work and suspect my use of vzwapp may have been hindering it.  It seems like it would be fairly simple to write a script to check periodically for "stuck" MMS messages and display a message when found so that I could use vzwinternet as the default and just switch to vzwapp when I need to read and reply to MMS.

mmsd-tng was waiting for dual APN support in modemmanager 1.18 (it's in mobian bookworm) but apparently there are also changes needed in network manager now.

[epiii2]

OK, good to know we're seeing the same thing.  I had the same thought about just swapping APNs for the time being, but I'll have to watch out for issues like that thing with time syncing or the modem getting confused.

I also realized my Chatty crashes actually aren't even related to any particular MMS messages.  It happens as long as I'm on the vzwapp APN, and then I have to reboot to get it working again-- just switching APNs back doesn't do the trick.  Looks like I'm a few versions behind with Chatty at this point, so maybe my first step should be getting everything up to date and then I'll troubleshoot from there.  (Unless the latest version fixes it!  I can hope.)