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
* make sure datagram.h is part of the group
* don't expose private #defines from C files to API documentation
Change-Id: I64a9ee3306bcc01ba785da476aea581ce31150bd
Let's make sure
* only exported / user-relevant #defines appear in the manual
* deprecated functions are marked in a way doxygen can mark them
* descriptive comments are using doxygen syntax
Change-Id: I5af0133322ddd5345a13380f1c007474c0bea117
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
This allows a user setting a name on the underlaying stream which
in turns allows easily identifying the socket.
Change-Id: Iba683e4d65e0aba81e13bdf1b9d5a9065b1fc89c
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
As a result, internal stream_srv_link logging will also show the whole
set of listening addresses. This is mostly fine since it mainly happens
only once, during connection accept(), and this way it provides full
view of where from and where to the client connected.
Depends: libosmocore.git Change-Id I18a0e1a652a3e8ef3e97154355eb1d07a14ef0bd
Related: SYS#5581
Change-Id: I216502a9aeafe638940f110bc9fddf2504b2ac3a
This is used by API callers, and internally to log
connected/disconnected events.
Related: SYS#5581
Change-Id: I249ee7cad824cf971faabe06d10de2426c1b0c8b
This can be used by apps retrieving struct sctp_status through
getsockopt(SCTP_STATUS).
The relevant field is spinfo_state: osmo_sctp_sstat_state_str(st.sstat_state);
Change-Id: Id7d8a9ad7b32406ac603e520b33809d7ae5c762f
Related: SYS#6636
This can be used by apps retrieving struct sctp_paddrinfo through
getsockopt(SCTP_GET_PEER_ADDR_INFO).
The relevant field is spinfo_state: osmo_sctp_spinfo_state_str(pinfo.spinfo_state);
Related: SYS#6636
Change-Id: I78a0bd8279a04f4011c7273e0f542981308e482f
osmo_stream_srv and osmo_stream_cli already had that API introduced in
order to use it instead of *_get_ofd(), since the later will eventually
be deprecated due to incoming osmo_io.
Change-Id: I1bd3f790d93af74c150938a59108b882ad2820f3
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
The corresponding client function osmo_stream_cli_get_ofd()
already contained an OSMO_ASSERT, but the server side was missing
this so far. The 'ofd' member only has meaning in the context
of OSMO_FD, so calling that function from generic code is wrong!
Change-Id: I50df259040e011135a31fe1aee231eba430fa94a
Fixes: Change-Id I2f52c7107c392b6f4b0bf2a84f8c873c084a200c
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
If read returned an error or the stream got closed then simply destroy
the connection.
If the user code called osmo_stream_srv_set_flush_and_destroy() then
ignore any incoming messages and destroy the connection once the tx
queue is empty.
Change-Id: I84eea2717f3762830f3f5b115e6fc8545eaa4fd5
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
With this commit, IPA segmentation can be taken care of by setting
the segmentation callback osmo_ipa_segmentation_cb().
Depends: libosmocore.git I3a639e6896cc3b3fc8e9b2e1a58254710efa0d3f
Related: OS#5753, OS#5751
Change-Id: I6c91ff385cb5f36ab6b6c96d0e44997995d0d24c
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
*Move the helper function to stream.c and pass a logging prefix string
so that it can be used by both client and server.
* Adapt log level based on message type.
* Rework logging code to log everything in one line
Change-Id: I0ed84cc2effb71b6ef1f6efb3f8b663c602a5a31
RFC 6458 6.1.1:
"""
sac_error: If the state was reached due to an error condition (e.g.,
SCTP_COMM_LOST), any relevant error information is available in
this field. This corresponds to the protocol error codes defined
in [RFC4960].
"""
Change-Id: Ie48360d22ce1e35eefb1a305dde106948dfa80e8
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
If internal send() fails with a fatal error, it should destroy the
socket. The user will know about the event through the close_cb() called
during osmo_stream_srv_destroy().
As a result, the socket is not closed when receiving SHUTDOWN by the
peer (through SCTP MSG_NOTIFICATION), but keep it alive since the socket
can still keep receiving data from the peer. Only fail if write() to
that read-only socket is attempted.
Related: OS#6134
Change-Id: I84ddebabdffe47733cb529bcfebec8757e6a172b
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
Pau Espin
Andreas Eversberg
Harald Welte
Vadim Yanitskiy
Daniel Willmann