OpenBSC

openbsc@lists.osmocom.org

9 participants
4171 discussions

[PATCH 0/1] pysim: make random seed function python3 compatible

by Jeremy Herbert

Currently the random seed function _digits is not python3 compatible as it passes a unicode string to the sha1 function. It generates the following exception: Using PC/SC reader interface Card programming failed with an execption: ---------------------8<--------------------- Traceback (most recent call last): File "./pySim-prog.py", line 718, in <module> rc = process_card(opts, first, card_handler) File "./pySim-prog.py", line 643, in process_card cp = gen_parameters(opts) File "./pySim-prog.py", line 342, in gen_parameters iccid += _digits(opts.secret, 'ccid', ml, opts.num) File "./pySim-prog.py", line 228, in _digits s = hashlib.sha1(secret + usage + '%d' % num) TypeError: Unicode-objects must be encoded before hashing ---------------------8<--------------------- This patch fixes this problem. Jeremy Herbert (1): make random seed function python3 compatible pySim-prog.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 2.25.1

4 years, 10 months

libosmocore: macOS support?

by Ludovic Rousseau

Hello, I try to build utils/osmo-sim-test.c on macOS. For that I need to build the complete libosmocore project. I already patched/hacked some source code file to make them compile on macOS but now the compiler fails on src/vty/cpu_sched_vty.c because cpu_set_t is Linux-specific. The problem is that src/vty/cpu_sched_vty.c contains *a lot* of use of cpu_set_t usage. I am pretty sure utils/osmo-sim-test.c will not need the functions defined in cpu_sched_vty.c. Is it possible to build utils/osmo-sim-test.c without building the complete libosmocore project? Any interest in macOS support (even partial & unofficial support)? Yes, the easiest option is to use Linux. But my main computer uses macOS. And I like challenges :-) Regards, -- Dr. Ludovic Rousseau

4 years, 10 months

E1 line debug L1/L2

by Ivan Babanov

Hello all, Brief question. Is it possible to debug E1 line by connecting it to the 2nd port of the same NIC making a wired loop? Is it enough to open->ioctl->read from /dev/dahdi/channel to get a stream of LAPD SABME messages transmitted by BSC? A bit more details for those interested I'm still trying to bring up BTS Nokia Flexi with OSMO-BSC. I'm using an E1 card Digium TE405P on the server side. OSMO-BSC is connected with Nokia BTS via a single E1 line. Looks like on Level1 everything is ok because BTS can detect the link and raise an alarm if the wire is getting disconnected. I can observe some data from timeslots on BTS side and if some channel is configured as D-Channel in /etc/dahdi/system I see transmission of block "01111110". But the problem is that LAPD link is not establishing. I can't find any tries on BTS side and BSC does not receive anything from BTS, just set of SABME messages in PCAP file. T200 expires and so on. I tried various T200 values. So, now it looks for me like L1 does not receive anything from L2 on BSC side and nothing is transmitted over the wire to BTS. dahdi_tool shows status "OK" So, my nearest plan to check data transmission over wired loopback. Thank you Babanov Ivan

4 years, 10 months

Osmocom Phone forcing encryption

by Radiarisainana Sitraka

Hello,i would like to ask if it's possible to forcing the encryption of osmcom phone like A5/1 or A5/2 or A5/3? How to process it? Chears,

4 years, 10 months

Application specific VTY attributes

by Vadim Yanitskiy

Hi Philipp, while reading your comments to: https://gerrit.osmocom.org/c/osmo-bsc/+/19670 https://gerrit.osmocom.org/c/osmo-mgw/+/20250 I realized that it would be better to discuss here. My initial idea was that the absence of attributes (in the command definition and thus in the VTY reference) implicitly indicates that a given VTY command in the 'config' node comes into effect immediately. This way we would only need to add attributes to commands requiring program restart or reestablishment of some link(s) / connection(s). However, in some applications *most* of the commands may require full program restart. Or the opposite: most commands may apply immediately. Adding same attributes to every command is annoying, so I came up with a concept of default 'applies when' policy: what if we add a new field to 'struct cmd_node' indicating default attributes of all commands belonging to it? struct cmd_node foo_node = { .node = FOO_NODE, .prompt = "%s(config-net)# ", .vtysh = 1, .usrattr = (1 << FOO_VTY_ATTR_RESTART_FULL), // (!) }; This way a DEFUN() command definition would inherit foo_node.usrattr, and a DEFUN_USRATTR() command definition would override it. dexter wrote: > I just wonder if there could be a VTY_ATTR_RESTART_FULL predefined in > libosmore. Almost any of the osmo program will need it. Maybe also an > VTY_ATTR_RESTART_IMMEDIATE? ACK. I think they could be even moved to generic attributes: /*! Attributes (flags) for \ref cmd_element */ enum { CMD_ATTR_DEPRECATED = (1 << 0), CMD_ATTR_HIDDEN = (1 << 1), CMD_ATTR_APPLY_IMMEDIATE = (1 << 2), CMD_ATTR_APPLY_FULL_RESTART = (1 << 3), }; dexter wrote: > Maybe we could have some standard letters defined in libosmocore > for standard situations: > F = Full restart required > I = Applied Immediately ACK. We can also agree that generic (pre-defined) attributes use upper case letters, while the application specific ones use lower case? What do you think about these ideas? If you agree, and nobody has any objections, I can quickly implement them in libosmocore. Would be also nice to know what other developers think. Neels, Harald, Pau, Daniel? Best regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

4 years, 10 months

gerrit upgade / new syntax for push to topics

by Harald Welte

Dear all, I did a major upgrade from the (unsupported) 2.16.x gerrit version to the latest 3.2.x series. For a detailed list of changes, please see the documentation / changelog. At least one change affects our day-to-day usage: How to push to a 'tpopic'. While in the past we would have done something like git push gerrit HEAD:refs/for/master/fr we now need to write git push gerrit HEAD:refs/for/master%topic=fr Don't ask me why that change was made... Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 years, 10 months

libosmocore stderr log performance / blocking

by Harald Welte

Hi! >From time to time we've been discussing logging related stalling of osmocom programs, particularly in the context of the stderr log target. In general, when we log to stderr, we perform a blocking, buffered write. So any slow output on stderr will slow down the entire osmocom program. I've taken some time to play with this using bpftrace and usdt (static userspace probes) in order to determine the latency of log statements in osmocom programs. My test program doesn't do anything else but an endless LOGP() of verying length (from 1..512 characters). It was executed on a Lenovo Thinkpad X260 (i7-6600U, 16GB RAM, SATA SSD with btrfs on top of dm-crypt). I've compared * launching the program in uxterm * launching the program in gnome-terminal * launching the program in screen (detached) * launching the program in screen (attached; printing via uxterm) * launching the program with 2>/dev/null * launching the program with 2>/file/on/btrfs/on/ssd * launching the program from systemd (with journald) * replacing stderr logging with gsmtap log target (without wqueue) The resulting histograms of the time spent for writing the logs are below. The git repo containing the test program, the libosmocore usdt patch and the bpftrace program can be found at git://git.osmocom.org/laforge/osmo-logbench.git == launching the program in uxterm @usecs: [2, 4) 30 | | [4, 8) 199963 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 82294 |@@@@@@@@@@@@@@@@@@@@@ | [16, 32) 6897 |@ | [32, 64) 1649 | | [64, 128) 57 | | [128, 256) 221 | | [256, 512) 8588 |@@ | [512, 1K) 13062 |@@@ | [1K, 2K) 144 | | [2K, 4K) 14 | | [4K, 8K) 3 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 28 | | == launching the program in gnome-terminal @usecs: [2, 4) 32387 |@@@ | [4, 8) 457668 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 44408 |@@@@@ | [16, 32) 466 | | [32, 64) 63 | | [64, 128) 9 | | [128, 256) 3 | | [256, 512) 53 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 1 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 39 | | [64K, 128K) 125 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 1 | | So we can see that gnome-terminal tends to be faster on most stderr-writes, but at the expens of introducing a few long-delays in the 32..128ms bucket. == launching the program in screen (detached) @usecs: [2, 4) 107649 |@@@@@@@@ | [4, 8) 699672 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 15262 |@ | [16, 32) 622 | | [32, 64) 5840 | | [64, 128) 42728 |@@@ | [128, 256) 14000 |@ | [256, 512) 68 | | [512, 1K) 3 | | [1K, 2K) 0 | | [2K, 4K) 1 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 50 | | * launching the program in screen (attached; printing via uxterm) @usecs: [2, 4) 2 | | [4, 8) 67887 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 30378 |@@@@@@@@@@@@@@@@@@@@@@@ | [16, 32) 58881 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ | [32, 64) 5188 |@@@ | [64, 128) 301 | | [128, 256) 61 | | [256, 512) 3963 |@@@ | [512, 1K) 7603 |@@@@@ | [1K, 2K) 407 | | [2K, 4K) 42 | | [4K, 8K) 20 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 1 | | so intrestingly, attaching the screen will significantly slow down stderr. It seems screen doesn't do sufficient buffering internally, or it blocks the osmocom program until not only it has updated its internal buffer, but also written to the output of the attached uxterm? == launching the program with 2>/dev/null @usecs: [1] 2202080 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [2, 4) 26966 | | [4, 8) 1107 | | [8, 16) 305 | | [16, 32) 10 | | [32, 64) 6 | | [64, 128) 0 | | [128, 256) 0 | | [256, 512) 1 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 153 | | unsurprisingly, this turns out to be rather fast == launching the program with 2>/file/on/btrfs/on/ssd @usecs: [2, 4) 2275464 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [4, 8) 265612 |@@@@@@ | [8, 16) 9384 | | [16, 32) 368 | | [32, 64) 4 | | [64, 128) 24 | | [128, 256) 3 | | [256, 512) 1 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 95 | | I've tried creating some load using a cocnrrent dd of the underlying block device, but couldn't make out any difference. I guess this shows how good the I/O subsystem is. Yes, some writes are slower than writing to /dev/null, but == launching the program from systemd (with journald) [2, 4) 1060607 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [4, 8) 75133 |@@@ | [8, 16) 724 | | [16, 32) 107 | | [32, 64) 8 | | [64, 128) 8 | | [128, 256) 0 | | [256, 512) 0 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 38 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 1 | | This is also pretty fast. There are some writes in the 64..128ms range, though. Those are likely going to cause problems in timing critical programs like osmo-bts, osmo-trx or osmo-mgw. * replacing stderr logging with gsmtap log target (without wqueue) @usecs: [4, 8) 776978 |@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@| [8, 16) 1771 | | [16, 32) 60 | | [32, 64) 0 | | [64, 128) 1 | | [128, 256) 0 | | [256, 512) 0 | | [512, 1K) 0 | | [1K, 2K) 0 | | [2K, 4K) 0 | | [4K, 8K) 0 | | [8K, 16K) 0 | | [16K, 32K) 0 | | [32K, 64K) 0 | | [64K, 128K) 0 | | [128K, 256K) 0 | | [256K, 512K) 0 | | [512K, 1M) 0 | | [1M, 2M) 0 | | [2M, 4M) 0 | | [4M, 8M) 0 | | [8M, 16M) 0 | | [16M, 32M) 0 | | [32M, 64M) 0 | | [64M, 128M) 0 | | [128M, 256M) 0 | | [256M, 512M) 0 | | [512M, 1G) 0 | | [1G, 2G) 0 | | [2G, 4G) 82 | | Ignoring the strange (and certainly bogus) artefacts in the 2..4s bin at the bottom, writes to the GSMTAP UDP socket tend to be quite fast, much faster than anything via stderr. Even faster than stderr-to-dev-null. == conclusion all-in-all, it looks not too bad at least on a relatively unloaded couple-of-years-old laptop. I would have expected worse. We can definitely see that there are non-neglectable delays created by both systemd/journald as well as gnome-terminal. One idea would be to play with setvbuf(3) to increase stderr buffering inside libc. The other idea would be to do our own buffering using osmo_wqueue() on the raw, unbuffered stderr-fd, which would then be in non-blocking mode and handled vis osmocom select. We'd have to add some kind of limit for that buffer in order to avoid OOM situations. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

4 years, 11 months

Fwd: OpenAirInterface releases 5G core network code

by Neels Hofmeyr

Possibly interesting to note this OAI announcement. Unfortunately none of the links are direct, but all of them are ugly tracking links. Also ads for facetwoogle. So I had to blank out a lot. Also interesting to note how they don't self-host, but rather spread their code across *both* hosted-gitlab and github. Also interesting how the From: address is a gmail one vs. the contact(a)openairinterface.org further below. In a massive herd effort, folks are fudging up the internet, no news there at least. ~N ----- Forwarded message from OpenAirInterface Software Alliance <osalliance5g(a)gmail.com> ----- Date: Fri, 25 Sep 2020 05:40:17 +0000 From: OpenAirInterface Software Alliance <osalliance5g(a)gmail.com> To: nhofmeyr(a)sysmocom.de Subject: OpenAirInterface releases 5G core network code X-Mailer: MailChimp Mailer - **CIDbb030ed5232925faf6b6** ** OpenAirInterface releases 5G core network code ------------------------------------------------------------ Dear Community, The OpenAirInterface Software Alliance is pleased to announce the release of the OAI 5G Core Network code. An initial set of features is already available and developments with a solid team are underway to build the rest of the 3GPP 5G SBA core. The project home page is here (<blanked-tracking-link>) and gives a good overview of the development phases and the roadmap. The AMF (<blanked-tracking-link>) and the SMF (<blanked-tracking-link>) code is available on GITLAB. While working to release the UPF code, we are working with the SPGW-U (<blanked-tracking-link>) on the GITHUB. A CI bench is already operational and in place. Any new features or developments introduced by community developers will automatically launch the CI pipeline and changes will only merge after having thoroughly been tested against third party testers and the OAI 5G RAN test benches. We cordially invite the community to contribute to the developments of the OAI 5G core network and reach out to contact(a)openairinterface.org for any questions and contribution proposals. The OpenAirInterface Software Alliance Team* [removing a ton of tracking links] ----- End forwarded message -----

4 years, 11 months

Structure alignment problems in PCUIFv9 and PCUIFv10

by Vadim Yanitskiy

Hi all, we seem to have problems with structure alignment in the new version of the PCUIF protocol: PCUIFv9: sizeof(struct gsm_pcu_if) -> 212; 212 % 4 == 0 PCUIFv10: sizeof(struct gsm_pcu_if) -> 1006; 1006 % 4 != 0 I think we would need to add/remove some padding. The question is whether we should make sure that all structures are aligned, or having the top level struct gsm_pcu_if aligned would be enough? Even in PCUIFv9 not all structures are properly aligned: sizeof(struct gsm_pcu_if_data_cnf_dt) -> 21; 21 % 4 -> 1, sizeof(struct gsm_pcu_if_rts_req) -> 13; 13 % 4 -> 1, sizeof(struct gsm_pcu_if_rach_ind) -> 15; 15 % 4 -> 3, sizeof(struct gsm_pcu_if_pag_req) -> 11; 11 % 4 -> 3, sizeof(struct gsm_pcu_if_susp_req) -> 11; 11 % 4 -> 3. I devise by 4 because the widest member is uint32_t in all cases. Kind regards, Vadim. -- - Vadim Yanitskiy <vyanitskiy at sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

4 years, 11 months

working dahdi config for Ericsson RBS 2000

by Ivan Babanov

Hello! Can anybody share a working /etc/dahdi/system.conf file? I'm trying to bring up RBS 2000 with osmo-bsc and I'm not sure that I have correct configuration. 1. Which signaling should be used? CAS? CCS? RBS? 2. There is the same thing with framing. hdb3? 3. parameter "dslot=1,4" pointed in RBS2000 wiki looks wrong. dahdi_cnf does not work with it at least now. Thank you Ivan

4 years, 11 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC