OpenBSC October 2020

openbsc@lists.osmocom.org

17 participants
14 discussions

E1 line debug L1/L2
by Ivan Babanov 13 Oct '20

13 Oct '20

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 10

Osmocom Phone forcing encryption
by Radiarisainana Sitraka 10 Oct '20

10 Oct '20

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,

2 1

Application specific VTY attributes
by Vadim Yanitskiy 05 Oct '20

05 Oct '20

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 10

gerrit upgade / new syntax for push to topics
by Harald Welte 03 Oct '20

03 Oct '20

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)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC October 2020