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