Notify user about read errors, similar to what is supported in the
earlier ofd cb backend of osmo_stream_cli/srv:
https://osmocom.org/issues/6405#note-15
Related: OS#6405
Fixes: 5fec34a9f2
Fixes: 0245cf5e07
Change-Id: I395c75ff1e9904757ce1d767a9ac2f779593c4c8
The amount and complexity of callbacks is increasing over time.
Use typedefs to define each of them so that callbacks:
- Are easier to identify (which types is used where)
- Are easier to document (have a 1st class place to write doxygen
documentation)
Change-Id: Ib0c4a9713fa4c755e457b8c2cbde6a7724d36e28
If read or recvfrom fails or returns 0, the connection must be closed.
This is already done when a write / send fails. In both cases the
disconnect callback is called to notify the user's client.
Not handling the error may cause an infinite loop of read or recvfrom
failures.
Related: OS#6405
Change-Id: I55426de6b49cb4cb0797e50dfeae11f2efc29b15
Using this, a user can obtain the osmo_io_fd, for example in order to
perform configuration like osmo_iofd_set_alloc_info() or
osmo_iofd_set_txqueue_max_length().
Change-Id: Ie19c8294ddb12dfe5e0fd44e047c47e6f9cbd384
The osmo_stream_{cli,srv}_recv() is only for osmo_fd mode users; in
case osmo_io mode is used, the read_cb is called with pre-filled message
buffers; no need to recv/read directly anymore.
Change-Id: Ie96cf1241b2ba4e0a7dda584182d18cad2b4f061
The behaviour is undefined on what should happen if a stream client user
is trying to write data before the client socket is connected. In
osmo_io mode we would actually crash due to a NULL-pointer dereference.
Let's discard any sent data in this situation and print a related error log message.
This problem actually shows up with osmo-bsc Change-Id
Icce412e6ee69366c7b131c9bc1d51e8d44204917 where we convert CBSP over to
osmo_io - here in situations where a CBSP client (using stream_cli) was
previously connected but has lost its connection.
Change-Id: I18d2e8e850c23a32f5983a715fa8a18747b296cd
Free osmo_io instance when calling osmo_stream_cli_close().
Also free osmo_io instance when calling osmo_stream_cli_open() if not
freed, to prevent memory leaks.
osmo_iofd_notify_connected() must be called before any registration
of read or write, because osmo_io_iouring does not allow this.
Change-Id: I91a6a76b9ff96034a7b333edf87af27490202932
If a message is not forwarded (to a read callback function, it must be
freed, to prevent memory leaks.
The message musst be freed before calling osmo_stream_srv_destroy() or
stream_cli_handle_connecting(), because within the function calls the
client/server instance may get destroyed and the message is 'owned' by
it. Calling msgb_free(msg) afterwards may result in double free bug.
Related: OS#5753
Change-Id: Ic043f11cdba0df9e0b78cac8db7206800098e0ba
Also the example client/server must not access msgb after sending it,
especially if the msgb got freed due to a failure.
Change-Id: I627a71b4f0183cd83835c328a5cdd67a413ae614
Let's enable the OSMO_IO_FD_MODE_RECVMSG_SENDMSG mode for SCTP
sockets, allowing OSMO_STREAM_MODE_OSMO_IO to be used with SCTP.
Change-Id: I6cf5bad5f618e71c80017960c38009b089dbd6a1
Depends: libosmocore Change-Id: I89eb519b22d21011d61a7855b2364bc3c295df82
Closes: OS#5753
This is used by API callers, and internally to log
connected/disconnected events.
Related: SYS#5581
Change-Id: I249ee7cad824cf971faabe06d10de2426c1b0c8b
Properly call osmo_sock_init2_multiaddr2() to use default binding
address if user of osmo_stream_cli didn't set one on the object
through the API.
osmo_sock_init2_multiaddr2() was also borken under that scenario until
recently (see Depends below). Until now, users of osmo_stream for SCTP
(mainly libosmo-sccp) relied on always setting a proper local address to
overcome this limitation.
Depends: libosmocore.git Change-Id I2641fbaca6f477404b094dbc53c0c1a3dd3fd2fd
Related: OS#6279
Change-Id: I0d9d0e48690c915f7b51ad09f452e551e01368b5
The old osmo_stream_{cli,srv}_get_ofd() API only works for streams
in OSMO_FD mode. However, it is legitimate for an application
wanting to get low-level access to the file descriptor, for example
to issue some {get,set}sockopt() calls on it.
Change-Id: Ib0737f21150f6ac8d524b92c7ddb098f2afdeaab
Related: OS#5753
With this commit, IPA segmentation is taken care of by setting the
segmentation callback provided by libosmo-netif.
The ipa-stream-server example needs to prepend IPA headers now because
those are stripped by the segm. cb on both sides.
Depends: libosmocore.git I3a639e6896cc3b3fc8e9b2e1a58254710efa0d3f
Related: OS#5753, OS#5751
Change-Id: I822abf52c6ae396c90b5c50228a0a39c848d3de6
This will allow osmo_stream users (like libosmo-sccp) to set
SCTP_INITMSG related parameters, like number on inbound/outbound
streams, connect attempts, connect timeout.
Related: SYS#6558
Change-Id: I5343c7659881b29e0201e72badbc2d07e1ef2dca
This will allow extending capabilitites to set different parameters at
the lower layers as we need them.
This commit changes the behavior of osmo_stream_{cli,srv_link}: It now
doesn't enable by default SCTP AUTH/ASCONF features using setsockopt. It
is left up to the user of the API (libosmo-sccp in this case) to set it.
Since this unilateral use of setsockopt() has only been added recently
and we didn't release yet, it's fine changing it. libosmo-sccp will be
changed to unconditionally set its using setsockopt. It is left up to
the user of the API (libosmo-sccp in this case) to set it.
Related: SYS#6501
Related: SYS#6558
Change-Id: I2607c1c926a625986cd851adc65dd8b4de83d6ab
Use the new API available in libosmocore to set sockopts related to
ASCONF SCTP features. The old flag OSMO_SOCK_F_SCTP_ASCONF_SUPPORTED has
been dropped. This only affects master builds since there's no release
ever done with that flag defined.
Depends: libosmocore.git Change-Id I1f6fd09a79b0a2bd794e5669d933be25bbf1eeaa
Related: SYS#6501
Related: SYS#6558
Change-Id: I2b2073de72625b4f4f99892179c9406163d28592
This is required if the user of the stream API wants to use SCTP extra
features such as setting the Peer Primary Address through ASCONF.
At a later point we may want to add new osmo_stream APIs to set extra
flags for the socket, or maybe simply add a new API specifically to
enable ASCONF for the stream.
Depends: libosmocore.git Change-Id Iac07031927b66a9d32d2bb2faab817e4c922a359
Related: OS#6076
Change-Id: I807b3748b8535d8e75ceea812d7baaf153fa1d60
Upon EAGAIN, simply re-enqueue the message and return waiting for next
poll. Upon any other error, force close + reconnect.
Related: OS#6134
Change-Id: I462cb176ebc51f3e99ee796310e8665144c84ccc
The previous behavior was not standarized, and even erratic under some
code paths (passing msgb_data() and size=msgb_tailroom()).
This patch standarizes the behavior, and makes it possible to append
content if the user wishes so instead of erasing old data in the msgb
passed to it.
Change-Id: I2cfcd4f61545e6a76d84495c3467999efccf22df
Commit 5b0ad8bd85 added call to
setsockopt(SO_NOSIGPIPE) in order to avoid SIGPIPE being signalled on
platforms not supporting send() flag MSG_NOSIGNAL (macOS, FreeBSD
etc...).
While it may be a topic to discuss whether we support those platorms or
not, the fact that we call an extra setsockopt() during socket creation
doesn't hurt much, and for sure we want to have the same behavior in
client and server.
Hence, this commit adds the same behavior pesent in srv sockets to cli
ones.
Change-Id: I867d8e244e473679abb7e7e7a9b531eeed046436
The dev/user in general is only interested about one side of the stream
when looking at the code. Since the stream.c file is tarting to be quite
large/bloated, this patch splits its content into stream_cli.c and
stream_srv.c to make it easier to improve/extend and review.
Keep common code between cli and srv in stream.c, and add a private header
to contain references to it.
Change-Id: I22af01bba2040eb320ba48fd1b46c090c98be159
Pau Espin
Andreas Eversberg
Harald Welte
Vadim Yanitskiy