nad6234 | # 1 | 2014-07-09, 10:31 | Report

I've had a few problems when I've not been receiving SMS txt messages. it's been intermittent but I have new narrowed it down to those that contain any Emoji symbols in them. i need seem to get them. i've also checked the events db and the message isnt in their either. has anyone else come across this?

---

Last edited by nad6234; 2014-07-09 at 10:33.

juiceme | # 2 | 2014-07-09, 11:27 | Report

Oh, it's probably the same problem I discovered on N9 while back.

Handling of the emoticons charset generated by Lumia range of devices, for example, fails in the receive/decode phase of the message and processing is aborted.

Why this is really bad is because the sender of the SMS gets the network confirmation that the message has been succellifully delivered, but the receiver never sees a trace of the message...
(well there is a syslog entry saying "cellular: csd[653]: SMS-lib .648529> utils_tpdu_data_parse(): Error decoding TPDUs. Discarding message" ... but a normal user would never look into syslog anyway!)

This breaks the trust paradigm of SMS, the undeniability of receiving a message.

Funny thing is, this was discovered/reported when N9 was still under maintanance but it was never corrected, even though it violates the 3GPP specification on charater message processing...

reinob | # 3 | 2014-07-09, 13:05 | Report

BS!

SMS is and was never intended as a reliable means for sending texts between users. For all intents and purposes it's like sending a datagram per UDP. If it doesn't arrive, or arrives mangled, it's your problem.

nad6234 | # 4 | 2014-07-09, 13:09 | Report

@juiceme is it possible to patch / intercept the decoding? I'm a software developer (C/C++ since 1990s) so might be able to fix the bug?

Also whereabouts is the syslog located in Maemo?

juiceme | # 5 | 2014-07-09, 16:29 | Report

well, BS yourself

You are basically correct in drawing an analogy there between an UDP datagram and a SMS message; both are just messages that are "sent there, godspeed", however, on top of both you could build reliable protocols, and the keyword here is the ACK.

When you send an SMS, and never receive any kind of confirmation, you are in the dark; it might be that the recipient got the message or not, you'll never know.

But if you get the confirmation of delivery message, you well can be 100% sure the message was received by the UE of the B-subscriber, and it signalled the RNC of its location area that the message has been received, loud and clear.

Now this problem here we are discussing breaks that paradigm; the message is received correctly by the UER-B signalling stack, and an acknowledge is sent to RNC counterpart. However, after that, the message is silently destroyed, never to be seen by the recipient.

This is a clear A-class pronto that should be corrected soonest. And if not, hurried by redhat-flag and 2nd-tier management escalation...

juiceme | # 6 | 2014-07-09, 16:52 | Report

Sorry, I only can comment this from Harmattan point-of-view, never having had the pleasure of owning a N900 device.
On Harmattan the buggy piece of code resides in /usr/lib/libsms.so.0.0.0 but as that is proprietary closed piece of code there's no way I can fix it...

If I had the source, I am sure I could fix da bug, test it, and package a correction in 2 hours tops ( + the time to set up my scratchbox installation, it's been while since I last compiled anything for Harmattan and it sure has rotted a bit...)

This is prime example why closed source is evil. The bug is probably just string length check failing when decoding input that contains multibyte characters...
The correct way for the messaging stack to handle this kind of exception is definitely not throwig its spoon to the corner and start crying, it should try to salvage the bits of the message it can decode, and replace the rest with "garbage chars"
On Symbian this works as expected, the multibyte chars end up looking like squiggly boxes but the 7-bit ascii part of the message is shown correctly.

Ilew | # 7 | 2014-07-09, 20:42 | Report

Syslog is located in /var/log/syslog if you have it installed.
http://wiki.maemo.org/Documentation/.../maemo5/syslog

nad6234 | # 8 | 2014-07-09, 20:49 | Report

@juiceme i know that closed source is frustrating but there is another way here. Take a look at this:
maemo.org/community/maemo-developers/advice_wanted_on_the_best_way_to_package_cell_broa dcast_sms_bugfix_for_closed_libsms_library/

This looks like a possible approach!

juiceme | # 9 | 2014-07-09, 22:17 | Report

Possible but tedious

The thing is, you'd have to fulfill all dependencies, both in and out the library. It's doable but I don't like that approach.

mikegioia | # 10 | 2014-10-05, 15:23 | Report

Was anyone able to figure this out? I recently confirmed the same problem receiving emojis sent from an iPhone to my n900.

At the very least, even if the payload was logged somewhere I could write a script to periodically read it and add the message to the rt-event DB.