16 Oct
2012
16 Oct
'12
7:51 p.m.
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
16 Oct
16 Oct
12:07 p.m.
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
18 Oct
18 Oct
11:57 a.m.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
21 Oct
21 Oct
8:57 p.m.
2012/10/18 Harald Welte <laforge(a)gnumonks.org>
On Tue, Oct 16, 2012 at 10:51:32AM -0700, Nicklas Boecking wrote:
I've attached a trace, no. 35 (data indication) seems to cause the drop.
Regards,
L.M.
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.
22 Oct
22 Oct
10:22 a.m.
Hi Lennart,
On Sun, Oct 21, 2012 at 08:57:31PM +0200, Lennart Müller wrote:
2012/10/18 Harald Welte <laforge(a)gnumonks.org>
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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. 
24 Oct
24 Oct
9:32 a.m.
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:
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.
2012/10/18 Harald Welte
<laforge(a)gnumonks.org>
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? 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.
4623
days inactive
4631
days old
6 comments
6 participants
participants (6)
-
Andreas Eversberg -
Harald Welte -
Lennart Müller -
Nicklas Boecking -
Pablo Neira Ayuso -
Peter Stuge