Comment 1 Ryan Abel 2010-01-21 07:41:44 UTC

Context: http://en.wikipedia.org/wiki/Cell_Broadcast

*** This bug has been confirmed by popular vote. ***

Is this a missing function in libisi or pnatd or is even cellmo firmware not
capable of handling it?

at+CSCB=1,"",""
ERROR

Whatever it is - will this eventually see a fix? As OP mentioned, this is an
increasingly important feature, and I dare to say (without confirming in the
specs) it's also mandatory according to 3GPP.

There is code in the N900 driver in ofono/MeeGo (written by Nokia) that
supports Cell Broadcast.

I have a plan to write some code to support Cell Broadcast inside the default
N900 stack.
It would be possible to write this by using the isi code from ofono, hacking
the ofono cbsms isi code to sit on top of it and out of that creating a
dbus-enabled Cell Broadcast daemon which could then be accessed by a userland
app to display incoming Cell Broadcast as appropriate.

However this would completly bypass the telephony stack and its unclear what
effect that would have on the normal phone functions and whether it would get
in the way.

What I would ideally like to be able to do is to wire the Cell Broadcast
support into the normal Fremantle telephony stack so it works properly with
everything else.
In order to do this I would require the following at a minimum:
development packages for libisi1 and libisi-glib0 (to talk to the cellular
modem)
development package for csd-base (to talk to the csd daemon)
development package for libsms-utils0 (to help with decoding and parsing of the
CBSMS messages)

It would be very usefull (if at all possible) to have information on/code for
libsms0 and csd-sms. This would serve as an example of how to talk to libisi
and csd as well as being able to identify if the SMS code already handles Cell
Broadcast (and to be sure that we dont have 2 different things both trying to
claim ownership of the cellular modem SMS interface in ways that would
conflict)

Lastly it would be nice (but not essential) to have code/headers/etc to allow
the Cell Broadcast functionality to be plugged into telepathy.

Having this stuff would also allow for support of other features supported by
the cellular modem but not by the linux side (if any) to be written and added.

I can provide more information if required

For reference, some of the reasons to have Cell Broadcast support:
1.Displaying the cell tower ID/name (many operators transmit such things)
2.Some operators use Cell Broadcast SMS to alert customers that they are in a
special home zone and can get cheaper rates than usual
3.Some authorities use Cell Broadcast to send emergency alerts for disasters
(fires, floods etc) so people can evacuate in time

Cell Broadcast is supported by many phones (including my mums old B&W-screen
Nokia) and its embarrassing that a flagship Nokia phone doesn't support this
feature.

Further examination indicates that most of the Telepathy framework is open
source with the exception of the telepathy-ring package.

I do not know if we would need code for/info on telepathy-ring, sms-manager or
both in order to handle Cell Broadcast SMS or whether it can be plugged in
using the Telepathy code we already have.

Further analysis indicates there is code in libsms.so.0 to do something with
Cell Broadcast. Functions like sms_gsm_cb_routing_req, sms_gsm_cb_routing_ntf
and sms_gsm_cb_routing_resp and strings like "%s(): Incoming cell broadcast
receive status:%d %s" and "%s(): Incoming cell broadcast" indicate that libsms
is doing something with Cell Broadcast messages. What its doing and where the
messages go I dont know.

I am unable to investigate further as it appears as though my phone carrier
doesn't even transmit the cell location/cell ID Cell Broadcast messages from
their 3G towers (I could try and force the N900 to connect to their 2G towers
which do transmit Cell Broadcast location messages but I dont know if that
would actually get the towers to send me Cell Broadcast messages or not)

Without more info on whats going on inside libsms/csd-sms (e.g. libsms and
csd-sms source code :), we cant really do more.

We would also need to find someone who knows 100% that the towers (3G or
otherwise) that they are talking to with their N900 DO transmit Cell Broadcast
messages (that would be received by their N900 if the N900 had full support for
this feature).

My provider O2 Germany definitely is sending SMS-CB, at least when I checked 2
weeks ago, on 2G.
So if you got any specific things to check, just ping me and toss over a
cmdline or link
jOERG

Some further analysis shows that there is something exported over dbus by the
csd-sms plugin on com.nokia.phone.SMS /com/nokia/phone/SMS

This then exports an interface called Phone.SMS and on this interface is a
signal called IncomingCBS
This seems to pass in the following arguments:
array of bytes
uint32
uint32
byte
byte
byte

Looks like we need someone who knows how to talk to dbus signals (and who's
carrier is definatly sending Cell Broadcast) to try and talk to this signal and
play with it. Or possibly someone at Nokia can examine the csd-sms code and
provide details of what the different arguments mean :)

I can confirm that the n900 running Fremantle does trigger the IncomingCBS
signal (or so says dbus-monitor)

Now we just need to figure out the parameters and write something like a status
bar widget to handle the CBS stuff.

Some analysis shows that the IncomingCBS signal is broken.
So what is needed is to write some new code to do Cell Broadcast SMS.
In order for this to be written, we need packages (or reverse engineered 
packages) for libisi-dev, libisi-glib-dev and csd-plugin-dev at a minimum.
libsms-dev may also be required.

For the user-space app, headers/dev packages for
libconnui,libconnui-cellular,libconbtui0,connui-conndlgs may be required to
handle stuff like airplane mode.
libsms-utils-dev may be useful to handle decoding the SMS (e.g. converting the
GSM alphabet into Ascii)

to add info:
dbus-monitor --system gives me

signal sender=:1.20 -> dest=(null destination) serial=3799
path=/com/nokia/phone/SMS; interface=Phone.SMS; member=IncomingCBS
   array [
   ]
   uint32 0
   uint32 221
   byte 0
   byte 17
   byte 255

which has a valid channel number of 221, but clearly doesn't hold any string of
some 12 digits as I know is the format transmitted on this SMS-CB channel.

On German provider O2 channel 221 is used to calculate a thing called
"homezone" which changes behaviour and billing of your phone a lot when you are
inside a clearly defined small area. 
This usually is done in SIM application toolkit, but that's not supported by
N900 so we could do it on application processor as well.
It is highly desirable to be able to show user if she's inside homezone or not.
For this to accomplish we need proper SMS-CB signalling.

I request either fixing this if it's a bug, or disclosing enough of sourcecode
to enable community to fix the bug, or share documentation how to implement
SMS-CB properly if that's not a bug but simply a poor understanding of how to
interface the telephony stack.

Thanks

The bug is this:
The cell modem sends libsms.so a SMS_GSM_CB_MESSAGE structure
This contains a field info_length.
The cell modem documentation says "Value 255 indicates that this parameter
should be ignored"

The code in libsms.so (in a function called sms_gsm_cb_routing_ntf) sets a
field in a structure (call it length) to the value of info_length. If
info_length is 255, the code sets this "length" field to 0.

This is wrong, based on my analysis of the code, this field should be set to
SMS_CB_MESSAGE_CONTENT_SIZE (i.e. 0x52).

What happens is that the "length" field in this other structure is later passed
to DBUS as the length of an array. This means when something talks to the
IncomingCBS signal, DBUS does not copy any actual data for the SMS message.
(the test Cell Broadcast messages I have dumped all have the info_length field
set to 255)

There are 4 ways to fix this bug and get Cell Broadcast SMS working:
1.Nokia finds the problem in libsms.so (or in libcsd-sms.so if that's where the
real problem is), fixes it and pushes a new package we can use
2.Nokia publishes the source code to libsms.so or libcsd-sms.so (or both) along
with all the headers required to recompile it and we fix the bug ourselves and
recompile it
3.Nokia publishes packages for libisi-dev, libisi-glib-dev and csd-plugin-dev
(or someone reverse engineers all the needed functions) and someone writes a
new CSD plugin that implements the Cell Broadcast stuff.
or 4.Someone writes something that handles Cell Broadcast outside of the CSD
daemon and infrastructure

(In reply to comment #13)

> 1.Nokia finds the problem in libsms.so (or in libcsd-sms.so if that's where the
> real problem is), fixes it and pushes a new package we can use
> 2.Nokia publishes the source code to libsms.so or libcsd-sms.so (or both) along
> with all the headers required to recompile it and we fix the bug ourselves and
> recompile it
> 3.Nokia publishes packages for libisi-dev, libisi-glib-dev and csd-plugin-dev
> (or someone reverse engineers all the needed functions) and someone writes a
> new CSD plugin that implements the Cell Broadcast stuff.
> or 4.Someone writes something that handles Cell Broadcast outside of the CSD
> daemon and infrastructure

5. you patch the function in the binary, I wouldn't expect Nokia to care
anymore about the N900, does not run MS-certified code.

6. you provide a preload library that patched bug in the running binary.

I admit 5/6 seem like ugly hacks, but then you've already done the work to
disassemble the thing, would be my guess.

yacc

from syslog:

Feb 18 19:38:11 IroN900 cellular: csd[784]: ISI_SMS .677887> ind_reg_status():
Net registration (ind) status:1 rc:0
Feb 18 19:38:11 IroN900 cellular: csd[784]: ISI_SMS .679169> set_timeout():
Timeout 3541 s event type:-1
Feb 18 19:38:14 IroN900 cellular: csd[784]: ISI_SMS .239563>
incoming_cell_broadcast(): Incoming cell broadcast

This or similar sequences to be found all over

Comment 16 Andre Klapper 2012-03-24 11:45:05 UTC

The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
enhancement/wishlist request. 
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)

Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).

There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates. 
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
https://bugs.maemo.org/enter_bug.cgi?product=Maemo%205%20Community%20SSU .
Please note: The Maemo CSSU project is not related in any way to Nokia.


( Tag for mass-deleting bugmail: [cleanup20120324] )