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
The generated API documentation should be relevant to the API user,
and hence only non-static/public functions are relevant
Change-Id: I6fee052ad22877db85fe3207c7eac950d875873b
We have that enabled in libosmcore.git for ages, somehow we missed
it here, resulting in missing 'brief' descriptions in the output.
Change-Id: I751036baa9a2b30d94a2a302c7072a5487d2c26e
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
In order to detect memory leaks while debugging, stream server/client
and keyboard is closed on exit.
Related: OS#5753
Change-Id: I9dbb7f46b2a798e88ad4df8ff73c6ee40c07b843
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 helps to test connections via a network and failing connections.
The client may add "-r <peer>" to the command line, to set the address
of the remote peer.
The server may add "-l <peer>" to the command line, to select address
of local peer.
By default "127.0.0.1" is used.
Change-Id: Ie6da55ef248436e521c5d8f21f8053356c46a114
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
- Use tall_test as root context everywhere, don't create any other contexts
- change .*_(cli|srv)_run_client() signature by adding talloc context as parameter
- Open and Close server link inside test_recon()
Related: OS#6222
Change-Id: I9ef02ed113bc049ae430b93d0eb69641e2ee809b
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
Pau Espin
Andreas Eversberg
Harald Welte
Vadim Yanitskiy
Daniel Willmann