aboutsummaryrefslogtreecommitdiffstats
path: root/tests (follow)
Commit message (Collapse)AuthorAgeFilesLines
* iuup: Fix Handling of subsequent Initialization msgsPau Espin Pedrol2022-06-132-13/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Once the IuUP FSM moved away from Init state, it stopped handling Initialization messages received from peers and simply ignored them starting from that point. As a result, if the first IuUP Init ACK it sent to the peer was lost, the peer would keep retrying with more IuUP Init and getting no answer. In any case, it seems possible and desirable that a peer may send an IuUP Init at a later point, as pointed out vaguely in 3GPP TS 25.415. sec 6.5.2.1: """ Upon reception of a frame indicating that an Initialisation procedure is active in the peer Iu UP entity, the Iu UP protocol layer forwards the whole protocol information contained in the INITIALISATION control frame to the upper layers. It also stores the RAB sub-Flow Combination set (and thus replaces a possible previous set) in order to control during the transfer of user data, that the Iu UP payload is correctly formatted (e.g. RFCI matches the expected Iu UP frame payload total length). The peer Iu UP entity receiving the INITIALISATION control frame shall choose a version that it supports among the proposed versions indicated by the sender for which it has enough initialisation information. """ sec B.2.2 "Initialisation State": """ After sending a positive acknowledgement of the last INITIALISATION control frame, the Iu UP instance enters SMpSDU data transfer ready state. Note that CN does not know if the initialisation ACK was correctly received by the RNC (and Initialisation procedure successfully completed) until it receives RAB assignment response, or use data from the RNC. The CN must therefore be able to continue receiving INITIALISATION control frames by re-entering the Initialisation state (from Support Mode Data Transfer Ready State), if the CN has started to send user data before receiving the indication that Initialisation was successfully completed """ sec B.2.3 "Support Mode Data Transfer Ready State": """ In case of handover or relocation, Initialisation procedures may have to be performed and Iu UP instance may have to enter the initialisation state. """ Related: SYS#5995 Change-Id: I5cb740702805693cc7f0a550e2e093f9bfdd507c
* tests/iuup: Showcase IuUP stack not answering subsequent Init msgsPau Espin Pedrol2022-06-132-0/+115
| | | | | | | | | | This test shows a bug in IuUP stack which makes it only handle the first Initialization IuUP message. After it moves to SMpSDU, it stops handling Initialization messages. A fix is provided in a follow up patch. Related: SYS#5995 Change-Id: I72c2c2d88f158f3ef35724fcb73854a1827aaab4
* iuup: Fix IPTIs_present not set to 0 if no IPTIs receivedPau Espin Pedrol2022-05-272-0/+117
| | | | | Related: SYS#5969 Change-Id: I503dc509ad8619f13cd83ae03261a2297e2b9fc7
* coding: add gsm0503_detect_a[fh]s_dtx_frame2()Vadim Yanitskiy2022-05-272-21/+25
| | | | | | | | | | | | The new functions accept an additional mode_id poiner, which is currently set for the following frames: AFS_ONSET, AHS_ONSET, AHS_SID_FIRST_P2 with N * 16 - M bit pattern. Also, the new API accepts soft-bits instead of hard-bits. Converting bits from soft to hard is now performed internally. Change-Id: Ibcac395f800bb64150c97fcdaca3523ecfc5fcee Related: OS#5570
* iuup: Rework API to support RFCI IDs != RFCI indexPau Espin Pedrol2022-05-251-5/+5
| | | | | | | | | | | | | | | | | | | | | The initially merged IuUP API and implementation assumed that RFCI with ID was always in the position of its ID inside the list of RFCIs. This was the case for messages sent by ip.access nano3g as well as our own osmocom implementation. However it was noticed that other nodes from other vendors actually use other order, as allowed by the IuUP message format. Hence, we need to break the assumption and provide explicit ID information in the list. NOTICE: This commit breaks API and ABI compatibility with older versions of libosmogsm, but not with any previous release of libosmocore since the API is only available in master so far (it was added in 9fe1f9fb0b3197cdecaa55017d3afd7355e59c36). Similary, it's only user (osmo-mgw) only uses the API in master, so there's no API breakage with older releases. Related: SYS#5969 Change-Id: Ib21cee2e30bf83dff4e167f79541796007af9845
* coding: fix decoding of AHS_SID_UPDATE frames (BER ~50%)Vadim Yanitskiy2022-05-251-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As was demonstrated in [1], there is a TCH/AHS specific problem in libosmocoding causing unexpected BER ~50% in decoded AHS_SID_UPDATE frames. The reason is that A[H]S_SID_UPDATE employs quite tricky interleaving algorithm, which is different from the algorithm used by normal TCH/AHS speech frames or A[F]S_SID_UPDATE frames. An AHS_SID_UPDATE frame consists of two halves (228 bits each): +---------+--------------------|---------+--------------------+ | in-band | SID marker | in-band | coded data | +---------+--------------------|---------+--------------------+ | 16 bits | 212 bits | 16 bits | 212 bits | The first half contains coded in-band signalling data (16 bits) and the identification marker (212 bits), which allows to detect that it's an AHS_SID_UPDATE. This half is carried by even bits of the first two bursts and odd bits of the last two bursts. The other half also contains the in-band data (16 bits), while the remaining 212 bits contain encoded SID_UPDATE (212 bits). This half is carried by even bits of the last two bursts and odd bits of the first two bursts. Current implementation does not use odd bits of the first two bursts at all, so buffer cB[] in gsm0503_tch_ahs_decode_dtx() contains only 114 out of 228 bits. This patch changes the logic, so that gsm0503_tch_ahs_decode_dtx() would not split AHS_SID_UPDATE onto two frames anymore like its TCH/AFS equivalent does, but attempt to deinterleave the second half and attempt to decode the payload immediately. Change-Id: I8686d895e96fa0e606c1898b6574cc80a8f46983 Related: [1] I434157e2091a306c039123cea08d84bd8533c937 Related: SYS#5853
* tests/dtx: test tagging of FACCH/[FH] framesVadim Yanitskiy2022-05-192-0/+31
| | | | | | | | This patch adds a new test confirming that [1] actually fixes the bug. Change-Id: I3d295a15d4446b3e440fbf4c90a1688d6c7275ae Related: [1] I2e6f4b748c6445725211e264ab5f3f5a2712087a Related: SYS#5853
* tests/dtx: test detection/decoding of A[FH]S_SID_UPDATEVadim Yanitskiy2022-05-192-0/+121
| | | | | | | | | | | | | | | This patch extends the existing unit test coverage for AMR's special DTX frames. The new tests confirm that the problem with unexpected BER in decoded AFS_SID_UPDATE frames has been actually fixed [1]. Additionally this patch demonstrates another TCH/AHS specific problem, which negatively affects RxQual-SUB measurements in osmo-bts-trx: the actual content of AHS_SID_UPDATE_CN is decoded with ~50% BER, because the burst buffer contains only half of the burst bits. Change-Id: I434157e2091a306c039123cea08d84bd8533c937 Related: [1] I813081a4c0865958eee2496fe251ae17235ac842 Related: SYS#5853
* gsm: Introduce helper rach_tx_integer_raw2val()Pau Espin Pedrol2022-04-262-0/+27
| | | | Change-Id: I6ef085ee92b2064cb46fa5ec3ae98a0ca59ad599
* rsl: Fix tlv_parse of IPAC_DLCX_IND messagePau Espin Pedrol2022-04-052-0/+48
| | | | | | | The IE was missing in rsl_att_tlvdef. Related: SYS#5915 Change-Id: Ib637197ef3508ec94aec05d08d4e6aa15ddea055
* bssmap_le: support additional IEs in Perform Location RequestVadim Yanitskiy2022-03-222-0/+31
| | | | | Change-Id: I8775a93cf4089b1752d040e43d2cba6b8997f955 Related: SYS#5891
* gsm0808: Fix decoding of IE GSM0808_IE_LCS_CLIENT_TYPEPau Espin Pedrol2022-03-181-1/+1
| | | | Change-Id: I7acafdefd105e330c466df2e17e884327651e348
* gsm0808_test: Add new unit test showing dec errorPau Espin Pedrol2022-03-182-0/+55
| | | | | | | | This unit tests shows how decoding of such message fails. Fix will be provided in a follow up patch to make the test pass. Related: SYS#5891 Change-Id: Ib4ff71d5e01d464febb062c5bfe3e06ee5a19ecd
* gsm: [ABI BREAK] Support CellId SAI, change CellId CGI-PS id numberPau Espin Pedrol2022-02-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Those are available in 3GPP TS 48.008 version 16.0.0 Release 16, section 3.2.2.17 Cell Identifier. It can be seen that we have a collision between the osmocom non-standard format and the SAI standard one. This is because CGI-PS is not really a TS 48.008 Cell Identifier, but only specified in TS 48.018 and has no ID number assigned. The CGI-PS was added there because the whole osmo-bsc neighbour configuration works with CellIds to manage neighbours, so it felt natural to extend the APIs to also provide means to use CGI-PS format (TS 48.018 even refers 48.008 existance and mentions there's no explicit ID). At the time this Cell Identifier was added, the firstly available number (11) was taken, which was of course a really bad idea since newer versions of the spec can at some point use it, which is the case if one checks for instance TS 48.008 Release 16 SAI Cell Id. There no perfect way to fix this bad decision at the time, but the CGI-PS is only used in osmo-bsc and only for RIM related purposes, so by changing the ID of CELL_IDENT_WHOLE_GLOBAL_PS, we only break RIM under some specific CIs being used, and when an osmo-bsc is built against older libosmocore and then used at runtime against a newer libosmocore (which should be rare). Hence, the downside is acceptable, and by moving the new ID number to be ouside of the spec proto TS 48.008 range (4 bits), we make sure we don't have the same problem again in the future. Related: SYS#5838 Fixes: ca33a71ca8eeaee98b1b53d5394b147a4ff0b429 Change-Id: Id25e563febdb7640174540136225f399515a0089
* gsm0808: Test if we properly decode a SRVCC cell identifier listHarald Welte2022-02-161-0/+13
| | | | | | | | We don't handle this correctly, as we decided to overload the meaning of 0b1011 in a cell identifier list (defined by 3GPP as used in SRVCC) with something osmocom proprietary. Change-Id: I608220e8e5dd5a44f85c6bc5ea04622a2cad24ec
* tests/logging: merge both logging_test_{stream,wqueue}.errVadim Yanitskiy2022-01-314-21/+5
| | | | Change-Id: I0ff0a6e0d22575047cc00dd822bc94d696171076
* logging: fix printing of '\0' when filename printed lastVadim Yanitskiy2022-01-311-0/+0
| | | | | | | | | | | As was demonstrated in I54bf5e5c036efb1908232fe3d8e8e2989715fbb3, when the logging is configured to print the filename *after* the logging message, each logging line contains an artifact - '\0'. The problem is that the 'len' variable is not updated. Fix this. Change-Id: I5c920a0d5c1cf45bcdd327b39e33d63346b4f51c Fixes: I393907b3c9e0cc1145e102328adad0a83ee13a9f
* add osmo_sockaddr_to_str_c(), osmo_sockaddr_to_str_buf2()Neels Hofmeyr2022-01-311-2/+4
| | | | | | | | | | | | | | | | | | | | To easily log and print a sockaddr using OTC_SELECT, add osmo_sockaddr_to_str_c(). Implement osmo_sockaddr_to_str_buf2() using osmo_strbuf, so that we can return the chars_needed which osmo_sockaddr_to_str_c() uses. From previous osmo_sockaddr_to_str_buf(), call osmo_sockaddr_to_str_buf2() and return NULL if the buf_len was insufficient, to mimick previous behavior. This makes it more consistently returning NULL for insufficient buf_len, as shown in the tweak that is needed in socket_test.c. Before osmo_sockaddr_to_str_buf() would return a truncated port number, now it's all or NULL. I will use osmo_sockaddr_to_str_c() in the new osmo-upf implementation. Related: SYS#5599 Change-Id: I12771bf8a021e6785217b1faad03c09ec1cfef0e
* tests/logging: also test printing the filename informationVadim Yanitskiy2022-01-313-0/+10
| | | | | | | | | | | | | | | | | | | | | | This commit demonstrates a bug introduced in [1], which can be observed when the logging is configured to print the filename *after* the logging message (LOG_FILENAME_POS_HEADER_END): logging print file 1 last ^^^^ In this mode, the code in _output_buf() overwrites the '\n' sybmol contained in the logging message itself by shifting the 'offset' backwards, and appends the nipped '\n' after the filename info. The problem is that the 'len' variable is not updated in this case, so the resulting length includes +1 character - '\0', which gets printed at the end of every logging line. Interestingly enough, this problem affects only the wqueue mode. Change-Id: I54bf5e5c036efb1908232fe3d8e8e2989715fbb3 Related: [1] I393907b3c9e0cc1145e102328adad0a83ee13a9f
* tests/logging: ensure both stream and wqueue modes are testedVadim Yanitskiy2022-01-315-7/+33
| | | | Change-Id: I37e789b5b287d72c443f50fd99a5284bc7296c0b
* PFCP: add DLPFCP and osmo-upf port numbersNeels Hofmeyr2022-01-211-2/+3
| | | | | Related: SYS#5599 Change-Id: I0a46b147ec6a76d909df28136cfd2b764b2c75ea
* iuup: Submit RNL-STATUS-Initialization.ind upon rx of InitPau Espin Pedrol2022-01-072-5/+14
| | | | | | | | This allows init-passive users to get the configured sizes for the RFCIs and other similar information once engotiated with the peer. Realted: OS#1937 Change-Id: I63ee780b4aa162ea097410b234e73984000c0965
* select: gather statistics for TCP connectionsPhilipp Maier2021-12-231-0/+1
| | | | | | | | | | | osmocom applications are deployed in a variety of different situations. Dependung on the medium that interconnects the network components unexpected behaviour may occur. To debug problems with the interconnection between network components it might help to monitor the health of the related TCP connections. Change-Id: I1416f95aff2adcf13689646b7574845de169fa3d Related: SYS#5701
* Introduce CRC and FSM for IuUP (user plane) as used in 3G RTP dataHarald Welte2021-12-225-2/+604
| | | | | | | | | | | | | | | | | | | | | | | Only support for SMpSDU mode is introduced in this commit. Not supported explicit list: - Transparent mode - ATM/AAL2 based Transport layer - GTP-U based Transport Layer - Iu Rate Control procedure - Time Alignment procedure APIs are provided to allocate the primitives properly inside the related msgb. This way primitives can be placed in the headroom, leaving the data part of the msgb for the IuUP payload, hence allowing re-use of the msgb and 0 copy of IuUP payload when forwarding data over RNL<->TNL. Since RNL and TNL primitives relu struct osmo_prim_header, which is not packed, they cannot be set to packed, and hence proper memory alignment in the msgb must be done to avoid misaligned accesses (Asan errors about it otherwise). Related: SYS#5516 Change-Id: Ibe356fa7b1abaca0091e368db8478e79c09c6cb0
* treewide: remove FSF addressOliver Smith2021-12-1440-161/+5
| | | | | | | | | Remove the paragraph about writing to the Free Software Foundation's mailing address. The FSF has changed addresses in the past, and may do so again. In 2021 this is not useful, let's rather have a bit less boilerplate at the start of source files. Change-Id: I5050285e75cf120407a1d883e99b3c4bcae8ffd7
* tests/testsuite.at: ensure empty stderr for the bitvec_testVadim Yanitskiy2021-11-181-1/+1
| | | | | | | | | | | The address sanitizer may print errors and warnings to stderr, and this was actually the case for bitvec_test before [1]: bitvec.c:492:24: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int' Change-Id: Ia82b92eddb18dc596881abcef2f098dc7385538b Related: [1] I4deeabba7ebb720cdbe7c85b37bc011d05bdfa65
* bitvec_read_field(): fix incorrect bit-shift issue found by UBSanVadim Yanitskiy2021-11-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | While running a sanitized version of the bitvec_test I get: bitvec.c:492:24: runtime error: shift exponent 64 is too large for 64-bit type 'long unsigned int' This error is triggered by the following line in the bitvec_test: _bitvec_read_field(0, 8 * 8 + 1); /* too many bits */ which basically tries to parse more bits (65) than the test vector actually has (64). The problem is that we don't check if the given vector has enough data *before* entering the parsing loop, so we end up doing weird bit-shifts and getting weird values: bitvec_read_field(idx=0, len=65) => bd5b7ddffdd7b5db (error) Unfortunately, this problem remained unnoticed so far because in 'tests/testsuite.at' we don't check if stderr is empty. This is fixed in a follow up change [1]. Rather than checking for errors in every loop iteration, do this once and return early if the overrun is possible with the given offset and length arguments. Change-Id: I4deeabba7ebb720cdbe7c85b37bc011d05bdfa65 Related: [1] Ia82b92eddb18dc596881abcef2f098dc7385538b
* bitvec_read_field(): indicate errors using errnoVadim Yanitskiy2021-11-182-17/+18
| | | | | | | | | | | | | | | | | | | | | This function returns an *unsigned* integer (uint64_t), so returning a negative value on error is a bad idea. A negative value turns into a huge positive value, what was demonstrated in the bitvec_test: bitvec_read_field(idx=512, len=16) => ffffffffffffffea bitvec_read_field(idx=0, len=65) => ffffffffffffffea bitvec_read_field(idx=64, len=16) => ffffffffffffffea The 0xffffffffffffffea above is basically: (uint64_t) -EINVAL, or (uint64_t) -22 + 1, or 0xffffffffffffffff - 0x16 + 1. Let's make use of the errno in order to indicate an error to the caller. Change-Id: I2cc734caa3365d03c2ae2b3f2cd9544933c25e9e Related: OS#4388
* tests/tdef: rename the binaries to end with '_test'Vadim Yanitskiy2021-11-177-21/+21
| | | | | | | | It's the usual naming for unit test binaries. Without the '_test' endig, the tdef_vty_test_{config_root,config_subnode,dynamic} binaries do not match the 'tests/*/*_test' pattern and appear as untracked files in git. Change-Id: I828fa45132e11a41c527d4b25df850c19871cb75
* tests/vty: fix use of GNU 'missing =' extension in designatorVadim Yanitskiy2021-11-171-3/+3
| | | | Change-Id: I66edb247898594b51cc9d7c1b3d0c60ba66fc637
* add osmo_time_cc, moved from osmo-bscNeels Hofmeyr2021-11-154-0/+1109
| | | | | | Related: SYS#4878 Related: Ica9f908a1a30f334a24c59471affa11225117e12 (osmo-bsc) Change-Id: Iabb17a08e6e1a86f168cdb008fba05ecd4776bdd
* stats: clarify error messages in cfg_no_stats_reporter_{statsd,log}Vadim Yanitskiy2021-11-091-0/+5
| | | | | Change-Id: I287130213c7de31a510f293bed0f3daddd53ce04 Related: SYS#5713
* stats: don't mark reporter as 'disable' beforehandVadim Yanitskiy2021-11-091-14/+4
| | | | | Change-Id: I330a079807cca48b7cc43767abcd2b58830a05fc Related: SYS#5713
* stats: cosmetic: print 'stats interval' before the reportersVadim Yanitskiy2021-11-091-1/+1
| | | | | | | It's better to have the common parameters printed first. Change-Id: Ifb401d4d363fb70e89960ca739baba5ee55eefe8 Related: SYS#5713
* stats: allow configuring reporter's name in the VTYVadim Yanitskiy2021-11-091-4/+70
| | | | | | | This allows configuring more than one reporter of the given type. Change-Id: Ia815c24dc974648985539913012b3b074ea317a9 Related: SYS#5713
* stats: use llist_add_tail() in osmo_stats_reporter_alloc()Vadim Yanitskiy2021-11-091-34/+34
| | | | | | | This allows printing reporters in the exact order as they were configired. Change-Id: I904cd0ed53510dbe26c15cd287ba2707ca04cd6e Related: SYS#5713
* tests/stats: add VTY transcript testsVadim Yanitskiy2021-11-093-0/+255
| | | | | Change-Id: I85ac73f4c866617179e55821a292aad33b6edc99 Related: SYS#5713
* logging: Change stderr + file target to use non-blocking writeHarald Welte2021-10-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | So far, we used blocking, buffered fwrite() to write to stderr and file targets. This causes problems if there are [slow] consumers causing delays, such as gnome-terminal (when the program is started interactively) or systemd/journald (where we observe 64..128ms blocks on stderr). This patch introduces stderr/file based logging via write_queue and osmo_select_main(), i.e. switch from glibc-buffered, blocking to internally buffered, non-blocking writes. * when osmo_stderr_target is created via application.c, we create it in blocking stream mode for backwards compatibility, particularly for [smaller] programs that don't use osmo_select_main() * when the VTY code encounters 'log stderr' or 'log file FILENAME', we switch that respective target to non-blocking write-queue mode, as this means the application is in fact using osmo_select_main() * The config file can now state 'log stderr blocking-io' or 'log file FILENAME blocking-io' to explicitly enforce using blocking stream based I/O * The application can at any time use API functions to switch either way Closes: OS#4311 Change-Id: Ia58fd78535c41b3da3aeb7733aadc785ace610da
* ns2: message: BLOCK/BLOCK ACK allow to use a given NSVCI instead of using the nsvc nsvciAlexander Couzens2021-10-081-1/+1
| | | | | | | The BLOCK and BLOCK ACK PDUs can be send over a working NSVC to inform the NSE that a NSVC is blocked. Change-Id: I6189229fdc1f054e86811bc60cb7646e1f758a78
* refactor stat_item: report only changed valuesNeels Hofmeyr2021-09-302-6/+4
| | | | | | | | | | | | | | | | | Change the functionality of skipping unchanged values: instead of looking up whether new values have been set on a stat item, rather remember the last reported value and skip reporting identical values. stats_test.c shows that previously, a stat item reported a value of 10 again, even though the previous report had already sent a value of 10. That's just because the value 10 was explicitly set again, internally. From a perspective of preserving all data points, it could make sense to send consecutive identical values. But since we already collapse all data points per reporting period into a max, that is pointless. Related: SYS#5542 Change-Id: I8f4cf34dfed17e0879716fa2cbeee137c158978b
* refactor stat_item: get rid of FIFO and "skipped" errorNeels Hofmeyr2021-09-303-106/+124
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Intead of attempting to store all distinct values of a reporting period, just store min, max, last as well as a sum and N of each reporting period. This gets rid of error messages like DLSTATS ERROR stat_item.c:285 num_bts:oml_connected: 44 stats values skipped while at the same time more accurately reporting the max value for each reporting period. (So far stats_item only reports the max value; keep that part unchanged, as shown in stats_test.c.) With the other so far unused values (min, sum), we are ready to also report the minimum value as well as an average value per reporting period in the future, if/when our stats reporter allows for it. Store the complete record of the previous reporting period. So far we only compare the 'max' value, but like this we are ready to also see changes in min, last and average value between reporting periods. This patch breaks API by removing: - struct members osmo_stats_item.stats_next_id, .last_offs and .values[] - struct osmo_stats_item_value - osmo_stat_item_get_next() - osmo_stat_item_discard() - osmo_stat_item_discard_all() and by making struct osmo_stats_item opaque. In libosmocore, we do have a policy of never breaking API. But since the above should never be accessed by users of the osmo_stats_item API -- or if they are, would no longer yield useful results, we decided to make an exception in this case. The alternative would be to introduce a new osmo_stats_item2 API and maintaining an unused legacy osmo_stats_item forever, but we decided that the effort is not worth it. There are no known users of the removed items. Related: SYS#5542 Change-Id: I137992a5479fc39bbceb6c6c2af9c227bd33b39b
* ns2: nsvc: add a uptime/downtime to track the last state changeAlexander Couzens2021-09-231-8/+8
| | | | | | | | | | | | | | | | | To show adminstrator the last state change of a nsvc add a timestamp and show it on the vty > show ns nsei 1234 NSEI 01234: UDP, DEAD since 0d 0h 1m 42s [...] 4 NS-VC: UNBLOCKED DYNAMIC sig_weight=1 data_weight=1 udp)[127.0.0.1]:22000<>[127.0.0.1]:23001 ALIVE since 0d 0h 0m 1s UNBLOCKED DYNAMIC sig_weight=2 data_weight=2 udp)[127.0.0.1]:22000<>[127.0.0.1]:23000 ALIVE since 0d 0h 0m 1s UNBLOCKED DYNAMIC sig_weight=2 data_weight=2 udp)[127.0.0.1]:22001<>[127.0.0.1]:23000 ALIVE since 0d 0h 0m 1s UNBLOCKED DYNAMIC sig_weight=1 data_weight=1 udp)[127.0.0.1]:22001<>[127.0.0.1]:23001 ALIVE since 0d 0h 0m 1s Related: OS#5028 Change-Id: Ie3a039a209869295afa5feda39297cee81fedf22
* ns2: nse: add a uptime/downtime to track the last state changeAlexander Couzens2021-09-231-2/+2
| | | | | | | | | | | | | | | | | To show adminstrator the last state change of a nse add a timestamp and show it on the vty > show ns nse 1234 NSEI 01234: UDP, ALIVE since 0d 0h 0m 16s FSM Instance Name: 'GPRS-NS2-SNS-SGSN(NSE01234-SNS)[0x6120000012a0]', ID: 'NSE01234-SNS' Log-Level: 'DEBUG', State: 'CONFIGURED' Timer: 4 Maximum number of remote NS-VCs: 8, IPv4 Endpoints: 2, IPv6 Endpoints: 0 [...] Related: OS#5028 Change-Id: I8143080a3c5c9a55d37dfad44ba2ac6561daa216
* osmo-auc-gen: Print RFC3310 IMS HTTP-AKA style base64 nonce/resHarald Welte2021-09-211-0/+30
| | | | | | | This is useful when debugging IMS Authentication which uses RFC3310 representation of the nonce and expected result. Change-Id: Ibfa72410d8ff8e5b42063f1a12bff69ad2bebbb8
* base64: reformat using Lindent to conform to our coding styleHarald Welte2021-09-211-32/+30
| | | | Change-Id: I2286fa0d2cba7c11359bb48329135dfcd0d8a948
* base64: Migrate over to osmocomHarald Welte2021-09-214-0/+70
| | | | | | | This containts the osmocom changes to the mbedtls base64 code merged in the previous commit. Change-Id: I82c1bf5f827c8def370dbcb80b146e9e4184c4a3
* stats_test: assert counter and stat item val counts separatelyNeels Hofmeyr2021-09-202-57/+51
| | | | | | | | | | | | | Instead of just a send_count, keep one such count for the counter updates, and a separate one for the stat item updates. Print those numbers in the test output. An upcoming patch will tweak stat_item reporting so that only an actually changed value results in sending a new stat value. This patch allows illustrating that change clearly. Related: SYS#5542 Change-Id: I2da003ee6ec15f1c3959efe69e01b4ee24af82bb
* utils: add osmo_str_to_int() and osmo_str_to_int64()Neels Hofmeyr2021-09-122-3/+316
| | | | | | | | | | | | | | | Properly converting a string to an integer while validating against all possible errors is not trivial. It is a recurring theme in code review, and there are places in osmo code that do it wrong. End this by providing a simple API, if for nothing else then as an example of how to use strol() / strtoul() / strtoll() / strtoull() in an airtight way. A subsequent patch, adding stat items to the CTRL interface, uses this to properly validate indexes in CTRL variables and convert them to int. Related: SYS#5542 Change-Id: I4dac826aab00bc1780a5258b6b55d34ce7d50c60
* gprs_ns2_sns: implement local change weight procedureAlexander Couzens2021-09-041-1/+1
| | | | | | | | When changing the bind ip-sns weight, initiate a SNS CHANGE WEIGHT procedure to inform the other side. Related: OS#5036 Change-Id: Icec4dabb46bc198f68f91bfe09ba279fbe68d454
* stats: send real last value if no new values comeOliver Smith2021-08-202-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Background: * Individual values can be added to osmo_stat_item.values at any time. * Stats are reported at a fixed interval (see vty 'stats interval'), e.g. every 10 seconds. * In order to report a new stat value, we use the maximum of all osmo_stat_item.values added since the last report. * By default, we do not send new stat values if they did not change (see vty 'config-stats' -> 'flush-period' default of 0). Fix the following bug: * If 'flush-period' is 0, and no new osmo_stat_item.values are coming in, the last value that gets reported is not necessarily the last entry in osmo_stat_item.values. * For attached reporters (statsd), it could then be that the given stat stays at the wrong value for a long stretch of time (think of several hours/days/forever). Explanation of how the test shows that it is fixed: * stats get reported (value is irrelevant) * osmo_stat_item gets a new value: 20 * osmo_stat_item gets a new value: 10 * stats get reported (value: 20, the maximum of both new values) * osmo_stat_item gets no new values * stats get reported (value: 10, this is new because of the bug fix, the real last value in osmo_stat_item, different from the 20 sent earlier, without the fix it would not send anything here and the last sent value would be 20) * osmo_stat_item gets no new values * stats get reported (nothing gets sent, since the real last value was already sent and 'flush-period' is 0) Fixes: OS#5215 Change-Id: Ibeefd0e3d1dbe4be454ff05a21df4848b2abfabe
Copyright © 1996 – 2023 Jason A. Donenfeld. All Rights Reverse Engineered.