MMS messages not forwarded

[regaladys]

MMS message is not forwarded,

logs indicate:
Failed to authenticate to server
(Phone number and password may be incorect)

Forwarding SMS messages however works fine.

Forwarding retries are also unsuccessful from the "Pending Messages" selection of the app.

[youngj]

That would seem to indicate that the server is computing a different validation signature from what is generated by the Android app. The POST fields from the MMS parts (i.e. file uploads) shouldn't be included in the validation check algorithm...

Is your server using the EnvayaSMS php server library for request validation or your own code?

If you remove the validation check, does it work?

[youngj]

Also does this mean that sometimes EnvayaSMS does not crash when you receive incoming MMS?

[regaladys]

So far today no app crashes. We've successfully forwarded an MMS before, haven't repeated it though. About the php server library, I'm still checking with the site developer.

[mfb]

Yes, we are using the EnvayaSMS php server library (along with the drupal module)

[mfb]

OK I added some debug code to look at the received vs. expected signature and found there is a mismatch, e.g.
mo555Z5u1HBY5HNkXjmH6VeiPdY= vs. GMCIitXjeCuIgP+6K8FCgIefL5s= I also am dumping the $data array to a file each time we receive a message.

I found this $data array includes $data['mms_parts'] a JSON string describing the MMS parts, as well as the actual MMS attachments: $data['part0'] $data['part1'] $data['part2'] - the last is raw jpeg data. If these MMS parts aren't supposed to be there, then maybe this is the cause for the invalid signature? i don't see any logic in the PHP library to remove these parts from the data array.

This issue is on a phone running Android 2.3.6 - have not seen this issue on my phone running Android 2.3.4

[mfb]

Also, it looks like the file uploads as received from Android 2.3.6 aren't being processed correctly by PHP - not saved to a temporary file etc.

[youngj]

Interesting ... PHP should automatically place part0, part1, part2, etc. in the $_FILES array instead of the $_POST array.

I think that could happen if EnvayaSMS failed to send a filename or content type in the multipart post data.

I'm guessing it's a similar issue to the other MMS bug, where EnvayaSMS attempts to read data from the Android MMS database before it's completely written.

[mfb]

Probably missing filename, because the mms_parts does have content type. I believe $_FILES array is showing up completely empty - there is no numeric 'error', error just does not exist.

i actually can work around this on the PHP side, just need logic to detect when file data is in $_POST, generate a random filename and save it.

[youngj]

If the parts do have a content type, I guess it's probably it's not a timing issue then, maybe just some mms parts don't have filenames. I'll just generate a random filename on the EnvayaSMS side in that case.

[youngj]

Could you install EnvayaSMS-mmstest.apk from https://github.com/youngj/EnvayaSMS/downloads and let me know if that fixes the problem?

It generates a random filename if the filename is empty.

It also should prevent the crash from the other MMS bug. But I'm not sure if it will eventually forward the MMS or not... Could you try it and let me know if you see the log message:

"Ignoring MMS [id] for now because sender number is null"

And if you do get that log message, is the MMS eventually forwarded to the server? If not, try sending another MMS after that, and then is the previous MMS forwarded to the server?

[youngj]

I was able to reproduce this and verify that the fix worked for me. The fix is included in EnvayaSMS version 2.0.5 on Android Market / Google Play : https://play.google.com/store/apps/details?id=org.envaya.sms

The new version is also available on the GitHub downloads page.

[regaladys]

Thanks youngj! It actually worked We've been using it for several days now. :)

[youngj]

Great!

I'd still recommend updating from EnvayaSMS-mmstest.apk to the new release 2.0.5, as it includes additional bug fixes and functionality improvements as noted here: f53ccc3