aboutsummaryrefslogtreecommitdiffstats
path: root/tests
AgeCommit message (Collapse)AuthorFilesLines
2020-10-06vty: check for reserved flags in application specific attributesVadim Yanitskiy2-0/+4
We agreed to reserve uppercase flag letters for libraries. Change-Id: If0c332f7c86ff26a4060a14b947445d194a6702e Related: SYS#4937
2020-10-04vty: check for duplicate flags in application specific attributesVadim Yanitskiy2-0/+20
This would facilitate detecting duplicates on early development stages. Change-Id: I4e27d6e89d3f851b5ea4f00da01e7093afa537b2 Related: SYS#4937
2020-10-04tests: do not ignore stderr of vty_test, also match itVadim Yanitskiy3-2/+64
This change is needed for I4e27d6e89d3f851b5ea4f00da01e7093afa537b2. Change-Id: Ia601ecd2e69aeb6669e0e2e5dd60135a751611e7
2020-09-15Gb: add a second NS implementationAlexander Couzens1-2/+3
Reimplement NS with FSM. Change-Id: I3525beef205588dfab9d3880a34115f1a2676e48
2020-09-14bitXXgen: add osmo_loadXXbe_ext_2() to get right-adjusted valuesNeels Hofmeyr2-2/+79
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
2020-09-14bitXXgen: add bitgen_test.cNeels Hofmeyr4-0/+279
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
2020-09-02socket: introduce osmo_sock_init_osa & osmo_sock_init_osa_ofdAlexander Couzens3-0/+141
osmo_sock_init_osa() takes osmo_sockaddr* as local and remote endpoints to setup a socket. Change-Id: I1eece543e3241ef0e095eb63bb831f7c15a16794
2020-09-02tests/socket: add testcase test_get_ip_and_portAlexander Couzens2-0/+35
Check if osmo_sock_get_ip_and_port() works correct. Change-Id: I4e69d814367168c05f0da161ec9b705db36ad096
2020-08-31socket: Fix bug in osmo_sock_init2(AF_UNSPEC) matching IP versionsPau Espin Pedrol2-2/+1
See previous commit for a bug description. Fixes: 2c962f5de1eeea119cfac7d9d92db31c570353b9 Change-Id: I59bf4b4b3ed14766a5a5285923d1ffa9fc8b2294
2020-08-31tests: Add test to showcase osmo_sock_init2 bug with AF_UNSPECPau Espin Pedrol3-0/+8
The function is checking for IP version matching between local and remote addresses even if only one is needed based on flags. For example, if user only desired to bind, the remote address should not be used nor checked. Bug was introduced here: 2c962f5de1eeea119cfac7d9d92db31c570353b9 Change-Id: I87afd1db9bd017426abcc959fa515d15784cdf1c
2020-08-31socket: Add support for AF_INET6 in osmo_sockaddr_to_str_and_uint()Pau Espin Pedrol2-16/+110
Related: SYS#4915 Change-Id: I439c7fa52a3a30eebc3d35e78be7f1724fb69294
2020-08-27lapdm: fix SAPI-0/SAPI-3 frame prioritization on DCCHVadim Yanitskiy1-5/+5
According to 3GPP TS 44.005, section 4.2.2 "Priority": a) on DCCH, a SAPI=0 frame always has higher priority than SAPI=3; b) on ACCH, the priority arrangement is more complex: b1) if a SAPI = 3 frame is awaiting transmission, two SAPI=0 frames shall not be sent in consecutive SACCH frames; b2) on the network side (LAPDM_MODE_BTS), it must also be ensured that any SAPI=3 frame is followed by at least one SAPI=0 frame; b3) a SAPI = 0 frame may be repeated in the next SACCH period if the Repeated SACCH is supported (see 3GPP TS 44.006, section 11). We definitely need to extend our testing coverage to ensure that we implement b) correctly, but for now let's focus on DCCH: a) for DCCH, ensure that SAPI=0 frames preceed SAPI=3 ones; b) for ACCH, re-use the existing round-robin implementation. Change-Id: Ia3780bce1222b312ae2fd2d21496a4d6c5ccb6e0 Related: SYS#5047, OS#4731
2020-08-27lapd_test: add a test checking SAPI0/SAPI3 prioritizationVadim Yanitskiy2-0/+87
Recently we've encountered a situation where during MT SMS delivery, the func=SABM for SAPI=3 was sent on Downlink *before* the BTS replied with the func=UA for SAPI=0 (contetion resolution procedure, where we echo the (RR) Paging Response back to the MS). This change adds a unit test reprodicing the problem. Change-Id: Ied0f8bb683de8e37bcfa984c2877aa1cec1c0b4b Related: SYS#5047, OS#4731
2020-08-27lapd_test: fix: print all messages to stdout, not stderrVadim Yanitskiy2-10/+38
We intentionally do not match stderr output because it contains non-deterministic messages (e.g. pointer addresses), so let's make sure that all test specific messages go to stdout. Change-Id: Ia52f8e811cee9d3e1cd5fcda49a9134ccaa31f7f
2020-08-27lapd_test: rename func=UA (RR) CM Service Request: s/ua/ua_cm/Vadim Yanitskiy1-4/+4
This is basically an ACKnowledgement for (RR) CM Service Request, thus it contains a copy of the original Uplink message (cm). Let's rename it to reflect this explicitly. Change-Id: Id497ff4b688528916495387d64915b14396a68f1
2020-08-27lapd_test: fix wrong comment in lapdm_establish()Vadim Yanitskiy1-1/+1
Change-Id: I2d8f191147249d5ec34a2d1aba3f4dbc26a7824f
2020-08-26gsm0808: add gsm0808_create_sapi_reject_cause()Vadim Yanitskiy1-1/+1
This is basically a successor of gsm0808_create_sapi_reject(), but instead of hard-coding GSM0808_CAUSE_BSS_NOT_EQUIPPED, it allows the caller to specify a cause value to be used. The old function is now deprecated and should not be used. Change-Id: Iefe5484d0fa02d5722b628b1dc237d51d3fb1a9b Related: OS#4728
2020-08-25tests: Split SCTP tests to its own file and run them conditionallyPau Espin Pedrol8-207/+282
Some systmes (like the ones available in OBS) don't support creating SCTP sockets, so we need to skip those tests there. Change-Id: I1d16280674625877ec22cc60cbc5deb67868a656
2020-08-24socket: Log proper getaddrinfo() errorPau Espin Pedrol1-2/+2
Drop one of the two log lines since it would be a duplicated and anyway it misses context (return code). Change-Id: I4620bf86f4bcda58ae85209278ac9ae9a0f3012a
2020-08-24socket: multiaddr: Support IPv4 + IPv6 addresses in SCTP associationsPau Espin Pedrol3-0/+208
The function is improved to support AF_INET:v4->v4, AF_INET6:v6->v6 and AF_UNSPEC:v4+v6->v4+v6. Unit tests for the function are added to make sure function behaves correctly in several scenarios. Change-Id: I36d8ab85d92bba4d6adb83bc1875eb61094ed2ef
2020-08-06osmo_sock_init2: improve support for AF_UNSPECAlexander Couzens3-0/+27
osmo_sock_init2 abstract two calls of getaddrinfo into one. While there aren't problems with AF_INET or AF_INET6. When using AF_UNSPEC there are corner cases when this fails. E.g. calling local_host with "" and remote_host with an IPv6 only address results in setting up a local socket with AF_INET while trying to connect from there towards AF_INET6 will most likely fail. To prevent such cases with AF_UNSPEC, search prio calling any syscalls if local and remote site supports AF_INET or AF_INET6. In case both supported, prefer AF_INET6 Change-Id: I397c633931fd00d4f083955a3c49a40fb002d766
2020-08-02i460: Fix bit- and subslots ordering of I.460 mux + demuxHarald Welte2-67/+67
When I wrote the new I.460 mux + demux code, I failed to realize that * bit numbers in relevant ITU specs start with 1 as MSB ... 8 as LSB * sub-slot 0 is bits 1+2, i.e. the two MSBs of a byte * bit-ordering within each sub-slot is also MSB first As a result, the code and test data was broken. Change-Id: I6df7dbf411efbdeaf516e72ac552432bf5a569d0
2020-08-02i460: pass more context to call-back functionsHarald Welte1-1/+2
When calling a user-provided call-back function for the i460 mux or demux, always pass a pointer to the osmo_i460_subchan the callback relates to. This way, the user can walk the i460 data structures to obtain information about which mux/demux instances is calling. Change-Id: Id842c72ce371a67fe5df6694e195c281aaf607ab
2020-07-30vty: Don't match negative values on purely positive rangesPau Espin Pedrol2-3/+2
Without this patch, for instance having a range 0-ULONG_MAX would match if someones types value -3, which would be converted to unsigned but that's clearly what is expected here from user point of view. Change-Id: Ia95f6314a2dd3f94d21fc219cf69bb8d39b8e7f0
2020-07-30vty: Allow 64 bit values in numeric ranges if system supports itPau Espin Pedrol2-6/+9
This fixes commands not being matched due to providing a range with more than 10 digits. The last case (passing -4000 matching 0-ULONG_MAX) shows a different bug which will be fixed in next commit. Change-Id: I0afa0caabffe36083c36b92ba90696ded00bb7be
2020-07-30tests: vty: Extend test to do some numeric range validationsPau Espin Pedrol2-0/+40
As per current status, the numeric tests are expected to fail due to a couple bugs which will be fixed in next commits. Change-Id: Id5b17bd96d7af4ed9a77ebbea0e6be4b0fcbde6c
2020-07-30tests/fsm_test.c: Disable use color in logging outputPau Espin Pedrol2-44/+45
This should avoid other problems in the future. Change-Id: I81368578c0830477d381566a54671fdde6067b23
2020-06-16gsm0408_test: allow deprecated APINeels Hofmeyr1-0/+2
This test knowingly calls deprecated functions -- allow that to squelch these warnings: warning: ‘gsm48_generate_lai’ is deprecated: Use gsm48_generate_lai2() instead, to not lose leading zeros in the MNC [-Wdeprecated-declarations] warning: ‘gsm48_decode_lai’ is deprecated: Use gsm48_decode_lai2() instead, to not lose leading zeros in the MNC [-Wdeprecated-declarations] Change-Id: Ifd618c1b9befa9c9ef0a338ab4aae2b0f796f4c2
2020-06-16add osmo_mobile_identity APINeels Hofmeyr4-0/+435
Implement better API around 3GPP TS 24.008 Mobile Identity coding. struct osmo_mobile_identity is a decoded representation of the raw Mobile Identity, with a string representation as well as dedicated raw uint32_t TMSI. The aim is to remove all uncertainty about decoded buffer sizes / data types. I have patches ready for current osmo CNI programs, replacing the Mobile Identity coding with this new API. Deprecate the old MI API. osmo-bsc: I71c3b4c65dbfdfa51409e09d4868aea83225338a osmo-msc: Ic3f969e739654c1e8c387aedeeba5cce07fe2307 osmo-sgsn: I4cacb10bac419633ca0c14f244f9903f7f517b49 Note that some GPRS and SGs related coding is done here in libosmocore and hence currently remains using the old implementation (see previous version of this patch: Ic3f969e739654c1e8c387aedeeba5cce07fe2307). New API functions provide properly size-checking implementations of: - decoding a raw MI from a bunch of MI octets; - locating and decoding MI from a full 3GPP TS 24.008 Complete Layer 3 msgb; - encoding to a buffer; - encoding to the end of a msgb. Other than the old gsm48_generate_mid(), omit a TLV tag and length from encoding. Many callers manually stripped the tag and value after calling gsm48_generate_mid(). The aim is to leave writing a TL to the caller entirely, especially since some callers need to use a TvL, i.e. support a variable-size length of 8 or 16 bit. New validity checks so far not implemented anywhere else: - stricter validation of number of digits of IMSI, IMEI, IMEI-SV MI. - stricter on filler nibbles to be 0xf. As a result, applications using osmo_mobile_identity will be stricter in rejecting coding mistakes (some of which we currently have in our test suites, and which we'll need to fix). Rationale: While implementing osmo-bsc's MSC pooling feature in osmo-bsc, this API will be used to reduce the number of times a Mobile Identity is extracted from a raw RSL message. Extracting the Mobile Identity from messages has numerous duplicate implementations across our code with various levels of specialization. https://xkcd.com/927/ To name a few: - libosmocore: gsm48_mi_to_string(), osmo_mi_name_buf() - osmo-bsc: extract_sub() - osmo-msc: mm_rx_loc_upd_req(), cm_serv_reuse_conn(), gsm48_rx_mm_serv_req(), vlr_proc_acc_req() We have existing functions to produce a human readable string from a Mobile Identity, more or less awkward: - gsm48_mi_to_string() decodes a TMSI as a decimal number. These days we use hexadecimal TMSI everywhere. - osmo_mi_name_buf() decodes the BCD digits from a raw MI every time, so we'd need to pass around the raw message bytes. Also, osmo_mi_name_buf() has the wrong signature, it should return a length like snprintf(). - osmo-bsc's extract_sub() first uses gsm48_mi_to_string() which encodes the raw uint32_t TMSI to a string, and then calls strtoul() via tmsi_from_string() to code those back to a raw uint32_t. Each of the above implementations employ their own size overflow checks, each invoke osmo_bcd2str() and implement their own TMSI osmo_load32be() handling. Too much code dup, let's hope that each and every one is correct. In osmo-bsc, I am now implementing MSC pooling, and need to extract NRI bits from a TMSI Mobile Identity. Since none of the above functions are general enough to be re-used, I found myself again copy-pasting Mobile Identity code: locating the MI in a 24.008 message with proper size checks, decoding MI octets. This time I would like it to become a generally re-usable API. This patch was first merged as Ic3f969e739654c1e8c387aedeeba5cce07fe2307 and caused test fallout, because it re-implemented old API with the new stricter decoding. In this patch version, old API remains 1:1 unchanged to avoid such fallout. Applications will soon switch to the new osmo_mobile_identity API and become stricter on MI coding when that happens, not implicitly by a new libosmocore version. Change-Id: If4f7be606e54cfa1c59084cf169785b1cbda5cf5
2020-06-16Revert "add osmo_mobile_identity API"Harald Welte4-457/+14
This reverts commit d1ceca9d48eb3d8b212f386a1ebb35d8fc612297, as it introduces regressions in both osmo-msc and osmo-nitb which have been causing failing builds for several days now. Change-Id: I4bd958d0cd2ab4b0c4725e6d114f4404d725fcf7
2020-06-12add osmo_mobile_identity APINeels Hofmeyr4-14/+457
Implement better API around 3GPP TS 24.008 Mobile Identity coding. struct osmo_mobile_identity is a decoded representation of the raw Mobile Identity, with a string representation as well as dedicated raw uint32_t TMSI. The aim is to remove all uncertainty about decoded buffer sizes / data types. I have patches ready for all osmo programs, completely replacing the Mobile Identity coding with this new API. Hence deprecate the old MI API. New API functions provide properly size-checking implementations of: - decoding a raw MI from a bunch of MI octets; - locating and decoding MI from a full 3GPP TS 24.008 Complete Layer 3 msgb; - encoding to a buffer; - encoding to the end of a msgb. Other than the old gsm48_generate_mid(), omit a TLV tag and length from encoding. Many callers manually stripped the tag and value after calling gsm48_generate_mid(). The aim is to leave writing a TL to the caller entirely, especially since some callers need to use a TvL, i.e. support a variable-size length of 8 or 16 bit. New validity checks so far not implemented anywhere else: - stricter validation of number of digits of IMSI, IMEI, IMEI-SV MI. - stricter on filler nibbles to be 0xf. Rationale: While implementing osmo-bsc's MSC pooling feature in osmo-bsc, this API will be used to reduce the number of times a Mobile Identity is extracted from a raw RSL message. Extracting the Mobile Identity from messages has numerous duplicate implementations across our code with various levels of specialization. https://xkcd.com/927/ To name a few: - libosmocore: gsm48_mi_to_string(), osmo_mi_name_buf() - osmo-bsc: extract_sub() - osmo-msc: mm_rx_loc_upd_req(), cm_serv_reuse_conn(), gsm48_rx_mm_serv_req(), vlr_proc_acc_req() We have existing functions to produce a human readable string from a Mobile Identity, more or less awkward: - gsm48_mi_to_string() decodes a TMSI as a decimal number. These days we use hexadecimal TMSI everywhere. - osmo_mi_name_buf() decodes the BCD digits from a raw MI every time, so we'd need to pass around the raw message bytes. Also, osmo_mi_name_buf() has the wrong signature, it should return a length like snprintf(). - osmo-bsc's extract_sub() first uses gsm48_mi_to_string() which encodes the raw uint32_t TMSI to a string, and then calls strtoul() via tmsi_from_string() to code those back to a raw uint32_t. Each of the above implementations employ their own size overflow checks, each invoke osmo_bcd2str() and implement their own TMSI osmo_load32be() handling. Too much code dup, let's hope that each and every one is correct. In osmo-bsc, I am now implementing MSC pooling, and need to extract NRI bits from a TMSI Mobile Identity. Since none of the above functions are general enough to be re-used, I found myself again copy-pasting Mobile Identity code: locating the MI in a 24.008 message with proper size checks, decoding MI octets. This time I would like it to become a generally re-usable API. Change-Id: Ic3f969e739654c1e8c387aedeeba5cce07fe2307
2020-06-10add gsm23236: MSC pooling: TMSI and NRI utility functionsNeels Hofmeyr4-0/+1145
These utilities will be used by osmo-bsc to determine the Network Resource Indicator seen in the TMSI, and (potentially) by osmo-msc to compose a TMSI with a specific NRI, for osmo-bsc's load balancing between several MSCs. Add utility functions to: - extract an NRI value from a TMSI. - overwrite the NRI value in a TMSI. - limit an NRI in a (random) TMSI to a given list of ranges. - add NRI value ranges to a list. - remove them from a list. - match NRI value (range) to a list. - parse NRI values from string, for VTY. - common VTY functionality of adding/removing NRI values from argv. Add C tests for the above. Why we need public API for NRI ranges: In osmo-bsc alone, we need the same NRI API twice, 1: to manage/list NRI value ranges per-MSC, and 2: to manage/list NULL-NRI values. If we also consider (potentially) adding NRI support to osmo-msc, we need the same API twice again there. Hence it is useful to define re-used API up here in libosmocore. Related: OS#3682 Change-Id: Icb57a2dd9323c7ea11b34003eccc7e68a0247bf5
2020-06-09gsm0808: fix endieness of call identifierPhilipp Maier1-3/+3
The call identifier in the ASSIGNMENT COMMAND is encoded in the wrong endieness. 3GPP TS 48.008, section 3.2.2.105 specifies that the least significant byte should be transmitted first, which means that the endieness here is little endian. Lets make sure that the endieness is correctly transmitted, regardless of the host byte order. Change-Id: I6468e502f552f99ab54aec9d4b1c169fdc0adfb8 Related: OS#4582
2020-05-28Implement ITU-T I.460 multiplex / demultiplexHarald Welte4-0/+523
This implements a multiplexer and de-multiplexer for the ITU-T I.460 standard. The latter covers the transmission of sub-slots of 32/16/8k inside 64k timeslots. Change-Id: Id522f06e73b77332b437b7a27e4966872da70eda
2020-05-17gsm0808: Implement helper functions for CONFUSION BSSMAP message decoding.Alexander Chemeris2-0/+57
Also add a test for an actual CONFUSION message parsing. Change-Id: If8afd2d096fb66c6c2f255a08fc1129de3d09cec
2020-05-14codec: Add functions for AMR s->d bits and d->s bitsHarald Welte2-0/+48
These functions implement re-ordering of bits as per TS 06.90 / 26.101 based on the already existing tables we've had in libosmocoding. Change-Id: Ia4ac2aea2e96f9185f082a07ca64dfc5276efb46
2020-05-13gsm0808: Make a function to extract Cause IE publicly available.Alexander Chemeris1-1/+1
Function gsm0808_get_cipher_reject_cause() was previously available in private gsm0808_utils.h. In practice, the exact same code is useful to extract Cause IE value from any of the many other BSSMAP messages which use it. So let's rename it to gsm0808_get_cause() and make it avilable to everyone to use. Change-Id: Idf2b99e9ef014eba26e3d4f0f38c2714d3a0520a
2020-05-12gsm0505_amr_dtx: add missing value stringsPhilipp Maier1-2/+2
The value string array that explain the type of the AMR DTX / SID frames is incomplete, lets add the missing strings. Change-Id: If9e80b4bd8bdc31323c7c276155b2538e20a99be Related: OS#2978
2020-05-12gsm0808: Fix encoding of the SAPI_N_REJECT BSSMAP message.Alexander Chemeris1-1/+1
See TS 08.08 section 3.2.1.34 SAPI "n" REJECT: 1) DLCI is a TV element, not V. 2) Cause is a TLV element and we have a special function to encode it. Change-Id: I033afe556c06427d06ac55c4f78854a45e41aae6
2020-04-17tests/coding_test: Fix test_pdtch() resultsPau Espin Pedrol2-29/+30
When switching the l2 structures passes to test_pdtch() to be constant, it was noted that output of the test changes. This happens because same array is tested several times with different length, incrementing each time. Since the test was modifying the input array directly, it means each new run of test_pdtch() the array was further modified. Upon constifying the structures, we copy the array and hence only modify the required bits each time. Change-Id: Iffd0ca3669eb8d0d2e80d754fc8acbf72f1bebe8
2020-04-17tests/coding: Test decoding of DL EGPRS data packetPau Espin Pedrol2-28/+106
Change-Id: Ide23a484b980995f24092d1cfbf062aed58fdf61
2020-04-14dtx: add decoding for AMR-DTX framesPhilipp Maier4-0/+153
gsm0503_coding contains AMR decoder functions for HR and FR. Those can only decode AMR payload frames but not amr DTX frames. Lets add functionality to detect DTX frames. Also lets add decoding for SID_UPDATE frames as well as error checking for the SID frame recognition patterns. Related: OS#2978 Change-Id: I2bbdb39ea20461ca08b2e6f1a33532cb55cd5195
2020-04-01coding: fix bit ordering in 11-bit RACH coding functionsVadim Yanitskiy1-6/+6
According to 3GPP TS 44.004, figure 7.4a.b, the format of 11-bit RACH uplink / Uplink access burst block is as defined follows: <--------------------------------------------------- 8 7 6 5 4 3 2 1 +--------------------------------------------------+ | 11 bit RACH uplink / Uplink access burst block | OCT1 +--------------------------------------------------+ | | OCT2 +-------------------+ As was (correctly) assumed in [1], the bit ordering in 11-bit RACH coding functions is wrong. The problem is that neither of generic functions from bit16gen.h can be used to load / store the RA11 value (regardless of the endianness), because they assume that the payload is 16 bit long. With this patch applied, RA11 values from [1] look correct: < EGPRS Packet channel request message content > ::= < Signalling : 110011 < RandomBits : 00111 > > | < Signalling : 110011 < RandomBits : 00110 > > | < Signalling : 110011 < RandomBits : 01111 > > | < Signalling : 110011 < RandomBits : 01100 > > | < Signalling : 110011 < RandomBits : 00111 > > | < Signalling : 110011 < RandomBits : 10110 > > ; [1] Id80e471d252b9416217b56f4c8c0a8f5f1289fee Change-Id: I43d30611dd69f77f2b3b46f4b56056a8891d3c24 Related: OS#1548
2020-03-31tests/coding: add 11-bit Access Burst samples from a real phoneVadim Yanitskiy2-0/+60
This change adds several soft-bit (-127 .. 127) sequences containing EGPRS Packet Channel Request message (11-bit, payload only) sent by an EGPRS capable phone, and captured on the BTS/PCU side using a tool from the TRX Toolkit - trx_sniff.py. As can be seen from the test output, none of decoded RA11 values looks like a valid EGPRS Packet Channel Request message (see table 11.2.5a.2 of 3GPP TS 44.060). All test sequences contain the same message with several random bits: < EGPRS Packet channel request message content > ::= < Signalling : 110011 < RandomBits : bit (5) > >; since the phone was trying to perform Attach Request. It seems the bit order of decoded messages is somehow wrong. Change-Id: Id80e471d252b9416217b56f4c8c0a8f5f1289fee Related: OS#1548
2020-03-31tests/coding: cosmetic: use ARRAY_SIZE() macro from utils.hVadim Yanitskiy1-2/+2
Change-Id: Ie6278d84d405f073669e607f978ca5b187bcf78e
2020-03-31tests/coding: reduce verbosity of 8-bit / 11-bit RACH coding testsVadim Yanitskiy2-34570/+16
We don't really need additional 1.4M of debug output, given that we test every possible 8-bit and 11-bit RA value. It's enough to print error message if the resulting value does not match. Otherwise it's hard to read the expected output without commenting the related log statements out. Note that it's still possible to re-enable verbose debug output by defining DEBUG. Change-Id: I0d5ed90cb0a2b3007d665520a73b0fa0b86a4099
2020-03-31tests/coding: check return value of encoding / decoding functionsVadim Yanitskiy1-14/+39
Change-Id: I78850a4ab2fb7cd63bb4a3789f934634b6fb2cb7
2020-03-13gsm690: Fix amr speech bit length tablePhilipp Maier1-2/+2
The table amr_len_by_ft represents the length of the raw AMR speech bits in bytes. The table is based on the Table found in RFC 4867 §3.6, Table 1, Column "Total speech bits". The number of bits is divided by 8 and then rounded up to get the number of consumed octets. An AMR SID frame (including STI and MI) takes up 39 bits, this will result in 5 octets, not in 7. Lets correct this. Related: OS#2978 Change-Id: Icf330450981b32be5d1cee5b10aa92bac4cb72f5
2020-03-09conv: add convolutional coder for AMR SID UPDATE framesPhilipp Maier1-0/+8
AMR SID update frames are protected using an 1/4 convolutional coder, wich is similar to the one used with 6,7 kbit voice frames. Except that there is no puncturing and the length is different. Change-Id: Ia35ed4178a7f0d816052b7e5d6478b93a1d9744f Related: OS#2978
2020-02-19bitvec: fix bitvec_unhex(): do not return 1 on successVadim Yanitskiy1-5/+5
This function is supposed to return 0 on success or 1 in case of error. However, it used to return 1 even in case of success. The reason is that length of the input string was not taken into account and sscanf() was failing on '\0'. Let's use osmo_hexparse() and rely on its return value. P.S. Funny that the unit test expectations were wrong too. Change-Id: I441a22c7964bb31688071d8bcf6a282d8c0187ff
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-20 01:38:01 +0000