This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at gnumonks.orgHi 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 <laforge at gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)