| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Only known user of API is in osmocom-bb and it compiles fine after the
change.
Related: OS#4244
Change-Id: Ia10345008b3aca50b30482ef3b852b03eca71995
|
|
Related: OS#4244
Change-Id: I32e9cc1c2397b44f0d48db2acdf782a821365b63
|
|
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
|
|
Change-Id: Iafd911dd55691b3715391e3899cd6971245c8d7f
|
|
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
|
|
The IMEI-SV is speified as a 16 digit number: 14 digits of IMEI plus
two digits of software version. Let's not try to feed 18 digit long
numbers into our functions, as the resulting behavior is unspecified.
Change-Id: I6fb85a0516dc387902ad9de4fe8c1ba82d68cae6
|
|
As part of fixing issue OS#3075, we want to migrate support
for encoding system information from osmo-bsc to libosmocore.
This change ports one of the prerequisites for doing so:
osmo-bsc code for range-encoding ARFCNs, including tests.
An osmo_gsm48_ prefix has been prepended to public symbols in
order to avoid clashes with existing symbols in osmo-bsc code.
Change-Id: Ia220764fba451be5e975ae7c5eefb1a25ac2bf2c
Related: OS#3075
|
|
We have gsm48_mi_to_string() and osmo_bcd2str(), but still lack a function that
conveniently prints both MI type and value in one function call.
Related: http://people.osmocom.org/neels/mi_mi_mi.jpg
Change-Id: I7798c3ef983c2e333b2b9cbffef6f366f370bd81
|
|
All successful cases already return from the switch(), so simply handle all
errors below it by returning an empty string (if there is enough string
buffer).
Change-Id: I709ac3b9efb7b4258d8660715b10312e11b9b571
|
|
For MI encoding, see 3GPP TS 24.008, 10.5.1.4 Mobile Identity. The 'odd' flag
indicates whether the last BCD nibble is used. Of course that flag should be
made sure to reflect the actual length.
Change-Id: Id6e695ebf9f86b295eaa7e2c6228989256f37e68
|
|
By using osmo_bcd2str(), ensure that the resulting string is always nul
terminated, and always return strlen()+1 whether truncated or not.
Still keep up the previous return value style, even if that isn't consistent at
all.
The difference between IMSI/IMEI and TMSI return values remains and is not part
of this patch.
Change-Id: I1b51b72a721e1cc9d69796b804ebda741ff0f36b
|
|
One would think by now we would solidly encode and decode Mobile Identities.
Well, guess again.
- rc is sometimes the amount of bytes written, sometimes actual strlen().
- on string truncation, rc is sometimes strlen() (assuming nul terminated), and
sometimes snprintf()-style would-be strlen().
- returned string, when truncated by not enough buffer size, is sometimes nul
terminated, sometimes not.
- gsm48_mi_to_string() happily reads a byte from zero-length input buffer.
- gsm48_mi_to_string() happily writes to zero length output buffer.
- gsm48_mi_to_string() returns nonempty string for empty input.
- encoding a MI type that still has the GSM_MI_ODD flag set results in encoding
an even-length MI as odd-length (hence appending a stray 'F').
I am going to tweak the implementation of gsm48 mobile identity encoding /
decoding, so first pinpoint the current behavior in a unit test, and show how
perforated even such a seemingly trivial API can be.
Change-Id: Iaae3af87f82f1a8f2e6273984c011b2813038cf7
|
|
Change-Id: I9b387e09293a6bbef84b9620ccf21ee2f9ec751c
|
|
Change-Id: I4c8492b8055803d2857f1ef30aede088778b085b
|
|
Note that on the input side, the 3-digits flag may be left false when the MNC
is >99 anyway. On the decoded side, the flag is set accurately.
Change-Id: I89765613d8c5bd939a6957f7443ac88475f1b93c
|
|
Change-Id: Idd6cee090464bc92b654332904a9a08edf16e5c9
|
|
(Preparation for adding 3-digit MNC)
Change-Id: Ifbc167de0cc039858112677b8d0cd14a2c8af086
|
|
(Preparation for adding 3-digit MNC)
Change-Id: I7f8ae05fa3e4a6fc004212757b05ca8a14c9ef45
|
|
For consistency in human readability, MCC simply should come first, always.
Change-Id: Idb86a7088fac4d8a8c41190ab46f9801635f4eee
|
|
(Preparation for adding 3-digit MNC)
Change-Id: Ic6c645ebf82d5f8d9d51c4c4cc804a0172008156
|
|
Change-Id: Ibe5c0831268c788ceecd10fd7b22ece6480da817
|
|
Add gsm48_encode_ra() which takes appropriate struct as [out] parameter
instead of generic buffer. Using uint8_t buffer instead of proper struct
type prooved to be error-prone - see Coverity CID57877, CID57876.
Old gsm48_construct_ra() is made into tiny wrapper around new
function. The test output is adjusted because of the change in function
return value which was constant and hence ignored anyway.
Related: OS#1640
Change-Id: I31f9605277f4945f207c2c44ff82e62399f8db74
|
|
Remove initial msgb talloc context creation: if we create a root ctx for msgb
that all msgb are allocated in, we would in a final cleanup discard all msgbs,
i.e. we would not verify that all msgb are cleaned up properly.
If we create the msgb context and *don't* clean it up in the end, the sanitizer
build fails because the context root is not cleaned up.
Easiest is to actually allocate all msgb at NULL ctx, because then any msgb
that aren't cleaned up properly would still linger, while we don't leave a root
ctx that we need to clean up either.
Helps fix sanitizer build on debian 9.
Change-Id: I1f2d1d05c75bbf4d92787f9735083f18cdc90f6f
|
|
Ensure that gsm48_parse_ra() and gsm48_construct_ra() behave properly.
Change-Id: I27117fe728407dd10886459e89ba4ff9d5e53e6b
|
|
Change-Id: Ib26214add1932e93651c248cc09fbc68339b4dce
|
|
The &buf[3] is unlikely to be aligned properly. Use memcpy instead
of an assignment. Add a small testcase that verifies that I didn't
mess up the conversion.
Alignment trap: osmo-nitb (3293) PC=0x492b7094 Instr=0xe5803003 Address=0xbeb259db FSR 0x801
|
|
Also adds a test case for both encoder and decoder of this IE
|
