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 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.