From: Pablo Neira Ayuso <pablo(a)gnumonks.org>
Hi Harald!
These are the two patches that I'm using to support signalling
and logging in the libraries.
The patch that adds the logging support reworks your previous
contribution so we only keep the logging subsystem in libosmocore,
instead of the full definition of the logging subsystem.
See patches descriptions for further details.
Let me know if you're OK with these changes.
Pablo Neira Ayuso (2):
signal: reserve signal subsystems >= 64 for libraries
logging: rework definition of logging subsystems for libraries
include/osmocom/core/logging.h | 22 ++++++--
include/osmocom/core/signal.h | 23 +++++++++
include/osmocom/gsm/gsm.h | 6 ++
src/gsm/Makefile.am | 2 +-
src/gsm/init.c | 22 ++++++++
src/logging.c | 107 ++++++++++++++++++++++-----------------
6 files changed, 129 insertions(+), 53 deletions(-)
create mode 100644 include/osmocom/gsm/gsm.h
create mode 100644 src/gsm/init.c
--
1.7.2.5
Hi all,
I have been working on a project involved using osmo-nitb and trying to read / send SMS by doing SQL queries directly hlr.sqlite3 in a perl program, but I cannot figure out the encode/decode process on the "user_data" field.
From "sms_from_text" function in libmsc/gsm_04_11.c, it appears to me that the content of user_data is a gsm_7bit_encode-ed of text if the SMS is sent with VTY interface. I then tried to port gsm_7bit_decode to perl and the implementation successfully decoded two test strings in libosmocore/tests/sms/sms_test.c. However it does not successfully decode any SMS user_data record in hlr.sqlite3 to the original text. The result looks like just a piece of garbled text, not even close to any human-readable text at all.
I also tried briefly to include gsm0338 decoding process, or some other perl-based implementation from CPAN, no success at all. I am currently out of ideas to try.
It will be really appreciated if anyone with similar experience can offer insight to my issue here.