| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
Change-Id: I52b9f6b5f3e96d85a390ba2af21d7814df8aaeec
|
|
|
|
|
|
|
|
|
| |
This reverts commit b3f94eb39e19366c3458643ee329a73155d46ff8, that
unfortunately breaks some projects which call osmo_fsm_register()
on DSO load (i.e. using __attribute__((constructor))) before the
logging is initialized.
Change-Id: Idc6fcce7e946c23d48589b920e309d60aa7b6645
|
|
|
|
|
|
|
|
|
|
| |
As suggested by Vadim while reviewing a related fix for ipa_keepalive.c
in libosmo-abis (see https://gerrit.osmocom.org/#/c/libosmo-abis/+/13540/),
it makes sense to print an error message if anyone registers a FSM
that specifies an allstate_action callback but at the same time no
events that would ever end up in that callback.
Change-Id: I9e73f7363ab15a00843e3f0d1e5776f4be7ebc46
|
|
|
|
|
|
|
|
|
|
|
| |
incomplete to vty func
For instance, take command "single0 [one]":
If user executes "single0 on", VTY func will receive argv[0]="one"
instead of argv[0]="on".
Related: OS#4045
Change-Id: I5f4e2d16c62a2d22717989c6acc77450957168cb
|
|
|
|
|
|
|
|
|
|
|
| |
vty func
For instance, take command "multi0 (one|two|three)":
If user executes "multi0 tw", VTY func will receive argv[0]="two"
instead of argv[0]="tw".
Fixes: OS#4045
Change-Id: I91b6621ac3d87fda5412a9b415e7bfb4736c8a9a
|
|
|
|
|
|
|
|
| |
The test shows that in the case were "single0 on" is executed, VTY
function should return complete "single0 one" but it doesn't.
Related: OS#4045
Change-Id: Ib5b9dc07e2b280dc95011b3926afb1d490cadd81
|
|
|
|
|
|
| |
This block will become bigger in forthcoming commits.
Change-Id: Ibc1494014b1e77ce10950f7268a44d2d2091a6f2
|
|
|
|
|
|
|
| |
Check against MAX argc is changed to == since it cannot be incremented
twice without passing the check.
Change-Id: Ia330e475989fda863bedcc3cbf94deaf8dd83037
|
|
|
|
|
|
|
|
| |
It was noticed that multithreaded processes like osmo-trx can crash upon
using ctime().
Related: OS#4055
Change-Id: I19ebf29a2f1fc855bb7d56766b338c7c3432dfd1
|
|
|
|
| |
Change-Id: I697af428a2ea9a0ccd3f04ba8ec4664935ae29f8
|
|
|
|
|
| |
Related: OS#4055
Change-Id: Ief155a76169426a677256e09d3e91751c4e2529f
|
|
|
|
|
|
|
|
|
|
|
| |
the DEBUG macro name and ARRAY_SIZE macro function are frequently
used in other projects. If these projects also use libosmocore,
the macros will be redefined. This also generates a warning message
during compilation.
Not redefining the macros removes the warning message and possible
(but unlikely) mis-redefinition.
Change-Id: I0ba91eae8eacc5542d1647601b372e417ed1713c
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fixes the following error warnings when cross-compiling using:
./configure --enable-static --prefix=/usr/local/arm-none-eabi --host=arm-none-eabi --enable-embedded --disable-doxygen --disable-shared --disable-pseudotalloc --enable-external-tests CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs -Werror -Wno-error=deprecated -Wno-error=deprecated-declarations -Wno-error=cpp -mthumb -Os -mlong-calls -g3 -mcpu=cortex-m4 -mfloat-abi=softfp -mfpu=fpv4-sp-d16 -Wno-error=format"
utils.c:1002:18: error: array subscript has type 'char' [-Werror=char-subscripts]
1002 | if (!isdigit(in[i]))
gsm23003.c:414:34: error: array subscript has type 'char' [-Werror=char-subscripts]
414 | if (!mnc_str || !isdigit(mnc_str[0]) || strlen(mnc_str) > 3)
Change-Id: Ia13fd5ee79fc6dc3291c0b99958ab3c01afee17d
|
|
|
|
|
|
|
|
| |
Huge conditional block inside for loop is negated in this patch
together with a "continue" keyword, similar to what was already done
recently in 4742526645d6137dd90ef369f0415afdb91736dc.
Change-Id: I803c4ed38e9ab09bf929528c75a60e6f65da3928
|
|
|
|
|
|
|
| |
Makes code easier to follow because enum values no longer look like
variables.
Change-Id: Ib6e9592c5962d047869a280c10f9b557fae6f435
|
|
|
|
| |
Change-Id: I6b486b52a3733d5fd5e8ba18acbc9374e2e8bd7e
|
|
|
|
| |
Change-Id: I085da06f31a0a6862ae2ba041fafc134cc240f7e
|
|
|
|
|
|
|
|
|
|
| |
inner block defined variable "enum match_type ret" was being masking
outter block variable "int ret = 0". The ret variable was being given
non zero values only inside the inner block, so that change was done on
the inner variable and not the outer one, which is returned.
Fixes: 5314c513f23688462d7f7937e5ae5e0d5cd4548e
Change-Id: Iec87d7db49a096d07e38ff8a060b923a52bfd6ba
|
|
|
|
|
|
|
| |
Huge conditional block inside foor loop is negated in this patch
together with a "continue" keyword.
Change-Id: I9715734ed276f002fdc8c3b9742531ad36b2ef9e
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Return ENOSPC if the decoding buffer is one byte too small, instead of
returning 0 and silently truncating the string. Add a new "truncated"
variable to detect if the loop breaks in the final iteration.
The string is not truncated if there is exactly one 0xf ('\0') higher
nibble remaining. This is covered by the existing test case "long
15-digit (maximum) MSISDN, limited buffer".
Related: OS#4049
Change-Id: Ie05900aca50cc7fe8a45d17844dbfcd905fd82fe
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is a result of discussion we had in [1]. The key idea
is that libosmovty should properly auto-complete the commands
containing choice, such as the following one:
multi0 (one|two|three)
[1] If9b0c0d031477ca87786aab5c269d00748e896c8
Right now, sending the following command:
(osmo-foo-bar)# multi0 th
would basically match the following vector:
multi0 three
however the resulting argv would be:
["multi0", "th"]
Moreover, sending the following command:
(osmo-foo-bar)# multi0 t
would basically match the following vectors:
multi0 two
multi0 three
because both start from 't', so the resulting argv would be:
["multi0", "t"]
which is ambiguous!
The expected output is:
(osmo-foo-bar)# multi0 th
ok argc=1 three
(osmo-foo-bar)# multi0 t
% Ambiguous command.
This is going to be fixed in the follow up patches.
Change-Id: I83c3aef813173952641035862c534ef16384780e
|
|
|
|
|
|
|
|
| |
Instead of copy+pasting the same LOGPFSMSRC("State change to " ...)
with slightly different trailer depending on the FSM timer, let's first
snprintf() to a stack variable and then have a single log statement.
Change-Id: I49528c4ca1fa11aef09c2092615dccca450b847c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, the public API of osmo_fsm only allowed integral seconds as
timeout. Let's change that to milli-seconds in order to cover more
use cases.
This introduces
* osmo_fsm_inst_state_chg_ms()
* osmo_fsm_inst_state_chg_keep_or_start_timer_ms()
Which both work exactly like their previous counterparts without the _ms
suffix - the only difference being that the timeout parameter is
specified in milli-seconds, not in seconds.
The value range for an unsigned long in milli-seconds even on a 32bit
platform extends to about 48 days.
This patch also removes the documentation notice about limiting the
maximum value to 0x7fffffff due to time_t signed-ness. We don't use
time_t but unsigned long.
Change-Id: I35b330e460e80bb67376c77e997e464439ac5397
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During testing with BTS_Tests_LAPDm.TC_t200_n200() it was discovered
that the existing LAPD[m] implementation always gave up at N200-1
retransmissions, rather than N200 retransmissions.
The first transmission doesn't count, and hence we must have N200
actual re-transmissions. The Error message is then described as
"T200 expired N200+1 times", i.e. we start T200 one more time after
the last re-transmission and only give up if it expires again (i.e.
no ACK received)
Change-Id: Ic33854ee61311f73b7db55eeef10280349151097
Related: OS4037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TS 04.06 specifies a N200 re-transmission counter that depends on the
channel type, which we didn't care about at all so far. Let's have the
caller tell us the channel type so we can internally look up the correct
N200 value for it.
At the same time, permit the user to specify T200 re-transmission timer
values for each SAPI on both DCCH and ACCH, which is required at least
in the BTS as per GSM TS 12.21. Also, extend the timer resolution of
the API from seconds to milli-seconds, which is more applicable as
particularly on the FACCH the recommended values are in the 200ms range.
Change-Id: I90fdc4dd4720d4e02213197c894eb0a55a39158c
Related: OS#3906
Related: OS#2294
Related: OS#4037
|
|
|
|
|
|
|
|
|
| |
This function parses a single Cell ID list element into a
'union gsm0808_cell_id_u'. This function is going to be used
by the upcoming CBSP support.
Related: OS#3537
Change-Id: I08b33881667aa32f01e53ccb70d44d5b79c7c986
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have a number of library-internal static global buffers which are
mainly used for various stringification functions. This worked as
all of the related Osmocom programs were strictly single-threaded.
Let's make those buffers at least thread-local. This way every thread
gets their own set of buffers, and it's safe for multiple threads to
execute the same functions once. They're of course still not
re-entrant. If you need re-entrancy, you will need to use the _c()
or _buf() suffix version of those functions and work with your own
(stack or heap) buffers.
Change-Id: I50eb2436a7c1261d79a9d2955584dce92780ca07
|
|
|
|
|
|
|
|
| |
Receive gsmtap logs and feeds it into the python logging
framework. Allows to use generic logging features and
further utilities.
Change-Id: I24478d8e16066c6118e867bdba54c6418c15e170
|
|
|
|
|
|
|
|
|
| |
3GPP TS 04.06 is quite clear that the [segmented] L3 payload can be as
long as 251 bytes. Our libosmocore lapdm implementation truncated
already at 200 bytes :(
Change-Id: I6769986f27dda1d429ed7b2e32c36d34663acba9
Closes: OS#4035
|
|
|
|
|
|
| |
One typo s/optionall/optionally/, and a few incorrect references.
Change-Id: Iab42aa376b5cf4cf36413fede46e001c6b2d1525
|
|
|
|
|
|
| |
Otherwise it's a bit hard to read the code.
Change-Id: I807ec71cfb67976251be844cdb2d2776b1837438
|
|
|
|
| |
Change-Id: Iafd911dd55691b3715391e3899cd6971245c8d7f
|
|
|
|
|
|
|
|
| |
The library should either provide functions that implement encoding
of those rest octets, or it shouldn't. Providing a function that
doesn't do anything but pad the buffer is useless.
Change-Id: Ie10684de6a6b2663e2a871fcdb2b275b6ad7a1e7
|
|
|
|
|
|
|
|
|
| |
There's very little sense behind introducing a function into
libosmogsm which doesn't implement 90% of the spec. Let's allow
the caller to provide the various optional bits of information to
the encoder, rather than generating mostly static SI6 rest octets.
Change-Id: Id75005a0c4a02ce7f809692d58b3bd226bc582b2
|
|
|
|
|
|
| |
Change-Id: I690cf308311f910005a325d50f5d5d825678d2b2
Related: OS#3075
Related: OS#4023
|
|
|
|
|
|
| |
... otherwise it's not really clear what they do.
Change-Id: I08e0ca9a8d13c7aa40b9d90f34f0e13adb87d4e0
|
|
|
|
|
|
|
|
| |
the symbols had an omso_ prefix, while the entry in the .map file
didn't. As a result, all related symbols were never exported and
hence not usable by any users of the dynamic library.
Change-Id: I8b1ee2405f6338507e9dfb5f1f437c4c2db2e330
|
|
|
|
|
|
|
|
|
| |
The gsm48_rest_octets.c file was added in Change-Id
I47888965ab11bba1186c21987f1365c9270abeab, but it never actually
ended up being compiled as it wasn't listed in the makefile :/
Change-Id: I0355115c2645f236c9e32cf7a563cf51a857e8a3
Relsted: OS#3075
|
|
|
|
|
|
|
|
|
| |
As gsm48_rest_octets.c is not listed in the Makefile.am, it's
never actually compiled and we never noticed that it's calling
functions by symbol names that don't exist :/
Change-Id: I7b1e436f70e0c60979261db87606f38271ec47d3
Related: OS#3075
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libosmo{core,gsm,vty} code is GPLv2+. The rest octet code originated in
osmo-bsc.git and was moved here without changing the license. That was a
mistake, it always was meant to be under GPLv2-or-later after moving to
libosmocore.git.
Original copyright is mine. For contributions by sysmocom, I as the
managing director can approve the license change.
This means only Holger needs to ACK this.
Change-Id: Ief3009dc28dd83e1e26a7101af2eed2341684a87
|
|
|
|
| |
Change-Id: Ie07b2e8bc2f9628904e88448b4ee63b359655123
|
|
|
|
|
|
|
|
| |
The documentation of gsm48_decode_bcd_number2() clearly states that
the output truncation is a erroneous case, so it should actually
return negative in such cases. Let's return -ENOSPC.
Change-Id: I75680f232001ba419a587fed4c24f32c70c3ad2b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Thanks to the new unit test for BCD number encoding / decoding, it was
discovered that gsm48_decode_bcd_number2() does not properly handle
encoded LV if the output buffer size is equal to the original MSISDN
length + 1 (\0-terminator): one digit is lost.
For example, decoding of 15-digit long MSISDN to a buffer of size
16 (15 digits + 1 for \0) would give us only 14 digits.
The problem was that 'output_len' was being decremented before
checking the remaining buffer length and writing a digit to it.
As a result, the maximum length was always one byte shorter.
Change-Id: I61d49387fedbf7b238e21540a5eff22f6861e27a
Fixes: OS#4025
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, both gsm48_encode_bcd_number() and gsm48_decode_bcd_number2()
did not have any unit test coverage. Let's fill this gap by testing
the following scenarios:
- encoding / decoding of a regular 9-digit MSISDN;
- encoding / decoding of a MSISDN with optional LHV;
- encoding / decoding of a long 15-digit MSISDN;
- encoding / decoding of a MSISDN to a buffer:
- with exactly matching size,
- with lower size (truncation);
- decoding LV buffer with incorrect length,
- encoding / decoding an empty input buffer.
As it turns out, gsm48_decode_bcd_number2() does not properly
handle encoded LV if the output buffer size is equal to the
original MSISDN length + 1 (\0-terminator): one digit is lost.
For example, decoding of 15-digit long MSISDN to a buffer of size
16 (15 digits + 1 for \0) would give us only 14 digits. This is
reflected in the unit test output:
Decoding HEX (buffer limit=16) '0821436587092143f5'...
Expected: (rc=0) '123456789012345'
Actual: (rc=0) '12345678901234'
Moreover, if the output buffer is shorter than decoded number,
gsm48_decode_bcd_number2() silently truncates it and returns 0,
while its description states, that the rc should reflect this.
To be fixed in the follow-up patches.
Change-Id: I4b2c330cf8ffe4427c0bee7d5f3b74be56ecd85d
Related: OS#4025
|
|
|
|
|
|
|
|
|
|
|
|
| |
libosmo{core,gsm,vty} code is GPLv2+. The tdef code originated in
osmo-msc.git and was moved here without changing the license. That
was a mistake, it always was meant to be under GPLv2-or-later after
moving to libosmocore.git.
Copyright is with sysmocom, so I as the managing director can
approve the license change.
Change-Id: Ie483ff6f6ea0a56c477649677b4b163c49df11d7
|
|
|
|
|
|
|
|
|
|
|
|
| |
libosmo{core,gsm,vty} code is GPLv2+. The OAP code originated in
osmo-msc.git and was moved here without changing the license. That
was a mistake, it always was meant to be under GPLv2-or-later after
moving to libosmocore.git.
Copyright is with sysmocom, so I as the managing director can
approve the license change.
Change-Id: I08311fa8214c15f8df8945b9894226608cf96f15
|
|
|
|
|
|
|
|
|
|
|
| |
We don't really *need* it in libosmocore as such, but the lack of
having all osmocom extensions listed here lead to using overlapping
definitions: 0x18 was used for dynamic PDCH on the Abis side, but also
for CBCH on the L1SAP side. Let's list them all here to increase
visibility in case anyone wants to extend this further...
Related: OS#4027
Change-Id: I93e557358cf1c1b622f77f906959df7ca6d5cb12
|
|
|
|
| |
Change-Id: Ic6d32c886f6f8f859e382d48f9e1b509000db9ba
|
|
|
|
|
|
|
|
|
|
|
|
| |
The caller of lapdm_rslms_recvmsg() (e.g. osmo-bts/src/common/rsl.c)
assumes the message ownership is transferred. However, in one of the
two error paths, msgb_free() was not called and hence we had a memory
leak.
Also clarify the msgb ownership transfer in a comment.
Related: OS#3750
Change-Id: Id60cb45e50bfc89224d97df6c68fcd2949751895
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, the TLV code contained two types of functions
* tlp_parse() to parse all TLVs according to definition into tlvp_parsed
* various helper functions to encode individual TLVs during message
generation
This patch implements the inverse of tlv_parse(): tlv_encode(), which
takes a full 'struct tlv_pared' and encodes all IEs found in it. The
order of IEs is in numerically ascending order of the tag.
As many protocols have different IE/TLV ordering requirements, let's add
a tlv_encode_ordered() function where the caller can specify the TLV
ordering during the one-shot encode.
Change-Id: I761a30bf20355a9f80a4a8e0c60b0b0f78515efe
|