aboutsummaryrefslogtreecommitdiffstats
path: root/include/Makefile.am
AgeCommit message (Collapse)AuthorFilesLines
2023-01-18Split include/Makefile.am content into subdirsPau Espin Pedrol1-225/+1
When someone is modifying a given library there's no need to be looking at a common file contains tons of lines from different libraries. Furthermore, this removes the need of "nobase" autofoo prefix, hence following the usual directive of having one Makefile per directory. Change-Id: I785891c2f89114bf8303c799094b637d3d25ac71
2021-12-23select: gather statistics for TCP connectionsPhilipp Maier1-0/+1
osmocom applications are deployed in a variety of different situations. Dependung on the medium that interconnects the network components unexpected behaviour may occur. To debug problems with the interconnection between network components it might help to monitor the health of the related TCP connections. Change-Id: I1416f95aff2adcf13689646b7574845de169fa3d Related: SYS#5701
2021-12-22Introduce CRC and FSM for IuUP (user plane) as used in 3G RTP dataHarald Welte1-0/+2
Only support for SMpSDU mode is introduced in this commit. Not supported explicit list: - Transparent mode - ATM/AAL2 based Transport layer - GTP-U based Transport Layer - Iu Rate Control procedure - Time Alignment procedure APIs are provided to allocate the primitives properly inside the related msgb. This way primitives can be placed in the headroom, leaving the data part of the msgb for the IuUP payload, hence allowing re-use of the msgb and 0 copy of IuUP payload when forwarding data over RNL<->TNL. Since RNL and TNL primitives relu struct osmo_prim_header, which is not packed, they cannot be set to packed, and hence proper memory alignment in the msgb must be done to avoid misaligned accesses (Asan errors about it otherwise). Related: SYS#5516 Change-Id: Ibe356fa7b1abaca0091e368db8478e79c09c6cb0
2021-11-15add osmo_time_cc, moved from osmo-bscNeels Hofmeyr1-0/+1
Related: SYS#4878 Related: Ica9f908a1a30f334a24c59471affa11225117e12 (osmo-bsc) Change-Id: Iabb17a08e6e1a86f168cdb008fba05ecd4776bdd
2021-11-11include: add enum for UTRAN cipherAlexander Couzens1-0/+1
Change-Id: I4b9baff2c2fbd0e339fc769cc69cce58d3a72cdf
2021-09-21base64: Migrate over to osmocomHarald Welte1-0/+1
This containts the osmocom changes to the mbedtls base64 code merged in the previous commit. Change-Id: I82c1bf5f827c8def370dbcb80b146e9e4184c4a3
2021-06-08kdf: add key derivation functionsEric1-0/+1
generic sha code from git://w1.fi/hostap.git commit 5ea93947ca67ba83529798b806a15b247cdb2e93 which also happens to be the source of our milenage code. Related: SYS#5324 Change-Id: Ibf2e49edada944d91ceba62bd0d6b6ce69261fcd
2021-02-17Introduce osmo_gettid() APIPau Espin Pedrol1-0/+1
This API wraps conventional gettid() linux-specific API, which even in Linux itself is sometimes not properly supported/announced. This API also allows future porting to other platforms if needed, and so far falls back to getpid() if no gettid(9 can be found. Code ported from osmo-trx.git, see commit 7a07de1efd4eb7cc11c33d3ad25cb2df70aa1ef1. Related: OS#5027 Change-Id: Id7534beeb22fcd50813dab76dd68818e2ff87ec2
2021-02-16gsm_08_58, gsm_44_004: add struct for l1 informationPhilipp Maier1-0/+1
Libosmocore currently does not offer any structs to encode and decode the l1 information on RSL level and the sacch l1 header on the air interface level. Both structs are identical but the field order in the first octet is reversed. Change-Id: I23c1890b89d5a0574eb05dace9f64cc59d6f6df7
2021-01-18bssgp_rim: add encoder/decoder for NACC related RIM containersPhilipp Maier1-0/+1
BSSGP RIM uses a number of nested containers to signal RIM application specific payload information in a generic way. Lets add the container structurs required for NACC. Depends: libosmocore If48f412c32e8e5a3e604a78d12b74787a4786374 Change-Id: Ibbc7fd67658e3040c12abb5706fe9d1f31894352 Related: SYS#5103
2021-01-06Add inter-thread queueHarald Welte1-0/+1
This adds an inter-thread queue "it_q" to libosmocore. With it_q, one can perform thread-safe enqueing of messages to another thread, who will receive the related messages triggered via an eventfd handled in the usual libosmocore select loop abstraction. Change-Id: Ie7d0c5fec715a2a577fae014b0b8a0e9c38418ef
2020-12-16gprs_bssgp: add IE parser/generator for RIM Routing InformationPhilipp Maier1-0/+1
The RIM Routing Information IE (see also 3GPP TS 48.018, section 11.3.70) is used to control the flow of BSSGP rim messages at the SGSN. Change-Id: I6f88a9aeeb50a612d32e9efd23040c9740bc4f11 Related: SYS#5103
2020-12-09gb: Add beginnings of a new BSSGP implementationHarald Welte1-0/+2
Similar to ns2 superseding ns, we now also intoduce a next generation of BSSGP related code to libosmogb. However, this is not aiming to be a full implementation yet, but simply those parts that we currently need from the revamped osmo-gbproxy. The gprs_bssgp2.[ch] differs in two ways from the old code: * it separates message encoding from message transmission * it supports more recent specs / IEs bssgp_bvc_fsm.c is a genric implementation of the BSSGP BVC RESET/BLOCK/UNBLOCK logic with support for both PTP and signaling, both on the SGSN side and the BSS side. Change-Id: Icbe8e4f03b68fd73b8eae95f6f6cccd4fa9af95a
2020-12-07Include mnl.h iif --enable-libmnlPau Espin Pedrol1-1/+4
Change-Id: I06016e3a6e90b09b76634a00081d0d40a8e2f94b
2020-12-05Add hlist and hashtable from Linux kernelHarald Welte1-0/+3
For more than a decade we've used the linuxlist.h for double-linked lists. Let's also add the hlist (double-linked lists with single pointer sized head, and the hashtable that builds on top of it. This reflects the versions included in Linux 5.8 with some modifications to make them build in userspace (remove RCU versions, adjust for userspace include files and types, convert to doxygen). Change-Id: I8ef73a62fe9846ce45058eb21cf999dd3eed5741
2020-12-02Integrate libmnl (minimal netlink) library with libosmocore select loopHarald Welte1-0/+1
This adds an easy way to listen to netlink events form the Linux kernel from within libosmocore applications. The new dependency can be disabled via the "--disable-lbimnl" configure flag. Change-Id: I4f787ee68f0d6d04f0a5655eb57d55b3b326a42f
2020-11-24ns2: add support for frame relayAlexander Couzens1-0/+1
Add support for frame relay over dahdi hdlc device. It's supporting lmi by q933 and supports both SGSN and BSS. Change-Id: Id3b49f93d33c271f77cd9c9db03cde6b727a4d30
2020-10-07add BSSMAP coding for Location ServicesNeels Hofmeyr1-0/+1
BSSMAP: add A-interface messages between MSC and BSC: - Perform Location Request - Perform Location Response - Perform Location Abort Change-Id: I4d7302a4853518916b6b425e710c10568eb2ffe5
2020-10-07add BSSMAP-LE coding for Location ServicesNeels Hofmeyr1-0/+1
BSSMAP-LE: add Lb-interface messages between BSC and SMLC: - Reset - Reset Acknowledge - Perform Location Request, possibly containing BSSLAP TA Layer3 - Perform Location Response - Perform Location Abort - Connection Oriented Information containing any BSSLAP APDU Add encoding and decoding tests. Change-Id: I271e59b794bafc0a7ae0eabbf58918f6d7df431d
2020-10-07add BSSLAP coding for Location ServicesNeels Hofmeyr1-0/+3
BSSLAP: there are APDUs transferred in BSSMAP-LE Connection Oriented Information messages on Lb between BSC and SMLC. Add BSSLAP coding for these APDU messages: - TA Layer3 - TA Request - TA Response, possibly containing Location Estimate coded in GAD - Reject - Reset (for intra-BSS handover during TA Request) - Abort (for inter-BSS handover) Add encoding and decoding tests. Change-Id: I6409c4bcac402dc7626a3afce9081c59cd715fe8
2020-10-07add GAD coding for Location ServicesNeels Hofmeyr1-0/+2
GAD, Universal Geographical Area Description: - raw coding for all GAD elements. - SI-units encoding and decoding for Ellipsoid point with uncertainty circle, which I presume is the typical "at most N meters away from cell tower located at X,Y", which corresponds to the TA positioning currently being implemented. - other SI-units GAD element encodings are so far not implemented. Add encoding and decoding tests. In gsm/protocol/gsm_23_032.h are the raw coding structs as defined in 3GPP TS 23.032. In gsm/gad.h are structs carrying consistent units based on meters and degrees, for convenient / less error prone handling of GAD data, and for human readable representations of the GAD data. The separation of the two is desirable because OsmoBSC will receive GAD data from OsmoSMLC on the Lb interface, and pass on this data to the MSC via the A interface. It is better to pass the GAD data as-is without de/encoding. Change-Id: I7a9dd805a91b1ebb6353bde0cd169218acbf223c
2020-09-15Gb: add a second NS implementationAlexander Couzens1-0/+1
Reimplement NS with FSM. Change-Id: I3525beef205588dfab9d3880a34115f1a2676e48
2020-08-10vty: Introduce support to set cpu-affinity and scheduler policyPau Espin Pedrol1-0/+1
Process willing to support this kind of configuration through VTY simply need to call "osmo_sched_vty_init(tall_ctx);" during startup to register the commands. For multithreaded processes, new threads willing to get their cpu-affinity mask according to VTY config should call osmo_sched_vty_apply_localthread() (potentially after setting the thread name through pthread_setname_np()). Related: SYS#4986 Change-Id: If76a4bd2cc7b3c7adf5d84790a944d78be70e10a
2020-06-10add gsm23236: MSC pooling: TMSI and NRI utility functionsNeels Hofmeyr1-0/+1
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-05-28Implement ITU-T I.460 multiplex / demultiplexHarald Welte1-0/+1
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-04-14dtx: add decoding for AMR-DTX framesPhilipp Maier1-0/+1
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
2019-12-17Introduce helper functions for safe fork+exec of processesHarald Welte1-0/+1
In some situations, we want to execute an external shell command in a non-blocking way. Similar to 'system', but without waiting for the child to complete. We also want to close all file descriptors ahead of the exec() and filter + modify the environment. Change-Id: Ib24ac8a083db32e55402ce496a5eabd8749cc888 Related: OS#4332
2019-12-16libosmocore libusb integrationHarald Welte1-0/+5
Osmocom applications typically use libosmocore select.[ch] event loop code as their main event dispatch mechanism. When they want to deal with libusb in a non-blocking/asynchronous way, they need to integrate libusb into that select(). The new libosmousb is doing exactly that: Providing a shared utility library for Osmocom programs that wish to use libusb. This is useful for example in simtrace2 host utilitie as well as osmo-e1d. Change-Id: I656a1a38cbb5b1f3a9145d2869d3b4d0adefcae3 Closes: OS#4299
2019-12-12debian, utils: switch to python 3Oliver Smith1-1/+1
Make build and external tests work with python3, so we can drop the python2 dependency. This should be merged shortly after osmo-python-tests was migrated to python3, and the jenkins build slaves were (automatically) updated to have the new osmo-python-tests installed. Related: OS#2819 Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7 Change-Id: I84ef43f700e125c7a65f92347f12844e07e65655
2019-07-20Add Cell Broadcast related definitions from 3GPP TS 23.041Harald Welte1-0/+1
Change-Id: I1e2c62cb9047648907c91b99f764f6caba8f4493
2019-07-20CBSP (Cell Broadcast Service Protocol; 3GPP TS 48.049) supportHarald Welte1-0/+2
This introduces definitions as well as a parser+encoder for the Cell Broadcast Service Protocol (CBSP) as specified in 3GPP TS 48.049. CBSP is used on the interface between CBC and BSC. Related: OS#3537 Change-Id: I5b7ae08f67e415967b60ac4b824db9e22ca00935
2019-04-08add osmo_use_count APINeels Hofmeyr1-0/+1
Provide a common implementation of use counting that supports naming each user as well as counting more than just one use per user, depending on the rules the caller implies. In osmo-msc, we were originally using a simple int counter to see whether a connection is still in use or should be discarded. For clarity, we later added names to each user in the form of a bitmask of flags, to figure out exactly which users are still active: for logging and to debug double get / double put bugs. This however is still not adequate, since there may be more than one CM Service Request pending. Also, it is a specialized implementation that is not re-usable. With this generalized implementation, we can: - fix the problem of inadequate counting of multiple concurrent CM Service Requests (more than one use count per user category), - directly use arbitrary names for uses like __func__ or "foo" (no need to define enums and value_string[]s), - re-use the same code for e.g. vlr_subscr and get fairly detailed VLR susbscriber usage logging for free. Change-Id: Ife31e6798b4e728a23913179e346552a7dd338c0
2019-04-08add osmo_sockaddr_str APINeels Hofmeyr1-0/+1
For handling RTP IP addresses and ports, osmo-mgw, osmo-bsc and osmo-msc so far have their own separate shims and code duplication around inet_ntoa(), htons(), sockaddr conversions etc. Unify and standardize with this common API. In the MGW endpoint FSM that was introduced in osmo-bsc and which I would like to re-use for osmo-msc (upcoming patch moving that to osmo-mgw), it has turned out that using char* IP address and uint16_t port number types are a convenient common denominator for logging, MGCP message composition and GSM48. Ongoing osmo-msc work also uses this for MNCC. This is of course potentially useful for any other IP+port combinations besides RTP stream handling. Needless to say that most current implementations will probably stay with their current own conversion code for a long time; for current osmo-{bsc,msc,mgw} work (MGW endpoint FSM) though, I would like to move to this API here. Change-Id: Id617265337f09dfb6ddfe111ef5e578cd3dc9f63
2019-02-04add osmo_tdef API, originally adopted from osmo-bsc T_defNeels Hofmeyr1-0/+2
Move T_def from osmo-bsc to libosmocore as osmo_tdef. Adjust naming to be more consistent. Upgrade to first class API: - add timer grouping - add generic vty support - add mising API doc - add C test - add VTY transcript tests, also as examples for using the API From osmo_fsm_inst_state_chg() API doc, cross reference to osmo_tdef API. The root reason for moving to libosmocore is that I want to use the mgw_endpoint_fsm in osmo-msc for inter-MSC handover, and hence want to move the FSM to libosmo-mgcp-client. This FSM uses the T_def from osmo-bsc. Though the mgw_endpoint_fsm's use of T_def is minimal, I intend to use the osmo_tdef API in osmo-msc (and probably elsewhere) as well. libosmocore is the most sensible place for this. osmo_tdef provides: - a list of Tnnnn (GSM) timers with description, unit and default value. - vty UI to allow users to configure non-default timeouts. - API to tie T timers to osmo_fsm states and set them on state transitions. - a few standard units (minute, second, millisecond) as well as a custom unit (which relies on the timer's human readable description to indicate the meaning of the value). - conversion for standard units: for example, some GSM timers are defined in minutes, while our FSM definitions need timeouts in seconds. Conversion is for convenience only and can be easily avoided via the custom unit. By keeping separate osmo_tdef arrays, several groups of timers can be kept separately. The VTY tests in tests/tdef/ showcase different schemes: - tests/vty/tdef_vty_test_config_root.c: Keep several timer definitions in separately named groups: showcase the osmo_tdef_vty_groups*() API. Each timer group exists exactly once. - tests/vty/tdef_vty_test_config_subnode.c: Keep a single list of timers without separate grouping. Put this list on a specific subnode below the CONFIG_NODE. There could be several separate subnodes with timers like this, i.e. continuing from this example, sets timers could be separated by placing timers in specific config subnodes instead of using the global group name. - tests/vty/tdef_vty_test_dynamic.c: Dynamically allocate timer definitions per each new created object. Thus there can be an arbitrary number of independent timer definitions, one per allocated object. T_def was introduced during the recent osmo-bsc refactoring for inter-BSC handover, and has proven useful: - without osmo_tdef, each invocation of osmo_fsm_inst_state_chg() needs to be programmed with the right timeout value, for all code paths that invoke this state change. It is a likely source of errors to get one of them wrong. By defining a T timer exactly for an FSM state, the caller can merely invoke the state change and trust on the original state definition to apply the correct timeout. - it is helpful to have a standardized config file UI to provide user configurable timeouts, instead of inventing new VTY commands for each separate application of T timer numbers. Change-Id: Ibd6b1ed7f1bd6e1f2e0fde53352055a4468f23e5
2019-01-12port rest octets encoding code from osmo-bscStefan Sperling1-0/+1
As part of fixing issue OS#3075, we want to migrate support for encoding system information from osmo-bsc to libosmocore. This change ports osmo-bsc code for encoding SI rest octets. The conversion was a bit tricky in some places because some functions receive a 'struct gsm_bts' parameter in osmo-bsc. In this libosmocore version, such functions expect parameters which correspond to the individual fields of 'struct gsm_bts' which are used by these functions. Several structs from osmo-bsc's system_information.h are now also declared in libosmocore headers, with an added osmo_ prefix to avoid collisions with existing definitions in osmo-bsc. Some helpers were ported from osmo-bsc's system_information.c to libosmocore's gsm48_rest_octets.c. Contrary to osmo-bsc's implementation they are now only visible within this file. Unfortunately, this code ported from osmo-bsc lacks unit tests. Change-Id: I47888965ab11bba1186c21987f1365c9270abeab Related: OS#3075
2019-01-12port arfcn range encode support from osmo-bscStefan Sperling1-0/+1
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
2018-12-18GSUP/SMS: introduce MO-/MT-FORWARD-SM messagesVadim Yanitskiy1-0/+1
According to 3GPP TS 29.002, there are two services: - MAP-MO-FORWARD-SHORT-MESSAGE (see 12.2), - MAP-MT-FORWARD-SHORT-MESSAGE (see 12.9), which are used to forward MO/MT short messages. This change replicates both services as GSUP messages: - OSMO_GSUP_MSGT_MO_FORWARD_SM_*, - OSMO_GSUP_MSGT_MT_FORWARD_SM_*. Please note, that only the 'must-have' IEs are introduced by this change, in particular the following: - OSMO_GSUP_SM_RP_MR_IE (see note below), - OSMO_GSUP_SM_RP_DA_IE (see 7.6.8.1), - OSMO_GSUP_SM_RP_OA_IE (see 7.6.8.2), - OSMO_GSUP_SM_RP_UI_IE (see 7.6.8.4), - OSMO_GSUP_SM_RP_MMS_IE (see 7.6.8.7), - OSMO_GSUP_SM_RP_CAUSE_IE (see GSM TS 04.11, 8.2.5.4), where both SM_RP_DA and SM_RP_OA IEs basically contain a single nested TV of the following format: - T: identity type (see 'osmo_gsup_sms_sm_rp_oda_t'), - V: encoded identity itself (optional). According to GSM TS 04.11, every single message on the SM-RL has an unique message reference (see 8.2.3), that is used to link an RP-ACK or RP-ERROR message to the associated (preceding) RP-DATA or RP-SMMA message transfer attempt. In case of TCAP/MAP, this message reference is being mapped to the Invoke ID. But since GSUP has no 'Invoke ID' IE, and it is not required for other applications (other than SMS), this change introduces a special 'SM_RP_MR' IE that doesn't exist in MAP. Change-Id: Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Related Change-Id: (docs) Ie0150756c33c1352bc4eb49421824542c711175c Related Change-Id: (TTCN) Ibf49474a81235096c032ea21f217170f523bd94e Related: OS#3587
2018-12-14LCLS, TS 29.205: add GCR routinesMax1-0/+1
Add functions to encode and decode Global Call Reference as per 3GPP TS 29.205 Table B 2.1.9.1 add corresponding tests. Change-Id: Iee95aa4e5c056645b6cb5667e4a067097d52dfbf Related: OS#2487
2018-12-07gsm29118: add generator functions for GSM29118 messagesPhilipp Maier1-0/+1
We already have some GSM29118 related definitions and functions in libosmocore. Lets also add some functions to generate GSM29118 messages (similar to those we have for GSM0808). Change-Id: Ic87f8a771b87b52215d0a7451b67794557b80b8a Related: OS#3615
2018-10-21SGsAP protocol definitions (header + C file)Harald Welte1-0/+1
Change-Id: Idddfc9b851eb4c2fa7dd661a9ce1b03a04883109
2018-09-13logging vty: rewrite 'logging level' vty cmd generationNeels Hofmeyr1-1/+4
Completely drop the implementations of log_vty_command_{str,description}(). These functions have been public API once, marked as deprecated since c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7 (March 2017). I considered to keep them, or reduce them to useless stubs, but it is quite silly, really. These functions are completely and utterly useless outside of libosmocore. Any program linking these deserves to fail. Re-implement vty logging level command gen, in logging_vty.c. logging.c is simply the wrong place for that. Introduce logging_internal.h to share logging definitions to logging_vty.c without publishing as API. Introduce static gen_logging_level_cmd_strs() to compose a list of category arguments with their descriptions for VTY commands. Use osmo_talloc_asprintf() instead of the previous error prone and chaotic strlen() counting method. Do not dynamically generate log level arguments, just keep static strings. We are super unlikely to ever change the log levels we have. No changes in logging_vty_test.vty: proves that there is no functional change. All of this, besides introducing basic sanity, is cosmetic preparation to be able to re-use the generic command generation code for arbitrary commands with category or level args (for deprecated and new keywords). Rationale: I want to hide 'all' and 'everything' from the VTY command documentation, by means of deprecating. I first tried to simply define a deprecated 'logging level CAT everything' command: logging level (all|rsl|rr|...) (debug|info|notice|error|fatal) logging level CAT everything # <- deprecated and hidden But unfortunately, command matching doesn't work as intended when the CAT argument reflects a valid category; I want it to invoke the deprecated function as soon as the 'everything' keyword follows, but it stays stuck to the "valid" command when the category argument matches an explicit keyword in that list, and will throw an error on the following 'everything' keyword. I.e.: logging level rsl everything % Unknown command # <-- leads to config file parse error logging level unknown_string everything % Ignoring deprecated 'everything' # <-- works only for invalid categories So I need to define 'everything' separately, again with a list of each valid category instead of a generic CAT arg. Change-Id: I3b083f27e3d751ccec258880ae7676e9af959a63
2018-07-30import oap_client into libosmogsmHarald Welte1-0/+1
This imports the code from osmo-msc 6afef893e17bce67e4d4119acd34d480ed03ba77 with minimal changes to make it compile. Symbol renaming to osmo_ prefix is done separately in a follow-up patch to have a as-clean-as-possible import first. Change-Id: I9bc38102318da02d1fe46ef516df3cfd6bf8e3da
2018-07-02Don't enforce Python 2 for utilitiesVadim Yanitskiy1-1/+1
The conv_gen.py utility was tested against both Python 2 and 3, so there is no need to enforce Python 2. Also, having: #!/usr/local/bin/python{2|3} is a bad idea, because Python may be installed in a different location. Change-Id: I6007d481047b584db13d6eda70fb99f11f9ddaa1
2018-05-11isdnhdlc: Port from kernel to userspaceHarald Welte1-0/+1
* prefix all symbols/constants with osmo_ * use stdint.h types instead of kernel types * use Doxygen API documentation * use Osmocom CRC16-CCITT functions * use Osmocom bit-reversal functions * integrate with Automake Change-Id: I109085ab3e412c20b19cd42fb7137aa0e4167542
2018-03-02features: move bts feature related functionality to libosmocorePhilipp Maier1-0/+1
osmo-bsc and osmo-bts share enums and value strings to describe feature data that is exchanged via OML (manufacturer id) on startup. Also the functions to set and get the respecitive bits in the feature bitvectors are in osmo-bsc and osmo-bts. This is a code duplication and should be resolved. - add enum osmo_bts_features (replaces enum gsm_bts_features) - add osmo_bts_features_descs (replaces gsm_bts_features_descs) - add osmo_bts_set_feature (replaces gsm_btsmodel_set_feature) - add osmo_bts_has_feature (replaces gsm_btsmodel_has_feature) Change-Id: Id0c35aef11aa49aa40abe7deef1f9dbd12210776
2018-02-27core: Add timespec helper macros and make timer_compat.h publicPau Espin Pedrol1-1/+1
If a monotonic clock must be used, then the clock_gettime API is used which uses timespec structures. Linux systems by default don't provide helpers to calculate time using timespecs, so let's add them here. Let's also make this header public so these helpers can be used in other projects using libosmocore (expected user: libosmo-netif). Change-Id: I45fc993b9bb0a343763238bf463c8640f47b00f1
2018-01-15libosmocodec: implement ECU (Error Concealment Unit) for FRPhilipp Maier1-0/+1
When a bad GSM voice frame is received, it's being replaced by a silence frame. This may cause unpleasant audio effects. This change implements a functionality to craft a replacement frame from the last known good frame. Currently, only FR is supported, support for other codecs may be added latter. Change-Id: I06a21f60db01bfe1c2b838f93866fad1d53fdcd1
2017-12-20libosmocodec: add FR bit offset definitionsPhilipp Maier1-0/+1
This change defines the GSM FR bit positions as described in RFC 3551, which will be used by further ECU (Error Correction Unit) implementation. Change-Id: I1d0a198af0f8dd1f690b5a81f5c9eb92c43aefed
2017-10-15Rename 'statistics.c' to 'counter.c'Harald Welte1-0/+1
With stat_item, stats.c and stats_statsd.c, it is becoming a bit difficult to understand file naming. Also, the 'statistics.c' file actually only contained osmo_counter handling, so let's rename it to counter.c altogether. Change-Id: I2cfb2310543902b7da46cb15a76e2da317eaed7d
2017-07-10Add pseudo-random bit sequence generator to libosmcooreHarald Welte1-0/+1
These PRBS sequences are specified in ITU-T O.150. They are typically used as test data to be transmitted for BER (bit error rate) testing. Change-Id: I227b6a6e86a251460ecb816afa9a7439d5fb94d1