aboutsummaryrefslogtreecommitdiffstats
AgeCommit message (Collapse)AuthorFilesLines
2023-03-09hnbgw context map FSMsneels/new_fsmNeels Hofmeyr1-17/+58
Change-Id: I15f3e8702ece65ddf05ea5389afab7404f8e5c51
2023-03-09new fsm pfcp peerNeels Hofmeyr1-14/+16
Change-Id: Ibecd831373c4fc1e839aa26c95d8c785c5ddc33d
2023-03-09new_fsm for time_ccNeels Hofmeyr1-35/+13
Change-Id: I1cf95b8aa2f104b2f839b14956e56a93001ce651
2023-03-09add contrib/new_fsm.pyNeels Hofmeyr1-0/+226
Change-Id: I7781008dffc49dc9a279fa066ad2e0bb7da25dfe
2023-03-08gsm_08_58: Document IPAC RTP CSD modes in at least a few wordsHarald Welte1-4/+4
Let's clarify what those modes mean Change-Id: I77fc7b24ccd387f54a7c7edad666737252af6bd9
2023-03-08gsm: TS 44.021 modified V.110 frame encoding/decoding supportHarald Welte9-1/+458
3GPP TS 44.021 specifies the format for modified V.110 frames as used on the GSM air (radio) interface. Implement encoders and decoders for this modified V.110 format. Related: OS#1572 Change-Id: I60a2f2690459359437df20cf4da9043fa7c3ad11
2023-03-08isdn: Add V.110 encoder/decoderHarald Welte11-1/+1030
V.110 defines a B-channel protocol for transmission of synchronous and asynchronous serial data of V-series interfaces via terminal adapters over ISDN. Let's add (unoptimized but easy to debug) functions for encoding and decoding of V.110 frames for various bit-rates. Related: OS#1572 Change-Id: I1b5fd3847d3bfb0a0f763e0574893962ec699680
2023-03-07logging: remove log_initialized(void)Eric1-1/+0
This function does not exist, and was apparently accidentally added (?) to the header. Change-Id: I479ef8484506ff27918df9fbf6cbeda8b304bbaa
2023-03-07fix _thread orderEric2-2/+2
As per gnu extension doc -> https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Thread-Local.html : ".. When used with extern or static, __thread must appear immediately after the other storage class specifier." Change-Id: Ied1d3cf3ad2ff424bd0a2682aff29a8939b419b8
2023-03-07gsm0502: add burst length definitions from chapter 5.2Vadim Yanitskiy1-0/+30
Change-Id: I1c38ccc2b64ba9046bb3b1221d99cc55ec493802 Related: OS#1572
2023-03-06Makefile.am: Make libraries depend on .map filesHarald Welte6-0/+7
Without this, an update to the .map file doesn't re-trigger a re-link of the library. Change-Id: If0ea6f41730a28b04562d45efa6ca376abaf3f6b
2023-03-06gsm: gsm_gsmtime2fn(): constify paramPau Espin Pedrol2-2/+2
Change-Id: Ib29d5a8e7dcf50fb086f967857b0afa076573163
2023-03-05libosmocore.map: Add two missing entries for gsmtap*2() APIHarald Welte1-0/+2
Those functions were introduced in I51b3604ba79e42c474aa17007e7e308a12afcea8 but the recent introduction of libosmocore.map didn't list them Change-Id: I4ac14aae13ff60c110444da989761cd1e86f8925 Fixes: I13169c00a59fb59513dfc598de5a71d094492422
2023-03-03gsm0808: make CSD enum values consistent with RSLOliver Smith2-25/+25
Use the same 32k0, 29k0, 14k4, … notation for GSM0808_DATA_RATE, as it is already used in RSL_CMOD_CSD. As GSM0808_DATA_RATE enumes were just added to libosmocore and aren't used yet, don't add backwards compatible defines. Related: OS#4393 Change-Id: Ia965cdd9f53af756e5ffaff9b8f389b5ad629969
2023-03-03rsl: RSL_CMOD_CSD_T: make enum values consistentOliver Smith1-7/+14
Use the 32k0, 29k0, 14k4, … notation instead of 32000, 29000, 14400 etc to make transparent data enums with non-transparent data enums where this notation is already used. Related: OS#4393 Change-Id: I7b7c8f175f349811b17a3db68a57577bd3f1d2df
2023-03-03rsl: put values for Channel Mode into enumsOliver Smith1-41/+49
Related: OS#4393 Change-Id: I25bfd02aa1428a35492b20376a31635a442e545f
2023-03-02Add osmo_sockaddr_size() to return the size of the variant usedDaniel Willmann1-0/+23
Change-Id: I952b6bb752441fe019fc18f89bce4bbfbe58994a
2023-02-28improve test output for gsm0808_sc_cfg_from_gsm48_mr_cfg()Neels Hofmeyr2-424/+468
Improve the test output to make it easier to confirm that the fix in an upcoming patch (I900fda192742fa8f6dd54e9131ef1704b14cc41a) is indeed correct. Spell out each S0-S15 mode along with the bitmask. Rejigger the format of printing the mr_cfg flags, so that the AMR modes line up vertically with the S0-S15 modes. This clearly shows that the mr_cfg <-> s15_s0 conversion is wrong. For example, in this test only 4k75 is enabled, yet we allow configs featuring 6 other rates: Input: cfg.smod=0 spare=0 icmi=0 nscb=0 ver=0 m4_75=1 ------- ------- ------- ------- ------- ------- ------- Result (fr): S15-S0 = 0x5701 = 0b0101011100000001 S0 4.75 S8 4.75 5.90 S9 4.75 5.90 6.70 S10 4.75 5.90 6.70 7.40 S12 4.75 5.90 6.70 10.2 S14 4.75 5.90 7.95 12.2 Result (hr): S15-S0 = 0x0701 = 0b0000011100000001 S0 4.75 S8 4.75 5.90 S9 4.75 5.90 6.70 S10 4.75 5.90 6.70 7.40 In this test, an s15_s0 featuring a configuration with 6k70 allowed does not result in m6_70 == 1: Input: S15-S0 = 0x0c12 = 0b0000110000010010 S1 4.75 5.90 7.40 12.2 S4 7.40 S10 4.75 5.90 6.70 7.40 S11 4.75 5.90 6.70 7.40 Output: cfg.smod=0 spare=0 icmi=1 nscb=0 ver=1 m4_75=1 ------- m5_90=1 ------- m7_40=1 ------- ------- m12_2=1 Almost every conversion contains errors like this. Related: I900fda192742fa8f6dd54e9131ef1704b14cc41a Change-Id: Iec7c491d9fadd37d9e43fbaac8e709c2029f8a8e
2023-02-28add gsm0808_amr_modes_from_cfgNeels Hofmeyr3-0/+122
Provide the definitions from 3GPP TS 28.062, Table 7.11.3.1.3-2 as generally usable API. Likely users: - upcoming patch to improve conversion between S0-S15 and MultiRate config, I900fda192742fa8f6dd54e9131ef1704b14cc41a - osmo-msc to figure out conversion between SDP AMR mode-set and 3GPP TS 48.008 Permitted Speech S0-S15. - osmo-bsc to choose AMR modes for channel activation from cfg / permitted speech from MSC. Related: SYS#5066 Change-Id: Icef7dd626d3d4641c66b8dd87e2047fc0ab547d1
2023-02-28doxygen: fix various typos in commands \param and \returnsVadim Yanitskiy11-14/+14
Change-Id: If87cec3739449c6a54e24fb2cb81e746d8244da2
2023-02-28doxygen: remove documentation for non-existent paramsVadim Yanitskiy1-3/+1
Change-Id: I8b1be37c8fdaa824637d306bdb40a3b78616f614
2023-02-28contrib/struct_endianness.py: simplify file extension checkVadim Yanitskiy1-1/+1
Change-Id: Iaf7194fdfc3772973f9a9c806d375a9a56ff57c8
2023-02-28libosmocore.map: add tall_{ctr/msgb}_ctxOliver Smith1-0/+2
These should not be used, but add them for backwards compatibility with building older versions of osmo-bsc, osmo-iuh, osmo-pcap against current libosmocore. Fixes: 213fc420 ("Add libosmocore.map") Change-Id: I4cfccf3622844d0923818bb8d8ce206f70e44a0d
2023-02-28GSMTAP: add missing parameter docstringsMax1-2/+4
Change-Id: I774b89e0358bdcf7c71c7fd9c9940f634a7d3822
2023-02-27Add libosmocore.mapDaniel Willmann3-1/+573
Generated with: nm src/core/.libs/libosmocore.so --defined-only |grep " T \| D \| B " | cut -c 20- >> src/core/libosmocore.map Change-Id: I13169c00a59fb59513dfc598de5a71d094492422
2023-02-27gsm0808_enc/dec_channel_type: fix transparent flagOliver Smith2-7/+7
According to 3GPP TS 48.008 3.2.2.11, it is inverted. 0: Transparent service 1: Non-transparent service Change-Id: I2e5786ad053ee871079b4a8d95caccd6b03b59b6
2023-02-27Interleaving for CSDHarald Welte2-0/+54
This patch adds the [de]interleaving for CSD (circuit switched data), nominally for TCH/F 9.6, but the same is also used for TCH/F 4.8, TCH/H 4.8, TCH/F 2.4 and TCH/F 14.4. Related: OS#4396, OS#1572 Change-Id: I6b16c2d0d7febf3883da662b2c7fec543335de12
2023-02-27doxygen: also generate documentation for libosmo{sim,usb}Vadim Yanitskiy10-12/+3563
We do have API documentation for all libraries, excepte these two. Change-Id: I2ec5803bc219b9ceaf0d52d41a03ab78f580e689
2023-02-27debian/control: fix typoVadim Yanitskiy1-1/+1
Change-Id: Ia9f99016dcf2a9584b59a253d19f391e8f5e5abb
2023-02-27debian/control: make libosmocore-doc depend on libosmo{ctrl,gb}-docVadim Yanitskiy1-1/+3
Change-Id: Icd84afcd035bdca9aabb4ea2b91c1227c4786da7
2023-02-27gsm: use OSMO_ASSERT() in osmo_iuup_msgb_alloc_c()Vadim Yanitskiy1-1/+1
This patch is a preparation for the upcoming change making use of the built-in static_assert(), which is available since C11. When using built-in static_assert(), gcc v12.2.1 fails: iuup.c: In function 'osmo_iuup_msgb_alloc_c': iuup.c:194:33: error: expression in static assertion is not constant 194 | osmo_static_assert(size > IUUP_MSGB_HEADROOM_MIN_REQUIRED, iuup_msgb_alloc_headroom_bigger); ../../include/osmocom/core/utils.h:86:24: note: in definition of macro 'osmo_static_assert' 86 | static_assert((exp), "(" #exp ") failed") | ^~~ This one is not really a *static* assert(), because it operates on the user supplied argument 'size', which is not guaranteed to be an integer literal. Neither it triggers a compilation failure as expected, nor does it abort at run-time. It simply does nothing. Change-Id: I53db679728250e0c60ed277efb18142073ffe9c4
2023-02-27msgb: use OSMO_ASSERT in msgb_alloc_headroom[_c]()Vadim Yanitskiy1-2/+2
This patch is a preparation for the upcoming change making use of the built-in static_assert(), which is available since C11. When using built-in static_assert(), gcc v12.2.1 fails: include/osmocom/core/msgb.h: In function 'msgb_alloc_headroom_c': include/osmocom/core/msgb.h:532:33: error: expression in static assertion is not constant 532 | osmo_static_assert(size >= headroom, headroom_bigger); include/osmocom/core/utils.h:86:24: note: in definition of macro 'osmo_static_assert' 86 | static_assert((exp), "(" #exp ") failed") | ^~~ include/osmocom/core/msgb.h: In function 'msgb_alloc_headroom': include/osmocom/core/msgb.h:554:33: error: expression in static assertion is not constant 554 | osmo_static_assert(size >= headroom, headroom_bigger); include/osmocom/core/utils.h:86:24: note: in definition of macro 'osmo_static_assert' 86 | static_assert((exp), "(" #exp ") failed") | ^~~ These are not really *static* assert()s, because they operate on the user supplied arguments 'size' and 'headroom', which are not guaranteed to be integer literals. Neither they trigger compilation failures as expected, nor do they abort at run-time. They simply do nothing. Change-Id: I17ef4f3283ce20a5b452b7874c826acfb02a0123
2023-02-25convolutional coding for CSDHarald Welte3-0/+123
This patch adds the convolutional code definitions for CSD (circuit switched data) on TCH/F channels with user bit rates of 2400, 4800, 9600 and 14400 bps. Related: OS#4396, OS#1572 Change-Id: I412131d7ee2e676402bf8d88394af17c4447b664
2023-02-25gsm/{bsslap,bssmap_le}: zero-initialize structs using memset()Vadim Yanitskiy2-9/+10
In the unit tests we're using memcmp() to compare decoding results against the expected results. This is a reasonable approach, but there is a pitfall: not only the struct fields are compared, but also the padding bytes preceding/following them. When using gcc's extension zero-initializer {} or even the standard approved { 0 } zero-initializer, padding bytes are not guaranteed to be zeroed. Even worse, according to [1], the init behavior is inconsistent between gcc and clang and optimization levels. All decoding functions in {bsslap,bssmap_le}.c currently use gcc's extension zero-initializer {}. This is not a problem when building with CC=gcc, but with CC=clang the bssmap_le_test fails due to mismatch of padding bytes in struct lcs_cause_ie: [4] PERFORM LOCATION RESPONSE: ERROR: decoded PDU != encoded PDU [5] PERFORM LOCATION RESPONSE: ERROR: decoded PDU != encoded PDU [6] PERFORM LOCATION ABORT: ERROR: decoded PDU != encoded PDU Out of the known struct initialization methods, only the memset() has consistent behavior and sets all bytes to zero, including the padding ones. Using it fixes the bssmap_le_test for CC=clang. [1] https://interrupt.memfault.com/blog/c-struct-padding-initialization Change-Id: Ib16964b16eb04315efc416164ed46c15b5dc7254 Fixes: OS#5923
2023-02-24i460_mux: add define constant for maximum number of subchannelsPhilipp Maier1-1/+3
Lets get rid of the magic number in struct osmo_i460_timeslot and replace it with a define constant. Change-Id: Id3a3782927c7dcbc873223d56129f291c04fee26 Related: OS#5198
2023-02-24gsm: ensure completeness of osmo_bts_features_{descs,names}[]Vadim Yanitskiy2-1/+8
It already happened several times [1][2] that new features were added to enum osmo_bts_features, but the osmo_bts_features_{descs,names}[] were left unchanged. Let's add static_assert()s to prevent this. Change-Id: I8e3b7d3996e9f3e16c6d4e0d1d406fa538d5e9be Related: [1] f4f5d54ea2cb47a51aeaec2b5fb990664755900a Related: [2] 18c6a8183f92915e77368ecffb1cbf7f555453a3
2023-02-24gsm: add missing features to osmo_bts_features_names[]Vadim Yanitskiy1-0/+2
Change-Id: I0ff47a79d611cd1c2d23ac5b4d53dca27e402821 Fixes: 812dfbf3a756088ef8ae083044c690783ef84067
2023-02-22add osmo_prim_operation_name()Neels Hofmeyr1-1/+5
Also remove the explicit array dimension from the .h file. Change-Id: I9f43428af654a5674ac3035fe4db1394aac7a7af
2023-02-22Rename OSMO_AUTH_ALG_XOR to OSMO_AUTH_ALG_XOR_3GHarald Welte3-4/+7
Let's disambiguate. Our existing OSMO_AUTH_ALG_XOR was always only the XOR-3G algorithm. Now that we recently introduced XOR-2G, let's rename (with backwards compatibility #define). Change-Id: I446e54d0ddf4a18c46ee022b1249af73552e3ce1
2023-02-22New unit test for XOR-2G authenticationHarald Welte4-0/+94
Let's test if the XOR-2G algorithm does what it's supposed to do. Change-Id: I7014258751624ff18c51912b6348c3cd876bb23f
2023-02-21Implement the XOR-2G authentication algorithmHarald Welte4-1/+82
We've so far only been supporting XOR-3G algorithm as specified in TS 34.108 (in both 3G and 2G-derivation mode). However, XOR-3G used for 2G auth is different from the XOR-2G algorithm as defined in Annex A of TS 51.010-1. Let's add support for that one, too. Change-Id: I0ee0565382c1e4515d44ff9b1752685c0a66ae39
2023-02-21tests: add test_gsm0808_enc_dec_channel_type_signOliver Smith1-0/+28
Verify that we have the spare byte when encoding the signalling type. Related: OS#5911 Change-Id: Ied6e451d2e884412104cd9d530d0cd1b39f17f27
2023-02-21gsm0808_dec_channel_type: fix dec of ch_rate_typeOliver Smith1-1/+1
According to 3GPP TS 48.008 V16.0.0 § 3.2.2.11, the "Channel and rate type" fills the whole octet 4, so don't cut it off. This fixes decoding of e.g. GSM0808_SIGN_FULL_PREF_NO_CHANGE, which I noticed while writing a test. Related: OS#5911 Change-Id: Ib5fba18eb82736c4f52f315ae1197159b7090e69
2023-02-20libosmogb.pc.in: Fix missing dependency on libosmogsmPau Espin Pedrol1-1/+1
Change-Id: I5efa04d1c5cabc65b42de624b26fdbf9ebe746b1
2023-02-20Move libosmogsm TS 44.060 declarations under include/osmocom/gsm/Pau Espin Pedrol8-258/+261
Currently there's a big mess where include dir osmocom/gprs/ is used by both libosmogsm and libosmogb. Most of the header files under osmocom/gprs/ are actually all the headers of libosmogb (there's no osmocom/gb/ dir). But a couple files are actually RLC/MAC (TS 44.060) related are are also stored in there. Those files have no relation/use in Gb, and are actually interused with GSM (eg System Information 13 Rest Octets). Hence, it makes sense to have the RLC/MAC related parts inside osmocom/gsm/ as they should be in libosmogsm (and they actually are, see gprs_rlc.h function implemented in src/gsm/gsm48_rest_octets.c). The fact that some libosmogsm headers were placed in osmocom/gprs instead of osmocom/gsm already created some issues, like libosmocore.spec.in putting "%_includedir/%name/osmocom/gprs/" under libosmogb, which is wrong. As a first step to fix the mess, we move the 2 RLC/MAC headers currently under osmocom/gprs/{gprs_rlc,protocol/gsm_04_60}.h under a single header gsm/protocol/gsm_44_060.h The two old headers are left existing for backward compatibility and now simply include the new libosmogsm header, plus a warning asking users to switch to the new header so we can eventually get rid of them. This means libosmogb depends on libosmogsm, which is fine and was already the case beforehand (libosmogb using functions like gsm48_encode_ra() and linking against it in src/gb/Makefile.am). Change-Id: I70cc21bf25a7081070738abacb409ed19094c3b2
2023-02-20gsmtap_util: remove whitespace at the end of linePhilipp Maier1-1/+1
Change-Id: Ib7afbfb1f7a95beab16fed11d07ae244b4fcfcdc
2023-02-20GSMTAP: add gsmtap_source_init*2()Max2-4/+49
Those allow selecting source host:port for UDP socket sending GSMTAP data. It's handy when you have several GSMTAP sources operating simultaneously. Change-Id: I51b3604ba79e42c474aa17007e7e308a12afcea8
2023-02-20gsm0808_enc_channel_type: Add spare byteMatan Perelman1-0/+1
Related: OS#5911 Change-Id: I6e05e4989924b2258122113eb134e946e9cf0107
2023-02-20Run struct_endianness.pyOliver Smith1-0/+1
Ensure there is no diff to prepare to run this in CI. Related: OS#5884 Change-Id: I194f3affeb969d485348c46a6dabbe5f8e47e780
2023-02-20gsm_04_60.h: Better describe origin of enum osmo_gprs_nmoPau Espin Pedrol1-1/+2
Change-Id: Ied6c11aa92ea5a2e18a6045cefddfd4e40108174
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-14 03:22:49 +0000