Hello, I'm working with OpenBSC since 2 month. Currently my OpenBSC setup runs with 2 mobile phones which can communicate A5/1 encrypted with each other. I got several problems while running this system with a NanoBTS. I use osmo-nitb. Entries in my HLR receive wrong time values. The time values of the column "created" and "updated" are exactly 2 hours earlier than they should be. The system time of the controller works fine and the time in the logs from "./osmo-nitb -e 1 -T" is correct. Are there any other timers which work with the NanoBTS? Furthermore my network does not run stable. Sometimes following error occurs : input/ipaccess.c:454 Bad signalling Message, sign link returned error input/ipaccess.c:260 Forcing socket shutdown with no signal link set The error usually appears after some authentification "traffic". Sometimes the system runs stable for several hours without any errors. The error leads to a restart of the connection. I'm not sure if this problem has something to do with the first problem. thanks and best regards! Nicklas
Nicklas Boecking wrote:
input/ipaccess.c:454 Bad signalling Message, sign link returned error hi nicklas,
i get these message too somtimes. i just put "return 0;" right below line 454 at ipaccess.c of libosmo-abis to ignore it. then it works. i know that this is not a solution. it would be better to check the message and implement/fix it, or better handle unknown messages correctly. regards, andreas
On Tue, Oct 16, 2012 at 10:51:32AM -0700, Nicklas Boecking wrote:
Furthermore my network does not run stable. Sometimes following error occurs :
input/ipaccess.c:454 Bad signalling Message, sign link returned error input/ipaccess.c:260 Forcing socket shutdown with no signal link set
I strongly suggest you take a pcap capture file (like "tcpdump -ni eth0 -s0 -w/tmp/my.pcap") and figure out which exact message is causing the problem. Then you forward the relevant portion of the pcap file to this list. -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
2012/10/18 Harald Welte <laforge@gnumonks.org>
On Tue, Oct 16, 2012 at 10:51:32AM -0700, Nicklas Boecking wrote:
Furthermore my network does not run stable. Sometimes following error occurs :
input/ipaccess.c:454 Bad signalling Message, sign link returned error input/ipaccess.c:260 Forcing socket shutdown with no signal link set
I strongly suggest you take a pcap capture file (like "tcpdump -ni eth0 -s0 -w/tmp/my.pcap") and figure out which exact message is causing the problem. Then you forward the relevant portion of the pcap file to this list.
I've attached a trace, no. 35 (data indication) seems to cause the drop. Regards, L.M.
Hi Lennart, On Sun, Oct 21, 2012 at 08:57:31PM +0200, Lennart Müller wrote:
2012/10/18 Harald Welte <laforge@gnumonks.org>
I strongly suggest you take a pcap capture file (like "tcpdump -ni eth0 -s0 -w/tmp/my.pcap") and figure out which exact message is causing the problem. Then you forward the relevant portion of the pcap file to this list.
I've attached a trace, no. 35 (data indication) seems to cause the drop.
I'm a bit puzzled by this. "MM STATUS" is handled by gsm48_rx_mm_status() which unconditionally returns '0', i.e. our return value for success. gsm0408_rcv_mm(), the calling function, clearly returns this return value of '0' up to the caller gsm0408_dispatch(), which again returns it to its caller. So from what I can tell in the code, I don't see an obvious path how that message should ever return -1 to libosmo-abis, which then drops the link. It would be useful if you could spend some more time to try to hunt this down, possibly by printing a backtrace using "osmo_log_backtrace(DLINP, LOGL_ERROR)" around line 455 of libosmo-abis/src/input/ipaccess.c within in the section/clause: if (e1i_ts->line->ops->sign_link(msg) < 0) { ... } which is where the 'Bad signalling message' error message is printed first. The backtrace will only be addresses, and you would have to use the symbol table to figure out which function caused it (e.g. by using objdump). Pablo: It actually would make sense to include this call to osmo_log_backtrace() as a default in libosmo-abis, what do you think? Regards, Harald -- - Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
Hi Harald, On Mon, Oct 22, 2012 at 10:22:45AM +0200, Harald Welte wrote:
Hi Lennart,
On Sun, Oct 21, 2012 at 08:57:31PM +0200, Lennart Müller wrote:
2012/10/18 Harald Welte <laforge@gnumonks.org>
I strongly suggest you take a pcap capture file (like "tcpdump -ni eth0 -s0 -w/tmp/my.pcap") and figure out which exact message is causing the problem. Then you forward the relevant portion of the pcap file to this list.
I've attached a trace, no. 35 (data indication) seems to cause the drop.
I'm a bit puzzled by this.
"MM STATUS" is handled by gsm48_rx_mm_status() which unconditionally returns '0', i.e. our return value for success. gsm0408_rcv_mm(), the calling function, clearly returns this return value of '0' up to the caller gsm0408_dispatch(), which again returns it to its caller.
So from what I can tell in the code, I don't see an obvious path how that message should ever return -1 to libosmo-abis, which then drops the link.
It would be useful if you could spend some more time to try to hunt this down, possibly by printing a backtrace using "osmo_log_backtrace(DLINP, LOGL_ERROR)" around line 455 of libosmo-abis/src/input/ipaccess.c within in the section/clause:
if (e1i_ts->line->ops->sign_link(msg) < 0) { ... }
which is where the 'Bad signalling message' error message is printed first. The backtrace will only be addresses, and you would have to use the symbol table to figure out which function caused it (e.g. by using objdump).
Pablo: It actually would make sense to include this call to osmo_log_backtrace() as a default in libosmo-abis, what do you think?
Not sure that will help. I can do that but, AFAICS, it will not show the code trace in openbsc that spotted that problem (since we would be already out of its scope once libosmo-abis notices the problem). As an alternative, I can develop some little extension for libosmocore to store the packet that triggered the problem in some file like "ipaccess-bad-signalling-link-DATE.pcap". So we can make sure what packet triggered the problem. Let me know if I'm missing anything.
participants (6)
-
Andreas Eversberg -
Harald Welte -
Lennart Müller -
Nicklas Boecking -
Pablo Neira Ayuso -
Peter Stuge