From nick at nickvsnetworking.com Sun Jul 5 08:49:50 2020 From: nick at nickvsnetworking.com (Nick Jones) Date: Sun, 5 Jul 2020 18:49:50 +1000 Subject: OsmoCBC Status? In-Reply-To: <20200625163226.GS2605027@nataraja> References: <20200625163226.GS2605027@nataraja> Message-ID: Thanks Harald, I spent some more time on this today, it looks like you can initiate the connection from the BSC to the CBC or the other way around, I worked out a basic config on OsmoCBC and OsmoBSC (going for BSC initiating the connection to CBC): OsmoCBC Config: cbc unknown-peers accept And the config on OsmoBSC: cbc remote-ip 10.0.1.252 remote-port 48049 no listen-port Unfortunately when the BSC connects to the CBC (abridged): <0000> cbsp_server.c:140 r=10.0.1.201:36667<->l=10.0.1.252:48049: Accepting unknown CBSP peer 10.0.1.201:36667 <0000> cbsp_server.c:153 r=10.0.1.201:36667<->l=10.0.1.252:48049: New CBSP client connection <0000> cbsp_server.c:154 CBSP-SERVER[0x55e569d983c0]{INIT}: Received Event RESET.cmd <0000> cbsp_server_fsm.c:203 CBSP-SERVER[0x55e569d983c0]{RESET_PENDING}: Event Rx Restart not permitted <0000> cbsp_server_fsm.c:206 r=10.0.1.201:36667<->l=10.0.1.252:48049: unknown/unhandled RESET COMPLETE Segmentation fault (core dumped) After that the connection is dropped and the CBC halts, So I tried it in reverse, on the CBC I set it up to connect to a remote BSC and plugged in the details of the BSC, and on the BSC I setup a CBC listener IP/port, but wasn't seeing any traffic originating from the CBC; I'm not sure if the CBC needs a REST request before it'll establish the connection, I got some way towards working out what the JSON encoding should be from the source code but I'm no good with C. Any pointers would be greatly appreciated, Cheers, Nick On Fri, Jun 26, 2020 at 2:32 AM Harald Welte wrote: > Dear Nick, > > On Mon, Jun 22, 2020 at 05:45:00PM +1000, Nick Jones wrote: > > Hi all, > > Just wondering what the status of OsmoCBC is? > > I guess nobody has played with it except myself (the main developer) > > > I started compiling from source, but I couldn't find any docs on > > interfacing with it other than that it's via a HTTP REST API, > > If there aren't any docs are there packet captures or examples I can work > > from that'd be quicker than trying to reverse it from the source code, > > Happy to contribute some docs once I work it out, > > I am currently buried alive in work and to be honest I don't recall the > details. > > I remember the BSC + BTS side of Cell Broadcast was fully implemented and > working, > and that the CBC was somewhat early stage. I will try to review the code > and > get back as soon as I can. If you don't get a response in 7 days, please > ping me again. > > -- > - 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 HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: BSC_to_CBC.pcapng Type: application/octet-stream Size: 1608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-cbc_logs Type: application/octet-stream Size: 2478 bytes Desc: not available URL: From laforge at osmocom.org Fri Jul 17 18:25:50 2020 From: laforge at osmocom.org (Harald Welte) Date: Fri, 17 Jul 2020 20:25:50 +0200 Subject: Osmocom scheduled outage on *2020-07-19 9am CEST* Message-ID: <20200717182550.GN132470@nataraja> There is an urgent need to migrate our most important public infrastructure to a new server, and I will be doing that on *Sunday, July 19 2020*, starting about 9am CEST. The migration involves redmine (main osmocom.org website), jenkins, gerrit, git, and cgit. In theory, the migration should be quick. I would expect (significantly) less than one hour of downtime. However, we all know Murphys law. Services not affected are mail (including mailman lists), ftp, dns. So in case of doubt, we can still use mailing lists to communicate. In case anyone urgently needs osmocom source code on Sunday morning during the downtime: There are public mirrors available on github. 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 246tnt at gmail.com Sat Jul 18 14:17:40 2020 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 18 Jul 2020 16:17:40 +0200 Subject: Support for new SDR devices In-Reply-To: References: Message-ID: Hi, > What are the plans to expand support for new SDR devices? I don't think there is any. Support for a given SDR pretty much needs two parts : - Someone to write initial support for it in good enough shape and submit it for inclusion. That can either be the vendor, a user, or someone contracted by someone else to write it. USRP1 support comes from the root of OpenBTS code. UHD device support was AFAIR initially written by Tom Tsou when he was working for Ettus. Lime Support was a first patch from Fairwaves and then improved and merged into mainline by Sysmocom. I know Lime themselves have at least sponsored some hardware to various devs. - Then someone has to maintain that driver and test it works. Once merged, it'll probably be auto tested that it builds as part of regression testing, but it won't be tested that it actually works. But for testing it works, someone with access to the hardware will need to continuously test it and make sure it doesn't get broken. AFAIR Sysmocom has some automated testing with real hardware but obviously they only do that with hardware that they have and have an interest in maintaining. > When I check the contents of osmo-trx/Transceiver52M/device/ on the git master I see the supported lms, uhd and usrp1 devices. For example the XTRX SDR was presented at OsmoDevCon 2018. I expected it to be included in the master soon. At this point I see its addition in the fairwaves / libxtrx-wip branch from 2018. That doesn't give me much encouragement for my next question. > Would it be possible to add support for PCIe SDR from Amarisoft? Probably ... see above. If you write a patch that works and can maintain support for it over time, that'll be a nice inclusion in osmo-trx. Cheers, Sylvain From pespin at sysmocom.de Sat Jul 18 16:19:37 2020 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Sat, 18 Jul 2020 18:19:37 +0200 Subject: Support for new SDR devices In-Reply-To: References: Message-ID: Hi, without looking into much detail at your branch, I should suggest: * Rebase your work on top of current osmo-trx master, the base commit you use is uite old and the API has changed a bit since then, with some fixes and improvements. * Make sure you run both osmo-trx and osmo-bts-trx with RR scheduler (realtime). For instance, osmo-trx VTY cmd "rt-prio 18", and osmo-bts-trx cmd line arg "-r 1". * From what i see in the logs, it looks like you have some issues with how you are managing the tmestamps inside your device backend, so something is not being done correctly in there most probably, then 0 is returned and osmo-trx upper layers decide to stop the process. Once you have something working acceptably fine (MS can use the network more or less reliably, and osmo-trx doesn't stop or crash), I'm happy to review your patch in gerrit. Regards, Pau -- - 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 laforge at osmocom.org Sun Jul 19 10:54:23 2020 From: laforge at osmocom.org (Harald Welte) Date: Sun, 19 Jul 2020 12:54:23 +0200 Subject: Osmocom scheduled outage on *2020-07-21 7.30am CEST* In-Reply-To: <20200717182550.GN132470@nataraja> References: <20200717182550.GN132470@nataraja> Message-ID: <20200719105423.GA132470@nataraja> Dear Osmocom community, the migration to the new server has completed today. All services are up and running. There will be another scheduled outage on Tuesday, July 21 at 7.30am CEST This second outage is to migrate the old server IP addresses to the new server, which appears to involve physical relocation between racks. Happy hacking! -- - 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 Jul 21 08:39:57 2020 From: laforge at osmocom.org (Harald Welte) Date: Tue, 21 Jul 2020 10:39:57 +0200 Subject: libosmocore / osmo_fd / select() / performance Message-ID: <20200721083957.GT328050@nataraja> Hi all, it has been coming up in at least two contexts recently: Select is showing up a lot in system-level profiles particularly on osmo-bts. This is hardly surprising, as select() is not particularly known for efficiency. It was used back in 2008 for the *BSC*, in a context where we were talking about 1-10 BTS with each no more than 1-2 TRX. Now we are using the same osmo_fd abstraction on the BTS, where the number of messages per second is much higher, particularly in osmo-bts-trx with its TRXD protocol, and particularly with higher number of TRX per BTS. There is an older feature request to introduce epoll support in https://osmocom.org/issues/1579 but unfortunately nobody has been finding the resources and/or time to implement it. Meanwhile, 1.5 years ago, the Linux kernel received a new sub-system called io_uring, which I would personally love to support. Here are some pointers for those who are interested: https://lwn.net/Articles/776703/ https://kernel.dk/io_uring.pdf https://lwn.net/Kernel/Index/#io_uring As unfortunately not everyone is using half-way recent kernels, we will likely have to fall back to epoll or something like that. 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 ralph at schmid.xxx Tue Jul 21 13:07:24 2020 From: ralph at schmid.xxx (Ralph A. Schmid, dk5ras) Date: Tue, 21 Jul 2020 15:07:24 +0200 Subject: Support for new SDR devices In-Reply-To: References:

Message-ID: Hi all, > Hi, > > > > What are the plans to expand support for new SDR devices? > > I don't think there is any. What about considering a somehow wider group of SDRs using an additional layer with Soapy? I am no coder at all and can't help, and maybe I am totally wrong anyway, but a more universal approach looks interesting to me. A friend is coding at the moment a DMR interface between MMDVM and soapy and is doing good progress. Also Soapy has proven to be somehow "cell infrastructure ready" in the srsLTE project. > Cheers, > > Sylvain With best regards Ralph. From 246tnt at gmail.com Sun Jul 26 07:31:25 2020 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sun, 26 Jul 2020 09:31:25 +0200 Subject: Support for new SDR devices In-Reply-To: References:

Message-ID: Hi, > > > What are the plans to expand support for new SDR devices? > > > > I don't think there is any. > > What about considering a somehow wider group of SDRs using an additional layer with Soapy? I am no coder at all and can't help, and maybe I am totally wrong anyway, but a more universal approach looks interesting to me. A friend is coding at the moment a DMR interface between MMDVM and soapy and is doing good progress. > Also Soapy has proven to be somehow "cell infrastructure ready" in the srsLTE project. Has it ? Is it used for production ready stability level anywhere ? Last I heard it was a "yeah, it works sort-of sometimes" level of support, but maybe that's outdated. Even with UHD which is supposed to be "universal" there is still a bunch of tweaking "per radio" for things like analog and digital delays in the hardware itself, gain range, etc etc ... so Soapy would likely have the same. But if you want to give it a shot, go ahead. Cheers, Sylvain