Hi list,
during testing of OsmoCSCN, I find that osmo-hnbgw connects to the CN servers once, but when such a CN component restarts, no new connection is established. Sequence:
- start hnbgw, which continuously tries to connect to CS and PS CN servers every five seconds (osmo-cscn and dummy-cn in my case). - start dummy-cn, hnbgw connects. - start osmo-cscn, hnbgw connects. - osmo-cscn segfaults ;) - hnbgw logs the disconnect - I restart osmo-cscn - but hnbgw never attempts to reconnect to osmo-cscn. - so I have to restart hnbgw, hnb-test and its VTY connection "all the time", which is cumbersome.
I briefly tried to resolve the issue, but I'm losing patience. I tried to enable the DLINP debug logging but found that hnbgw's VTY doesn't allow me to manipulate logging levels, apparently.
Next I'd have liked to set the hnbgw_log_info to indicate [DLINP] = { .loglevel = LOGL_DEBUG } but DLINP is negative. Does this really have to be as fiendish? I guess the INT2IDX() macro doesn't apply here, as it would cause index overlaps with the other D* constants. It can be really hard to find my way around the Osmo source code, with the little non-obvious things accumulating...
I did find that much: the reconnect flag passed to osmo_stream_cli_open2() is effective only while state == STREAM_CLI_STATE_CONNECTING, i.e. until a first connection is established. Now, if upon disconnect, something were to set the state back to cli->state = STREAM_CLI_STATE_CONNECTING my guess is that the cli_timer_cb() would indeed attempt to reconnect as I intend.
BTW, what does cli stand for? Not command-line interface, is it.
If I stayed onto this I'd probably solve the issue. My focus should be on an IuCS Location Update though, so comments or help is appreciated :)
So long I'll carry on with the workaround, restarting hnbgw "all the time".
Thanks! ~Neels
On 10 Feb 2016, at 22:47, Neels Hofmeyr nhofmeyr@sysmocom.de wrote:
Hi!
Next I'd have liked to set the hnbgw_log_info to indicate [DLINP] = { .loglevel = LOGL_DEBUG } but DLINP is negative. Does this really have to be as fiendish? I guess the INT2IDX() macro doesn't apply here, as it would cause index overlaps with the other D* constants. It can be really hard to find my way around the Osmo source code, with the little non-obvious things accumulating...
well the default is defined where the entire log area is defined. With DL the indication is that it is one library, most likely libosmo-abis. To change the default for the application the config file is the right place. In the hnbgw somebody needs to call logging_vty_add_cmds.
I did find that much: the reconnect flag passed to osmo_stream_cli_open2() is effective only while state == STREAM_CLI_STATE_CONNECTING, i.e. until a first connection is established. Now, if upon disconnect, something were to set the state back to cli->state = STREAM_CLI_STATE_CONNECTING my guess is that the cli_timer_cb() would indeed attempt to reconnect as I intend.
Which library and which branch is this coming from?
On Thu, Feb 11, 2016 at 07:54:11AM +0100, Holger Freyther wrote:
In the hnbgw somebody needs to call logging_vty_add_cmds.
sounds simple enough :) And it worked! thanks!
I did find that much: the reconnect flag passed to osmo_stream_cli_open2() is effective only while state == STREAM_CLI_STATE_CONNECTING, i.e. until a first connection is established. Now, if upon disconnect, something were to set the state back to cli->state = STREAM_CLI_STATE_CONNECTING my guess is that the cli_timer_cb() would indeed attempt to reconnect as I intend.
Which library and which branch is this coming from?
Ah, sorry, it's on: libosmo-netif branch sysmocom/sctp src/stream.c
hold on, weren't you supposed to do your tax reports today? ;)
~Neels
On Wed, Feb 10, 2016 at 10:47:20PM +0100, Neels Hofmeyr wrote:
BTW, what does cli stand for? Not command-line interface, is it.
I guess stream_cli_ means "stream client" ... IMHO one of the less readable abbreviations ;)
~Neels
Hi Neels, sorry for the late response,
On Wed, Feb 10, 2016 at 10:47:20PM +0100, Neels Hofmeyr wrote:
I did find that much: the reconnect flag passed to osmo_stream_cli_open2() is effective only while state == STREAM_CLI_STATE_CONNECTING, i.e. until a first connection is established. Now, if upon disconnect, something were to set the state back to cli->state = STREAM_CLI_STATE_CONNECTING my guess is that the cli_timer_cb() would indeed attempt to reconnect as I intend.
the function osmo_stream_cli_reconnect() should be called in all cases where the connection is determined dead. It then re-starts the timer and re-sets the state to STREAM_CLI_STATE_CONNECTING, i.e. does exactly what you wrote above.
It is called * if sctp_send() / send() returns a negative value * if getsockopt() return an error * if recv() returns a negative value * if recv() returns zero
Which I would consider a comprehensive list of the cases where the connection is gone.
A [sctp_]send() return value of zero would mean that the window is stalled and our local send buffer is exceeded. That's not equal to the connection beign lost or disconnected.
In general, the bst way to debug this kind of issue is to use ltrace or strace to see what's happening in terms of the system calls on the SCTP client socket when provoking such a situation.
-
Harald Welte -
Holger Freyther -
Neels Hofmeyr