From laforge at osmocom.org Tue Oct 1 11:14:17 2019 From: laforge at osmocom.org (Harald Welte) Date: Tue, 1 Oct 2019 13:14:17 +0200 Subject: DW-TV report on Rhizomatica, TIC and Osmocom/sysmocom In-Reply-To: <20190913190636.GF1669@nataraja> References: <20190913190636.GF1669@nataraja> Message-ID: <20191001111417.GD3529@nataraja> Hi all, On Fri, Sep 13, 2019 at 09:06:36PM +0200, Harald Welte wrote: > DW-TV has just released a video report on the community owned and operated > cellular networks within TIC, the Mexican partner of Rhizomatica. > > You can find the (Spanish only) video at > https://www.dw.com/es/telefon%C3%ADa-ind%C3%ADgena-en-defensa-del-derecho-a-la-comunicaci%C3%B3n/av-50416268 Thanks to Rhizomatica, the video has now been re-released on vimeo with English language subtitles: https://vimeo.com/363361602 Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From mychaela.falconia at gmail.com Tue Oct 1 16:31:00 2019 From: mychaela.falconia at gmail.com (Mychaela Falconia) Date: Tue, 1 Oct 2019 08:31:00 -0800 Subject: DW-TV report on Rhizomatica, TIC and Osmocom/sysmocom In-Reply-To: <20191001111417.GD3529@nataraja> References: <20190913190636.GF1669@nataraja> <20191001111417.GD3529@nataraja> Message-ID: On 10/1/19, Harald Welte wrote: > Thanks to Rhizomatica, the video has now been re-released on vimeo with > English language subtitles: https://vimeo.com/363361602 Unlike YouTube, Vimeo supports a static download option for some videos, but on this one it is disabled. Why? Does anyone have a statically downloadable version for those of us who cannot watch browser-tethered videos? M~ From axilirator at gmail.com Tue Oct 1 17:36:02 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 2 Oct 2019 00:36:02 +0700 Subject: DW-TV report on Rhizomatica, TIC and Osmocom/sysmocom In-Reply-To: References: <20190913190636.GF1669@nataraja> <20191001111417.GD3529@nataraja> Message-ID: Hi Mychaela, this link works for me (checked with curl): https://gcs-vimeo.akamaized.net/exp=1569957669~acl=%2A%2F1494861524.mp4%2A~hmac=9a269639585ea28161d4a777a2b2cddd918297161e80fd7cd691028061a1ff49/vimeo-prod-skyfire-std-us/01/2672/14/363361602/1494861524.mp4 With best regards, Vadim Yanitskiy. From laforge at osmocom.org Tue Oct 1 21:00:11 2019 From: laforge at osmocom.org (Harald Welte) Date: Tue, 1 Oct 2019 23:00:11 +0200 Subject: DW-TV report on Rhizomatica, TIC and Osmocom/sysmocom In-Reply-To: References: <20190913190636.GF1669@nataraja> <20191001111417.GD3529@nataraja> Message-ID: <20191001210011.GE7812@nataraja> Hi Mychaela, On Tue, Oct 01, 2019 at 08:31:00AM -0800, Mychaela Falconia wrote: > On 10/1/19, Harald Welte wrote: > > Thanks to Rhizomatica, the video has now been re-released on vimeo with > > English language subtitles: https://vimeo.com/363361602 > > Unlike YouTube, Vimeo supports a static download option for some > videos, but on this one it is disabled. Why? Does anyone have a > statically downloadable version for those of us who cannot watch > browser-tethered videos? I suppose you are aware of the youtube-dl command-line utility? It downloads virtually anything, whether youtube or vimeo or hundreds of other websites. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at osmocom.org Fri Oct 11 10:47:27 2019 From: laforge at osmocom.org (Harald Welte) Date: Fri, 11 Oct 2019 12:47:27 +0200 Subject: gerrit update / reply by e-mail Message-ID: <20191011104727.GP3578@nataraja> Dear Osmocom community, I just upgraded gerrit to 2.16.12, the latest version of the 2.16 branch, still featuring the option to use the old UI. While reading through change logs, I just discovered that one can actually send responses to gerrit e-mail notifications, and those changes will end up creating new comments int he gerrit database/UO: http://gerrit-documentation.storage.googleapis.com/Documentation/2.14/intro-user.html#reply-by-email Maybe that's useful for some of you here... Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Thu Oct 17 21:51:20 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 17 Oct 2019 23:51:20 +0200 Subject: optional steps in ttcn3 interleave Message-ID: <20191017215120.GA14183@my.box> Hi, I've got the problem that optional steps seem to not be possible in 'interleave' statements. What I want: accept either BSSMAP Assignment Request or Iu Rab Assignment: interleave { [g_pars.ran_is_geran] BSSAP.receive(tr_BSSMAP_AssignmentReq) { ... }; [not g_pars.ran_is_geran] BSSAP.receive(tr_RANAP_RabAssReq(rab_sml)) { ... }; [] other {...}; [] complex {...}; [] steps {...}; } But that's illegal syntax; works for altsteps, but not for interleave. Even in the language spec, there is no token between the interleave braces. How unfortunate. Options I am considering: 1) moving the optionals into a separate altstep var default assignment; if (g_pars.ran_is_geran) { assignment := activate(as_BSSMAP_assignment()); } else { assignment := activate(as_RANAP_assignment()); } interleave { [] other {...}; [] complex {...}; [] steps {...}; } deactivate(assignment); or 2) blatant code dup if (g_pars.ran_is_geran) { interleave { [] BSSAP.receive(tr_BSSMAP_AssignmentReq) { ... }; [] other {...}; [] complex {...}; [] steps {...}; } } else { interleave { [] BSSAP.receive(tr_RANAP_RabAssReq) { ... }; [] other {...}; [] complex {...}; [] steps {...}; } } 3) boolean dance and break var boolean done1 := false; var boolean done2 := false; var boolean done3 := false; var boolean done4 := false; interleave { [] BSSAP.receive(tr_BSSMAP_AssignmentReq) { if (not g_pars.ran_is_geran) { setverdict(fail); } done1 := true; if (done1 and done2 and done3 and done4) { break; } }; [] BSSAP.receive(tr_RANAP_RabAssReq(rab_sml)) { if (g_pars.ran_is_geran) { setverdict(fail); } done1 := true; if (done1 and done2 and done3 and done4) { break; } }; [] other { done2 := true; if (done1 and done2 and done3 and done4) { break; } }; [] complex { done3 := true; if (done1 and done2 and done3 and done4) { break; } }; [] steps { done4 := true; if (done1 and done2 and done3 and done4) { break; } }; } 1) is bad because the interleave may exit without having seen an actual assignment at all. Also interacting with local variables isn't allowed in this kind of altstep. Also if there are more optional parts, the side-altsteps become hard to understand. Also the altstep needs to "repeat;" so that it doesn't break the outer interlave, which makes us accept more than one of the optional message. 2) is bad because it is code dup. 3) is bad because of code clutter that is likely to cause weird failure when the interleave is modified. I am already using this method somewhere... but. Are there other options?? Why is this coming up? I am preparing for a change in osmo-msc during call setup, and I am making the ttcn3 call testing more flexible and cleaning things up. As a result, some more tests are moved to using f_mo_call_establish() instead of copy-pasting it. That makes some Iu tests go from passed to FAIL, because the f_mo_call_establish() is unable to do the above distinguishing between BSSMAP and IU. We can also choose to ignore those Iu tests that start to fail. But I am curious whether there is a way for optional interleave steps in ttcn3. Thanks, ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at osmocom.org Fri Oct 18 09:06:30 2019 From: laforge at osmocom.org (Harald Welte) Date: Fri, 18 Oct 2019 11:06:30 +0200 Subject: optional steps in ttcn3 interleave In-Reply-To: <20191017215120.GA14183@my.box> References: <20191017215120.GA14183@my.box> Message-ID: <20191018090630.GJ4389@nataraja> Hi Neels, On Thu, Oct 17, 2019 at 11:51:20PM +0200, Neels Hofmeyr wrote: > I've got the problem that optional steps seem to not be possible in > 'interleave' statements. yes, they are not. The TTCN-3 core language specification explicitly mandates that the guard expression in 'interleave' must be empty. I guess it was done to simplify the transformation from interleave to nested alt (that's what supposedly happens internally) is simpler - or maybe to guarantee it is possible to solve the resulting logic based on nested alt statements at all? Another sad thing about interleave is that there's no equivalend to altsteps. > What I want: accept either BSSMAP Assignment Request or Iu Rab Assignment: > > interleave { > [g_pars.ran_is_geran] BSSAP.receive(tr_BSSMAP_AssignmentReq) { ... }; > [not g_pars.ran_is_geran] BSSAP.receive(tr_RANAP_RabAssReq(rab_sml)) { ... }; > [] other {...}; > [] complex {...}; > [] steps {...}; > } why not simply have a "var template ..." that is assigned before and then use that variable instead of the template in the receive statement? Probably because it's separate TTCN-3 types (BSSAP vs. RANAP)? I think I read that there's some kind of "ANY" type (called anytype). but have never used it, and I don't know if you can have a "var template anytype". Maybe worth a try? TTCN3_P.pdf contains a slide about it, important part seems to use the 'with extension anytype' part at the end of the module, listing the types. Or you could "cheat" and do something like [] BSSAP.receive((tr_BSSMAP_AssignmentReq, tr_RANAP_RabAssReq(rab_sml))) which would accept either of the two in both cases. Not exactly great as the condition would be fulfilled even if you receive BSSAP but are in a 3G scenario (or vice versa). > 1) moving the optionals into a separate altstep > > var default assignment; > if (g_pars.ran_is_geran) { > assignment := activate(as_BSSMAP_assignment()); > } else { > assignment := activate(as_RANAP_assignment()); > } > interleave { > [] other {...}; > [] complex {...}; > [] steps {...}; > } > deactivate(assignment); possible, and I would say very ttcn3-like > 2) blatant code dup > > if (g_pars.ran_is_geran) { > interleave { > [] BSSAP.receive(tr_BSSMAP_AssignmentReq) { ... }; > [] other {...}; > [] complex {...}; > [] steps {...}; > } > } else { > interleave { > [] BSSAP.receive(tr_RANAP_RabAssReq) { ... }; > [] other {...}; > [] complex {...}; > [] steps {...}; > } > } easy to read but probably less easy to maintain. > 3) boolean dance and break > > var boolean done1 := false; > var boolean done2 := false; > var boolean done3 := false; > var boolean done4 := false; god forbid. > Are there other options?? you could try to perform the manual conversion of interleave to nested ALT statements? Not sure if that's nicer than any of the other options. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at osmocom.org Fri Oct 18 09:13:51 2019 From: laforge at osmocom.org (Harald Welte) Date: Fri, 18 Oct 2019 11:13:51 +0200 Subject: optional steps in ttcn3 interleave In-Reply-To: <20191018090630.GJ4389@nataraja> References: <20191017215120.GA14183@my.box> <20191018090630.GJ4389@nataraja> Message-ID: <20191018091351.GK4389@nataraja> Hi Neels, On Fri, Oct 18, 2019 at 11:06:30AM +0200, Harald Welte wrote: > why not simply have a "var template ..." that is assigned before and then use that > variable instead of the template in the receive statement? Probably because it's > separate TTCN-3 types (BSSAP vs. RANAP)? I think I read that there's some kind of > "ANY" type (called anytype). but have never used it, and I don't know if you can have a > "var template anytype". Maybe worth a try? > > TTCN3_P.pdf contains a slide about it, important part seems to use the 'with extension anytype' part at the end of the module, listing the types. I just gave it a very simple try, and at least "var template anytype foo" still compiles, as do statements like "foo.PDU_BSSAP := tr_BSSMAP_..." and "foo.RANAP_PDU := tr_RANAP_...". So it should be possible to construct a receive-template variable this way. I haven't used it from an interleave PORT.receive() but don't see why it shouldn't work. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From jstjep00 at gmail.com Sat Oct 12 09:06:07 2019 From: jstjep00 at gmail.com (=?UTF-8?Q?Josip_Stjepanovi=C4=87?=) Date: Sat, 12 Oct 2019 11:06:07 +0200 Subject: libosmovty version is UNKNOWN Message-ID: Hello, Unfortunately I have come up to the problem that I can't google myself and my friends can't help with either. Maybe it has something to do with readme saying that libsomocore in the git I pulled isn't for system wide installation but when I make the osmocombb src then it spits out this: configure: error: Package requirements (libosmovty >= 0.10.0) were not met: Requested 'libosmovty >= 0.10.0' but version of Osmocom VTY Interface Library is UNKNOWN Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables LIBOSMOVTY_CFLAGS and LIBOSMOVTY_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. Makefile:94: recipe for target 'host/layer23/Makefile' failed make: *** [host/layer23/Makefile] Error 1 If I need to get a different libosmocore could you provide it to me? Thank you -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Sun Oct 20 16:12:09 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 20 Oct 2019 23:12:09 +0700 Subject: libosmovty version is UNKNOWN In-Reply-To: References: Message-ID: Hello Josip, > If I need to get a different libosmocore could you provide it to me? You need generic libosmocore for building the host utilities of OsmocomBB. Please see: https://osmocom.org/projects/libosmocore/wiki/Libosmocore. OsmocomBB ships a local copy, which is only needed to build the firmware. That copy is quite dated, and shall never be installed system wide. Could you attach output of the following commands please? $ pkg-config --libs libosmovty $ ldconfig -v | grep osmo With best regards, Vadim Yanitskiy. From grgrehreher at gmail.com Sun Oct 20 16:35:53 2019 From: grgrehreher at gmail.com (ah med) Date: Sun, 20 Oct 2019 17:35:53 +0100 Subject: unable to install osmo-bts Message-ID: HI Hope that you are doing well! system : Ubuntu 18.04.3 LTS when trying to start the osmocom CNI using the osmo-all script i will get : ./osmo-all.sh restart > + systemctl restart osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn > osmo-stp osmo-bsc osmo-hnbgw osmo-bts-sysmo osmo-pcu > Failed to restart osmo-bts-sysmo.service: Unit osmo-bts-sysmo.service not > found. > so seems that osmo-bts it's not installed,wjen i try to install it will get : sudo apt-get install osmo-bts > > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: > osmo-bts : Depends: libosmoabis5 (>= 0.3.2+20151106git86fc3c8) but it is > not going to be installed > E: Unable to correct problems, you have held broken packages. and when trying to install libosmoabis5 i will get : sudo apt-get install libosmoabis5 > The following packages will be REMOVED: > libosmo-gsup-client0 libosmoabis6 osmo-bsc osmo-bts-trx osmo-bts-virtual > osmo-hlr osmo-msc osmo-sgsn > The following NEW packages will be installed: > libosmoabis5 > 0 upgraded, 1 newly installed, 8 to remove and 0 not upgraded. > thanks in advnace! -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Mon Oct 21 06:16:08 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 21 Oct 2019 13:16:08 +0700 Subject: libosmovty version is UNKNOWN In-Reply-To: References: Message-ID: Hi, > libosmocore.so.4 -> libosmocore.so.4.0.0 > libosmovty.so.0 -> libosmovty.so.0.0.0 it looks like you have installed a very old libosmocore. You need to remove it (make uninstall) and install the recent one from the upstream (not from OsmocomBB). With best regards, Vadim Yanitskiy. From pespin at sysmocom.de Mon Oct 21 08:12:23 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 21 Oct 2019 10:12:23 +0200 Subject: unable to install osmo-bts In-Reply-To: References: Message-ID: <978baf88-13f8-cce9-ff23-e062a0f2159b@sysmocom.de> Hi, where did you get that osmo-all.sh from? If you are using Ubuntu it means most probably you are not running under under a sysmobts and hence don't need osmo-bts-sysmo in there (perhaps osmo-bts-trx + osmo-trx?). Make sure you are using apt osmocom repositories [1]. Make sure you remove all osmocom packages and install them again to avoid collisions between both repositories. [1] https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds -- - Pau Espin Pedrol 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 From nhofmeyr at sysmocom.de Mon Oct 21 14:17:16 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 21 Oct 2019 16:17:16 +0200 Subject: unable to install osmo-bts In-Reply-To: References: Message-ID: <20191021141716.GB25837@my.box> On Sun, Oct 20, 2019 at 05:35:53PM +0100, ah med wrote: > ./osmo-all.sh restart > > + systemctl restart osmo-hlr osmo-msc osmo-mgw osmo-ggsn osmo-sgsn > > osmo-stp osmo-bsc osmo-hnbgw osmo-bts-sysmo osmo-pcu curious, osmo-all.sh is a script I wrote for myself at some point, apparently for running an entire core network on a physical sysmoBTS device. Normally there is no osmo-bts-sysmo process on your CNI host, of course. I wonder how you came across that script. You should probably look at https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box to get started (maybe use http://git.osmocom.org/osmo-dev net/* to build config) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From grgrehreher at gmail.com Tue Oct 22 08:43:41 2019 From: grgrehreher at gmail.com (ah med) Date: Tue, 22 Oct 2019 09:43:41 +0100 Subject: Bladerf X40 failure with osmo-trx-uhd Message-ID: after setting the osmo-bts-trx and osmo-trx-uhd and with a BLADERF X40 ,i just got this when running my network ! every other services like HLR,MSC...work perfectly and just the osmo-trx-uhd have some problems with the bladerf ! osmo-trx-uhd.service - Osmocom SDR BTS L1 Transceiver (UHD Backend) Loaded: loaded (/lib/systemd/system/osmo-trx-uhd.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2019-10-21 20:04:25 CET; 5min ago Process: 20384 ExecStart=/usr/bin/osmo-trx-uhd -C /etc/osmocom/osmo-trx-uhd.cfg (code=exited, status=1/FAILURE) Main PID: 20384 (code=exited, status=1/FAILURE) Oct 21 20:04:24 osmo-trx-uhd[20384]: -- setSampleRate(Rx, 0, 4.000000 MHz), actual = 4.000000 MHz Oct 21 20:04:24 osmo-trx-uhd[20384]: -- setSampleRate(Tx, 0, 4.000000 MHz), actual = 4.000000 MHz Oct 21 20:04:24 osmo-trx-uhd[20384]: Mon Oct 21 20:04:24 2019 DDEV <0002> UHDDevice.cpp:355 [tid=140004723987136] Unsupported device bladeRF Oct 21 20:04:24 osmo-trx-uhd[20384]: Mon Oct 21 20:04:24 2019 DMAIN <0000> osmo-trx.cpp:514 [tid=140004723987136] Failed to create radio device Oct 21 20:04:24 osmo-trx-uhd[20384]: Mon Oct 21 20:04:24 2019 DMAIN <0000> osmo-trx.cpp:485 [tid=140004723987136] Shutting down transceiver... Oct 21 20:04:24 osmo-trx-uhd[20384]: -- bladerf_close() Oct 21 20:04:25 systemd[1]: Stopping Osmocom SDR BTS L1 Transceiver (UHD Backend)... Oct 21 20:04:25 systemd[1]: osmo-trx-uhd.service: Main process exited, code=exited, status=1/FAILURE Oct 21 20:04:25 systemd[1]: osmo-trx-uhd.service: Failed with result 'exit-code'. Oct 21 20:04:25 systemd[1]: Stopped Osmocom SDR BTS L1 Transceiver (UHD Backend). I am using the systemd service file .all parts are installed using apt-get install via the latest builds!. by the way,the uhd_find_devices give the correct output! uhd_find_devices linux; GNU C++ version 7.3.0; Boost_106501; UHD_003.010.003.000-0-unknown [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; UHD_3.14.1.1-release -------------------------------------------------- -- UHD Device 0 -------------------------------------------------- Device Address: serial: 9e52d2c864bc9b191e8a3327a4b2a216 backend: libusb device: 0x01:0x0E driver: bladerf instance: 0 label: BladeRF #0 [9e52d2c8..a4b2a216] type: soapy bladeRF-cli -p Description: Nuand bladeRF Backend: libusb Serial: 9e52d2c864bc9b191e8a3327a4b2a216 USB Bus: 1 USB Address: 17 bladeRF> version bladeRF-cli version: 1.7.1-2018.12-rc3-2-ppabionic libbladeRF version: 2.2.0-2018.12-rc3-2-ppabionic Firmware version: 1.9.1 FPGA version: 0.10.2 SoapySDRUtil --probe="driver=bladerf" ###################################################### ## Soapy SDR -- the SDR abstraction library ## ###################################################### Probe device driver=bladerf [INFO] bladerf_open_with_devinfo() [WARNING @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1705] RX DC calibration table not found. Manual gain control will be used instead. [INFO @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1706] To enable AGC, see "Generating a DC offset table" at https://github.com/Nuand/bladeRF/wiki/DC-offset-and-IQ-Imbalance-Correction [INFO] bladerf_get_serial() = 9e52d2c864bc9b191e8a3327a4b2a216 [INFO] setSampleRate(Rx, 0, 4.000000 MHz), actual = 4.000000 MHz [INFO] setSampleRate(Tx, 0, 4.000000 MHz), actual = 4.000000 MHz [WARNING @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1705] RX DC calibration table not found. Manual gain control will be used instead. [INFO @ host/libraries/libbladeRF/src/board/bladerf1/bladerf1.c:1706] To enable AGC, see "Generating a DC offset table" at https://github.com/Nuand/bladeRF/wiki/DC-offset-and-IQ-Imbalance-Correction ---------------------------------------------------- -- Device identification ---------------------------------------------------- driver=bladeRF hardware=bladerf1 fpga_size=40 fpga_version=0.10.2 fw_version=1.9.1 serial=9e52d2c864bc9b191e8a3327a4b2a216 ---------------------------------------------------- -- Peripheral summary ---------------------------------------------------- Channels: 1 Rx, 1 Tx Timestamps: YES Registers: LMS Other Settings: * XB200 Transverter - bladeRF XB200 Transverter Board [key=xb200, default=disabled, type=string, options=(disabled, 50M, 144M, 222M, auto1db, auto3db, auto, custom)] * Sampling Mode - Internal = Via RX/TX connectors, External = Direct sampling from J60/J61 connectors [key=sampling_mode, default=internal, type=string, options=(internal, external)] * Loopback Mode - Enable/disable internal loopback [key=loopback, default=none, type=string, options=(none, firmware, bb_txlpf_rxvga2, bb_txlpf_rxlpf, bb_txvga1_rxvga2, bb_txvga1_rxlpf, rf_lna1, rf_lna2, rf_lna3)] * Reset Device - Reset the device, causing it to reload its firmware from flash. [key=reset, default=false, type=bool, options=(true, false)] * Erase the FPGA region of flash - Erase the FPGA region of SPI flash, effectively disabling FPGA autoloading. [key=erase_stored_fpga, default=false, type=bool, options=(true, false)] * Write FX3 firmware to flash - Write FX3 firmware to the bladeRF's SPI flash from the provided file path. This will require a power cycle to take effect. [key=flash_firmware, type=string] * Write to the FPGA region of flash - Write FPGA image to the bladeRF's SPI flash from the provided file path and enable FPGA loading from SPI flash at power on. [key=flash_fpga, type=string] * Clear out a firmware signature word in flash and jump to FX3 bootloader - The device will continue to boot into the FX3 bootloader across power cycles until new firmware is written to the device. [key=jump_to_bootloader, default=false, type=bool, options=(true, false)] * Load device's FPGA - Load device's FPGA from the provided file path. Note that this FPGA configuration will be reset at the next power cycle. [key=load_fpga, type=string] GPIOs: CONFIG, EXPANSION ---------------------------------------------------- -- RX Channel 0 ---------------------------------------------------- Full-duplex: YES Supports AGC: NO Stream formats: CS16, CF32 Native format: CS16 [full-scale=2048] Stream args: * Buffer Count - Number of async USB buffers. [key=buffers, units=buffers, default=32, type=int] * Buffer Length - Number of bytes per USB buffer, the number must be a multiple of 1024. [key=buflen, units=bytes, default=4096, type=int] * Num Transfers - Number of async USB transfers. Use 0 for automatic [key=transfers, units=bytes, default=0, type=int, range=[0, 32]] Antennas: RX Corrections: DC offset, IQ balance Full gain range: [-1, 60, 1] dB lna gain range: [0, 6, 3] dB rxvga1 gain range: [5, 30, 1] dB rxvga2 gain range: [0, 30, 3] dB Full freq range: [237.5, 3800] MHz RF freq range: [237.5, 3800] MHz Sample rates: [0.08, 10], [10, 20], [20, 40] MSps Filter bandwidths: [1.5, 28] MHz ---------------------------------------------------- -- TX Channel 0 ---------------------------------------------------- Full-duplex: YES Supports AGC: NO Stream formats: CS16, CF32 Native format: CS16 [full-scale=2048] Stream args: * Buffer Count - Number of async USB buffers. [key=buffers, units=buffers, default=32, type=int] * Buffer Length - Number of bytes per USB buffer, the number must be a multiple of 1024. [key=buflen, units=bytes, default=4096, type=int] * Num Transfers - Number of async USB transfers. Use 0 for automatic [key=transfers, units=bytes, default=0, type=int, range=[0, 32]] Antennas: TX Corrections: DC offset, IQ balance Full gain range: [17, 73, 1] dB txvga1 gain range: [-35, -4, 1] dB txvga2 gain range: [0, 25, 1] dB Full freq range: [237.5, 3800] MHz RF freq range: [237.5, 3800] MHz Sample rates: [0.08, 10], [10, 20], [20, 40] MSps Filter bandwidths: [1.5, 28] MHz [INFO] bladerf_close() -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Tue Oct 22 09:04:58 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 22 Oct 2019 16:04:58 +0700 Subject: Bladerf X40 failure with osmo-trx-uhd In-Reply-To: References: Message-ID: Hello, > osmo-trx-uhd and with a BLADERF X40 [...] > UHDDevice.cpp:355 [tid=140004723987136] Unsupported device bladeRF please see https://osmocom.org/projects/osmotrx/wiki/OsmoTRX#RF-Hardware-support. BladeRF is not supported by OsmoTRX, because nobody has implemented the corresponding interface so far. And even if you fool it by making BladeRF look like a pure UHD device (using Soapy or whatever), do not expect any positive experience from that setup. Patches adding _native_ support of BladeRF would be very much welcome! With best regards, Vadim Yanitskiy. From pespin at sysmocom.de Tue Oct 22 09:06:48 2019 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 22 Oct 2019 11:06:48 +0200 Subject: Bladerf X40 failure with osmo-trx-uhd In-Reply-To: References: Message-ID: <63849369-aa49-9582-a258-f3e27007a547@sysmocom.de> Hi, On 10/22/19 10:43 AM, ah med wrote: > Oct 21 20:04:24? osmo-trx-uhd[20384]: Mon Oct 21 20:04:24 2019 DDEV > <0002> UHDDevice.cpp:355 [tid=140004723987136] Unsupported device bladeRF osmo-trx-uhd BladeRF is currently unsupported device. Support for it needs to be added. Feel free to submit a patch in gerrit if you get it working correctly. -- - Pau Espin Pedrol 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 From nhofmeyr at sysmocom.de Wed Oct 23 21:12:28 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 23 Oct 2019 23:12:28 +0200 Subject: unable to install osmo-bts In-Reply-To: References: <20191021141716.GB25837@my.box> Message-ID: <20191023211228.GA9998@my.box> On Mon, Oct 21, 2019 at 05:37:51PM +0100, ah med wrote: > well,for the osmo-all.sh script,it can be found here under Running > examples : > > https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box Ha, completely forgot about that. I tweaked that wiki page a bit to be less of a pitfall to newcomers (hopefully). BTW, off-list, ah med wrote to us that he figured out to use osmo-trx and osmo-bts-trx but still struggles with the BladeRF. We asked him to come back on-list or visit IRC for further questions. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at osmocom.org Mon Oct 28 21:01:20 2019 From: laforge at osmocom.org (Harald Welte) Date: Mon, 28 Oct 2019 22:01:20 +0100 Subject: build2.osmocom.org hardware replacement Message-ID: <20191028210120.GK23009@nataraja> Hi all, during the past couple of days, there have been a high number of build failures due to 'illegal instruction'. I checked about a handful of them, and they all happened on build2.osmocom.org. On the machine nothing strange could be observed, i.e. no oopses or the like. Also, debsums didn't report any broken compiler binaries. I've taken the builds slaves offline and asked for the machine to be replaced (disks will be moved so no data loss expected). Let's hope that fixes it. If not, I guess a full re-install of OS + lxc's (via ansible) is up next. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at osmocom.org Mon Oct 28 22:02:21 2019 From: laforge at osmocom.org (Harald Welte) Date: Mon, 28 Oct 2019 23:02:21 +0100 Subject: build2.osmocom.org hardware replacement In-Reply-To: <20191028210120.GK23009@nataraja> References: <20191028210120.GK23009@nataraja> Message-ID: <20191028220221.GO23009@nataraja> On Mon, Oct 28, 2019 at 10:01:20PM +0100, Harald Welte wrote: > I've taken the builds slaves offline and asked for the machine to be replaced > (disks will be moved so no data loss expected). that has just happened; jenkins build slaves are already online again. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at osmocom.org Tue Oct 29 07:40:48 2019 From: laforge at osmocom.org (Harald Welte) Date: Tue, 29 Oct 2019 08:40:48 +0100 Subject: massive VTY related master-osmo-{msc,sgsn} build failures Message-ID: <20191029074048.GT23009@nataraja> Dear Osmocom developers, please see the attached messages. I'm getting dozens of these since yesterday, it appears likely some regression was merged? Any help is appreciated. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An embedded message was scrubbed... From: jenkins at lists.osmocom.org Subject: Build failed in Jenkins: master-osmo-msc ? --disable-iu,1,a3=default,a4=default,osmocom-master-debian9 #13560 Date: Tue, 29 Oct 2019 06:34:40 +0000 (UTC) Size: 11872 URL: -------------- next part -------------- An embedded message was scrubbed... From: jenkins at lists.osmocom.org Subject: Build failed in Jenkins: master-osmo-sgsn ? --enable-iu,0,a3=default,a4=default,osmocom-master-debian9 #13962 Date: Tue, 29 Oct 2019 07:37:01 +0000 (UTC) Size: 14588 URL: From osmith at sysmocom.de Tue Oct 29 08:48:07 2019 From: osmith at sysmocom.de (Oliver Smith) Date: Tue, 29 Oct 2019 09:48:07 +0100 Subject: massive VTY related master-osmo-{msc,sgsn} build failures In-Reply-To: <20191029074048.GT23009@nataraja> References: <20191029074048.GT23009@nataraja> Message-ID: <0ef68ad9-7d7d-bd82-460b-1762532529d7@sysmocom.de> Hello Harald and ML, I haven't quite figured out the cause. But so far I was able to reproduce the problem locally with master-osmo-sgsn, and also with just running one build at a time (to rule out that this is not related to running builds in parallel, which should not be a problem due to builds running in docker, but just to be sure). In jenkins, the job built fine here (Oct 28, 2019 6:46 PM): https://jenkins.osmocom.org/jenkins/job/master-osmo-sgsn/13941/ This one is a segfault (Oct 28, 2019 6:55 PM): https://jenkins.osmocom.org/jenkins/job/master-osmo-sgsn/13942/ Here it definitively failed with the vty error (Oct 28, 2019 7:17 PM): https://jenkins.osmocom.org/jenkins/job/master-osmo-sgsn/13943/ It seems to be a regression in libosmocore (there were quite a few changes, especially [1]), but so far I was not able to get it building locally with an older libosmocore version. [1]: https://gerrit.osmocom.org/c/libosmocore/+/15827 Regards, Oliver On 10/29/19 8:40 AM, Harald Welte wrote: > Dear Osmocom developers, > > please see the attached messages. I'm getting dozens of these since yesterday, > it appears likely some regression was merged? Any help is appreciated. > > Regards, > Harald > -- - Oliver Smith https://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 From osmith at sysmocom.de Tue Oct 29 10:58:53 2019 From: osmith at sysmocom.de (Oliver Smith) Date: Tue, 29 Oct 2019 11:58:53 +0100 Subject: massive VTY related master-osmo-{msc,sgsn} build failures In-Reply-To: <0ef68ad9-7d7d-bd82-460b-1762532529d7@sysmocom.de> References: <20191029074048.GT23009@nataraja> <0ef68ad9-7d7d-bd82-460b-1762532529d7@sysmocom.de> Message-ID: It is caused by the strict config parsing. I'm creating fixes and submitting them here: https://gerrit.osmocom.org/q/topic:fix-config-warning On 10/29/19 9:48 AM, Oliver Smith wrote: > Hello Harald and ML, > > I haven't quite figured out the cause. But so far I was able to > reproduce the problem locally with master-osmo-sgsn, and also with just > running one build at a time (to rule out that this is not related to > running builds in parallel, which should not be a problem due to builds > running in docker, but just to be sure). > > In jenkins, the job built fine here (Oct 28, 2019 6:46 PM): > https://jenkins.osmocom.org/jenkins/job/master-osmo-sgsn/13941/ > > This one is a segfault (Oct 28, 2019 6:55 PM): > https://jenkins.osmocom.org/jenkins/job/master-osmo-sgsn/13942/ > > Here it definitively failed with the vty error (Oct 28, 2019 7:17 PM): > https://jenkins.osmocom.org/jenkins/job/master-osmo-sgsn/13943/ > > It seems to be a regression in libosmocore (there were quite a few > changes, especially [1]), but so far I was not able to get it building > locally with an older libosmocore version. > > [1]: https://gerrit.osmocom.org/c/libosmocore/+/15827 > > Regards, > Oliver > > On 10/29/19 8:40 AM, Harald Welte wrote: >> Dear Osmocom developers, >> >> please see the attached messages. I'm getting dozens of these since yesterday, >> it appears likely some regression was merged? Any help is appreciated. >> >> Regards, >> Harald >> > -- - Oliver Smith https://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