Receiving "garbage" from Modem on MMS receive attempts

[brennana]

Ever since installing this modem firmware, I have had issues receiving MMS messages (both versions 0.6.1 and 0.6.4). SMS messages have been fine, however. While I cannot be completely certain that this is the fault of the firmware, I do receive some odd "garbage" text from the Modem via its SMS number, each time I should be getting an MMS.

To illustrate, I sent a single MMS message to my phone from another number. I immediately receive a message from the Modem (at +015550199999 of course), but the message always takes the form ??8l)4W0@??? with small variations at times (such as ending in ?H? instead of ???). In 0.6.1, this garbage seemed to take the form ìè8l)4W0¡ΔHè, again with small ending variations.

After receiving this single garbage message, and usually after a 15-20 minute delay, I will receive an MMS "notification" from the appropriate sender in Spacebar, so that I can download the message from my network's MMS servlet, but this message is never downloadable, and so ultimately I cannot view the message, regardless of whether it is an image or group text. I do not think this is a bug in Spacebar, as this used to work in the past before flashing this firmware.

Exactly 5 minutes after receiving the garbage Modem message, two lines are generated in the ModemManager log:

May 09 18:02:28 pinephonepro ModemManager[3702]: transaction 0x1b aborted, but message is not abortable
May 09 18:02:31 pinephonepro ModemManager[3702]: transaction 0x1e aborted, but message is not abortable

Here also is the OpenQTI log from beginning to end upon receiving the single MMS message: openqti.log

Let me know if there's any further information I can supply regarding this. I did not find any relevant dmesg logs generated during this message transaction.

Phone: Pinephone Pro w/ Manjaro Plasma Mobile Firmware ver: 0.6.4 (previous versions had issues, too) Spacebar (PlaMo SMS app): 22.04 (tested on 22.02 before and after flashing this firmware)

[Biktorgj]

Hi! Really interesting! OpenQTI is misjudging a QMI message and interpreting it as a cell broadcast message, that's why you receive the "garbage" message wheever you get an MMS.

The message type is the same, and the header matches (in principle), so Openqti catches the full message, tries to decode it (which it cannot do because data isn't what it thinks it is), and sends whatever it can.

Without more data is difficult to guess if the "transaction aborted" is related to this or not, as I coded CB message relay speficially so it would still push the message to ModemManager for processing, and that error happens much later, but it's possible that the fact that it tries to inject a SMS while the MMS transaction is in progress is messing up things

This test image should ignore that type of event report, could you flash this and try sending yourself another MMS? (Meant to be flash on top of current 0.6.4)

package_test.tar.gz EDIT: Reuploaded to include the flashing script SHA512: b548f98d97e0e582fc38d25dd887d224bb089bcc1cc81c56b83ba9b4a1c6ed9a2aae1eac69b813868a51819de43b5298e78aba613e263abd2a59730bd1bcac0d package_test.tar.gz

[brennana]

I flashed the package_test images to the Modem, and indeed this squelches the "garbage" messages from the Modem. It also seems to have squelched the "transaction aborted" messages from ModemManager as well. It looks like the Modem is otherwise handling the MMS transaction appropriately. Thanks for the quick patch!

Any further issues I'm having with MMS seem to be a cellular network problem, as the servlet simply connects, but times out in response to requests, so I doubt at this point it has anything to do with the firmware. I guess it just broke around the same time I flashed this firmware.

[Biktorgj]

Well at least we removed part of the problem :) About the MMS actually being downloaded, two possible issues come to mind:

1. The PinePhone is trying to download the message through wifi and your carrier only allows downloading trough the cellular interface, so it times out because it doesn't come from "inside" the carrier network
2. The APN you have set is configured to access the internet, but the MMS APN doesn't work or isn't being applied

Option 2 I don't know if it's still the case, but ModemManager didn't have the capability to use different APNs for different things (maybe that's implemented by now), so if your carrier used a specific APN for MMS that could be a reason why it isn't working. Testing it should be simple enough, add the MMS APN if there is one for your carrier, select that instead of your default and try to re-download the message

[brennana]

Indeed, Spacebar has the issue in (1) where WiFi must be disconnected in order to download from the wwan, but this used to work without fail before, even over my network's internet-bound APN. I'm not aware that my network has an MMS-specific APN (Verizon US, over which I used to download MMS from vzwinternet APN).

The curious thing is that the the IP address that my phone contacts to download MMS over wwan indeed connects (according to cURL, connection is established to the MMS servlet, and the appropriate message-id is sent in HTTP request, but the server simply does respond after connect/request). So, I can see the server, but it no longer talks back now, not even with an HTTP error code. I've tested this with daemons such as mmsd-tng, and its attempts to download messages over wwan similarly time out.

[Biktorgj]

I have a very limited knowledge of MMS internals, but I seem to remember you needed a specific user agent if you were to manually retrieve a MMS, so if that wasn't included in the header or the server doesn't understand which user agent you're using it might kick you out.

When sending an MMS, the modem (again, if I recall, didn't really look deep into it), uses a Nokia provisioning profile + User agent, if you were using the modem directly to send an MMS. You're probably using mmsd from the PinePhone itself (as far as I know all distros do it this way), so best hint I can give you is to take a look at the settings in .mms/modemmanager/mms, and check mmsd logs.

In any case, given the two events happened mostly at the same time, you can also go back to stock and recheck if MMS works with stock (it shouldn't, but just in case...). If it does and the difference is my firmware, I'll have to go down the rabbit hole with that :)

[brennana]

Just to be sure, I tried this again on the stock firmware with the same results on Spacebar/mmsd-tng. Looking closer at the logs from mmsd, specifically it can connect to the VZW mms servlet, but after sending down its request, it errors each time with HTTP/1.1 7 Connection terminated unexpectedly. I guess Verizon has perhaps done something to block my requests, or have further complicated request requirements, but it's not really possible to tell why this is happening.

Thanks for all your help with this, and thanks for the superior modem firmware!

[thw26]

Just to note, Plasma Mobile's Spacebar does not use mmsd-tng.

[brennana]

Just to note, Plasma Mobile's Spacebar does not use mmsd-tng.

Indeed, that's why I was using both to test this strange MMS servlet problem (ultimately it has nothing to do with the choice of MMS application).

[ghost]

just so you know Verizon mss does not work atm because it uses duel apns

[Biktorgj]

Closing this now since there's not much more we can do about it here. Still, feel free to reopen/comment if you find a fix for Verizon :)