aboutsummaryrefslogtreecommitdiffstats
path: root/src
AgeCommit message (Collapse)AuthorFilesLines
2020-08-13Bump version: 1.3.0.173-51974 → 1.4.01.4.0Harald Welte4-4/+4
Change-Id: I4fc6dd4f727c8ff5a64865bbb87e1d9feb7c5174
2020-08-10vty: Introduce support to set cpu-affinity and scheduler policyPau Espin Pedrol2-1/+675
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-08-07src/Makefile.am: add conv_acc_neon_impl.h to EXTRA_DISTVadim Yanitskiy1-1/+1
Change-Id: I641c25f8aec249df43c781debfc967f07e221b9d
2020-08-06libomsocoding: NEON viterbi accelerationEric4-0/+497
configure flag required to enable this: --enable-neon Although autodetection according to __ARM_NEON would work because this is only defined if the fpu is neon neon-fp16 neon-vfpv3 neon-vfpv4 neon-fp-armv8 crypto-neon-fp-armv8 doing that would lead to a unknown performance impact, so it needs to be enabled manually. Speedup is about ~1.3-1.5 on a unspecified single core Cortex A9. This requires handling a special case for RACH with len 14 which is far too short for neon and would actually incur a performance penalty of 25%. Related: OS#4585 Change-Id: I58ff2cb4ce3514f43390ff0a2121f81e6a4983b5
2020-08-06osmo_sock_init2: improve support for AF_UNSPECAlexander Couzens1-14/+78
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-06gsm 12.21: add osmocom specific NM_ATT_OSMO_NS_LINK_CFGAlexander Couzens1-0/+1
The sysmobts uses the same OML attributes as IP.access. Because the IP.access attribute only supports IPv4 as NSVC configuration, add an own attribute. Change-Id: Ic261bc43a07fa741b97a9c6ec5a9ed6f5ecae588
2020-08-04Gb/BSSGP: replace hardcoded Tx into NS library by a callbackAlexander Couzens6-23/+51
Add bssgp_ns_send callback() to set the transmission path into the NS library. This allows to use the Gb implementation with the old NS and the new upcoming NS implementation. Users of the old NS implementation don't have to set the callback as the default is the old NS implementation. Only users of the new NS implementation need to set the callback and the callback data. Change-Id: I3a498e6a0d68b87fed80c64199b22395796761b4
2020-08-02i460: Fix bit- and subslots ordering of I.460 mux + demuxHarald Welte1-27/+32
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-5/+5
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-08-02i460: Add back-pointer from sub-channel to timeslotHarald Welte1-0/+1
A user may want to walk back from a sub-channel to the timeslot to which it belongs. Change-Id: Id6e5e208c5daa63fd23ac719d62314622b5d0ed9
2020-08-02i460_mux: add callback to notify empty tx queuePhilipp Maier1-3/+11
There is no way for the API user to know if the TX queue of the multiplexer runs empty. However, this is criticil since an empty TX queue will cause dropout of a TRAU frame, which can have quite severe effects to the receiving end. Lets add a callback that allows the APU user to insert appropiate idle frames or silent frames into the queue before it runs empty. Change-Id: I88a87724235fe50d55ce6215bb385c044072226e Related: OS#2547
2020-08-02bits.c: Use faster look-up-table approach for osmo_revbytebits_{buf,u8}Harald Welte1-26/+32
Benchmarking has shown that a look-up table based approach is much faster than the arithmetic approach we used so far. This is from a Core i7-6600U: 10 bytes, 1 iterations: flip=379, revb=5491; revb = 1448 % 10 bytes, 10 iterations: flip=728, revb=1517; revb = 208 % 10 bytes, 100 iterations: flip=2952, revb=9305; revb = 315 % 10 bytes, 1000 iterations: flip=26305, revb=90953; revb = 345 % 100 bytes, 1 iterations: flip=468, revb=1093; revb = 233 % 100 bytes, 10 iterations: flip=2634, revb=7418; revb = 281 % 100 bytes, 100 iterations: flip=23666, revb=70718; revb = 298 % 100 bytes, 1000 iterations: flip=237595, revb=900555; revb = 379 % 1024 bytes, 1 iterations: flip=3417, revb=11454; revb = 335 % 1024 bytes, 10 iterations: flip=33579, revb=92353; revb = 275 % 1024 bytes, 100 iterations: flip=555399, revb=1196228; revb = 215 % 1024 bytes, 1000 iterations: flip=3478271, revb=9227966; revb = 265 % 1048576 bytes, 1 iterations: flip=10189583, revb=7022193; revb = 68 % 1048576 bytes, 10 iterations: flip=19693347, revb=54389925; revb = 276 % 1048576 bytes, 100 iterations: flip=151308243, revb=454293151; revb = 300 % 1048576 bytes, 1000 iterations: flip=1390338439, revb=4429862642; revb = 318 % where 'revb' is the old arithmetic approach, and 'flip' the new look-up-table approach. In our usual cases of 100..1024 bytes in a single iteration, the old code takes 233..335% of the look-up table. Benchmarks on an Atom E6xx also show improvements except in one situation (a single iteration over one 1MB large buffer). 10 bytes, 1 iterations: flip=416, revb=9184; revb = 2207 % 10 bytes, 10 iterations: flip=1960, revb=4024; revb = 205 % 10 bytes, 100 iterations: flip=13624, revb=32408; revb = 237 % 10 bytes, 1000 iterations: flip=160656, revb=361784; revb = 225 % 100 bytes, 1 iterations: flip=3536, revb=4952; revb = 140 % 100 bytes, 10 iterations: flip=12960, revb=20912; revb = 161 % 100 bytes, 100 iterations: flip=122448, revb=215152; revb = 175 % 100 bytes, 1000 iterations: flip=1204928, revb=1647680; revb = 136 % 1024 bytes, 1 iterations: flip=12944, revb=23128; revb = 178 % 1024 bytes, 10 iterations: flip=126192, revb=239784; revb = 190 % 1024 bytes, 100 iterations: flip=1190184, revb=1491672; revb = 125 % 1024 bytes, 1000 iterations: flip=11865872, revb=15113872; revb = 127 % 1048576 bytes, 1 iterations: flip=16288272, revb=15925888; revb = 97 % 1048576 bytes, 10 iterations: flip=121957000, revb=157883384; revb = 129 % 1048576 bytes, 100 iterations: flip=1219264992, revb=1621265216; revb = 132 % 1048576 bytes, 1000 iterations: flip=12219520648, revb=15960035856; revb = 130 % Change-Id: I25029fe7e54c92979fb0119992fb8dc167e1536e
2020-07-31gsm_08_58: add missing RSL error cause codesPhilipp Maier1-0/+3
The define constants for the cause codes "BTS not equipped", "remote transcoder failure" and "notification overflow" are missing. Lets add them including value strings. Change-Id: Ic3e936da00bd256bae03867887851f1a4e30e218
2020-07-30vty: Don't match negative values on purely positive rangesPau Espin Pedrol1-0/+3
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 Pedrol1-6/+22
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-30gsm0411_{smc,smr}.c: Work around newlib bugHarald Welte2-2/+4
At least on Debian unstable, newlib is [currently?] buggy in that we need to include sys/types.h before including inttypes.h, otherwise PRIu64 is not defined. Change-Id: Ic1c9cdf66cfd5b82bd7e20eaaf05b10e6bdb675e Closes: OS#4686
2020-07-30i460_mux: correctly reset subchannelsPhilipp Maier1-7/+23
When a subchannel is deleted or created the initalization mainly consists of a memset over the wohle subchannel struct a message buffer initailization. However, when we delete a subchannel we also must take of the resetting of the related struct. Currently this is done with a memest. Unfortunately this creates not only a memory leak (there might be still items in the multiplexer tx queue) but also it makes the application crash when the message buffer is used the next time since the llist_head of the tx queue looses its initialization. Lets fix the memory leak problem and the message buffer problem and put the reset functionality in a single place. Change-Id: I937a9d4db95f44a860cd2c5dbb660dc1970b9a49
2020-07-28socket: osmo_sock_local_ip: correct doxygen commentAlexander Couzens1-1/+0
There is no parameter fd. Change-Id: I1e31fcbf40d8abf99214b87e70e867b5ab66bd75
2020-07-28bts_features: add feature BTS_FEAT_IPV6_NSVCAlexander Couzens1-0/+1
Previous both the IPA nanobts and the sysmobts has been using the IPv4 only OML attribute NM_ATT_IPACC_NS_LINK_CFG. A bts with BTS_FEAT_IPV6_NSVC supports IPv6 for NSVC (PCU<Gb>SGSN) using the new OML attribute NM_ATT_OSMO_NS_LINK_CFG. Change-Id: I9ef7949f66764b3c639e45eb440122e318da44a0
2020-07-28gprs_ns: fix typo in commentAlexander Couzens1-1/+1
Change-Id: Ie9d8decea18542cb0e1641dcb5fca5e4850910eb
2020-07-17stats: Add stats commands related to testingDaniel Willmann2-8/+53
* Allow to set the reporting interval to 0 for manual reporting * stats reset command to reset all statistics * stats report command to manually trigger statistics reporting Change-Id: I9febcb65650abfd538caedfbca77a787e66d517a Related: SYS#4877
2020-07-17stat_item: Add function to reset stat items and groupsDaniel Willmann1-0/+29
Change-Id: I80fc0ea8865ec4efdcd4c982e69d863275fd9919 Related: SYS#4877
2020-07-17rate_ctr: Add functions to reset rate counter (groups)Daniel Willmann1-0/+21
Change-Id: If2f806d044cd0fb6929dac44ef8f8a15941ffe9b Related: SYS#4877
2020-07-15vty: Avoid ultra-long multi-line strings cluttering talloc reportsHarald Welte1-0/+6
The talloc_asprintf() series includes an unconditional call to talloc_set_name_const(), turning the entire long constructed string into the name of the talloc object. That simply doesn't work when creating kilobytes-sized VTY reference strings including linefeeds. Let's add an explicit talloc_set_name_const() to prevent this. Change-Id: Ibd77684b88cc3572047daa98c9a6b9119fba041b Closes: OS#4668
2020-07-14fixup for gsm0808_create_common_id(): add API doc, use new MI APINeels Hofmeyr1-4/+17
Follows patch I353adc1aa72377f7d4b3336d2ff47791fb73d62c that was merged too soon. Applying my code review in form of this fixup patch. Change-Id: I979bca0c6aaa8fe4feddda922bd2e6c1cb49585b
2020-07-09Revert "gsmtap_makemsg_ex: NULL for unknown chan_type"Pau Espin Pedrol1-5/+1
Reverting due to being completely normal for some applications to submit usning this channel type when decoding/parsing failed and hence not being able to determine channel type. This reverts Change-Id Ib4147a33a75c3cf425c30da8b0678c7fba8a371d (commit 12f93be6073ed89055862baafbfe0e08e50ed17a.) Change-Id: I6ebaa89cc3422df1d7fd2365a6176cb2902d1c67
2020-07-04lapd_core: After calling into L3, check if the state has changedHarald Welte1-0/+4
While processing an I-frame we may deliver its payload to L3. After returning from L3 procesing, we run some additional code, assuming the LAPD/DL state has not changed meanwhile. However, if the application destroys the LAPD/DL meanwhile, our state might be NULL again, and in this state we should not perform any further action. This is one of the cases where synchronous in-line dispatch across various layers is hitting us. L3 should have an input queue, and only start processing after all L2 work has completed and we're about to go back to sleep in select(). Change-Id: I026b64503511002c13c0f4117648c366c48ecc62 Related: OS#1761 Closes: OS#4646
2020-07-03lapd_core: Ensure we always have some tailroomHarald Welte1-1/+2
At some points, e.g. when allocating message buffers from the Tx history, we used to allocate them exactly as large as the defined headroom plus the user data. This means that the underlying PH layer (E1 mostly) had no tailroom to add anything to the end of the message. Especially for DAHDI this is a problem, as we need to make space for two more bytes of frame check sequence (FCS). So let's simply make sure we always have some extra space at the end of such buffers. Change-Id: Id362ce131157c7513d744b0248c7f78fb75c590c Related: OS#4644
2020-06-26gprs_ns: Set sockaddr_in.sin_family for persistent NSVCsHarald Welte1-0/+1
We cannot just set sockaddr_in.sin_addr + sin_port, we also must initializa sin_family. The reason this has worked so far is because we probably always first received a NS packet from the peer, rather than being the first one to send. Change-Id: I6cefc2cd5516c7a4c01a2cc040afca454e59dd57 Related: OS#4629
2020-06-26gprs_bssgp: Add bssgp_tx_bvc_reset2()Harald Welte2-2/+7
If a BVC-RESET is sent from SGSN, there must not be a cell ID IE included. See "Note 1" of TS 48.018 Section 10.4.12. Change-Id: I11d4e70d510265b9c09dffccdab10b3f0816715a
2020-06-24api comment: fix example of osmo_mobile_identity_encode_msgbNeels Hofmeyr1-1/+2
The previous example showed a type == IMSI while setting a TMSI value. Rather show how to encode IMSI digits. Change-Id: I41af6bf0d61443465172123297b1228584d791d6
2020-06-21gsm0808: Add gsm0808_create_common_id()Harald Welte2-0/+43
This function encodes a GSM 08.08 / 48.008 "Common ID" message. Change-Id: I353adc1aa72377f7d4b3336d2ff47791fb73d62c Related: OS#2969
2020-06-21bts_features.h: Introduce BTS_FEAT_PAGING_COORDINATIONHarald Welte1-0/+1
This feature indicates if the given BTS supports paging coordination, that is the transmission of CS paging (received on Abis) to be sent via PACCH/PCU in PS domain fro MS with active TBF. Change-Id: Ifb2e83eaf05dd36e5b203ed2de1a74864b039e38 Related: OS#2406
2020-06-16add osmo_mobile_identity APINeels Hofmeyr3-7/+526
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 Welte7-658/+128
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 Hofmeyr7-128/+658
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-12osmo_bcd2str: also validate start_nibble parameterNeels Hofmeyr1-1/+1
If start_nibble were passed negative, we'd end up accessing invalid memory. Safeguard against that. Change-Id: Ied3c1e02c3a01d868e08195cbd8dfa52d2c19ac3
2020-06-10add gsm23236: MSC pooling: TMSI and NRI utility functionsNeels Hofmeyr3-1/+578
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-1/+11
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-06-08lapd_core: Fix log line being about LAPD and not LAPDmHarald Welte1-1/+1
Change-Id: I92c8a9752e88164eedffb9f9a081288458f6eadb
2020-06-08lapd/lapdm: print user-defined string name instead of (dl=%p)Harald Welte3-318/+285
At the moment we print the pointer address to identify the log lines belonging to a specific connection. Since pointer addresses are difficult to work with, a human readable ID should be printed instead. e.g. "This is LAPD instance for SAPI3 on bts0/trx1/ts5/lchan3" Change-Id: Ie6742843fff809edffcac24c4dce4edf66bc71be Closes: OS#1938
2020-06-08NS: replace use of gprs_nsvc_create() with gprs_nsvc_crate2()Harald Welte3-12/+6
Change-Id: I2b10e1707b0976b685d1c14016481d5565888150
2020-06-08NS: Optionally disable NS-{RESET,BLOCK,UNBLOCK} when using UDP/IPHarald Welte2-24/+55
3GPP TS 48.016 is quite clear in that no NS-{RESET,BLOCK,UNBLOCK} procedures shall be used over an IP based transport. They are only for use in Frame Relay based transport. However, as libosmogb was first developed against ip.access nanoBTS, and their Gb implementation mandates those procedures, we unconditionally implemented those procedures back then. Let's give the user the option of disabling this behavior to become more spec compliant (and interoperate with more other vendors out there). Change-Id: Ic4eba1b4dcbeac00f5879db295e0a9f1a50f71d8
2020-05-28Implement ITU-T I.460 multiplex / demultiplexHarald Welte3-1/+371
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-26fix osmo_mi_name_c() to always return talloced strings, via osmo_mi_name_buf()Neels Hofmeyr1-3/+5
Fix osmo_mi_name_buf() to snprintf() into the buf in *all* cases. osmo_mi_name_c() is implemented via osmo_mi_name_buf(), which returns compile-time string constants in special cases. That means that osmo_mi_name_c() does return non-allocated strings in these special cases. The caller of functions like osmo_mi_name_c() must always be able to rely on getting a talloced string, or run a danger of deallocating const pointers. Change-Id: I623959f01b72642bcdd18508097c5c405c59f6f1
2020-05-26api doc: clarify 'returns' of gsm48_mi_to_string()Neels Hofmeyr1-2/+4
Change-Id: I81646ff8284061a60c208bd8f9233f66c3e410f8
2020-05-20gsmtap_makemsg_ex: NULL for unknown chan_typeOliver Smith1-1/+5
Related: osmo-bts Ic22ab71e520ab44429a93724250d349d16250801 Change-Id: Ib4147a33a75c3cf425c30da8b0678c7fba8a371d
2020-05-18enable vty xml dumping to stdoutNeels Hofmeyr1-25/+60
Allow dumping the VTY XML reference (for generating manuals) to a normal FILE* stream instead of a vty output buffer. We currently generate the VTY reference by starting the client program, connecting to the VTY telnet and dumping the reference. That is weirdly convoluted, especially since there has to be a valid config file that successfully starts up a minimal set of external links before the reference can be generated. IMO we should have dumped the XML reference to stdout from the start, and never to a VTY session. With this patch, it is trivial to generate the XML VTY reference by a commandline switch. The client program will set up the entire VTY, and immediately after parsing the cmdline options but before parsing a config file, just dumps the reference and doesn't even start establishing local ports. That would allow generating the XML reference on the fly during the build process of the manuals, without the need of a docker container or somesuch. A first implementation of such a commandline switch is `osmo-bsc -X`, added in I316efedb2c1652791434ecf14a1e261367cd2fb7 This patch jumps through a bit of a hoop to still allow dumping to a VTY buffer without code dup, to still allow dumping the XML reference through telnet VTY, until all our programs have implemented an -X switch (TM). Change-Id: Ic74bbdb6dc5ea05f03c791cc70184861e39cd492
2020-05-17gsm0808: Implement helper functions for CONFUSION BSSMAP message decoding.Alexander Chemeris2-0/+40
Also add a test for an actual CONFUSION message parsing. Change-Id: If8afd2d096fb66c6c2f255a08fc1129de3d09cec
2020-05-15libosmogsm: add Doxygen docs for gsm0502_hop_seq_gen()Harald Welte1-1/+10
This is basically I16d5190b3cdc997c5609b52d41203f10264b017c. Change-Id: Ife660f00d7a6d3b874ab2e59e34dca2109fa82d8 Related: OS#4546
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-26 05:52:56 +0000