07-24-2022, 07:30 PM
(07-24-2022, 07:31 AM)treebeard Wrote: The files in ~/.mms/modemmanager/ are MMS messages that are being processed.
My understanding of the process for receving a MMS: ModemManager gets a special SMS. It puts that raw message in a file in ~/.mms/modemmanager/ and then creates a similarly-named ".state" file with metadata for that message. MMSDTNG then attempts to process those messages, which are mostly just a URL where the actual content can be retrieved from the carrier. The MMS data expires after about 5 days (for Verizon) so if MMSDTNG can't get it by then, you'll never get it. I wonder if that's what the 404 might be? Seems like MMSDTNG should be smart enough to quit trying the expired messages, though.
This rings true for me mostly, although I do think they expire after ten-twelve days (something slightly shorter than two weeks), not five.
Quote:Things to try:
1) You'll see entries in the logs like "Using URI for request: http://63.55.99.247/servlets/mms?message...XXXXXXXXXX". Open a shell and use curl or wget to get the contents of that URL, or see what error happens.
The funny thing, now that I look at it is that there is nothing after:
Code:
http://63.55.99.247/servlets/mms?message-id=
Also, when I look at the files in .mms/modemmanager/ there is something there after message-id, but it looks kind of like a binary with a phone number appended to the end (the phone number, FWIW, seems accurate, based on the messages I expect to be receiving.)
Quote:2) do a "ip route get 63.55.99.247" (or whatever IP is appropriate) on the phone to see if it has a viable route to the carrier's server.
I will try this later.
I will try and add more detailed logs later.
At any rate, I feel some relief knowing I have some more debugging options.