A use_count struct gets properly initialized once the first use count is added.
Normally, this happens directly at object allocation. Still make sure
osmo_use_count_to_str_*() don't crash on a yet unused struct use_count.
Change-Id: I47b1acc7f13f2557c78e2cbe67d4690709ce795e
The NM_ATT_OSMO_NS_LINK_CFG is used for NSVC configuration of osmocom based BTS to support
IPv6 NSVCs.
Change-Id: I9e279bb20940c66eea5196f281184cb4f8a5cc5f
By adding this functionality, the write_cb() handler can "un-dequeue"
the msgb in case of some error. The msgb might have been modified
meanwhile, e.g. due to a partial write already pulling some data off
the head of the msgb.
Change-Id: I97bb0d64ec991adf5dd0b3708e0c7cf029e03b5f
The write_queue.c implemetation predates the msgb_*queue_count()
functions for maintaining a count alongside witha msgb queue. Let's
migrate over to those implementations.
Change-Id: I0ebd42a50f239dd7e9f663ce4c42824a5c1b3ce7
Given that commands with either/both of the following attributes:
- CMD_ATTR_DEPRECATED,
- CMD_ATTR_HIDDEN,
never end up in the XML reference, only CMD_ATTR_IMMEDIATE would
be reflected for commands taking effect immediately as follows:
<command id='foo'>
<!-- Global attributes -->
<attributes scope='global'>
<attribute doc='This command applies immediately' />
</attributes>
<!-- Application specific attributes -->
<attributes scope='application'>
<!-- ... -->
</attributes>
<params>
<!-- ... -->
</params>
</command>
Change-Id: I8476c1163c23a9a52641987acf3df0b8c49d8f7b
Related: SYS#4937
gprs_ns2_nsvc_by_sockaddr_nsei is doing the lookup within a NSE.
gprs_ns2_nsvc_by_sockaddr_bind is doing the lookup within a bind.
Make both function look similiar and take similiar arguments.
Change-Id: Ia499fc279013668abe7348e578a0768f7d16faf9
There shouldn't be any knowledge of the upper layer in the NS layer.
The PCU / SGSN / gbproxy have to add the pointer when parsing the primitives.
Change-Id: Id7edb8feb96436ba170383fc62d43ceb16955d53
utils.h is needed for struct value_string
This probably never caused a problem because every file including
gsm_08_16.h also included utils.h, but we should still include the file
here.
Change-Id: Iae09b4e8e42be6c371fb34279b7981db2af8cf4c
So far there is only osmo_use_count_name_buf(). Also provide a use count to
string using a talloc context, allowing to use OTC_SELECT.
- instead of foo_name(), rather use foo_to_str().
- osmo_use_count_name_buf() returns the buf and not the chars_needed. So add
osmo_use_count_to_str_buf() with a signature that is usable by
OSMO_NAME_C_IMPL().
- provide osmo_use_count_to_str_c() using OSMO_NAME_C_IMPL().
Change-Id: I1d2e7ee979f8c316ef99f7c65675b36d092ddfca
I was reading through the code and noticed many functions not
documented yet, or with incomplete documentation. Change that.
Change-Id: I85a2419604a9fd9ff3c4828a7463e222652f77bf
Originally we only learned about the protocol from looking at hexdumps
without any specification or the like.
Due to a GPL request to ip.acecss, we actually do have an 'official'
resource: The packet-ipa.c from their wireshark-1.0.6ipa27.tar.gz
Let's use its contents to complete our definitions here.
Change-Id: Ic1f2b32c72d162f31b422293d2a361d528443f01
According to 3GPP TS 48.008, section 3.2.2.44, the Chosen Encryption
Algorithm IE, which may be included in the following messages:
- 3.2.1.2 ASSIGNMENT COMPLETE
- 3.2.1.8 HANDOVER REQUEST
- 3.2.1.10 HANDOVER REQUEST ACKNOWLEDGE
- 3.2.1.12 HANDOVER COMPLETE
- 3.2.1.25 HANDOVER PERFORMED
- 3.2.1.31 CIPHER MODE COMPLETE
is coded as follows:
0000 0001 No encryption used
0000 0010 GSM A5/1
0000 0011 GSM A5/2
0000 0100 GSM A5/3
0000 0101 GSM A5/4
0000 0110 GSM A5/5
0000 0111 GSM A5/6
0000 1000 GSM A5/7
basically A5/X => X + 1. All other values are Reserved for future
international use. As can be seen, value 0x00 is RFU. Passing
this value to some encoding functions would result in a PDU with
this IE omitted. Although, some functions would still encode
Chosen Encryption Algorithm IE with this RFU value.
Let's ensure that all functions behave consistently.
Change-Id: If10e433a8174eabe6aa6d2c2937bf9cf5d14d7c9
[ 198s] for (unsigned i = 0; i < gss->num_ip6_remote; i++) {
[ 198s] ^
[ 198s] gprs_ns2_sns.c: In function 'ns2_sns_st_configured_change':
[ 198s] gprs_ns2_sns.c:1053:3: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
[ 198s] for (int i = 0; i < num_v4; i++) {
[ 198s] ^
[ 198s] gprs_ns2_sns.c:1067:3: error: 'for' loop initial declarations are only allowed in C99 or C11 mode
[ 198s] for (int i = 0; i < num_v6; i++) {
[ 198s] ^
[ 198s] Makefile:535: recipe for target 'gprs_ns2_sns.lo' failed
Change-Id: I4b7c576fcdf9d35f85e00ad076af7c48d5eb34a5
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
Add OSMO_ASSERT()s to ensure bounds checking.
For example, for osmo_store32le_ext(), passing n > 5 would read past the end of
the uint32_t. Similarly, osmo_load32le_ext() for n > 4 would write past the
uint32_t's end.
Change-Id: I2dc21582cd8a679b6624cefbc0c1678b093a3d08
There's no point in printing that code if no color was used in first
place, and looks strange when using logging with color enabled but no
color assigned to the category printing lines.
Only affected unit test output by this fix is osmo-bts'x
tx_power_test.c, which has been fixed in osmo-bts.git Change-Id
I5aa95997c8df4ce5ba8271acae99c45f68b96e11.
Change-Id: Ie38cc639d7f4acd908f357e5bfb3ced07147583e
As long the filter doesn't look into the nsvc/bvc structs
there is no need to use the type.
Further it allows to use the same code for NS1 and NS2.
Change-Id: I9b9a70f382a94f1d41142060d5db569f9df865ac
Alexander Couzens
Harald Welte
Vadim Yanitskiy
Pau Espin
Daniel Willmann