aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2020-04-07gsm0503_tables: Document USF encoding tablespespin/egprsPau Espin Pedrol1-0/+6
Change-Id: I596c10960bd1ff1b1ec14ad953ce5e1ed040d35a
2020-04-07gsm0503_coding: Fix USF encoding in MCS1-4Pau Espin Pedrol1-1/+1
osmo-gsm-tester raised an ASan warning in osmo-bts-trx during execution of a test with EGPRS enabled and a modem connecting to it (see OS#4483 for full trace): ==12388==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7fa20b9ab8d0 at pc 0x7fa20b982894 bp 0x7ffdfea8b9c0 sp 0x7ffdfea8b9b8 READ of size 1 at 0x7fa20b9ab8d0 thread T0 #0 0x7fa20b982893 in gsm0503_mcs1_dl_interleave /home/osmocom-build/jenkins/workspace/osmo-gsm-tester_build-osmo-bts/libosmocore/src/coding/gsm0503_interleaving.c:165 Function gsm0503_mcs1_dl_interleave() was being passed the 6-bit USF encoding while clrearly expecting a 12 element array. TS 05.03 5.1.5.1.2 "USF precoding" also clearly states that 12bit encoding is to be used for MCS1-4. Fixes: OS#4483 Change-Id: I94db14de770070b17894a9071aa14391d26e776c
2020-04-07gsm0503_coding: Fix misleading comment UL vs DLPau Espin Pedrol1-1/+1
Change-Id: I563c60271e218f9953e26f9bf0304d442c6acd43
2020-04-01coding: fix bit ordering in 11-bit RACH coding functionsVadim Yanitskiy2-8/+9
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-31coding: fix documentation of PDTCH encoding functionsVadim Yanitskiy1-2/+2
Change-Id: Ia38723fb9424551eaf5747d736ae73ab20873def
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-22osmo-sim-test: Avoid double-closeHarald Welte1-4/+1
Change-Id: Ibd67a5461085a77dd9e804a4f1266d67ee91a04a Closes: CID#208960
2020-03-21sim: Add HPSIM application supportHarald Welte4-1/+79
Change-Id: I883faae5e170803b8301d10c8b9fad7892da009c
2020-03-21card_fs_{usim,isim}: Update to 15.7.0 / Release 15Harald Welte2-6/+56
Various new files and some new status words have been defined by now. Let's add them. Change-Id: Ia007281bcb61dcd8260d0a77203abeff21d5255f
2020-03-21osmo-sim-test: Also [attempt to] dump DF.GSM on USIM cardsHarald Welte3-12/+12
an USIM application can very well exist on a UICC without supporting classic DF.GSM access. However, most commonly, both are found on cards. Change-Id: I6180a3f81a7d3006e8ece4302c2433db2588bfaa
2020-03-21sim: re-structure how we support cards + applicationsHarald Welte8-122/+326
Before this change, a card application (USIM, ISIM, ...) didn't exist as a separate concept from a card profile. This meant, we had a manual combination of UICC card profile with USIM application, and another one of UICC card profile and ISIM application. But what if there's a combined USIM+ISIM? In reality, applications exist as separate objects, on top of an ETSI UICC. Lets therefore register all known applications to the osim library core, and add code to osmo-sim-test which dynamically detects all applications present on a given card (by reading EF.DIR). Change-Id: Ic4b4ac433a9976842b30a017fb0fc347d87201cd
2020-03-21sim: add osim_file_desc_find_aid()Harald Welte3-1/+21
Change-Id: I80468c8c4f4590c262019f42285e8d8fd3444f7f
2020-03-21osmo-sim-test: Optionally dump card files to host filesystemHarald Welte1-11/+97
Using the new '--output-dir' command line argument, the user can instruct osmo-sim-test to dump the file content to a local directory. osmo-sim-test will create one sub-directory per DF, and create a text file for each EF. The contents of the text files are a hexdump of the contents. Transparent EF are dumped as one line of hex, while linear fixed EF are dumped as one record per line, i.e. the number of lines corresponds to the number of records. Change-Id: I35176f4a13c3537eaa8de550e231818a22b4c07c
2020-03-21osmo-sim-test: don't print SW in successful case of dump_file()Harald Welte1-1/+0
Change-Id: Ie5a58a89052400d76a8607a2e0063917385beb25
2020-03-21osmo-sim-test: Use stderr for error messagesHarald Welte1-7/+7
Change-Id: I8f36b07b8601af2b0d54d95c3c6374d6c54bafd1
2020-03-21card_fs_sim: Avoid '/' in file namesHarald Welte1-1/+1
... as that doesn't work if we want to create a similarly-named file in the local file system. Change-Id: Ib8734e2e4b81c915ab0fbd0d9b6662275b1d33d1
2020-03-21sim: card_fs_usim.c: Fix FID of EF.EXT4Harald Welte1-1/+1
The 3GPP spec document also contains this error at one point, and it seems I copied it from there :/ Change-Id: I7ad9f491c06f6540747b77017678ee37e6a1550d
2020-03-17debian: Change python3 dependency to native archMaksim Aristov1-1/+1
This small fix enables cross compilation using dpkg-buildpackage on multiarch: https://wiki.debian.org/CrossCompiling#Building_with_dpkg-buildpackage `apt build-dep -a<arch>` incorrectly installed non-native python for building Change-Id: I85994447657cda757348855c3ee9978e8c7c2377
2020-03-16libosmosim: Build irrespective of PC/SC supportHarald Welte3-8/+14
libosmosim contains a variety of definitions and utility fuinctions useful when working with SIM card [protocol]. They can not only be used with PC/SC readers but also in other contexts. Change-Id: I741940d3dc2a5653c760e9d1597d7f08afb3b631
2020-03-13gsm690: Fix amr speech bit length tablePhilipp Maier2-3/+4
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-10socket: Add osmo_sock_mcast_iface_set() to bind multicast to deviceHarald Welte2-0/+23
Change-Id: Ib52d22710020b56965aefcef09bde8247ace4a9c Related: OS#2966
2020-03-09conv: add convolutional coder for AMR SID UPDATE framesPhilipp Maier3-0/+28
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-03-09parity: add amr crc14 definitionPhilipp Maier3-0/+13
AMR not only specifies a 6 bit CRC for regular voice information. It also specifies a 14 bit CRC to protect the comfort noise updates contained in the SID_UPDATE frames. Change-Id: I5cfd8ca806aba8d42cb9787f69605cea7de6e900 Related: OS#2978
2020-03-08fixup depreciation warningHarald Welte1-2/+2
Change-Id: Id2d016939c3a6185cc3cfa8631da0c8d187a8c5a
2020-03-08gsmtap: Solve TCH / FACCH confusion once and for allHarald Welte3-13/+40
* What we used to call TCH/F and TCH/H in gsmtap are actually only FACCH/F and FACCH/H, i.e. the signaling part of Bm/Lm channels * Give them proper names with backwards compatibility #define * Split VOICE into VOICE_F and VOICE_H. If we don't differentiate this, a receiver is not able to determine the RSL channel ID of a frame without looking at external state/context. That in turn has been a design feature of GSMTAP Um format so far, and programs like osmo-bts-virtual rely on it. Change-Id: I952044a17334f35712e087dc41781805000aebc1 Related: OS#2557
2020-03-08Add CTRL port number for osmo-mgwHarald Welte1-0/+2
Related: OS#4441 Change-Id: I70ae237ea27972f6819fd217c3d5059dda009486
2020-03-08Add GSMTAP_CHANNEL_VOICE to gsmtap_gsm_channel_names[] value_stringHarald Welte1-0/+1
In Change-Id If223020933b083fe359a2e8ff5fab1ce64a363d8 we introduced GSMTAP_CHANNEL_VOICE, but we didn't add it to gsmtap_gsm_channel_names[] Change-Id: I7ab696d3e0edb13632e048a9e05be03612d3d28c Related: OS#2557
2020-03-05gsmtap.h: Add definitions for voice inside GSMTAPHarald Welte1-2/+26
We so far are only able to transmit signalling data inside GSMTAP, but not actual voice / user plane payload data. we cannot use the existing TCHF/TCHH sub-types, as those are already used [without further discrimination] for FACCH + SACCH Data on those channels. Instead, we will introduce a new GSMTAP_CHANNEL_VOICE sub-type, which then will have the first byte for a sub-sub-type specifying the payload format in detail. Change-Id: If223020933b083fe359a2e8ff5fab1ce64a363d8 Related: OS#2557
2020-03-04osmo-sim-test: check tlv_parsed struct tp before accessPhilipp Maier1-4/+8
The variable struct tlv_parsed tp in dump_file() conditionally initalized by tlv_parse() but later it is accessed under a different condition without a check that makes sure that tp is only accessed when tlv_parse() was called beforehand. Lets introduce a check that makes sure tp can not be accessed when it is uninitalized. Change-Id: I6b0209b966127a4195e6f4bcb43d49387c7646ce Fixes: CID#208435
2020-03-04gb: Print signalling and data weights on NS-VC creation.Alexander Chemeris1-1/+2
Change-Id: Ieebec5487f5d995a453d15bc024931299d5cf5bf
2020-03-04gb: Fix typos in gprs_ns.c commentsAlexander Chemeris1-2/+2
Change-Id: I24605c8616015b5f7d45297afc65d6a93d2edbaf
2020-02-28chantype_rsl2gsmtap(): Add entries for CBCHHarald Welte1-0/+6
This adds missing entries for CBCH in the conversion between RSL-style channel numbers and GSMTAP channel types. Without this change, you will see tons of messages like virtphy[19865]: Wed Feb 26 16:16:28 2020 DVIRPHY <0002> gsmtapl1_if.c:267 MS 0000: Ignoring unknown channel type UNKNOWN (0) if running virtphy of osmocom-bb with a BTS that broadcasts CBCH. Change-Id: I19bbd2942adf441f58955ac896ef968bfd8aec5f
2020-02-19bitvec: avoid redundant zero-initialization in bitvec_alloc()Vadim Yanitskiy1-1/+1
All the fields of the structure are set explicitly anyway. Change-Id: I40c0322d5f2febd98bae6fbe0ec2132eda6fb35b
2020-02-19bitvec: cosmetic: init i only once in bitvec_[un]pack()Vadim Yanitskiy1-2/+2
Change-Id: I5606ca34a72d42a9b6aafed662b995f9fa77be09
2020-02-19bitvec: fix misleading description of bitvec_spare_padding()Vadim Yanitskiy1-1/+1
Change-Id: Ie60bf7d993fe80d3c0fcd04e4c3dd81da4a2ea0b
2020-02-19bitvec: fix bitvec_unhex(): do not return 1 on successVadim Yanitskiy2-15/+12
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
2020-02-19tests/bitvec: add a unit test for bitvec_read_field()Vadim Yanitskiy2-0/+60
The aim of this unit test is to demonstrate the problem described in OS#4388: bitvec_read_field() can never return negative value on error (e.g. out of bounds access). Change-Id: I340ab5799fa53d5345edb02f3e2a3655527705c0 Related: OS#4388
2020-02-15osmo-sim-test: Fall-back to classic SIMHarald Welte2-20/+104
If selection of ADF_USIM fails, let's fall-back to reading/dumping a classic TS 11.11 (51.011) SIM card. Change-Id: I5a986fc65de76c24c5af52ce7e8c699cf302fda9
2020-02-15osmo-sim-test: Recurse through subdirectoriesHarald Welte1-13/+39
Don't just iterate over all files in the current working directory (cwd), but also recurse through all sub-directories. Change-Id: I737b01d9a845e37d8be9d4709ef0de04e749daec
2020-02-10bitvec: make bitvec_free() safe against NULLVadim Yanitskiy1-0/+2
Change-Id: Ifafb65e9d0adc286e16104274db440f38a86d800 Related: CID#208181, CID#208179
2020-02-09exec: propogate errors from osmo_environment_[filter|append]Vadim Yanitskiy1-4/+10
Change-Id: If7d6e0441f73092a4fb455340c076ba4dc60af3f
2020-02-09exec: prevent uninitialized memory access in osmo_system_nowait()Vadim Yanitskiy1-0/+3
If (!env_whitelist && addl_env), osmo_environment_append() would access uninitialized memory. If both are false, execle() would also deal with garbage values. Let's ensure that at least the first element of new_env[] is initialized. Change-Id: Id3901de4692ef44e9e9c67b1804e027fc4ce7c18 Fixes: CID#206571
2020-02-09osmo_libusb: check return value of osmo_fd_register()Vadim Yanitskiy1-1/+4
Most likely, we should not assert() here, but let's at least log an error message in case if osmo_fd_register() fails. Change-Id: Ia20755ec12ee9fb0eba8322551642a96e68e1570 Related: CID#206572
2020-02-09conv: prevent theoretical NULL pointer dereference in osmo_conv_encode()Vadim Yanitskiy1-0/+2
A caller shall never pass NULL to osmo_conv_encode(). Change-Id: Ice0050cd7c7e3fcbf57c2c73682ca28843a92d8b Fixes: CID#208174
2020-02-06tdef_vty: do not enforce enum 'node_type' in osmo_tdef_vty_groups_init()Vadim Yanitskiy2-4/+4
Some osmo-* applications may need to use their own VTY node as a parent for the timer configuration commands. Therefore it makes more sense to use 'unsigned int' instead of 'enum node_type'. Let's also clarify that osmo_tdef_vty_groups_init() accepts parent node for configuration commands only: 'parent_node' -> 'parent_cfg_node'. Change-Id: Ifb4c406c85d76a25fc53fc235484599aa87dc77c
2020-02-04value_string: Switch val from unsigned to intPau Espin Pedrol1-1/+1
There's nothing really preventing a user from user negative values. Otherwise if we keep it like this then g++ is not happy when passing eg. { -2, "foobar" } when initializing a value_string array. Change-Id: I754fa7e054cb89801ef82edc82199dcfbe59c6ab
2020-01-29pcsc: don't leak memoryEric Wild1-1/+4
Change-Id: I183882ff2eae82754d55189b154863fad9cce4aa