Using 'uint8_t' for the length argument is definitely a bad idea.
Because of this, packing more than 255 septets would not work as
expected. Deprecate the old function and use 'size_t' instead.
Change-Id: Ib1aac538afeb0a5c76a1df472d555139a496e12e
As can be seen, this unit test reveals problems with encoding
of more than 250 septets using gsm_7bit_encode_n(). The problem
is that some API functions use type 'uint8_t' for the length, so
we basically suffer from integer overflows.
Change-Id: I723300578d5ab0c7b94cf49c14d962b2dbf47740
Avoid code duplication between three different drivers by sharing
the "core" of the bind initialization in a new, shared ns2_bind_alloc().
Change-Id: I535fc68e94fcd695de827dd922706adc1c5a2cb7
All public enum should have the prefix GPRS_NS2_.
API change which must be synchronized with osmo-pcu,
osmo-gbproxy, osmo-sgsn.
Change-Id: I548ff12f7277cbb7e1a630a3dc02b738ce89be72
All functions which are exposed by gprs_ns2_internal.h should not contain
the public prefix gprs_. Internal function should only contain ns2_ prefix.
Change-Id: Icecc5a918902cd10efac72bbac20780d39aab272
Prepare to set -std=gnu89 in a future commit, which will cause gcc warn
about "control reaches end of non-void function" in main().
Change-Id: I7c33cac30e5859060f083813d8433011f5eaf0d0
[ 352s] gb/gprs_ns2_test.c: In function 'test_block_unblock_nsvc':
[ 352s] gb/gprs_ns2_test.c:200:2: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
[ 352s] for (int i=0; i<2; i++) {
[ 352s] ^
[ 352s] gb/gprs_ns2_test.c:200:2: note: use option -std=c99, -std=gnu99, -std=c11 or -std=gnu11 to compile your code
Change-Id: I72310886bef4db635078b75715c9d98ee45391cc
The vty should be able to block or unblock a specific NSVC.
Further more this case is special for the UNITDATA as those
can be still received until the other side response to the BLOCK PDU.
Related: OS#4939
Change-Id: Ic0ce3c5fabc8644cc1ee71a8f6dd783fadf7b84d
free_bind() should free up all driver specific state but NOT
the bind itself. As the only thing left is clearing the pdus
rename the function to it.
Change-Id: Iac506734c93aca8be045ac13788d07d1bdc78eb3
The function bssgp_parse_rim_ri() and bssgp_create_rim_ri() are located
in gprs_bssgp.c, since there is now a gprs_bssgp_rim.c module it makes
more sense to put them there. Also adjust the code a bit so that its
more intuitive to read.
Change-Id: Icd667f41d5735de56cd9fb257670337c679dd258
Related: SYS#5103
BSSGP RIM uses a number of nested containers to signal RIM application
specific payload information in a generic way. Lets add the container
structurs required for NACC.
Depends: libosmocore If48f412c32e8e5a3e604a78d12b74787a4786374
Change-Id: Ibbc7fd67658e3040c12abb5706fe9d1f31894352
Related: SYS#5103
The libosmocore TLV parser had a number of insufficient bounds checks
leading to reads beyond the end of the respective input buffer.
This patch
* adds proper out-of-bounds checks to all TLV types
* simplifies some of the existing checks
* introduces test cases to test all the corner cases
where either TAG, or length, or value are not fully contained
in the input buffer.
Thanks to Ilja Van Sprundel for reporting these problems.
Change-Id: I98b02c914c9e3ecf56050af846292aa6979d7508
This adds an inter-thread queue "it_q" to libosmocore. With it_q,
one can perform thread-safe enqueing of messages to another thread,
who will receive the related messages triggered via an eventfd
handled in the usual libosmocore select loop abstraction.
Change-Id: Ie7d0c5fec715a2a577fae014b0b8a0e9c38418ef
A dummy client to do integration tests of the ns2 layer.
It drop all unit data. But allows vty tests.
Change-Id: I127c178426bc1a3da8de251740eda93853030d6d
The RIM Routing Information IE (see also 3GPP TS 48.018, section
11.3.70) is used to control the flow of BSSGP rim messages at the SGSN.
Change-Id: I6f88a9aeeb50a612d32e9efd23040c9740bc4f11
Related: SYS#5103
Historically, BSSGP uses a non-constant, user-configurable integer
varieable for the logging sub-system. Let's replace this with a
statically-allocated library logging constant.
This is required if we want to use the subsystem number in e.g.
static initialized for osmo_fsm.log_subsys.
Change-Id: I506190aae9217c0956e4b5764d1a0c0772268e93
100 minutes = 6000000000 microseconds was too big to be stored in an
unsigned long in a 32bit platform, making the test print 4294967295
instead. Let's set a smaller value to have the test happy on 32 bits.
Change-Id: Ic0d009f00a69cee59f2d3fc0b40ecdc97d81c75c
3GPP TS 24.008 section 10.5.1.7 describes a Mobile Station Classmark 3
IE, which is encoded as CSN.1 struct. This means that it can not be
parsed by just casting a memory location to a struct pointer, so lets
add a parser to parse the CM3 IE.
This is fixed version of Ic8b2bfd00330235f5bed00771e421588abfaac1f,
which got reverted because it used the keyword "class" as struct member,
which lead into problems with c++ builds. This is now fixed.
Change-Id: Id8732551b33616227609cd6fcf6c3133751a89eb
Related: OS#4796 SYS#5114
60 seconds = 6000000000 microseconds was too big to be stored in an
unsigned long in a 32bit platform, making the test print 4294967295
instead. Let's set a smaller value to have the test happy on 32 bits.
Change-Id: I97d53f6b7b410cef4b3f3fbe3162626fcdd7b05a
This reverts commit a4939dc846,
which caused massive build failures in C++ programs like osmo-pcu
- unsurprisingly, as it calls a struct member "class", which is a
reserved keyword in C++.
Change-Id: Ia43e56385e7b580f492c560aee8ff8b1e8a0e1d8
Some applications may need submillisecond timers, such as those
interacting with modbus serial lines (RS-485, RTU), which require
timers of values around 1.5 char-time (T1.5), where a data char is
composed of 11 bits sent on the line: 1 start bit, 8 data bits,
1 stop bit, and and parity bit (or 2nd stop bits if no parity).
For instance, for a baudrate of 9600:
1.5 * 11 / 9600 = 1.718 ms = 1718 us
So having a granularity of MS is not enough here.
Change-Id: I71848d7c1ee0649929ce07680ee7320bb2a42f0e
3GPP TS 24.008 section 10.5.1.7 describes a Mobile Station Classmark 3
IE, which is encoded as CSN.1 struct. This means that it can not be
parsed by just casting a memory location to a struct pointer, so lets
add a parser to parse the CM3 IE.
Change-Id: Ic8b2bfd00330235f5bed00771e421588abfaac1f
Related: OS#4796 SYS#5114
Some VTY commands are intentionally hidden, e.g. because they might
by relatively dangerous if used in production operation. We equip
such commands with a special attribute - CMD_ATTR_HIDDEN.
The problem is that neiter they appear in the XML VTY reference,
nor in the online VTY help, so it's a bit tricky to invoke them.
This change introduces so-called 'expert' mode, in which hidden
(but not deprecated) commands are getting visible.
In the (telnet) VTY session, this mode can be activated by passing
an additional argument to well-known 'enable' command:
OsmoApp> enable ?
[expert-mode] Enable the expert mode (show hidden commands)
OsmoApp> enable expert-mode
OsmoApp#
so then hidden commands will appear together with all the other
commands. They will be marked with a special '^' flag:
OsmoApp# list with-flags
^ ... foo-hidden [expert-mode]
. ... foo-regular-one
! ... foo-immediate
^ u.. app-hidden-unbelievable
For the XML reference generation, additional API needs to be
introduced. This will be implemented in subsequent patches.
Change-Id: Ie69c2a19b22fb31d7bd7f6412f0aeac86ea5048f
Related: SYS#4910
Otherwise we get (valid!) format string warnings like these on 32bit
targets:
[ 372s] bssmap_le/bssmap_le_test.c: In function 'test_bssmap_le_enc_dec':
[ 372s] bssmap_le/bssmap_le_test.c:141:15: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'int' [-Wformat=]
[ 372s] printf("[%ld] %s: ERROR: failed to encode pdu\n", (pdu - bssmap_le_test_pdus),
[ 372s] ^
Closes: OS#4786
Change-Id: Ib1c16b8adc5c8c0a2b418db51d12089f9b49a844
BSSLAP: there are APDUs transferred in BSSMAP-LE Connection Oriented
Information messages on Lb between BSC and SMLC.
Add BSSLAP coding for these APDU messages:
- TA Layer3
- TA Request
- TA Response, possibly containing Location Estimate coded in GAD
- Reject
- Reset (for intra-BSS handover during TA Request)
- Abort (for inter-BSS handover)
Add encoding and decoding tests.
Change-Id: I6409c4bcac402dc7626a3afce9081c59cd715fe8
GAD, Universal Geographical Area Description:
- raw coding for all GAD elements.
- SI-units encoding and decoding for Ellipsoid point with uncertainty circle,
which I presume is the typical "at most N meters away from cell tower located
at X,Y", which corresponds to the TA positioning currently being implemented.
- other SI-units GAD element encodings are so far not implemented.
Add encoding and decoding tests.
In gsm/protocol/gsm_23_032.h are the raw coding structs as defined in 3GPP TS
23.032.
In gsm/gad.h are structs carrying consistent units based on meters and degrees,
for convenient / less error prone handling of GAD data, and for human readable
representations of the GAD data.
The separation of the two is desirable because OsmoBSC will receive GAD data
from OsmoSMLC on the Lb interface, and pass on this data to the MSC via the A
interface. It is better to pass the GAD data as-is without de/encoding.
Change-Id: I7a9dd805a91b1ebb6353bde0cd169218acbf223c
This will be useful to handle latitude and longitude numbers for GAD, which is
the location estimate representation used for LCS (Location Services).
The OsmoSMLC VTY user interface will provide floating-point strings like
"23.456" while GAD stores them as micro-degress 23456000. The osmo_gad_to_str*
will also convert latitude and longitude to floating-point string.
There was code review concerns against adding this API, upon which I tried to
use floating point string formats. But I encountered various problems with
accuracy and trailing zeros. For global positioning data (latitude and
longitude), even inaccuracy on the sixth significant decimal digit causes
noticeable positional shift. To achieve sufficient accuracy on the least
significant end, I need to use double instead of float. To remove trailing
zeros, the idea was to use '%.6g' format, but that can cause rounding. '%.6f'
on a double looks ok, but always includes trailing zeros. A test program shows:
%.6g of ((double)(int32_t)23230100)/1e6 = "23.2301" <-- good
%.6g of ((double)(int32_t)42419993)/1e6 = "42.42" <-- bad rounding
%.6g of ((double)(int32_t)23230199)/1e6 = "23.2302" <-- bad rounding
%.6f of ((double)(int32_t)23230100)/1e6 = "23.230100" <-- trailing zeros
%.6f of ((double)(int32_t)42419993)/1e6 = "42.419993" <-- good
%.6f of ((double)(int32_t)23230199)/1e6 = "23.230199" <-- good
It looks like when accepting that there will be trailing zeros, using double
with '%.6f' would work out, but in the end I am not certain enough that there
aren't more hidden rounding / precision glitches. Hence I decided to reinforce
the need to add this API: it is glitch free in sufficient precision for
latitude and longitude data, because it is based on integer arithmetic.
The need for this precision is particular to the (new) OsmoSMLC vty
configuration, where reading and writing back user config must not modify the
values the user entered. Considering to add these functions to osmo-smlc.git,
we might as well add them here to libosmocore utils, and also use them in
osmo_gad_to_str_*() functions.
Change-Id: Ib9aee749cd331712a4dcdadfb6a2dfa4c26da957
As shown in the recently added bitgen_test.c, using osmo_loadXXbe_ext() with a
smaller n produces results aligned on the most significant bytes, which is
cumbersome, since it does not return a previously stored value. This problem
exists only for the big-endian functions, the little-endian osmo_loadXXle_ext()
properly return values adjusted on the least significant octets.
Add osmo_loadXXbe_ext_2() variants that properly right-adjust the returned
value. Prominently highlight this behavior in API doc. Test the new functions
in bitgen_test.c.
For example, this eases handling of 24bit integers (e.g. loaded from buffer to
uint32_t, and stored into buffer from uint32_t). Also explicitly show this 24
bit case in bitgen_test.c
Change-Id: I2806df6f0f7bf1ad705d52fa386d4525b892b928
The autogenerated bitXXgen.h headers for osmo_load16le_ext() thru
osmo_store64_be() are not actually tested at all. Add a test.
The test output shows that the osmo_load*be_ext for a shorter len do not return
nicely matching results. A practical example showing the difficulty in storing
and loading 24bit integer values as/from big-endian:
uint8_t buf[4];
memset(buf, 0, sizeof(buf));
osmo_store32be_ext(0x00112233, buf, 3); // stores 11 22 33
printf("%s\n", osmo_hexdump(buf, 4));
uint32_t r = osmo_load32be_ext(buf, 3); // returns 0x11223300, not 0x00112233
printf("0x%x\n", r);
output is:
11 22 33 00
0x11223300
In contrast, the little-endian variant properly aligns the loaded bytes on the
least significant octet:
uint8_t buf[4];
memset(buf, 0, sizeof(buf));
osmo_store32le_ext(0x00112233, buf, 3); // stores 33 22 11
printf("%s\n", osmo_hexdump(buf, 4));
uint32_t r = osmo_load32le_ext(buf, 3); // returns 0x00112233 as expected
printf("0x%x\n", r);
output for le is:
33 22 11 00
0x112233
Change-Id: I5542ace54376a206aa8574812d4c742c86c293b4
Vadim Yanitskiy
Harald Welte
Alexander Couzens
Oliver Smith
Philipp Maier
Pau Espin