aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2024-01-09isdn: initial implementation of the V.110 TAVadim Yanitskiy10-1/+1758
ITU-T recommendation V.110 defines Terminal Adaptor (TA) functions for the connection of Terminal Equipment (TE) having standard V-series interfaces to the ISDN. This patch brings "software" implementation of the TA to libosmoisdn. The primary user for this soft-TA is the mobile-side implementation of CSD (Circuit Switched Data) in osmocom-bb. CSD is heavily based on V.110, which is not surprising given that GSM is a "wireless ISDN". Nevertheless, this code will likely also be useful in the context of retro-networking. Similarly to the existing V.110 code in libosmoisdn, the present implementation aims to be functional and correct, rather than efficient in any way. It also has several limitations, which are not critical for the CSD use case, but eventually may be a problem for other use cases in the context of retro-networking. Therefore, the V.110 TA API should be considered _unstable_, and may be subject to change in the future. +-------+ +------+ B-channel +------+ +-------+ | TE1 |------| TA |~~~~~~~~~~~~~~~| TA |------| TE2 | +-------+ +------+ +------+ +-------+ TE (also known as DTE) is basically a computer, having a V-series (usually RS-232) connection to TA (also known as DCE). The TA acts like a regular analog modem, except that it is not performing any kind of modulation or demodulation itself. The TE-TA interface is implemented by the user supplied callback functions, configured during the allocation of a TA instance: * .rx_cb() - receive call-back of the application, * .tx_cb() - transmit call-back of the application, * .status_update_cb() - status line update call-back. In addition to that, the application (TE) can interact with the V.24 status lines (circuits) using the following API: * osmo_v110_ta_{get,set}_status(), * osmo_v110_ta_{get,set}_circuit(). The Rx and Tx between TE and TA is always driven by the TA itself, as a result of an interaction with the lower layer implementing the B-channel interface. There is currently no buffering and thus no way for TE to initiate transmission or pull data on its own. The TA-TA (B-channel) interface is implemented by the following functions, which are meant to be called by the lower layer transmitting and receiving V.110 frames over certain medium: * osmo_v110_ta_frame_in() - indicate a received V.110 frame, * osmo_v110_ta_frame_out() - pull a V.110 frame for transmission, * osmo_v110_ta_[de]sync_ind() - indicate a synchronization event. The lower layer is responsible for finding the synchronization pattern (if needed), aligning to the frame boundaries, and doing the V.110 frame coding. The D-channel signalling is behind the scope of this module. Initial (Work-in-Progress) implementation by Harald Welte, completed and co-authored by Vadim Yanitskiy. Change-Id: I5716bd6fd0201ee7a7a29e72f775972cd374082f Related: OS#4396
2024-01-09fsm: fix OSMO_T_FMT_ARGS: add missing bracesVadim Yanitskiy1-1/+1
Change-Id: I3ea7cbc8a51d310d9929ca5a805eb1d3d3880793
2024-01-09tests/tdef: improve test output (use OSMO_T_FMT[_ARGS])Vadim Yanitskiy2-15/+16
Change-Id: Ie216bcf93b96610c46c6e616835a6793772e2baa Related: e30d22a0 "tests/tdef: also test OSMO_TDEF_US and negative T values"
2024-01-09core: osmo_tdef_fsm_inst_state_chg(): allow millisecond precisionVadim Yanitskiy5-19/+34
This API predates commit 7b74551b9, which added support for millisecond granularity to osmo_fsm. Let's do the same for the tdef FSM wrapper API, allowing the millisecond precision without rounding-up to seconds. Of course, this patch changes behavior of the existing API, but having more precise state timeouts is not going to make the API user experience worse. The old behavior of using seconds is for kept for: * OSMO_TDEF_CUSTOM -- still treated as if it was OSMO_TDEF_S. * \param[in] default_timeout -- still expected to be in seconds. Change-Id: I4c4ee89e7e32e86f74cd215f5cbfa44ace5426c1 Related: 7b74551b9 "fsm: Allow millisecond granularity in osmo_fsm built-in timer"
2024-01-08gsm: fix osmo_mobile_identity_decode(): init *mi on errorVadim Yanitskiy1-2/+4
Change-Id: I1c1503120c6c0e5479d8350fe762470bdb6266b8
2024-01-07gsm48_ie: fix various issues in doxygen docsVadim Yanitskiy1-7/+8
Change-Id: Id168c5115588b2dbc48605ee0bba13ccc9913bbe
2024-01-05vty: suppress warnings about len being set but not usedVadim Yanitskiy1-0/+1
This commit fixes the following warning seen with CC=clang: utils.c:376:6: warning: variable 'len' set but not used [-Wunused-but-set-variable] int len = 0, offset = 0, ret, rem; ... and finally allows to build libosmocore with --enable-werror. Change-Id: I0040ef20ba3fc53ee7ccefc4885170f333f80566
2024-01-05gsm0808_utils: use osmo_strbuf API, drop APPEND_{THING,STR,CELL_ID_U}Vadim Yanitskiy1-31/+16
This code predates 2cbe25f4, adding osmo_strbuf API and so using its own append-to-strbuf implementation. Let's use the new generic API. Change-Id: Ifdfd18eeef6a0932995063259f9f179b22e781de
2024-01-04ecu: fix alignment of fr_ecu_statePhilipp Maier1-13/+13
The member data[0] in struct osmo_ecu_state is used as an anchor to attach private structs for a concrete ECU implementation. This works by allocating more memory then struct osmo_ecu_state actually needs and then using the excess memory to store the private struct of the concrete ECU implementation. However, this poses a problem since data[0] is at the end of the struct it may land in an unaligned position. This also means that the struct we store there is also unaligned. We should fix this enclosing the public struct osmo_ecu_state into our private struct fr_ecu_state. Then we can use container_of to cast from osmo_ecu_state to fr_ecu_state and correct alignment is ensured as well. Related: OS#6286 Change-Id: I28672856e8e8f47e04ffe09ee3e07b577108cdc7
2024-01-03pseudotalloc: add talloc_memdup(), use it in talloc_strdup()Vadim Yanitskiy2-12/+13
Change-Id: Ifcf377c3496a9e75404932a1aaba7d74888cf4cf
2024-01-03tests/tdef: tune logging, also match stderrVadim Yanitskiy4-2/+37
Change-Id: I7f346dfbec9e724e905d26990a978495d3a9b030
2024-01-03tests/tdef: also test OSMO_TDEF_US and negative T valuesVadim Yanitskiy2-20/+28
Basically improving testing coverage... Change-Id: I09945d277a5ec94985900a3f39f1cbb54c8ed6ff
2024-01-03tests/{gb,iuup}: also match stderrVadim Yanitskiy5-7/+358
Change-Id: Icc2b372563f9ca142d256f2b8e9700220c37fddf
2024-01-03bitvec: bitvec_to_string_r(): drop unused variableVadim Yanitskiy1-3/+1
bitvec.c:543:14: warning: variable 'pos' set but not used [-Wunused-but-set-variable] unsigned i, pos = 0; Change-Id: I17df6f9263bee06676309c00837f12220803c814
2024-01-03tests/utils: do not test strbuf_example2() with buf=NULLVadim Yanitskiy2-4/+0
The following can be seen when building with CC=clang: utils/utils_test.c:1239:2: runtime error: applying non-zero offset 99 to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior utils/utils_test.c:1239:2 in utils/utils_test.c:1241:3: runtime error: applying non-zero offset 99 to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior utils/utils_test.c:1241:3 in utils/utils_test.c:1242:2: runtime error: applying non-zero offset 99 to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior utils/utils_test.c:1242:2 in 44. testsuite.at:274: 44. utils (testsuite.at:274): FAILED (testsuite.at:278) This makes utils_test fail due to unexpected UBSan's output. Even though passing NULL to the strbuf API is relatively safe, it makes no sense and the API user should ensure that this never happens. And so we should not be testing this case. Change-Id: Icd2323e93ec64afc1822d48e5e1d090083edf539
2024-01-03utils: osmo_bcd2str(): fix applying non-zero offset to null pointerVadim Yanitskiy1-1/+3
This can be seen when building with CC=clang: utils.c:150:22: runtime error: applying non-zero offset 100 to null pointer SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior utils.c:150:22 in utils.c:150:33: runtime error: addition of unsigned offset to 0x000000000064 overflowed to 0x000000000063 SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior utils.c:150:33 in The *dst pointer may be NULL (e.g. bcd2str_test() is passing it). This makes tests/utils/utils_test fail. Let's fix this. Change-Id: I542aef1ac220891b6bbdb0c60c39232f0df0a43c
2023-12-31utils: fix -Wsign-compare in definition of OSMO_STRBUF_CHAR_COUNTVadim Yanitskiy1-1/+1
We're seeing tons of -Wsign-compare warnings since I merged 0f59cebf: include/osmocom/core/utils.h: In function 'size_t _osmo_strbuf_char_count(const osmo_strbuf*)': include/osmocom/core/utils.h:24:29: error: comparison of integer expressions of different signedness: 'long int' and 'long unsigned int' [-Werror=sign-compare] 24 | #define OSMO_MIN(a, b) ((a) >= (b) ? (b) : (a)) | ~~~~^~~~~~ include/osmocom/core/utils.h:309:16: note: in expansion of macro 'OSMO_MIN' 309 | return OSMO_MIN(sb->pos - sb->buf, sb->len - 1); | ^~~~~~~~ Interestingly enough, this -Wsign-compare problem has always been the case, even before commit 0f59cebf. And somehow this did not show up when building libosmocore.git, but only when building C++ projects (osmo-pcu and osmo-trx). Perhaps it has something to do with how g++ compiles extern "C" code. Change-Id: I8e396459409e4260b8715f9e890e8972d4609a31 Fixes: 0f59cebf "utils: improve readability of OSMO_STRBUF_CHAR_COUNT"
2023-12-30utils: improve readability of OSMO_STRBUF_CHAR_COUNTVadim Yanitskiy1-4/+14
Similarly to OSMO_STRBUF_REMAIN, let's improve the code readability by adding a static inline function. We should generally prefer using static inline functions over macros, unless there is something that only the proprocessor can do. Change-Id: I71f24b87c13fd83952029171a6993f8da5e32e5b
2023-12-30utils: fix OSMO_STRBUF_REMAIN to handle sb.pos == NULL correctlyVadim Yanitskiy3-1/+39
Currently, OSMO_STRBUF_REMAIN would return a huge number if the given strbuf has its .pos pointer set to NULL. This macro is safe against the .buf pointer being NULL, but not against .pos being NULL. Fix this by adding a static inline function (for the sake of code readability) and handle .pos being NULL properly by returning length of the buffer. Add a unit test. Change-Id: I294a74a99c40995cf7fb5520d61f697d967be5a4
2023-12-29tests: fix update-exp: soft_uart_test overwrites rlp_test.okVadim Yanitskiy1-1/+1
Change-Id: I41ea2c3d5b1e2e0349740acd63c39413472e0dad Fixes: 9ef304dd2 "soft_uart: add unit tests for the receiver and transmitter"
2023-12-27tests/fsm: also test .onenter and .onleave callbacksVadim Yanitskiy2-0/+42
Extend the existing testing coverage to check per-state enter/leave callbacks. An interesting behavior can be seen from the test output: when allocating an FSM instance, the .onenter callback is not being called for the initial FSM state (ST_NULL). Likewise, the .onleave callback is not being called when free()ing an FSM instance. Change-Id: I22edcf91375a09854f0dab1e2e02e034629310f7
2023-12-18tests: Test gsmtap logging if write queue fills upDaniel Willmann4-0/+276
Change-Id: Id5ae0c4c3820a9ed59eaf4003d2c57b6bdfe3468
2023-12-17rlp: Add support for 576bit RLP framesHarald Welte1-21/+26
The code so far only supported 240bit RLP frames; Add support for 576bit in this patch. We still only support versions 0+1 and not version 2. Change-Id: Idfdcabb19fe8733fb9c5ee76a39b0bf4cdf60c2c
2023-12-14ipa_ccm_tlv_to_unitdata(): free previous string if present before allocating ↵Pau Espin Pedrol1-12/+21
new one Change-Id: I66cbd900676875145810ad1d5c07e719311852fb
2023-12-14ns2: Improve code consistencyarehbein2-13/+28
- Use defines instead of repeating string literals - Use enum for indexing same data everywhere consistently Related: OS#5915 Change-Id: I11c926dd4125c6657ae3cd21d8038f161d9fd9c3
2023-12-12tests/iuup: fix assert()s in test_decode_passive_init_2_rfci_no_iptis()Vadim Yanitskiy1-2/+6
We should not be doing the actual logic inside the assert statements. Change-Id: I3bbf4e602c25c5aaced609e9834d6b053688194d Fixes: CID#274664, CID#274679
2023-12-12tests/gsm0808: fix assert()s in test_gsm0808_dec_cell_id_list_srvcc()Vadim Yanitskiy1-2/+2
Change-Id: I6aa901fd706c74fe86b65a474c1d82803f28eeb4 Fixes: CID#274663
2023-12-12tests/lapd: fix wrong size passed in test_lapdm_contention_resolution()Vadim Yanitskiy1-1/+1
We should be passing size of the cm[] array, not size of a pointer! Change-Id: I0a878570e3a3d4e57ff44a7bc460ddb0a1b08558 Fixes: CID#274662
2023-12-12socket: Introduce defines OSMO_SOCK_MULTIADDR_{PEER_STR,NAME}_MAXLENPau Espin Pedrol2-6/+14
These values end up being used by API users of osmo_sock_multiaddr_get_name_buf() and osmo_multiaddr_ip_and_port_snprintf(). Change-Id: I18a0e1a652a3e8ef3e97154355eb1d07a14ef0bd
2023-12-11soft_uart: demonstrate a problem with inefficient pollingVadim Yanitskiy2-0/+39
As outlined in the test case, we pull a total of 50 bits from the transmitter in two rounds, pulling 25 bits at a time. In the default 8-N-1 configuration, 50 bits should ideally comprise 5 characters. However, as observed, only a total of 4 characters are retrieved from the application, leaving the remaining 10 bits (5 + 5) unused. Change-Id: Ic2539681a4adf6c1822e0bc256e4c829813d0e21
2023-12-11soft_uart: demonstrate a problem with manual flush()ingVadim Yanitskiy2-0/+24
This problem can only happen if the user is flush()ing the Rx buffer manually by calling osmo_soft_uart_flush_rx(). Let's demonstrate it in the unit test, so that we don't forget about it (add FIXME). Change-Id: Iad932a505d6fd98360f90510651501f8708ff5d2
2023-12-11soft_uart: fix the Rx flushing logic, add a unit testVadim Yanitskiy3-3/+28
Coverity tells us that with the current logic it's possible (in theory) that we may dereference NULL pointer in osmo_soft_uart_flush_rx(). This is highly unlikely, because the Rx buffer gets allocated once when the Rx is enabled and remains even after the Rx gets disabled. The Rx flags cannot be anything than 0x00 before the Rx gets enabled. Even though this NULL pointer dereference is unlikely, the Rx flushing logic is still not entirely correct. As can be seen from the unit test output, the Rx callback of the application may be called with an empty msgb if the following conditions are both met: a) the osmo_soft_uart_flush_rx() is invoked manually, and b) a parity and/or a framing error has occurred previously. We should not be checking suart->rx.flags in osmo_soft_uart_flush_rx(), since this is already done in suart_rx_ch(), which is calling it. Removing this check also eliminates a theoretical possibility of the NULL pointer dereference, so we're killing two birds with one stone. - Do not check suart->rx.flags in osmo_soft_uart_flush_rx(). - Add a unit test for various flush()ing scenarios. Change-Id: I5179f5fd2361e4e96ac9bf48e80b99e53a7e4712 Fixes: CID#336545
2023-12-11socket: Introduce API osmo_sock_sctp_get_peer_addr_info()pespin/multiaddrPau Espin Pedrol4-0/+82
This is a convenience helper to reetrieve the whole set of remote addresses and call getsockopt() on them, making it easy for users to analyse the full set of remote addresses of a socket simply providing an fd. Related: SYS#6636 Change-Id: I3e1c84526b006baff435bbbca49dc6cf7d201cf5
2023-12-11logging: fix NULL pointer dereference in _output_buf()Vadim Yanitskiy1-1/+1
In the _output_buf() we explicitly initialize only the 'buf' and 'len' fields of the struct osmo_strbuf, leaving the 'pos' field implicitly initialized to NULL. Later, in this function, 'sb.pos' is passed to ctime_r() and strlen(), leading to a NULL pointer dereference (segfault) in certain scenarios. This situation can occur when color logging is disabled or when a specific logging subsystem has no associated color. Any application using libosmocore's logging API would crash with the following config: log stderr logging filter all 1 logging timestamp 1 logging color 0 Fix this by initializing the 'pos' field explicitly. Change-Id: I7ec9badf525e03e54e10b725d820c636eaa3fd1c Fixes: d71331bc "logging: fix nul octets in log output / use osmo_strbuf" Fixes: CID#336550
2023-12-10socket: Fix uninitialized mem ptr free in osmo_sock_init2_multiaddr2()Pau Espin Pedrol1-1/+1
The goto tag was wrong, probably due to a copy-paste mistype while reimplementing the function. Closes: Coverity CID#336546 Change-Id: I06b810fde7bf750fcb42d6d9e6223883e26f5f0b
2023-12-10soft_uart: cosmetic: use consistent naming for the Rx buffer msgbVadim Yanitskiy1-1/+1
In osmo_soft_uart_flush_rx() we use "soft_uart_rx", so be consistent. Change-Id: Id637a39bab8ecd04bca5580bb48f965b501f5b2e
2023-12-10tests/soft_uart: cosmetic: improve readability of the test outputVadim Yanitskiy2-61/+93
Change-Id: Icf5410f0b292d41532e0cbd17e6ca0509c76cbd5
2023-12-10tests/soft_uart: assert that osmo_soft_uart_rx_ubits() returns 0Vadim Yanitskiy1-1/+3
According to Coverity, we check return value of this function in all other cases except this one (9 out of 10 times), so let's add the missing assert(), just to be sure. Change-Id: I675f4089cc990be5fcda792276b6808742f6f0d7 Fixes: CID#336557
2023-12-09core: fix wrong logic in _osmo_it_q_dequeue()Vadim Yanitskiy3-11/+6
If the given queue is empty, queue->list.next points to &queue->list. Current implementation would call llist_del() on the queue's llist_head, decrement queue->current_length (which will be 0), and return a pointer to &queue->list to the caller. This is completely wrong. - Use the existing item_dequeue(), which does exactly what we need. - Do not decrement the current_length if nothing was dequeued. - Uncomment code in the unit test, we should not crash anymore. Change-Id: I63094df73b166b549616c869ad908e9f4f7d46d1 Fixes: CID#336557
2023-12-09tests/it_q: add tc_enqueue/dequeue testcaseVadim Yanitskiy2-0/+48
This patch is adding a simple testcase, which does the following: * enqueue up to the limit (12 items), * dequeue up to the limit (12 items). Everything works as expected, unless you attempt to dequeue from an empty queue: the test binary segfaults. The problem is explained and fixed in a subsequent patch. Change-Id: Ie0edbf00e656fbe231952bdbccfd37d143e8b2b1 Related: CID#336557
2023-12-08tests/coding: fix -Wmaybe-uninitialized in test_pdtch()Vadim Yanitskiy1-2/+2
I am seeing this when building with gcc v13.2.1: tests/coding/coding_test.c: In function ‘test_pdtch’: tests/coding/coding_test.c:444:23: warning: ‘*result[<unknown>]’ may be used uninitialized 444 | result[len - 1] &= 0x7f; | ~~~~~~^~~~~~~~~ tests/coding/coding_test.c:448:23: warning: ‘*result[39]’ may be used uninitialized 448 | result[len - 1] &= 0x07; | ~~~~~~^~~~~~~~~ The idea here is to pre-clear some bits in the resulting buffer, because they're not going to be set during decoding of the burst bits. The problem is that result[] holds uninitialized data, so we're basically taking a 'garbage' octet and clear some of its bits. The remaining 'garbage' bits of that octet are overwritten by the decoder, so in the end we still get deterministic results. Let's make GCC happy by clearing all bits in the last octet. Change-Id: I24d79de8b3a5f4184b71414504657e5857498e0e
2023-12-08coding: gsm0503_pdtch_decode(): implement USF decoding for CS1Vadim Yanitskiy1-0/+4
This patch brings decoding of the CS1 in consistency with the other three coding schemes, for which we support decoding USF independently. Change-Id: I61a3628741c0ac68374fc7f077cf3a07e51277c3
2023-12-08coding: clarify the USF decoding for PDCH blocksVadim Yanitskiy1-2/+5
The USF (Uplink State Flag) field is present in the MAC header of all Downlink PDCH blocks. It is used by the network to indicate which MS can transmit on subsequent Uplink PDCH block(s). This field is of a high importance for the MS, thus the decoder API allows the caller to obtain USF value separately from the actual data bits. In the case of gsm0503_pdtch_decode(), if the 'usf_p' pointer is not NULL, the USF value would be assigned for CS2/CS3/CS4 (but not CS1) even if the CRC check fails (negative return value). A subsequent patch is to bring the CS1 in consistency with CS2/CS3/CS4. In the case of gsm0503_pdtch_egprs_decode(), decoding of the USF field separately from data bits is not implemented, and moreover the function itself cannot be used for decoding Downlink blocks. Change-Id: I43e8bfb4003f34766ace7c5c6080ca583ce5efbb
2023-12-08coding: fix doxygen docs for gsm0503_pdtch[_egprs]_decode()Vadim Yanitskiy1-2/+2
Change-Id: I09a4c52f5704a6436eff524cd2ce5c35347aafde
2023-12-07socket: Introduce API osmo_sock_multiaddr_get_name_buf()Pau Espin Pedrol4-1/+113
An extra osmo_multiaddr_ip_and_port_snprintf() API is introduced which is used by osmo_sock_multiaddr_get_name_buf() but which will also be used by other app uers willing to use osmo_sock_multiaddr_get_ip_and_port() according to its needs (eg. only printing the local side). Related: SYS#6636 Change-Id: I48950754ed6f61ee5ffa04a447fab8903f10acc0
2023-12-07socket: Introduce API osmo_sock_multiaddr_get_ip_and_port()Pau Espin Pedrol4-0/+93
This API will be used internally by osmo_sock_multiaddr_get_name_buf() in a follow-up patch. This API can also be used directly by user who wish to obtain a list of local/remote IP addresses and port from an SCTP socket. Related: SYS#6636 Related: OS#5581 Change-Id: I19d560ab4aadec18a4c0f94115675ec1d7ab14d7
2023-12-07logging: fix nul octets in log output / use osmo_strbufNeels Hofmeyr1-84/+44
Patch [1] merged few weeks ago, for yet unknown reasons, sprinkles nul characters at seemingly randomly chosen log line ends. Trying to figure out why that happens, i got tired of the unreadable cruft, and decided to migrate the _output_buf() implementation to osmo_strbuf first. With osmo_strbuf in use and implementing 1:1 what the previous code did, the odd nul octets have disappeared. So the bug was caused by unreadable code. [1] 11a416827dd9f2da6b7c1db0e1e83adb1e6e5cc8 Ia7de9d88aa5ac48ec0d5c1a931a89d21c02c5433 "logging: ensure ANSI color escape is sent in same line/before newline" Related: OS#6284 Related: Ia7de9d88aa5ac48ec0d5c1a931a89d21c02c5433 Change-Id: Ib577a5e0d7450ce93ff21f37ba3262704cbf4752
2023-12-07util: add osmo_strbuf macros to manipulate the strbuf tailNeels Hofmeyr5-0/+163
Upcoming patch adopts osmo_strbuf in logging.c, which sometimes needs to steal and re-add trailing newline characters, and also needs to let ctime_r() write to the buffer before updating the osmo_strbuf state. Related: OS#6284 Related: Ib577a5e0d7450ce93ff21f37ba3262704cbf4752 Change-Id: I997707c328eab3ffa00a78fdb9a0a2cbe18404b4
2023-12-07util: add OSMO_STRBUF_REMAIN()Neels Hofmeyr1-2/+5
This code already exists twice, and upcoming patch will need this as well in logging.c. Add a macro to remove the code dup. Related: OS#6284 Related: Ib577a5e0d7450ce93ff21f37ba3262704cbf4752 Change-Id: I6f2991125882bff948708bbb4ae218f9f3d1e50c
2023-12-06socket: osmo_sock_init2_multiaddr2(): Apply params too if no ↵Pau Espin Pedrol1-19/+21
OSMO_SOCK_F_BIND flag set Those parameters are not related to binding and hence should be applicable before binding. This allows a caller setting them while not caring about explicit binding (OSMO_SOCK_F_BIND). Until recently calling this function without OSMO_SOCK_F_BIND was not really supported, so the previous placement setting these params in the function didn't matter much. It does now. Change-Id: Ia32510e8db1de0cc0dc36cebf8a94f09e44fda70
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-22 16:02:18 +0000