Hi Dimitris,
On Wed, Jan 06, 2010 at 02:49:39PM +0200, Dimitris Karampatsis wrote:
I ‘ve tried to use the latest OpenBSC code with a
nanoBTS at 850 MHz.
great news. I think you might be the first one.
I have been able to compile the code in Debian Linux
and run it
successfully. Mobiles were able to register successfully to the network. In
addition the IMSI and TMSI numbers were collected successfully. However, I
have encountered a few issues that are summarised below:
- Segmentation faults (software crashes) occur in situations where I try
to send an SMS message through the telnet interface or when I try to make a
phone call from one mobile to another
gdb backtraces would be helpful in those cases. I have not seen any of those,
at least not in configurations with a single BTS. The only case I remember
seeing this is when you have multiple BTS in the same location area, which is
currently not supported.
- When sending SMSs from one mobile to another, the
SMS are collected
successfully to the database but are not sent to the other mobile. In the
telnet interface I use the command “SMS SEND PENDING” but nothing happens.
The SMSs are sent to the terminating mobile when either restarting the
OpenBSC software or when the terminating mobile re-registers to the OpenBSC
network
that is strange, and definitely works here.
- IMEI numbers are sometimes not collected
(especially on Nokia phones)
or the wrong IMEI number is displayed
I have also noticed the missing collection of IMEI numbers, but have not yet
debugged it.
Regarding apparent "wrong" numbers: We are inquiring the IMEI, whereas what you
see on *#06# is the IMEISV. It might be that this is the vcase.
I am trying to install a debugger to check why the
segmentation faults
occurs. The only debugger that works is from Netbeans that uses the GDB
debugger. However the debugger hangs when trying to initialise the database
(it stucks in command dbi_initialize(NULL) on db.c file)
Can anyone help why the debugger hangs or recommend a debugger that will
work with this code?
we all work with gdb. What we usually do is to do something like 'ulimit -c
unlimited', then start bsc_hack. When it crashes, it leaves a 'core' file.
You can then start the debugger using 'gdb ./bsc_hack ./core' and see the
backtrace,
navigate through the call stack, etc.
--
- Harald Welte <laforge(a)gnumonks.org>
http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)