Hi,
This a respin of my old series of patches[1], to add decoding of SMSCB
messages on the MS side.
The series defines a new smscb_entity, which can be fed L1 messages from
a CBCH, performs reassembly, and constructs equivalent SMS Broadcast
Command (RSL_MT_SMS_BC_CMD) messages for L3.
I also have a follow-up patch for bb/cell_log which makes use of this
functionality.
Please review and consider for merging, thanks.
[1] http://lists.osmocom.org/pipermail/baseband-devel/2010-November/000834.html
Alex Badea (8):
gsm: add skeleton smscb module
smscb: add unit test for smscb_entity
smscb: process Null messages
smscb test: support a list of L1 messages to test
smscb: add test-case for reassembling a normal message
smscb: add test-case for reassembling a Schedule message
smscb: implement reassembly
smscb: hook into LAPDm
include/Makefile.am | 1 +
include/osmocom/gsm/lapdm.h | 3 +
include/osmocom/gsm/smscb.h | 37 ++++++++
src/gsm/Makefile.am | 1 +
src/gsm/lapdm.c | 13 +++
src/gsm/libosmogsm.map | 5 +
src/gsm/smscb.c | 209 +++++++++++++++++++++++++++++++++++++++++++
tests/smscb/smscb_test.c | 118 ++++++++++++++++++++++++
tests/smscb/smscb_test.ok | 9 ++
tests/testsuite.at | 2 +-
10 files changed, 397 insertions(+), 1 deletions(-)
create mode 100644 include/osmocom/gsm/smscb.h
create mode 100644 src/gsm/smscb.c
When building out-of-srcdir, paths such as "src/gsm" will not find any
source files. Since the Doxyfiles are preprocessed, we can prepend
@srcdir@ to fix that.
Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com>
---
Doxyfile.codec.in | 2 +-
Doxyfile.core.in | 2 +-
Doxyfile.gsm.in | 2 +-
Doxyfile.vty.in | 2 +-
4 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Doxyfile.codec.in b/Doxyfile.codec.in
index fcd5122..1b0df5e 100644
--- a/Doxyfile.codec.in
+++ b/Doxyfile.codec.in
@@ -610,7 +610,7 @@ WARN_LOGFILE =
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.
-INPUT = include/osmocom/codec src/codec
+INPUT = @srcdir@/include/osmocom/codec @srcdir@/src/codec
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
diff --git a/Doxyfile.core.in b/Doxyfile.core.in
index 18eb226..ee58f80 100644
--- a/Doxyfile.core.in
+++ b/Doxyfile.core.in
@@ -610,7 +610,7 @@ WARN_LOGFILE =
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.
-INPUT = include/osmocom/core src
+INPUT = @srcdir@/include/osmocom/core @srcdir/@src
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
diff --git a/Doxyfile.gsm.in b/Doxyfile.gsm.in
index ab25b22..36a6ae2 100644
--- a/Doxyfile.gsm.in
+++ b/Doxyfile.gsm.in
@@ -610,7 +610,7 @@ WARN_LOGFILE =
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.
-INPUT = include/osmocom/gsm include/osmocom/gsm/protocol src/gsm
+INPUT = @srcdir@/include/osmocom/gsm @srcdir@/include/osmocom/gsm/protocol @srcdir@/src/gsm
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
diff --git a/Doxyfile.vty.in b/Doxyfile.vty.in
index 57f19ad..527cdb2 100644
--- a/Doxyfile.vty.in
+++ b/Doxyfile.vty.in
@@ -610,7 +610,7 @@ WARN_LOGFILE =
# directories like "/usr/src/myproject". Separate the files or directories
# with spaces.
-INPUT = include/osmocom/vty src/vty
+INPUT = @srcdir@/include/osmocom/vty @srcdir@/src/vty
# This tag can be used to specify the character encoding of the source files
# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is
--
1.7.0.4
When building out-of-srcdir, "../../config.h" fails to reach config.h
because the compiler is invoked in $builddir/tests/, not
$builddir/tests/timer/. Use "../config.h" instead; this also works
for in-srcdir builds.
Signed-off-by: Alex Badea <vamposdecampos(a)gmail.com>
---
tests/timer/timer_test.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tests/timer/timer_test.c b/tests/timer/timer_test.c
index ba3127d..bb9a177 100644
--- a/tests/timer/timer_test.c
+++ b/tests/timer/timer_test.c
@@ -33,7 +33,7 @@
#include <osmocom/core/select.h>
#include <osmocom/core/linuxlist.h>
-#include "../../config.h"
+#include "../config.h"
static void main_timer_fired(void *data);
static void secondary_timer_fired(void *data);
--
1.7.0.4
Hi,
I just setup a machine running ArchLinux which has a pretty recent
automake/autoconf. libosmocore fails to build. Attached (trivial) patch
fixes that. Someone with a really old toolchain/automake should check
if it breaks setups we consider supported.
Chris
This fixes the following complaint by autoconf 2.69-1, automake 1.13.1-1.
: configure.ac:80: error: 'AM_CONFIG_HEADER': this macro is obsolete.
: You should use the 'AC_CONFIG_HEADERS' macro instead.
: /usr/share/aclocal-1.13/obsolete-err.m4:12: AM_CONFIG_HEADER is expan
: configure.ac:80: the top level
Automake 1:1.11.3-1ubuntu2, autoconf 2.68-1ubuntu2 don't even emit a warning
without, and work just fine with this patch.
Signed-off-by: Christian Vogel <vogelchr(a)vogel.cx>
---
configure.ac | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 24ddd0c..fbc83f3 100644
--- a/configure.ac
+++ b/configure.ac
@@ -77,7 +77,7 @@ AC_DEFUN([CHECK_TM_INCLUDES_TM_GMTOFF], [
CHECK_TM_INCLUDES_TM_GMTOFF
dnl Generate the output
-AM_CONFIG_HEADER(config.h)
+AC_CONFIG_HEADER(config.h)
AC_ARG_ENABLE(talloc,
[AS_HELP_STRING(
--
1.8.1
--VS++wcV0S1rZb1Fb--
From: Sylvain Munaut <tnt(a)246tNt.com>
Currently msgb_pull returns a pointer to the new start of msgb, which
is pretty counter intuitive and when using msgb_pull is often annoying.
For eg, the msgb_pull_u{8,16,32} were previously "fixed" for this quirk
in a previous commit. The msgb_pull_l2h in lapdm is also wrong because
of this, same for code in osmocom-bb loader.
AFAICT, the current users of msgb_pull either don't care about the
return value, or expect it to be a pointer to the pulled header and not
the new start of msgb (and so are currently buggy).
Without this patch, you have things like:
struct foo *bar = msgb_pull(msg, sizeof(struct foo)) - sizeof(struct foo)
With the patch, you have:
struct foo *bar = msgb_pull(msg, sizeof(struct foo));
which is IMHO a much better style.
Signed-off-by: Sylvain Munaut <tnt(a)246tNt.com>
---
include/osmocom/core/msgb.h | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/include/osmocom/core/msgb.h b/include/osmocom/core/msgb.h
index a1939ab..4a72f2d 100644
--- a/include/osmocom/core/msgb.h
+++ b/include/osmocom/core/msgb.h
@@ -287,16 +287,18 @@ static inline unsigned char *msgb_push(struct msgb *msgb, unsigned int len)
/*! \brief remove (pull) a header from the front of the message buffer
* \param[in] msgb message buffer
* \param[in] len number of octets to be pulled
- * \returns pointer to new start of msgb
+ * \returns pointer to header that's been pulled (i.e. previous start of msgb)
*
* This function moves the \a data pointer of the \ref msgb further back
* in the message, thereby shrinking the size of the message by \a len
* bytes.
*/
static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len)
-{
+{
+ unsigned char *tmp = msgb->data;
msgb->len -= len;
- return msgb->data += len;
+ msgb->data += len;
+ return tmp;
}
/*! \brief remove uint8 from front of message
@@ -305,7 +307,7 @@ static inline unsigned char *msgb_pull(struct msgb *msgb, unsigned int len)
*/
static inline uint8_t msgb_pull_u8(struct msgb *msgb)
{
- uint8_t *space = msgb_pull(msgb, 1) - 1;
+ uint8_t *space = msgb_pull(msgb, 1);
return space[0];
}
/*! \brief remove uint16 from front of message
@@ -314,7 +316,7 @@ static inline uint8_t msgb_pull_u8(struct msgb *msgb)
*/
static inline uint16_t msgb_pull_u16(struct msgb *msgb)
{
- uint8_t *space = msgb_pull(msgb, 2) - 2;
+ uint8_t *space = msgb_pull(msgb, 2);
return space[0] << 8 | space[1];
}
/*! \brief remove uint32 from front of message
@@ -323,7 +325,7 @@ static inline uint16_t msgb_pull_u16(struct msgb *msgb)
*/
static inline uint32_t msgb_pull_u32(struct msgb *msgb)
{
- uint8_t *space = msgb_pull(msgb, 4) - 4;
+ uint8_t *space = msgb_pull(msgb, 4);
return space[0] << 24 | space[1] << 16 | space[2] << 8 | space[3];
}
--
1.7.8.6
hi,
just fixed the issue from 29c3, where flashing of phones did not work
anymore. if no one complains, i will apply it.
it is also possible to flash c155 phones. the original compal boot
loader will start firmware at 0x20000 instead of 0x2000 (c123), so i
modified the linker scripts for compal_e99. i am not sure, if all c155
phones behave the same. to check this, i dumped some pages of the flash
memory:
run the loader:
$ host/osmocon/osmocon -p /dev/ttyUSB0 -m c155
target/firmware/board/compal_e99/loader.compalram.bin
start the phone and dump some flash:
$ host/osmocon/osmoload memdump 0x000000 0x30000 dump
a hexdump of that dump showed me where the actual firmware starts:
...
0000800 4f42 544f 392e 2e30 3530 0000 0000 0000
0000810 3031 3330 0101 0000 ffff ffff ffff ffff
0000820 ffff ffff ffff ffff ffff ffff ffff ffff
*
0020000 4f43 4544 392e 2e30 3130 0000 0000 0000
0020010 4c46 5845 392e 2e30 3130 302e 0031 0000
0020020 5352 4b50 392e 2e30 3130 302e 0031 0000
...
i would like to know, if this is true for other c155 phones.
regards,
andreas
Hi,
I'm thinking about why the mobile app don't show me the German GSM-R (MCC: 262, MNC: 10) cells they are around me.
The rssi app shows me the cells (e. g. ARFCN: 957 and 961).
I'm using the sylvain/testing branch and I am searching for more details in the source code and found in settings.c that the r gsm band are enabled and in the freq_list.
Can someone tell me another point for searching in source?
Thanks in advance.
Best regards.
kasio