OpenBSC September 2020

openbsc@lists.osmocom.org

14 participants
15 discussions

by Martin Nagy

Hi all, After buying a super Sim Kit (16 in 1) from China, I tried the reader (green PCB inside a blue transparent plastic case with a blue LED) and SIM (identified as a fakesupersim) with pysim tool. However i am getting the following error: /pySim-prog.py -n 26C3 -c 49 -x 262 -y 42 -z 1234 -j 1 -t auto Insert card now (or CTRL-C to cancel) Autodetected card type fakemagicsim Generated card parameters : > Name : 26C3 > SMSP : e1ffffffffffffffffffffffff058100945555ffffffffffff000000 > ICCID : 8949262427518313026 > MCC/MNC : 262/42 > IMSI : 262422461512085 > Ki : 7b74741a1ee14337ec23f9ab92a13648 > OPC : ccd867d60797d8d45354a51b3ef568ff Programming ... Traceback (most recent call last): File "./pySim-prog.py", line 530, in <module> card.program(cp) File "/home/nadicek/pysim/pysim/pySim/cards.py", line 231, in program self._scc.update_binary('6f30', hplmn + 'ff' * (tl-3)) File "/home/nadicek/pysim/pysim/pySim/commands.py", line 53, in update_binary return self._tp.send_apdu_checksw(pdu) File "/home/nadicek/pysim/pysim/pySim/transport/__init__.py", line 87, in send_apdu_checksw raise RuntimeError("SW match failed ! Expected %s and got %s." % (sw.lower(), rv[1])) RuntimeError: SW match failed ! Expected 9000 and got 9804. I checked mailing lists and haven’t found anybody who had similar problem with pysim. Also I have tried forcing different models of SIM, but nothing is working. Obviously I can remove this check from the script file (__init__.py in /pySim/transport), however somebody had a reason to put such condition there. I would like to ask if it is safe to remove that line of code and the purpose of that line of code. Thanks a lot and best regards Martin

4 weeks, 1 day

Re: Help with sccp library

by mosbah abdelkader

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

2 months, 1 week

dynamic traffic channels

by Neels Hofmeyr

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

3 months, 3 weeks

Problem while running NIB on Open Cellular Base sation

by Brackley Casinga

Hi, My name is Brackley Cassinga Form DRC, we run a community network called pamoja net where we offer gsm services using osmocom open source software and OC Base station. Recently I have tried to install another base station as the same installed but I could not find any resource guiding through all the steps to take to run NIB on a base station. I'm currently running Ubuntu and I will appreciate if you could guide me on the installation of BSC,hlr,MSC , in order to run a basic gsm network. Thank you. Regards -- *Ir Brackley heshima Casinga **Pacifique* *CEO and Founder of kwanzatechnologie* KwanzaTechnologies ,GlobalElectronics +243977265291 | +243977265291 | Pcassinga(a)gmail.com/ brackley(a)ensemblepourladifference.org www.kwantechnologies.jimdosite.com <http://www.kwantechnologies.com/> | Skype: Brackley cassinga <https://webapp.wisestamp.com/#> Av Semliki N 43

1 year, 7 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, 11 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, 12 months

Re: Support for new SDR devices

by Harald Welte

Hi Xaver, [posting this on the mailing list, as it may be of interest to others] On Fri, Sep 11, 2020 at 04:55:35PM +0200, Xaver Zu wrote: > This is a dynamic linking. this is true, but the nature of the linking does not matter in terms of what creates the derivative work. > Is this a problem even if I do not distribute the resulting binary? The AGPL (contrary to the GPL) conditions start when users remotely interact with your software (See Section 13 of AGPLv3). This means even operating a network with remote users already means you need to provide the complete and corresponding source code to the entire work under AGPLv3, which is impossible if you have a proprietary dependency. So if you build the software, and you make sure that nobody but yourself every uses the resulting GSM network, you are fine. But as soon as any third party uses it, you would be putting yourself in the impossible position to providing the source code to a proprietary library. > I can simply add a warning to the file that the compiled program cannot be distributed. One might consider this a "further restriction" which by itself is a violation of AGPLv3: All other non-permissive additional terms are considered "further restrictions" within the meaning of section 10. [...] You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. But even beyond that: How many users do you think willread that warning in the source code vs. how many will simply run it (and possibly allow others to register). Even if you added a message to start-up, and to the user manual, I still would think many people don't look at that. I don't think we should distribute something that "tricks" people into committing license violations or putting them in an impossible position, legally speaking. > Is it a violation that someone assembles and uses it on their own machine? It is not a violation as long as they are they only person using the resulting GSM network (or using its VTY or its TRXC/TRXD interface). I would compare distributing source code like that to shipping a product that is almost impossible to use safely, but very easy to use in a [legally] unsafe way. > Is it a violation to even have sources and build instructions for it? Maybe not, but see above, I don't want to make it too easy for people to shoot themselves into their foot. > Can we agree to leave it as a starting point until someone will have the > time to do it using IPC? I'm very sorry (really), but we will not merge this code to the mainline osmo-trx code base on osmocom.org. Kind 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, 12 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC September 2020