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.