From ron.menez at entropysolution.com Thu Mar 1 03:05:19 2018 From: ron.menez at entropysolution.com (Ron) Date: Thu, 1 Mar 2018 03:05:19 +0000 Subject: A5/1 Encryption Enabled - Programmable SIM unable to camp In-Reply-To: <20180228150747.GB1709@my.box> References: <187747E2-D0D5-4D18-B950-B3A296DBDC95@entropysolution.com> <20180228141810.GA1709@my.box> <20180228150747.GB1709@my.box> Message-ID: <15BD3532-17F5-4BEB-9ADF-3119224BE36D@entropysolution.com> Noted on this Neels. Thank you for the confirmation. We?ll try to check our SIM/USIM configuration first. Best Regard, Ron Menez ron.menez at entropysolution.com On Feb 28, 2018, at 11:07 PM, Neels Hofmeyr > wrote: Actually, Ron, there is no bug here. I was quite sure of my SIM configuration, but in fact it was programmed to use COMP128v3, not v1, and hence I got a differing SRES upon Auth Response. Double check that your SIM/USIM is configured to use COMP128v1 for 2G! For example, try to configure COMP128v3 in the HLR and see if that helps. I've rejected issue #3017 now. It all works. (Feels good to be able to say that for a change.) ~N -- - Neels Hofmeyr > http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Thu Mar 1 21:50:50 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 2 Mar 2018 04:50:50 +0700 Subject: trxcon, fake-trx and osmo-bts-trx: Simulating TA + Power Control Message-ID: Hi Harald, > fake_trx must be able to insert additional false "delay" > ... > 1) Implementation of TA in fake_trx > ... > 2) implementation of "fake delay" in fake_trx > ... Done. Great collaborative work! > fake_trx must be able to insert additional false "path loss" > ... > For RSSI processing it's slightly more complicated: This needs to be discussed. > fake_trx would need to know the nominal transmit power > of both MS and BTS. For this example, let's assume MS > nominal power is +30dBm and BTS +23 dBm... Do we really need to specify the nominal transmit power for both? At the moment, trxcon is capable to parse the L1CTL_PARAM_REQ messages from the higher layers, and it basically forwards exactly TX power instead of TX attenuation to transceiver... Or should we change this value to attenuation, and go by the way you suggested above? This task doesn't seem too complicated, so I'll implement this. By the way, I have another idea. We are talking about path loss, which does not only affect power levels, but also introduces some bit corruption level. This could be also simulated in FakeTRX, but first of all, it's good to know, do we need this feature? I think it makes sense, because a MS also reports BER in its Measurement Reports. With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Mar 1 22:57:27 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 1 Mar 2018 23:57:27 +0100 Subject: TTCN-3 test suite for OsmoBTS Message-ID: <20180301225727.GI5227@nataraja> Hi all, today I've docker-ized the latest TTCN-3 test suite I've been developing over the last week or so. They're now running nightly in our Jenkins, you can see the results analyzer at https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bts-test/test_results_analyzer/ (don't forget the "Expand All" button) Out of all the test suites I've written in recent months, the OsmoBTS test suite is what I'm particularly happy about. While of course not achieving 100% coverage it actually tests a lot of things, including various cases that would be very hard to impossible to achieve in manual testing.o A larger number of tests is also relate to the BTS<->PCU socket interface, where [almost] each of the message types occurring in Rx/Tx is triggered + tested accordingly. The system information scheduling test cases were working for me 2 days ago, I'm not sure what I did wrong to break them again, I'll investigate. In terms of important needed OsmoBTS tests, I see: * verification of PCU -> Um for all different coding schemes (requires PDCH support in trxcon first, or fall-back to virt_phy instead) * testing of timing advance loop * testing of uplink power control loop (needs fake_trx extension) * testing of voice channels in all codec modes * memory leak related testing It was a loooong week full of late night and early morning shifts, but I'm happy that progress was possible in a rather short amount of time. Thanks to Vadim "fixeria" for his work on trxcon + fake_trx, which means we can test a fully unmodified osmo-bts-trx ("the real thing"), rather than osmo-bts-virtual, which is a BTS model that doesn't exist this way in reality. The nice part is that the test cases only use L1CTL on one hand side and RSL/PCUIF/VTY/CTRL on the other side, and as such they should in theory work equally with the followign setups: a) TTCN3 -L1CTL-> trxcon -> fake_trx -> osmo-bts-trx -> TTCN3 (current) b) TTCN3 -L1CTL-> virt_phy osmo-bts-virtual -> TTCN3 c) TTCN3 -L1CTL-> OsmocomBB-firmware -RF-> osmo-bts-{sysmo,lc15,octphy} -> TTCN3 Only 'a)' is currently used, but it would definitely be interesting to be able to use the exact same test cases (minus TA/power-control loop test) with real hardware and the different PHYs. Any contributions are as always very much welcome. With all the existing test cases out there and the dockerized setup, it should be super easy to reproduce the test results on your local machine, and to copy+paste+edit an existing test to extend test coverage even further. The development of the test suite has already resulted in dozens (!) of bugs being discovered some of them quite severe. Check the increased activity since february 22nd at http://osmocom.org/projects/osmobts/issues?utf8=%E2%9C%93&set_filter=1&f%5B%5D=&c%5B%5D=tracker&c%5B%5D=status&c%5B%5D=priority&c%5B%5D=subject&c%5B%5D=assigned_to&c%5B%5D=updated_on&group_by=&t%5B%5D= for more information 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 cyril.deletre at gmail.com Fri Mar 2 13:49:59 2018 From: cyril.deletre at gmail.com (Cyril) Date: Fri, 2 Mar 2018 14:49:59 +0100 Subject: osmo-trx commit 3da1f83 Message-ID: Hello, How do you select the log level with the libosmocore logging system introduced in commit 3da1f83 ? What is the equivalent of '-l DEBUG' command line option now ? Thanks ! Cyril -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Fri Mar 2 16:44:41 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 2 Mar 2018 17:44:41 +0100 Subject: osmo-trx commit 3da1f83 In-Reply-To: References: Message-ID: Hi Cyril, I am currently in the process of modifying osmo-trx to use several components from libosmocore, such as configuration handling through VTY, a CTRL interface and logging system. This work is mostly done but only the first steps have been merged. The pending patches can be found in [1] and I expect to continue work on them next week. I also plan to make a new release in a new branch 0.3.0 based on master c92dad32dd403d84617236e98db892d7d285cd35, that is before dependency to libosmocore was added. As you may have noticed already, in the current state of master you must already pass a .cfg file in order to start osmo-trx. This .cfg file has the same format as all other osmocom related projects. The logging is configured through this cfg file (actually, it's mostly the only thing that the cfg file configures at this point in current master). In later commits (still not merged), as sample cfg file is added to the repo in doc/examples/osmo-trx*.cfg. In the current master state, you should pass a file containing something like this: ! ! OsmoHLR example configuration ! log stderr logging filter all 1 logging color 1 logging print category 1 logging timestamp 1 logging print extended-timestamp 1 logging level all debug ! line vty bind 127.0.0.1 ctrl bind 127.0.0.1 Then, as of now still call osmo-trx the same way you used to do (you can omit the -l param) and add a capital C parameter with the config file: ./osmo-trx ... -C osmo-trx.cfg [1] https://gerrit.osmocom.org/#/c/6651 -- - 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 gnumonks.org Sun Mar 4 10:55:43 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 4 Mar 2018 11:55:43 +0100 Subject: Submissions for OsmoDevCon 2018 In-Reply-To: <20180131230130.GK20115@nataraja> References: <20180131230130.GK20115@nataraja> Message-ID: <20180304105543.GV5227@nataraja> Dear Osmocom Developer Community, one month has passed without much edits of the OsmoDevCon 2018 wiki page at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2018 If you're attending, please do your part to help us with planning of the event by adding to the list of topics * what you would like to present / discuss * what you would like others to present / discuss This will allow us to plan accordingly, and to make sure that we can group related topics. Thanks for your help! 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 cyril.deletre at gmail.com Mon Mar 5 15:53:05 2018 From: cyril.deletre at gmail.com (Cyril) Date: Mon, 5 Mar 2018 16:53:05 +0100 Subject: osmo-trx commit 3da1f83 In-Reply-To: References: Message-ID: Thank you for your detailled answer :) Cyril 2018-03-02 17:44 GMT+01:00 Pau Espin Pedrol : > Hi Cyril, > > I am currently in the process of modifying osmo-trx to use several > components from libosmocore, such as configuration handling through VTY, a > CTRL interface and logging system. > > This work is mostly done but only the first steps have been merged. The > pending patches can be found in [1] and I expect to continue work on them > next week. > > I also plan to make a new release in a new branch 0.3.0 based on master > c92dad32dd403d84617236e98db892d7d285cd35, that is before dependency to > libosmocore was added. > > As you may have noticed already, in the current state of master you must > already pass a .cfg file in order to start osmo-trx. This .cfg file has the > same format as all other osmocom related projects. The logging is > configured through this cfg file (actually, it's mostly the only thing that > the cfg file configures at this point in current master). > > In later commits (still not merged), as sample cfg file is added to the > repo in doc/examples/osmo-trx*.cfg. In the current master state, you should > pass a file containing something like this: > > ! > ! OsmoHLR example configuration > ! > log stderr > logging filter all 1 > logging color 1 > logging print category 1 > logging timestamp 1 > logging print extended-timestamp 1 > logging level all debug > ! > line vty > bind 127.0.0.1 > ctrl > bind 127.0.0.1 > > Then, as of now still call osmo-trx the same way you used to do (you can > omit the -l param) and add a capital C parameter with the config file: > > ./osmo-trx ... -C osmo-trx.cfg > > [1] https://gerrit.osmocom.org/#/c/6651 > > -- > - 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cyril.deletre at gmail.com Mon Mar 5 16:02:23 2018 From: cyril.deletre at gmail.com (Cyril) Date: Mon, 5 Mar 2018 17:02:23 +0100 Subject: osmo-trx and limesdr mini Message-ID: Hello, I wonder if someone has got the limesdr mini (hardware v1.1, gateway 1.24) running with osmo-trx ? I've been able to get it working with the non-mini version (the "big" mimo limesdr) but with the mini version it crashes after a few tenth seconds with apparently something going wrong on the tx side (see attachments) Any feedback is welcomed :) Cyril -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- $ osmo-trx -e -l INFO linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.003.000-0-gef157678 Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU <0001> telnet_interface.c:104 telnet at 127.0.0.1 4237 <0008> control_if.c:854 CTRL at 127.0.0.1 4236 Config Settings Log Level............... INFO Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM Core Address.........127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ Enabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 Tx Antennas............. '' Rx Antennas............. '' INFO 140310767695680 13:59:02.5 UHDDevice.cpp:663:open: Using discovered UHD device addr=1d50:6108,driver=lime,label=LimeSDR-USB [USB 3.0] 9060B00460817,media=USB 3.0,module=FX3,name=LimeSDR-USB,serial=0009060B00460817,type=soapy -- Make connection: 'LimeSDR-USB [USB 3.0] 9060B00460817' -- Reference clock 30.72 MHz -- Device name: LimeSDR-USB -- Reference: 3.072e+07 MHz CGEN: Freq=80 MHz, VCO=2.56 GHz, INT=82, FRAC=349525, DIV_OUTCH_CGEN=15 -- LMS7002M calibration values caching Disable INFO 140310767695680 13:59:05.2 UHDDevice.cpp:480:set_antennas: Antennas configured successfully CGEN: Freq=8.66667 MHz, VCO=2.42667 GHz, INT=77, FRAC=1041294, DIV_OUTCH_CGEN=139 CGEN: Freq=34.6667 MHz, VCO=2.42667 GHz, INT=77, FRAC=1041294, DIV_OUTCH_CGEN=34 CGEN: Freq=34.6667 MHz, VCO=2.42667 GHz, INT=77, FRAC=1041294, DIV_OUTCH_CGEN=34 CGEN: Freq=138.667 MHz, VCO=2.496 GHz, INT=80, FRAC=262144, DIV_OUTCH_CGEN=8 CGEN: Freq=138.667 MHz, VCO=2.496 GHz, INT=80, FRAC=262144, DIV_OUTCH_CGEN=8 INFO 140310767695680 13:59:05.6 UHDDevice.cpp:454:set_rates: Rates configured for LimeSDR 4 SPS MCU programming : 16384/16384 MCU Programming finished, 1036 ms -- Filter calibrated. Filter order-4th, filter bandwidth set to 5 MHz.Real pole 1st order filter set to 2.5 MHz. Preemphasis filter not active -- TX LPF configured -- RX LPF configured INFO 140310767695680 13:59:07.6 UHDDevice.cpp:414:init_gains: Supported Tx gain range [-12; 64] INFO 140310767695680 13:59:07.6 UHDDevice.cpp:419:init_gains: Supported Rx gain range [-12; 61] INFO 140310767695680 13:59:07.6 UHDDevice.cpp:423:init_gains: Default setting Tx gain for channel 0 to 26 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=79, FRAC=0, DIV_OUTCH_CGEN=39 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=79, FRAC=0, DIV_OUTCH_CGEN=39 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=79, FRAC=0, DIV_OUTCH_CGEN=39 INFO 140310767695680 13:59:09.5 UHDDevice.cpp:430:init_gains: Default setting Rx gain for channel 0 to 24.5 INFO 140310767695680 13:59:09.5 UHDDevice.cpp:757:open: Single USRP: Device: FX3 Mboard 0: LimeSDR-USB RX Channel: 0 RX DSP: 0 RX Dboard: 0 RX Subdev: SoapyRF RX Channel: 1 RX DSP: 1 RX Dboard: 1 RX Subdev: SoapyRF TX Channel: 0 TX DSP: 0 TX Dboard: 0 TX Subdev: SoapyRF TX Channel: 1 TX DSP: 1 TX Dboard: 1 TX Subdev: SoapyRF -- Transceiver active with 1 channel(s) INFO 140310767929088 13:59:36.6 Transceiver.cpp:685:driveControl: command is CMD POWEROFF INFO 140310767929088 13:59:36.7 Transceiver.cpp:685:driveControl: command is CMD POWEROFF INFO 140310767929088 13:59:36.8 Transceiver.cpp:685:driveControl: command is CMD RXTUNE 900200 INFO 140310767929088 13:59:37.0 UHDDevice.cpp:1145:set_freq: Tune Result: Target RF Freq: 900.200000 (MHz) Actual RF Freq: 900.199995 (MHz) Target DSP Freq: -0.000005 (MHz) Actual DSP Freq: -0.000005 (MHz) INFO 140310767929088 13:59:37.0 Transceiver.cpp:685:driveControl: command is CMD TXTUNE 945200 INFO 140310767929088 13:59:37.5 UHDDevice.cpp:1145:set_freq: Tune Result: Target RF Freq: 945.200000 (MHz) Actual RF Freq: 945.199995 (MHz) Target DSP Freq: 0.000005 (MHz) Actual DSP Freq: 0.000005 (MHz) INFO 140310767929088 13:59:37.5 Transceiver.cpp:685:driveControl: command is CMD SETTSC 7 NOTICE 140310767929088 13:59:37.5 Transceiver.cpp:791:driveControl: Changing TSC from 0 to 7 INFO 140310767929088 13:59:37.5 Transceiver.cpp:685:driveControl: command is CMD POWERON NOTICE 140310767929088 13:59:37.5 Transceiver.cpp:244:start: Starting the transceiver INFO 140310767929088 13:59:37.5 radioInterface.cpp:153:start: Starting radio device INFO 140310767929088 13:59:37.5 UHDDevice.cpp:835:start: Starting USRP... Tx calibration using MCU INTERNAL loopback Tx ch.A @ 945.2 MHz, BW: 5 MHz, RF output: BAND1, Gain: 2 Current MCU firmware: 5, DC/IQ calibration full MCU Ref. clock: 30.72 MHz INFO 140310767929088 13:59:37.9 UHDDevice.cpp:344:uhd_msg_handler: Tx calibration finished Tx | DC | GAIN | PHASE ---+-----+------+------ I: | -7 | 1979 | 9 Q: | 70 | 2047 | Duration: 423 ms Rx calibration using INTERNAL loopback Rx ch.A @ 900.2 MHz, BW: 5 MHz, RF input: LNAH, PGA: 12, LNA: 5, TIA: 3 Current MCU firmware: 5, DC/IQ calibration full MCU Ref. clock: 30.72 MHz INFO 140310767929088 13:59:38.1 UHDDevice.cpp:344:uhd_msg_handler: Rx calibration finished RX | DC | GAIN | PHASE ---+-----+------+------ I: | 20 | 2047 | -18 Q: | 0 | 2010 | Duration: 230 ms INFO 140310767929088 13:59:38.3 UHDDevice.cpp:810:flush_recv: Initial timestamp 128520 INFO 140310767929088 13:59:38.3 UHDDevice.cpp:856:start: The current time is 0.119575 seconds INFO 140310767929088 13:59:38.3 radioInterface.cpp:174:start: Radio started INFO 140310767929088 13:59:38.3 Transceiver.cpp:685:driveControl: command is CMD SETRXGAIN 1 INFO 140310766311168 13:59:38.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 788372 INFO 140310767929088 13:59:38.3 UHDDevice.cpp:528:setRxGain: Set RX gain to 0dB (asked for 1dB) INFO 140310767929088 13:59:38.3 Transceiver.cpp:685:driveControl: command is CMD SETPOWER 20 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=79, FRAC=0, DIV_OUTCH_CGEN=39 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=79, FRAC=0, DIV_OUTCH_CGEN=39 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=79, FRAC=0, DIV_OUTCH_CGEN=39 INFO 140310767929088 13:59:38.4 UHDDevice.cpp:513:setTxGain: Set TX gain to 44dB (asked for 44dB) INFO 140310767929088 13:59:38.4 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 0 5 INFO 140310767929088 13:59:38.4 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 1 7 INFO 140310767929088 13:59:38.4 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 2 1 INFO 140310767929088 13:59:38.4 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 3 1 INFO 140310767929088 13:59:38.4 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 4 1 INFO 140310767929088 13:59:38.4 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 5 1 INFO 140310767929088 13:59:38.4 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 6 1 INFO 140310767929088 13:59:38.4 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 7 1 Rx: 3.916 MB/s INFO 140310766311168 13:59:39.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 788588 Tx: 4.096 MB/s Rx: 4.350 MB/s INFO 140310766311168 13:59:40.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 788805 Tx: 4.349 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:41.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 789022 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:42.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 789238 Tx: 4.354 MB/s Rx: 4.349 MB/s INFO 140310766311168 13:59:43.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 789455 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:44.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 789672 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:45.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 789888 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:46.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 790105 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:47.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 790322 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:48.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 790539 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:49.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 790755 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:50.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 790972 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:51.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 791189 Tx: 4.346 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:52.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 791405 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:53.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 791622 Tx: 4.350 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:54.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 791838 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:55.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 792055 Tx: 4.353 MB/s Rx: 4.350 MB/s INFO 140310766311168 13:59:56.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 792272 Tx: 4.358 MB/s Rx: 4.358 MB/s INFO 140310766311168 13:59:57.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 792488 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 13:59:58.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 792705 Tx: 4.354 MB/s Rx: 4.350 MB/s INFO 140310766311168 13:59:59.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 792922 Tx: 4.346 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:00.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 793138 Tx: 4.350 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:01.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 793355 Tx: 4.354 MB/s Rx: 4.349 MB/s INFO 140310766311168 14:00:02.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 793572 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:03.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 793788 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:04.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 794005 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:05.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 794221 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:06.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 794438 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:07.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 794654 Tx: 4.346 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:08.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 794871 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:09.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 795087 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:10.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 795304 Tx: 4.350 MB/s Rx: 4.350 MB/s INFO 140310766311168 14:00:11.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 795520 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:12.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 795737 Tx: 4.353 MB/s Rx: 4.349 MB/s INFO 140310766311168 14:00:13.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 795954 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:14.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 796171 Tx: 4.349 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:15.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 796388 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:16.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 796605 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:17.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 796822 Tx: 4.342 MB/s Rx: 4.350 MB/s INFO 140310766311168 14:00:18.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 797038 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:19.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 797255 Tx: 4.350 MB/s Rx: 4.350 MB/s INFO 140310766311168 14:00:20.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 797472 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:21.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 797688 Tx: 4.353 MB/s Rx: 4.350 MB/s INFO 140310766311168 14:00:22.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 797905 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:23.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 798121 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:24.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 798338 Tx: 4.354 MB/s Rx: 4.350 MB/s INFO 140310766311168 14:00:25.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 798554 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:26.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 798771 Tx: 4.342 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:27.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 798988 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:28.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 799204 Tx: 4.350 MB/s Rx: 4.350 MB/s INFO 140310766311168 14:00:29.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 799421 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:30.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 799638 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:31.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 799854 Tx: 4.354 MB/s Rx: 4.350 MB/s INFO 140310766311168 14:00:32.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 800071 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:33.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 800288 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:34.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 800505 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:35.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 800722 Tx: 4.349 MB/s Rx: 4.350 MB/s INFO 140310766311168 14:00:36.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 800938 Tx: 4.346 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:37.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 801155 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:38.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 801371 Tx: 4.350 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:39.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 801588 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:40.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 801804 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:41.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 802021 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:42.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 802237 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:43.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 802454 Tx: 4.346 MB/s Rx: 4.350 MB/s INFO 140310766311168 14:00:44.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 802670 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:45.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 802887 Tx: 4.350 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:46.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 803103 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140310766311168 14:00:47.3 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 803320 Tx: 4.354 MB/s Rx: 4.354 MB/s ^Csignal 2 received shutting down Shutting down transceiver... NOTICE 140310767695680 14:00:48.3 Transceiver.cpp:298:stop: Stopping the transceiver INFO 140310767695680 14:00:48.3 Transceiver.cpp:311:stop: Stopping the device NOTICE 140310767695680 14:00:48.4 Transceiver.cpp:324:stop: Transceiver stopped WARNING 140310309750528 14:00:48.8 UHDDevice.cpp:347:uhd_msg_handler: popping from TX, samples popped 920/1020 -------------- next part -------------- osmo-trx -e -l INFO linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_003.010.003.000-0-gef157678 Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU <0001> telnet_interface.c:104 telnet at 127.0.0.1 4237 <0008> control_if.c:854 CTRL at 127.0.0.1 4236 Config Settings Log Level............... INFO Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM Core Address.........127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ Enabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 Tx Antennas............. '' Rx Antennas............. '' INFO 140606467434304 13:54:44.1 UHDDevice.cpp:663:open: Using discovered UHD device addr=24607:1027,driver=lime,label=LimeSDR Mini [USB 3.0] 1D3A0124D7A59C,media=USB 3.0,module=FT601,name=LimeSDR Mini,serial=1D3A0124D7A59C,type=soapy -- Make connection: 'LimeSDR Mini [USB 3.0] 1D3A0124D7A59C' -- Reference clock 40.00 MHz -- Device name: LimeSDR-Mini -- Reference: 4e+07 MHz CGEN: Freq=61.44 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=19 -- LMS7002M calibration values caching Disable CGEN: Freq=80 MHz, VCO=2.56 GHz, INT=63, FRAC=0, DIV_OUTCH_CGEN=15 UHD Error: SetFrequencyCGEN(80 MHz) failed INFO 140606467434304 13:54:45.4 UHDDevice.cpp:480:set_antennas: Antennas configured successfully CGEN: Freq=8.66667 MHz, VCO=2.42667 GHz, INT=59, FRAC=699050, DIV_OUTCH_CGEN=139 CGEN: Freq=34.6667 MHz, VCO=2.42667 GHz, INT=59, FRAC=699050, DIV_OUTCH_CGEN=34 CGEN: Freq=138.667 MHz, VCO=2.496 GHz, INT=61, FRAC=419430, DIV_OUTCH_CGEN=8 INFO 140606467434304 13:54:45.6 UHDDevice.cpp:454:set_rates: Rates configured for LimeSDR 4 SPS MCU programming : 16384/16384 MCU Programming finished, 3118 ms -- Filter calibrated. Filter order-4th, filter bandwidth set to 5 MHz.Real pole 1st order filter set to 2.5 MHz. Preemphasis filter not active -- TX LPF configured -- RX LPF configured INFO 140606467434304 13:54:49.7 UHDDevice.cpp:414:init_gains: Supported Tx gain range [-12; 64] INFO 140606467434304 13:54:49.7 UHDDevice.cpp:419:init_gains: Supported Rx gain range [-12; 61] INFO 140606467434304 13:54:49.7 UHDDevice.cpp:423:init_gains: Default setting Tx gain for channel 0 to 26 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 INFO 140606467434304 13:54:50.9 UHDDevice.cpp:430:init_gains: Default setting Rx gain for channel 0 to 24.5 INFO 140606467434304 13:54:50.9 UHDDevice.cpp:757:open: Single USRP: Device: FT601 Mboard 0: LimeSDR-Mini RX Channel: 0 RX DSP: 0 RX Dboard: 0 RX Subdev: SoapyRF TX Channel: 0 TX DSP: 0 TX Dboard: 0 TX Subdev: SoapyRF -- Transceiver active with 1 channel(s) INFO 140606467667712 13:55:01.9 Transceiver.cpp:685:driveControl: command is CMD POWEROFF INFO 140606467667712 13:55:02.0 Transceiver.cpp:685:driveControl: command is CMD POWEROFF INFO 140606467667712 13:55:02.1 Transceiver.cpp:685:driveControl: command is CMD RXTUNE 900200 INFO 140606467667712 13:55:02.4 UHDDevice.cpp:1145:set_freq: Tune Result: Target RF Freq: 900.200000 (MHz) Actual RF Freq: 900.199995 (MHz) Target DSP Freq: -0.000005 (MHz) Actual DSP Freq: -0.000005 (MHz) INFO 140606467667712 13:55:02.4 Transceiver.cpp:685:driveControl: command is CMD TXTUNE 945200 INFO 140606467667712 13:55:03.1 UHDDevice.cpp:1145:set_freq: Tune Result: Target RF Freq: 945.200000 (MHz) Actual RF Freq: 945.199995 (MHz) Target DSP Freq: 0.000005 (MHz) Actual DSP Freq: 0.000005 (MHz) INFO 140606467667712 13:55:03.1 Transceiver.cpp:685:driveControl: command is CMD SETTSC 7 NOTICE 140606467667712 13:55:03.1 Transceiver.cpp:791:driveControl: Changing TSC from 0 to 7 INFO 140606467667712 13:55:03.1 Transceiver.cpp:685:driveControl: command is CMD POWERON NOTICE 140606467667712 13:55:03.1 Transceiver.cpp:244:start: Starting the transceiver INFO 140606467667712 13:55:03.1 radioInterface.cpp:153:start: Starting radio device INFO 140606467667712 13:55:03.1 UHDDevice.cpp:835:start: Starting USRP... Tx calibration using MCU INTERNAL loopback Tx ch.A @ 945.2 MHz, BW: 5 MHz, RF output: BAND1, Gain: 2 Current MCU firmware: 5, DC/IQ calibration full MCU Ref. clock: 40 MHz INFO 140606467667712 13:55:03.5 UHDDevice.cpp:344:uhd_msg_handler: Tx calibration finished Tx | DC | GAIN | PHASE ---+-----+------+------ I: | -69 | 2008 | -9 Q: | -230 | 2047 | Duration: 381 ms Rx calibration using INTERNAL loopback Rx ch.A @ 900.2 MHz, BW: 5 MHz, RF input: LNAH, PGA: 12, LNA: 5, TIA: 3 Current MCU firmware: 5, DC/IQ calibration full MCU Ref. clock: 40 MHz INFO 140606467667712 13:55:03.7 UHDDevice.cpp:344:uhd_msg_handler: Rx calibration finished RX | DC | GAIN | PHASE ---+-----+------+------ I: | 5 | 2047 | -25 Q: | 7 | 1993 | Duration: 206 ms INFO 140606467667712 13:55:03.8 UHDDevice.cpp:810:flush_recv: Initial timestamp 128520 INFO 140606467667712 13:55:03.8 UHDDevice.cpp:856:start: The current time is 0.119575 seconds INFO 140606467667712 13:55:03.8 radioInterface.cpp:174:start: Radio started INFO 140606467667712 13:55:03.8 Transceiver.cpp:685:driveControl: command is CMD SETRXGAIN 1 INFO 140606466049792 13:55:03.8 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1595232 INFO 140606467667712 13:55:03.8 UHDDevice.cpp:528:setRxGain: Set RX gain to 0dB (asked for 1dB) INFO 140606467667712 13:55:03.8 Transceiver.cpp:685:driveControl: command is CMD SETPOWER 20 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 WARNING 140606319671040 13:55:04.0 UHDDevice.cpp:347:uhd_msg_handler: L CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 INFO 140606467667712 13:55:04.1 UHDDevice.cpp:513:setTxGain: Set TX gain to 44dB (asked for 44dB) INFO 140606467667712 13:55:04.1 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 0 5 INFO 140606467667712 13:55:04.1 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 1 7 INFO 140606467667712 13:55:04.1 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 2 1 INFO 140606467667712 13:55:04.1 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 3 1 INFO 140606467667712 13:55:04.1 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 4 1 INFO 140606467667712 13:55:04.1 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 5 1 INFO 140606467667712 13:55:04.1 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 6 1 INFO 140606467667712 13:55:04.1 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 7 1 WARNING 140606302885632 13:55:04.5 UHDDevice.cpp:347:uhd_msg_handler: popping from TX, samples popped 0/1020 WARNING 140606319671040 13:55:04.5 UHDDevice.cpp:347:uhd_msg_handler: L Rx: 3.809 MB/s INFO 140606466049792 13:55:04.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1595448 Tx: 4.219 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:05.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1595665 Tx: 4.358 MB/s WARNING 140606319671040 13:55:06.6 UHDDevice.cpp:347:uhd_msg_handler: L Rx: 4.354 MB/s INFO 140606466049792 13:55:06.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1595881 Tx: 4.227 MB/s Rx: 4.350 MB/s INFO 140606466049792 13:55:07.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1596098 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:08.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1596314 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:09.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1596531 Tx: 4.353 MB/s Rx: 4.349 MB/s INFO 140606466049792 13:55:10.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1596748 Tx: 4.354 MB/s Rx: 4.358 MB/s INFO 140606466049792 13:55:11.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1596965 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:12.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1597181 Tx: 4.353 MB/s Rx: 4.350 MB/s INFO 140606466049792 13:55:13.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1597398 Tx: 4.354 MB/s Rx: 4.358 MB/s INFO 140606466049792 13:55:14.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1597614 Tx: 4.358 MB/s Rx: 4.350 MB/s INFO 140606466049792 13:55:15.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1597831 Tx: 4.349 MB/s Rx: 4.350 MB/s INFO 140606466049792 13:55:16.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1598047 Tx: 4.354 MB/s Rx: 4.358 MB/s INFO 140606466049792 13:55:17.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1598264 Tx: 4.354 MB/s Rx: 4.349 MB/s INFO 140606466049792 13:55:18.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1598480 Tx: 4.346 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:19.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1598697 Tx: 4.350 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:20.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1598913 Tx: 4.349 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:21.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1599130 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:22.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1599346 Tx: 4.349 MB/s Rx: 4.350 MB/s INFO 140606466049792 13:55:23.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1599563 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:24.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1599779 Tx: 4.353 MB/s Rx: 4.350 MB/s INFO 140606466049792 13:55:25.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1599996 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:26.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1600212 Tx: 4.358 MB/s Rx: 4.350 MB/s INFO 140606466049792 13:55:27.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1600429 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:28.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1600645 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 140606466049792 13:55:29.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1600862 Rx: 4.350 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:30.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1601078 Rx: 4.354 MB/s Tx: 4.346 MB/s INFO 140606466049792 13:55:31.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1601295 Rx: 4.350 MB/s Tx: 4.350 MB/s INFO 140606466049792 13:55:32.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1601511 Rx: 4.354 MB/s Tx: 4.353 MB/s INFO 140606466049792 13:55:33.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1601728 Rx: 4.354 MB/s Tx: 4.353 MB/s INFO 140606466049792 13:55:34.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1601944 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:35.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1602161 Rx: 4.350 MB/s Tx: 4.358 MB/s INFO 140606466049792 13:55:36.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1602378 Rx: 4.354 MB/s Tx: 4.358 MB/s INFO 140606466049792 13:55:37.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1602594 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:38.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1602811 Rx: 4.354 MB/s Tx: 4.342 MB/s INFO 140606466049792 13:55:39.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1603027 Rx: 4.350 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:40.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1603244 Rx: 4.350 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:41.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1603460 Rx: 4.354 MB/s Tx: 4.353 MB/s INFO 140606466049792 13:55:42.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1603677 Rx: 4.349 MB/s Tx: 4.358 MB/s INFO 140606466049792 13:55:43.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1603893 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:44.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1604110 Rx: 4.350 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:45.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1604327 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:46.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1604543 Rx: 4.350 MB/s Tx: 4.346 MB/s INFO 140606466049792 13:55:47.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1604760 Rx: 4.354 MB/s Tx: 4.350 MB/s INFO 140606466049792 13:55:48.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1604977 Rx: 4.350 MB/s Tx: 4.353 MB/s INFO 140606466049792 13:55:49.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1605194 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:50.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1605410 Rx: 4.354 MB/s Tx: 4.353 MB/s INFO 140606466049792 13:55:51.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1605627 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:52.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1605843 Rx: 4.354 MB/s Tx: 4.358 MB/s INFO 140606466049792 13:55:53.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1606060 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:54.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1606277 Rx: 4.354 MB/s Tx: 4.342 MB/s INFO 140606466049792 13:55:55.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1606493 Rx: 4.350 MB/s Tx: 4.345 MB/s INFO 140606466049792 13:55:56.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1606710 Rx: 4.349 MB/s Tx: 4.358 MB/s INFO 140606466049792 13:55:57.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1606926 Rx: 4.354 MB/s Tx: 4.349 MB/s INFO 140606466049792 13:55:58.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1607143 Rx: 4.350 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:55:59.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1607359 Rx: 4.354 MB/s Tx: 4.353 MB/s INFO 140606466049792 13:56:00.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1607576 Rx: 4.354 MB/s Tx: 4.358 MB/s INFO 140606466049792 13:56:01.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1607792 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:56:02.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1608009 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:56:03.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1608226 Rx: 4.354 MB/s Tx: 4.342 MB/s INFO 140606466049792 13:56:04.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1608442 Rx: 4.350 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:56:05.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1608659 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:56:06.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1608875 Rx: 4.354 MB/s Tx: 4.353 MB/s INFO 140606466049792 13:56:07.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1609092 Rx: 4.350 MB/s Tx: 4.349 MB/s INFO 140606466049792 13:56:08.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1609308 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:56:09.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1609525 Rx: 4.354 MB/s Tx: 4.353 MB/s INFO 140606466049792 13:56:10.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1609742 Rx: 4.354 MB/s Tx: 4.349 MB/s INFO 140606466049792 13:56:11.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1609958 Rx: 4.349 MB/s Tx: 4.353 MB/s INFO 140606466049792 13:56:12.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1610175 Rx: 4.354 MB/s Tx: 4.353 MB/s INFO 140606466049792 13:56:13.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1610392 Rx: 4.349 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:56:14.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1610608 Rx: 4.354 MB/s Tx: 4.358 MB/s INFO 140606466049792 13:56:15.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1610825 Rx: 4.358 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:56:16.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1611042 Rx: 4.354 MB/s Tx: 4.342 MB/s INFO 140606466049792 13:56:17.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1611259 Rx: 4.354 MB/s Tx: 4.354 MB/s INFO 140606466049792 13:56:18.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1611475 WARNING 140606319671040 13:56:19.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:19.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:19.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:19.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:19.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:19.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:19.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:19.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:19.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:19.8 UHDDevice.cpp:347:uhd_msg_handler: L Rx: 4.350 MB/s WARNING 140606319671040 13:56:19.9 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:19.9 UHDDevice.cpp:347:uhd_msg_handler: L INFO 140606466049792 13:56:19.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1611692 WARNING 140606319671040 13:56:20.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.7 UHDDevice.cpp:347:uhd_msg_handler: L Rx: 4.354 MB/s WARNING 140606319671040 13:56:20.8 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:20.8 UHDDevice.cpp:347:uhd_msg_handler: L INFO 140606466049792 13:56:20.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1611908 WARNING 140606319671040 13:56:20.9 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.8 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.8 UHDDevice.cpp:347:uhd_msg_handler: L Rx: 4.354 MB/s WARNING 140606319671040 13:56:21.9 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:21.9 UHDDevice.cpp:347:uhd_msg_handler: L INFO 140606466049792 13:56:21.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1612125 WARNING 140606319671040 13:56:22.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.8 UHDDevice.cpp:347:uhd_msg_handler: L Rx: 4.354 MB/s WARNING 140606319671040 13:56:22.8 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:22.9 UHDDevice.cpp:347:uhd_msg_handler: L INFO 140606466049792 13:56:22.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1612342 WARNING 140606319671040 13:56:22.9 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.8 UHDDevice.cpp:347:uhd_msg_handler: L Rx: 4.354 MB/s WARNING 140606319671040 13:56:23.8 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:23.9 UHDDevice.cpp:347:uhd_msg_handler: L INFO 140606466049792 13:56:23.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1612558 WARNING 140606319671040 13:56:23.9 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.8 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.8 UHDDevice.cpp:347:uhd_msg_handler: L Rx: 4.354 MB/s WARNING 140606319671040 13:56:24.9 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:24.9 UHDDevice.cpp:347:uhd_msg_handler: L INFO 140606466049792 13:56:24.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1612775 WARNING 140606319671040 13:56:25.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.8 UHDDevice.cpp:347:uhd_msg_handler: L Rx: 4.354 MB/s WARNING 140606319671040 13:56:25.8 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:25.9 UHDDevice.cpp:347:uhd_msg_handler: L INFO 140606466049792 13:56:25.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1612992 WARNING 140606319671040 13:56:25.9 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.5 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.6 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.7 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.8 UHDDevice.cpp:347:uhd_msg_handler: L Rx: 4.354 MB/s WARNING 140606319671040 13:56:26.8 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:26.9 UHDDevice.cpp:347:uhd_msg_handler: L INFO 140606466049792 13:56:26.9 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1613208 WARNING 140606319671040 13:56:26.9 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:27.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:27.0 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:27.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:27.1 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:27.2 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:27.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:27.3 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:27.4 UHDDevice.cpp:347:uhd_msg_handler: L WARNING 140606319671040 13:56:27.4 UHDDevice.cpp:347:uhd_msg_handler: L ^Csignal 2 received shutting down Shutting down transceiver... NOTICE 140606467434304 13:56:27.5 Transceiver.cpp:298:stop: Stopping the transceiver INFO 140606467434304 13:56:27.5 Transceiver.cpp:311:stop: Stopping the device NOTICE 140606467434304 13:56:27.5 Transceiver.cpp:324:stop: Transceiver stopped -------------- next part -------------- $ osmo-trx -e -l INFO Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU <0001> telnet_interface.c:104 telnet at 127.0.0.1 4237 <0008> control_if.c:854 CTRL at 127.0.0.1 4236 Config Settings Log Level............... INFO Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 GSM Core Address.........127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ Enabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 Tx Antennas............. '' Rx Antennas............. '' [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; UHD_3.11.0.0-0-unknown INFO 139673748260800 14:10:14.5 UHDDevice.cpp:663:open: Using discovered UHD device addr=24607:1027,driver=lime,label=LimeSDR Mini [USB 3.0] 1D3A0124D7A59C,media=USB 3.0,module=FT601,name=LimeSDR Mini,serial=1D3A0124D7A59C,type=soapy [INFO] [UHDSoapyDevice] Make connection: 'LimeSDR Mini [USB 3.0] 1D3A0124D7A59C' [INFO] [UHDSoapyDevice] Reference clock 40.00 MHz [INFO] [UHDSoapyDevice] Device name: LimeSDR-Mini [INFO] [UHDSoapyDevice] Reference: 4e+07 MHz CGEN: Freq=61.44 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=19 [INFO] [UHDSoapyDevice] LMS7002M calibration values caching Disable CGEN: Freq=80 MHz, VCO=2.56 GHz, INT=63, FRAC=0, DIV_OUTCH_CGEN=15 INFO 139673748260800 14:10:17.1 UHDDevice.cpp:480:set_antennas: Antennas configured successfully CGEN: Freq=8.66667 MHz, VCO=2.42667 GHz, INT=59, FRAC=699050, DIV_OUTCH_CGEN=139 CGEN: Freq=34.6667 MHz, VCO=2.42667 GHz, INT=59, FRAC=699050, DIV_OUTCH_CGEN=34 CGEN: Freq=138.667 MHz, VCO=2.496 GHz, INT=61, FRAC=419430, DIV_OUTCH_CGEN=8 INFO 139673748260800 14:10:17.3 UHDDevice.cpp:454:set_rates: Rates configured for LimeSDR 4 SPS MCU programming : 16384/16384 MCU Programming finished, 3028 ms [INFO] [UHDSoapyDevice] Filter calibrated. Filter order-4th, filter bandwidth set to 5 MHz.Real pole 1st order filter set to 2.5 MHz. Preemphasis filter not active [INFO] [UHDSoapyDevice] TX LPF configured [INFO] [UHDSoapyDevice] RX LPF configured INFO 139673748260800 14:10:21.2 UHDDevice.cpp:414:init_gains: Supported Tx gain range [-12; 64] INFO 139673748260800 14:10:21.2 UHDDevice.cpp:419:init_gains: Supported Rx gain range [-12; 61] INFO 139673748260800 14:10:21.2 UHDDevice.cpp:423:init_gains: Default setting Tx gain for channel 0 to 26 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 INFO 139673748260800 14:10:22.7 UHDDevice.cpp:430:init_gains: Default setting Rx gain for channel 0 to 24.5 INFO 139673748260800 14:10:22.7 UHDDevice.cpp:757:open: Single USRP: Device: FT601 Mboard 0: LimeSDR-Mini RX Channel: 0 RX DSP: 0 RX Dboard: 0 RX Subdev: SoapyRF TX Channel: 0 TX DSP: 0 TX Dboard: 0 TX Subdev: SoapyRF -- Transceiver active with 1 channel(s) INFO 139673748494080 14:10:50.0 Transceiver.cpp:685:driveControl: command is CMD POWEROFF INFO 139673748494080 14:10:50.0 Transceiver.cpp:685:driveControl: command is CMD POWEROFF INFO 139673748494080 14:10:50.2 Transceiver.cpp:685:driveControl: command is CMD RXTUNE 900200 INFO 139673748494080 14:10:50.4 UHDDevice.cpp:1145:set_freq: Tune Result: Target RF Freq: 900.200000 (MHz) Actual RF Freq: 900.199995 (MHz) Target DSP Freq: -0.000005 (MHz) Actual DSP Freq: -0.000005 (MHz) INFO 139673748494080 14:10:50.4 Transceiver.cpp:685:driveControl: command is CMD TXTUNE 945200 INFO 139673748494080 14:10:50.8 UHDDevice.cpp:1145:set_freq: Tune Result: Target RF Freq: 945.200000 (MHz) Actual RF Freq: 945.199995 (MHz) Target DSP Freq: 0.000005 (MHz) Actual DSP Freq: 0.000005 (MHz) INFO 139673748494080 14:10:50.8 Transceiver.cpp:685:driveControl: command is CMD SETTSC 7 NOTICE 139673748494080 14:10:50.8 Transceiver.cpp:791:driveControl: Changing TSC from 0 to 7 INFO 139673748494080 14:10:50.8 Transceiver.cpp:685:driveControl: command is CMD POWERON NOTICE 139673748494080 14:10:50.8 Transceiver.cpp:244:start: Starting the transceiver INFO 139673748494080 14:10:50.8 radioInterface.cpp:153:start: Starting radio device INFO 139673748494080 14:10:50.8 UHDDevice.cpp:835:start: Starting USRP... Tx calibration using MCU INTERNAL loopback Tx ch.A @ 945.2 MHz, BW: 5 MHz, RF output: BAND1, Gain: 2 Current MCU firmware: 5, DC/IQ calibration full MCU Ref. clock: 40 MHz [INFO] [UHDSoapyDevice] Tx calibration finished Tx | DC | GAIN | PHASE ---+-----+------+------ I: | -68 | 2012 | -8 Q: | -239 | 2047 | Duration: 382 ms Rx calibration using INTERNAL loopback Rx ch.A @ 900.2 MHz, BW: 5 MHz, RF input: LNAH, PGA: 12, LNA: 5, TIA: 3 Current MCU firmware: 5, DC/IQ calibration full MCU Ref. clock: 40 MHz RX | DC | GAIN | PHASE ---+-----+------+------ I: | 5 | 2047 | -26 Q: | 6 | 1994 | Duration: 210 ms [INFO] [UHDSoapyDevice] Rx calibration finished INFO 139673748494080 14:10:51.5 UHDDevice.cpp:810:flush_recv: Initial timestamp 128520 INFO 139673748494080 14:10:51.5 UHDDevice.cpp:856:start: The current time is 0.119575 seconds INFO 139673748494080 14:10:51.5 radioInterface.cpp:174:start: Radio started INFO 139673748494080 14:10:51.5 Transceiver.cpp:685:driveControl: command is CMD SETRXGAIN 1 INFO 139673746876160 14:10:51.5 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1857223 INFO 139673748494080 14:10:51.5 UHDDevice.cpp:528:setRxGain: Set RX gain to 0dB (asked for 1dB) INFO 139673748494080 14:10:51.5 Transceiver.cpp:685:driveControl: command is CMD SETPOWER 20 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 [WARNING] [UHDSoapyDevice] L CGEN: Freq=30.72 MHz, VCO=2.4576 GHz, INT=60, FRAC=461373, DIV_OUTCH_CGEN=39 INFO 139673748494080 14:10:51.7 UHDDevice.cpp:513:setTxGain: Set TX gain to 44dB (asked for 44dB) INFO 139673748494080 14:10:51.7 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 0 5 INFO 139673748494080 14:10:51.7 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 1 7 INFO 139673748494080 14:10:51.7 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 2 1 INFO 139673748494080 14:10:51.7 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 3 1 INFO 139673748494080 14:10:51.7 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 4 1 INFO 139673748494080 14:10:51.7 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 5 1 INFO 139673748494080 14:10:51.7 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 6 1 INFO 139673748494080 14:10:51.7 Transceiver.cpp:685:driveControl: command is CMD SETSLOT 7 1 [WARNING] [UHDSoapyDevice] popping from TX, samples popped 0/1020 [WARNING] [UHDSoapyDevice] L Rx: 3.822 MB/s INFO 139673746876160 14:10:52.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1857439 Tx: 4.227 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:10:53.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1857656 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:10:54.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1857872 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:10:55.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1858089 Tx: 4.354 MB/s Rx: 4.349 MB/s INFO 139673746876160 14:10:56.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1858305 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:10:57.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1858522 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:10:58.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1858738 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:10:59.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1858955 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:00.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1859171 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:01.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1859388 [WARNING] [UHDSoapyDevice] L Rx: 4.350 MB/s INFO 139673746876160 14:11:02.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1859604 Tx: 4.223 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:03.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1859821 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:04.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1860037 Tx: 4.354 MB/s Rx: 4.350 MB/s INFO 139673746876160 14:11:05.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1860254 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:06.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1860470 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:07.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1860687 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:08.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1860904 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:09.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1861120 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:10.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1861337 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:11.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1861553 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:12.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1861770 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:13.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1861987 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:14.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1862203 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:15.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1862420 Tx: 4.354 MB/s Rx: 4.349 MB/s INFO 139673746876160 14:11:16.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1862636 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:17.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1862853 Tx: 4.346 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:18.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1863070 Tx: 4.354 MB/s Rx: 4.350 MB/s INFO 139673746876160 14:11:19.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1863286 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:20.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1863503 Tx: 4.350 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:21.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1863720 Tx: 4.354 MB/s Rx: 4.350 MB/s INFO 139673746876160 14:11:22.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1863937 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:23.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1864154 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:24.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1864370 Tx: 4.346 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:25.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1864587 Tx: 4.350 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:26.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1864803 Tx: 4.350 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:27.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1865020 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:28.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1865236 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:29.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1865453 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:30.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1865669 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:31.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1865886 Tx: 4.353 MB/s Rx: 4.350 MB/s INFO 139673746876160 14:11:32.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1866102 Tx: 4.349 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:33.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1866319 Tx: 4.358 MB/s Rx: 4.350 MB/s INFO 139673746876160 14:11:34.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1866535 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:35.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1866752 Tx: 4.358 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:36.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1866968 Tx: 4.354 MB/s Rx: 4.350 MB/s INFO 139673746876160 14:11:37.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1867185 Tx: 4.342 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:38.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1867402 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:39.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1867618 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:40.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1867835 Tx: 4.354 MB/s Rx: 4.349 MB/s INFO 139673746876160 14:11:41.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1868052 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:42.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1868268 Tx: 4.354 MB/s [WARNING] [UHDSoapyDevice] L Rx: 4.350 MB/s INFO 139673746876160 14:11:43.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1868485 Tx: 4.235 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:44.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1868702 Tx: 4.346 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:45.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1868919 Tx: 4.361 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:46.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1869135 Tx: 4.353 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:47.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1869352 Tx: 4.346 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:48.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1869569 Tx: 4.361 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:49.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1869786 Tx: 4.346 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:50.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1870003 Tx: 4.361 MB/s Rx: 4.350 MB/s INFO 139673746876160 14:11:51.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1870219 Tx: 4.342 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:52.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1870436 Tx: 4.366 MB/s Rx: 4.350 MB/s INFO 139673746876160 14:11:53.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1870653 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:54.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1870870 Tx: 4.354 MB/s Rx: 4.349 MB/s INFO 139673746876160 14:11:55.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1871087 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:56.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1871303 Tx: 4.354 MB/s Rx: 4.350 MB/s INFO 139673746876160 14:11:57.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1871520 Tx: 4.349 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:58.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1871736 Tx: 4.350 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:11:59.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1871953 Tx: 4.358 MB/s Rx: 4.349 MB/s INFO 139673746876160 14:12:00.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1872170 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:12:01.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1872387 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:12:02.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1872604 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:12:03.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1872820 Tx: 4.354 MB/s Rx: 4.354 MB/s INFO 139673746876160 14:12:04.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1873037 Tx: 4.354 MB/s Rx: 4.350 MB/s INFO 139673746876160 14:12:05.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1873253 Tx: 4.346 MB/s Rx: 4.358 MB/s INFO 139673746876160 14:12:06.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1873470 [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L Rx: 4.349 MB/s [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L INFO 139673746876160 14:12:07.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1873687 [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L Rx: 4.354 MB/s [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L INFO 139673746876160 14:12:08.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1873904 [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L Rx: 4.350 MB/s [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L INFO 139673746876160 14:12:09.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1874120 [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L Rx: 4.354 MB/s [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L INFO 139673746876160 14:12:10.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1874337 [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L Rx: 4.350 MB/s [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L INFO 139673746876160 14:12:11.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1874553 [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L Rx: 4.358 MB/s [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L INFO 139673746876160 14:12:12.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1874770 [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L Rx: 4.354 MB/s [WARNING] [UHDSoapyDevice] L [WARNING] [UHDSoapyDevice] L INFO 139673746876160 14:12:13.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1874987 Rx: 4.350 MB/s INFO 139673746876160 14:12:14.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1875203 Rx: 4.354 MB/s INFO 139673746876160 14:12:15.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1875420 Rx: 4.354 MB/s INFO 139673746876160 14:12:16.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1875636 Rx: 4.354 MB/s INFO 139673746876160 14:12:17.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1875853 Rx: 4.354 MB/s INFO 139673746876160 14:12:18.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1876069 Rx: 4.350 MB/s INFO 139673746876160 14:12:19.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1876286 Rx: 4.354 MB/s INFO 139673746876160 14:12:20.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1876502 Rx: 4.354 MB/s INFO 139673746876160 14:12:21.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1876719 Rx: 4.350 MB/s INFO 139673746876160 14:12:22.6 Transceiver.cpp:1002:writeClockInterface: ClockInterface: sending IND CLOCK 1876936 ALERT 139673746908928 14:12:23.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.354 MB/s ALERT 139673746908928 14:12:23.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:23.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.350 MB/s ALERT 139673746908928 14:12:24.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:24.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.354 MB/s ALERT 139673746908928 14:12:25.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:25.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.354 MB/s ALERT 139673746908928 14:12:26.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:26.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.350 MB/s ALERT 139673746908928 14:12:27.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:27.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.354 MB/s ALERT 139673746908928 14:12:28.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:28.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.354 MB/s ALERT 139673746908928 14:12:29.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:29.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.349 MB/s ALERT 139673746908928 14:12:30.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:30.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.354 MB/s ALERT 139673746908928 14:12:31.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:31.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.354 MB/s ALERT 139673746908928 14:12:32.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:32.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.354 MB/s ALERT 139673746908928 14:12:33.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:33.9 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.0 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.1 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.2 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.3 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.4 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.5 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out Rx: 4.354 MB/s ALERT 139673746908928 14:12:34.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.6 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.7 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ALERT 139673746908928 14:12:34.8 UHDDevice.cpp:1067:writeSamples: UHD: Device send timed out ^Csignal 2 received shutting down Shutting down transceiver... NOTICE 139673748260800 14:12:34.9 Transceiver.cpp:298:stop: Stopping the transceiver terminate called without an active exception signal 6 received talloc report on 'OsmoTRX' (total 9 bytes in 4 blocks) telnet_connection contains 1 bytes in 1 blocks (ref 0) 0x15cd1a0 struct trx_ctx contains 8 bytes in 1 blocks (ref 0) 0x15685b0 msgb contains 0 bytes in 1 blocks (ref 0) 0x1568540 full talloc report on 'OsmoTRX' (total 9 bytes in 4 blocks) telnet_connection contains 1 bytes in 1 blocks (ref 0) 0x15cd1a0 struct trx_ctx contains 8 bytes in 1 blocks (ref 0) 0x15685b0 msgb contains 0 bytes in 1 blocks (ref 0) 0x1568540 Aborted (core dumped) From pespin at sysmocom.de Mon Mar 5 16:08:22 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 5 Mar 2018 17:08:22 +0100 Subject: osmo-trx and limesdr mini In-Reply-To: References: Message-ID: Hi Cyril, Those send timeout issues are not limesdr-mini specific, I'm having them too with the non-mini one. You are most probably hitting this bug: https://projects.osmocom.org/issues/2343 The crash appears after you pressed CTRL+C on the terminal to stop osmo-trx, so it's not a big issue. -- - 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 cyril.deletre at gmail.com Mon Mar 5 18:43:25 2018 From: cyril.deletre at gmail.com (Cyril) Date: Mon, 05 Mar 2018 18:43:25 +0000 Subject: osmo-trx and limesdr mini In-Reply-To: References: Message-ID: Well, maybe it?s not clear in the logs but I press CTRL+C after it crashes. On Mon 5 Mar 2018 at 17:08, Pau Espin Pedrol wrote: > Hi Cyril, > > Those send timeout issues are not limesdr-mini specific, I'm having them > too with the non-mini one. > > You are most probably hitting this bug: > https://projects.osmocom.org/issues/2343 > > The crash appears after you pressed CTRL+C on the terminal to stop > osmo-trx, so it's not a big issue. > > -- > - 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 > -- Cyril -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Mon Mar 5 18:47:40 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Mon, 5 Mar 2018 19:47:40 +0100 Subject: osmo-trx and limesdr mini In-Reply-To: References: Message-ID: <2535820c-4310-634e-5629-9e49f4e087c1@sysmocom.de> Hi, Can you then attach gdb (or enable coredumps) and check if the stacktrace for the crash is similar to the bug I provided? Feel free to update that one if it's the same, or create a new one otherwise. -- - 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 Mar 5 21:42:54 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 5 Mar 2018 22:42:54 +0100 Subject: fsm4 branch and handover_test.c Message-ID: <20180305214254.GA3551@my.box> Hi Philipp, I promised you to look at handover_test.c on the new fsm4 branch. Looking at it now, I immediately ran into FSM events being dropped on the floor because it was in the wrong state. When I initially fix that, the test runs into the MGCP FSM not existing. So at the end of the day, it is all related to the recently added FSMs and how they interact, and it seems to me that you are more familiar with those than me. In other words, I'm playing the ball back into your corner now: Look at osmo-bsc branch neels/fsm4, here are the differences to pmaier/fsm4: - right at the start, I add a patch to properly wrap abis_rsl_sendmsg(). That's just cosmetic, really. It was doing its job well, just I don't trust that implicit linking. It's at the start because I also submitted it to gerrit. 5eaaf6120e21 (I'd link to git.osmocom.org but after 10 minutes the branch still isn't synced there, strange.) - I add the DMSC logging category to handover_test.c. That enables the FSM's error messages to be logged. This only makes sense as long as that FSM is actually logging on DMSC, which doesn't seem a good fit. 8128a49a6c6ce4ae - I kick the gscon into the ACTIVE state when a conn is created. That might be taking a shortcut, since I'm not sure how e.g. the conn->user_plane.fi_bts should be populated... c2f90c36c445b2a38 So, e.g. when running './handover_test 1', my code state enabled the logging for them and uncovered the errors: DMSC handover_logic.c:135 SUBSCR_CONN[0x564f2a1d3b70]{INIT}: Event HO_START not permitted and then DMSC handover_logic.c:135 SUBSCR_CONN[0x564f2a1d3b70]{WAIT_CC}: Event HO_START not permitted These two are fixed, and now I'm stuck at: DMSC handover_logic.c:333 SUBSCR_CONN[0x560525a1cb70]{WAIT_HO_COMPL}: Received Event HO_COMPL DMSC bsc_subscr_conn_fsm.c:710 SUBSCR_CONN[0x560525a1cb70]{WAIT_HO_COMPL}: state_chg to WAIT_MDCX_BTS_HO Assert failed fi ../../../../src/osmo-mgw/src/libosmo-mgcp-client/mgcp_client_fsm.c:603 i.e. the handover_test.c is trying to indicate a 'Handover Complete' to the libbsc machinery by calling handover_test.c:send_ho_complete(), and it runs into a wall of the fake conn having conn->user_plane.fi_bts == NULL. At this point I could start figuring out how to fake the fi_bts, but in fact I assume you're more proficient in that area, so please take over from here. Thanks! ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From holger at freyther.de Mon Mar 5 23:15:46 2018 From: holger at freyther.de (Holger Freyther) Date: Mon, 5 Mar 2018 23:15:46 +0000 Subject: GSM tester scenarios and beyond Message-ID: <92578B8B-8D5A-4D35-A6A4-50EF4FB6302A@freyther.de> Hey neels, pespin, while looking at configuration handling for the MS driver I started to have sone questions about scenarios. I see that we have multiple yaml files and through scenarios can control ciphering, the timeslot configuration, which BTS model to test, and more. What would it take to get this abstraction one step further? When I diff the aoio_sms and sms suite the difference is in setup (and then naming of msc vs. nitb)? Wouldn't this be something we can get into the scenario as well? The requirements for this test are two connected and routable subscribers? low priority thing but what do you think? holger From holger at freyther.de Mon Mar 5 23:28:49 2018 From: holger at freyther.de (Holger Freyther) Date: Mon, 5 Mar 2018 23:28:49 +0000 Subject: MS driver: GSM tester config integration Message-ID: Hey, pespin left a good comment about the question of how the MS driver and the GSM tester could be better integrated. I was about to write some argparse code for the MS driver but I think it is best to make this configurable as a scenario. In terms of scenario knobs I can see: - #MS - CDF function - IMSI generator (start with XXX and count upwards) - virtphy vs. trxcon? The actual test would remain separate (and maybe turn it into a suite at some point in the future). What do you think? What should I obey when parsing/handling config? holger From nhofmeyr at sysmocom.de Tue Mar 6 09:33:10 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 6 Mar 2018 10:33:10 +0100 Subject: GSM tester scenarios and beyond In-Reply-To: <92578B8B-8D5A-4D35-A6A4-50EF4FB6302A@freyther.de> References: <92578B8B-8D5A-4D35-A6A4-50EF4FB6302A@freyther.de> Message-ID: <20180306093310.5aqhhqvhw3tbhw3b@ass40.sysmocom.de> On Mon, Mar 05, 2018 at 11:15:46PM +0000, Holger Freyther wrote: > Hey neels, pespin, > > while looking at configuration handling for the MS driver I started to have sone questions about scenarios. I see that we have multiple yaml files and through scenarios can control ciphering, the timeslot configuration, which BTS model to test, and more. > > What would it take to get this abstraction one step further? When I diff the aoio_sms and sms suite the difference is in setup (and then naming of msc vs. nitb)? Wouldn't this be something we can get into the scenario as well? The requirements for this test are two connected and routable subscribers? My plan was to instead provide convenience "set up the network" functions to call from the test. The point is we don't always know what kind of net programs we want to start, in which order, how. In most cases we do start it up so that it works, but some tests may want to deliberately omit one component, start and stop it again, and so forth. So it's for me not a part in the scenario; the scenario is all about: which hardware and which resources do we get. The "what do we run" should be completely in the test script. And about those "shortcut" functions to setup the standard network, we just never got around to it and went with copy paste for the time being. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From Jan.Bruckner at escrypt.com Tue Mar 6 09:58:08 2018 From: Jan.Bruckner at escrypt.com (Bruckner Jan (ETAS-SEC/ECT-Mu)) Date: Tue, 6 Mar 2018 09:58:08 +0000 Subject: Problems with A5/3 encryption Message-ID: Dear list, I'm having trouble using the A5/3 encryption in my setup. A5/1 works perfectly fine [attachment a5_1.pcapng]. As soon as I switch to A5/3 and e.g. send an SMS, the last valid message I see in the Wireshark traces of the GSMTAP of osmo-bts-trx is the Ciphering Mode Command requesting A5/3. After that, several messages arrive at the bts, but it seems like it can't make any sense of them. The MS repeatedly tries to send the SMS but never succeeds [attachment a5_3.pcapng]. Both MSs are connected to the same bts. According to the Classmarks of all MSs, A5/1 as well as A5/3 are supported. This is my Setup: - USRP N210 - osmo-trx - osmo-bts-trx - osmo-nitb - osmo-pcu - osmo-sgsn - osmo-ggsn I'm using a Debian 9 VM and tried both the packages from osmocom-latest as well as osmocom-nightly. The MSs I've tested are two Nexus 6 and one Samsung Galaxy S I9000. All three with sysmocom nano USIMs. Could the decryption at the bts be incorrect? Has anyone tested/used it recently? I'll be happy to provide additional information if needed. Thanks, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: a5_3.pcapng Type: application/octet-stream Size: 69644 bytes Desc: a5_3.pcapng URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: a5_1.pcapng Type: application/octet-stream Size: 11644 bytes Desc: a5_1.pcapng URL: From nhofmeyr at sysmocom.de Tue Mar 6 10:59:24 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 6 Mar 2018 11:59:24 +0100 Subject: GSM tester scenarios and beyond In-Reply-To: <20180306093310.5aqhhqvhw3tbhw3b@ass40.sysmocom.de> References: <92578B8B-8D5A-4D35-A6A4-50EF4FB6302A@freyther.de> <20180306093310.5aqhhqvhw3tbhw3b@ass40.sysmocom.de> Message-ID: <20180306105924.xlfzakx6hhew4ot5@ass40.sysmocom.de> On Tue, Mar 06, 2018 at 10:33:10AM +0100, Neels Hofmeyr wrote: > My plan was to instead provide convenience "set up the network" functions > to call from the test. Just remembered: also, I initially had the idea of being able to have net components running across tests. The idea was to have one, like, "0_setup" test that would start test components, and pass ownership of the running processes a level up to the scenario, so that the processes remain running and are available for all of the remaining tests of that scenario (as it is now, all processes are shut down when the test case ends). The only benefit here is that a number of test cases don't each setup and tear down the core net, so they would be a bit faster. And there's also the drawback of complexity about handling situations where one test manages to crash a program which then affects subsequent tests -- but I guess I would just let all remaining tests fail then. So I guess all I would implement would be some convenience function that allows reducing code dup across the test functions, for tests that just want a working network with the modems subscribed, ready for testing. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From domi at tomcsanyi.net Tue Mar 6 11:14:27 2018 From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi_Domonkos?=) Date: Tue, 6 Mar 2018 12:14:27 +0100 Subject: Problems with A5/3 encryption In-Reply-To: References: Message-ID: <1028CB04-C63E-4570-9BB4-B15872D7B556@tomcsanyi.net> Hi Jan, Do you have traces of the attach/authentication? It seems like for some reason your MS don't like A5/3, because they are supposed to reply with Cipher Mode Complete. So top of my head I had the thought there might be something wrong with the initial establishment of the keys. Cheers, Domi > 2018. m?rc. 6. d?tummal, 10:58 id?pontban Bruckner Jan (ETAS-SEC/ECT-Mu) ?rta: > > Dear list, > > I?m having trouble using the A5/3 encryption in my setup. A5/1 works perfectly fine [attachment a5_1.pcapng]. As soon as I switch to A5/3 and e.g. send an SMS, the last valid message I see in the Wireshark traces of the GSMTAP of osmo-bts-trx is the Ciphering Mode Command requesting A5/3. After that, several messages arrive at the bts, but it seems like it can?t make any sense of them. The MS repeatedly tries to send the SMS but never succeeds [attachment a5_3.pcapng]. Both MSs are connected to the same bts. > > According to the Classmarks of all MSs, A5/1 as well as A5/3 are supported. > This is my Setup: > - USRP N210 > - osmo-trx > - osmo-bts-trx > - osmo-nitb > - osmo-pcu > - osmo-sgsn > - osmo-ggsn > I?m using a Debian 9 VM and tried both the packages from osmocom-latest as well as osmocom-nightly. > The MSs I?ve tested are two Nexus 6 and one Samsung Galaxy S I9000. All three with sysmocom nano USIMs. > > Could the decryption at the bts be incorrect? Has anyone tested/used it recently? > I?ll be happy to provide additional information if needed. > > Thanks, > Jan > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Tue Mar 6 11:32:23 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 6 Mar 2018 12:32:23 +0100 Subject: MS driver: GSM tester config integration In-Reply-To: References: Message-ID: <20180306113222.mxyaxraaargcywgn@ass40.sysmocom.de> On Mon, Mar 05, 2018 at 11:28:49PM +0000, Holger Freyther wrote: > Hey, > > pespin left a good comment about the question of how the MS driver and the GSM tester could be better integrated. I was about to write some argparse code for the MS driver but I think it is best to make this configurable as a scenario. > > In terms of scenario knobs I can see: > > - #MS > - CDF function what's CDF? > - IMSI generator (start with XXX and count upwards) We have MSISDN and I think LAC generated on-the-fly, with state in the file system. You could basically copy-paste that MSISDN generator code to make an IMSI generator. > - virtphy vs. trxcon? (no idea) > The actual test would remain separate (and maybe turn it into a suite at some point in the future). What do you think? What should I obey when parsing/handling config? The way I see it, you implement a "copy" of the mobile.py interface to, instead of talking to ofono, talk to the virtphy/MS, whatever it's called. (Like Pau said.) Then either: - We define a limited specific number of those virtual modems in the resources.conf to be available, and add a specific trait, as in a 'type: virtual' or something. You would then add a scenario that asks for the modems to be of 'type: virtual', and run the exact tests from the existing suites, just with virtual modems instead of physical ones. - Or we could even auto-generate the entire virtual modem, sort of in the way that we start core net components at the moment, by calling a function from within the test case. For example, the osmo-msc is not a resource handled in scenarios, we just ask for IP address resources and hand one to the osmo-msc startup. Then there would be a separate *suite* with its conf not even asking for any modem resources, just its tests call a function that ask to setup virtual modems on-the-fly. A drawback here is that you can't just re-run existing suites -- you can't just swap out the physical modem kind for a virtual one and run the exact same suite, you have to write different tests that launch virtual modems from the test case script. It depends on: a) do you want to run the existing tests on the virtual modems at all? b) how physical/resource-like vs. software-component-running-like is a virtual modem? For virtual modem being a resource, I'd add only separate scenario definitions and possibly add tests to existing suites if that makes any sense; for virtual modems started up like a software component, I'd add an entirely separate suite even for the first test implemented (because then that suite wouldn't ask for 'modem' resources to begin with). BTW, in general, a virtphy issue could be the multicast. I saw stsp having some trouble keeping the multicast from seeping out of all the interfaces. We probably want the osmo-gsm-tester to contain that somehow. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From pespin at sysmocom.de Tue Mar 6 12:20:11 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Tue, 6 Mar 2018 13:20:11 +0100 Subject: MS driver: GSM tester config integration In-Reply-To: References: Message-ID: Hi, I guess you are referring to my comment in [1]. You can reuse suite and resources management utilities already present in osmo-gsm-tester. The easiest way to do that would be to create a new implementation for class Modem which would start a mobile process underneath. Then in suite() when requesting a modem add a function to allocate class ModemOfono or ModemOsmoMobile based on config type, similar to how it is done for different bts (see example/resources.conf and src/osmo_gsm_tester/suite.py). Then, you have your resources files with 300 modems: modem: - label: mobile_xyz type: osmo-mobile auth_algo: 'comp128v1' ciphers: [a5_0, a5_1] features: ['sms', 'voice', 'ussd', 'gprs'] times: 300 Then create a suite with a suite.conf containing your scenario (see suites/aoip_sms/suite.conf): resources: ip_address: - times: 6 # msc, bsc, hlr, stp, mgw*2 bts: - times: 1 modem: - times: 300 features: - sms Then, create a test which manages all those (see suites/aoip_sms/mo_mt_sms.py): #!/usr/bin/env python3 from osmo_gsm_tester.testenv import * while True: modems = [] try: # we could add a suite.get_num_resources(type='modem') API instead m = suite.modem() modems.append(m) except NoResourceExn: break; # Then do here whatever you like to do with them, like register them, etc. I think that CDF functions and IMSI generation and alike are really attach to the test and they are really not resources, so no need to "configure" them. This topic matches with your other mail thread too. We already talked with Neels about providing a set of functionality helpers and repeating code used in tests, in order to keep tests small and easy to follow. My bet here would be to have code like CDF functions which is not used internally by osmo-gsm-tester classes into this kind of library (which can be imported like from osmo_gsm_tester.testenv import *). Same goes for IMSI generation, then use modem.set_imsi(generated_imsi) or whatever before calling modem.connect(). If you want to avoid IMSI collision between consecutive tests, then add it to osmo-gsm-tester resource.py (see next_lac() for instance). About using virtphy, trxcon and all these stuff, we have the problem that the ARFCN config is still not completely arranged and implemented. I arrived to some good proposal after several patch revision with Neels, which can be found in [2], but still missing the actual implementation. The idea I have in mind would be to add an extra attribute to arfcn resources called "group" which allows to have separate groups of arfcn, for instance phy-air vs virt, but also phy-dn1 vs phy-dn2 in case we have several non colliding distributions networks (Distributed network = MS and BTS connected through wires). Then each resource playing with arfcn should have the attribute "arfcn-group: xyz" to know to which arfcn medium is it connected. This will be used by the algorithm in [2] to manage arfcn correctly or error if the combination specificed in the scenario is not possible (for instance explicitly requesting a phy BTS but only having virtphy MS). We could Add DistributionNetwork class if needed, which could be accessed and started from the different objects using them, like ms.dn() or bts.dn(). [1] https://gerrit.osmocom.org/#/c/6919/ [2] https://osmocom.org/issues/2230 -- - 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 Jan.Bruckner at escrypt.com Tue Mar 6 13:03:30 2018 From: Jan.Bruckner at escrypt.com (Bruckner Jan (ETAS-SEC/ECT-Mu)) Date: Tue, 6 Mar 2018 13:03:30 +0000 Subject: Problems with A5/3 encryption In-Reply-To: <1028CB04-C63E-4570-9BB4-B15872D7B556@tomcsanyi.net> References: <1028CB04-C63E-4570-9BB4-B15872D7B556@tomcsanyi.net> Message-ID: <4a6d021926e34f5eb3d1946d80975424@escrypt.com> Hi Domi, I have attached another trace containing the following: - Location Update + Authentication of the MS that will send the SMS (packets 1-45) - Sending and receiving an SMS (text: ?a5/1?) with encryption set to A5/1 (packets 46-140) - works - Sending an SMS (text: ?a5/3?) with encryption set to A5/3 (packets 141-730) - the MS tries to send several times until it gives up. No Ciphering Mode Complete is received. - Switching back to A5/1 and resending the SMS with text "a5/3" (packets 731-827) - works I hope that helps. Thanks, Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: a5_1_3_with_LU_Auth.pcapng Type: application/octet-stream Size: 96324 bytes Desc: a5_1_3_with_LU_Auth.pcapng URL: From rafael at riseup.net Tue Mar 6 13:17:32 2018 From: rafael at riseup.net (Rafael Diniz) Date: Tue, 6 Mar 2018 10:17:32 -0300 Subject: OsmoBsc_Nat with osmux configuration example Message-ID: Hi all, Does anyone have a working OsmoBsc_Nat with osmux working example? I just want to take a look in osmux, so it doesn't matter if it's with old NITB-era stack or new split stack. Thanks, Rafael Diniz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nhofmeyr at sysmocom.de Tue Mar 6 16:10:03 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 6 Mar 2018 17:10:03 +0100 Subject: Problems with A5/3 encryption In-Reply-To: <4a6d021926e34f5eb3d1946d80975424@escrypt.com> References: <1028CB04-C63E-4570-9BB4-B15872D7B556@tomcsanyi.net> <4a6d021926e34f5eb3d1946d80975424@escrypt.com> Message-ID: <20180306161003.gixgtlr7kuh3zv5e@ass40.sysmocom.de> Hi Jan, A5/1 works, which means that your auth keys in the SIM and subscriber database match. In the CM Service Request, your MS indicates that it is capable of A5/3. (In the Classmark 2) I see that you only have one Location Updating with A5/1. It should work to switch to A5/3 on-the-fly, but just for curiosity, you could try to detach and re-attach the phone after switching to A5/3. You write that you are using osmo-nitb. Does the problem persist if you use osmo-bsc + osmo-msc + osmo-hlr instead? See: https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box Other than that I can't see anything wrong with anything. If you switch back and forth between A5/3 and /1, do the results remain stable? So it's not your SDR coincidentally clock-unsyncing in the wrong moment by coincidence? Seems curious that recently there have been other questions about auth / ciph not working for specific osmo-bts-trx variants. There is a faint possibility that one thing or other doesn't get encoded/decoded right?? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From pmaier at sysmocom.de Tue Mar 6 16:57:46 2018 From: pmaier at sysmocom.de (Philipp Maier) Date: Tue, 6 Mar 2018 17:57:46 +0100 Subject: fsm4 branch and handover_test.c In-Reply-To: <20180305214254.GA3551@my.box> References: <20180305214254.GA3551@my.box> Message-ID: <1a9b24b3-99cb-0cdb-1ba4-6ea5c88bbf84@sysmocom.de> Hello Neels, > I'm playing the ball back into your corner now: I managed to fix the unit tests now. I wrapped the MGCP client FSM API functions mgcp_conn_delete() and mgcp_conn_delete(). The delete just does nothing and lets the GSCON FSM think that everything went fine. The modify just dispatches the GSCON_EV_MGW_MDCX_RESP_BTS signal back to the GSCON fsm and tricks it into thinking that all MGCP operations went well. I hadd to do a little hacking because the reference pointer to the MGCP client FSM is unpopulated, but to me this looks ok. I documented the details of this in the code. All unit tests now pass fine and I think we are finally there. I have put the current status on pmaier/fsm5. If everything is fine I would squash everything between 4b159cb6f39e7f0516b191575f4420819de3606e and 8f9d6124c5eb6ae11fea7dd5113c15775d8ecc99 into one commit and give it one last TTCN3 test run before I would submit it into review tomorrow. best regards, Philipp -- Philipp Maier 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 holger at freyther.de Tue Mar 6 17:25:13 2018 From: holger at freyther.de (Holger Freyther) Date: Tue, 6 Mar 2018 17:25:13 +0000 Subject: GSM tester scenarios and beyond In-Reply-To: <20180306105924.xlfzakx6hhew4ot5@ass40.sysmocom.de> References: <92578B8B-8D5A-4D35-A6A4-50EF4FB6302A@freyther.de> <20180306093310.5aqhhqvhw3tbhw3b@ass40.sysmocom.de> <20180306105924.xlfzakx6hhew4ot5@ass40.sysmocom.de> Message-ID: <3AB0B903-1FD7-4549-8CD9-A7193A950317@freyther.de> > On 6. Mar 2018, at 10:59, Neels Hofmeyr wrote: > > The only benefit here is that a number of test cases don't each setup and > tear down the core net, so they would be a bit faster. And there's also > the drawback of complexity about handling situations where one test > manages to crash a program which then affects subsequent tests -- but I > guess I would just let all remaining tests fail then. For optimization the state of CRIU might be good enough. Once a network is up you might be able to take a snapshot (and resume it). But we probably don't have this problem yet. > So I guess all I would implement would be some convenience function that > allows reducing code dup across the test functions, for tests that just > want a working network with the modems subscribed, ready for testing. Makes sense to solve it like this. I haven't looked at TTCN-3 test composition but I do like the Phexample[1] approach. In one test one can use the result of other tests. E.g. something like this: smpp = suite.given_a_configured_network().smpp_interface() smpp.submit_sm... Anyway... Talk is cheap. Given that a scenario is the merged config, would you take changes to accept the rename (scenario->config)? holger [1] http://smalltalkthoughts.blogspot.hk/2009/11/phexample-because-examples-expand-on.html From laforge at gnumonks.org Tue Mar 6 18:44:14 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 6 Mar 2018 19:44:14 +0100 Subject: OsmoBsc_Nat with osmux configuration example In-Reply-To: References: Message-ID: <20180306184414.GA29872@nataraja> Hi Rafael, On Tue, Mar 06, 2018 at 10:17:32AM -0300, Rafael Diniz wrote: > Does anyone have a working OsmoBsc_Nat with osmux working example? I > just want to take a look in osmux, so it doesn't matter if it's with old > NITB-era stack or new split stack. osmux was originally implemented in osmo-bsc + osmo-bsc_nat for SCCP-Lite You will need a MSC that implement SCCP-Lite in order to set it up. The "new" osmo-bsc and osmo-msc implement the much more recent and officially 3GPP specified "AoIP" over M3UA instead of SCCPlite. While this setup is working, there is neither a bsc-nat for AoIP yet, nor is Osmux yet fully integrated into this configuration. The plan is to be able to have osmux as an alternative to native RTP/IP between the BSC-colocated OsmoMGW and the MSC-colocated OmsoMGW. So basically, OsmoMGW acts as a converter between classic RTP/IP and OSMUX. In this case the user plane would be something like BTS--[RTP]--BSC/MGW--[OSMUX]--MSC/MGW--[RTP]--SIP This plan has not been completed yet, but we are actively working towards it. During past months, progress has been slow due to the large number of regressions and other bugs, which prompted our main attention towards implementing testsuites for the various Osmocom elements to achive higher overall code quality and to be able to maintain that quality by continuous automatic testing. If somebody for some reason wants to have an AoIP bsc-nat, then we would likely also put an OsmoMGW to it. This would look like: BTS--[RTP]--BSC/MGW--[OSMUX]--BSCNAT/MGW--[RTP]--MSC/MGW--[RTP]--SIP But currently there is no strong requirement or clear roadmap on this particular feature/functionality. More immediate priorities from current point of view are: * improve coverage of automatic testing of each Osmocom element * resolve bugs found by the existing test suites * automatic testing of dynamic PDCH switching * automatic testing of intra-BSC hand-over * support for inter-BSC hand-over on AoIP side in OsmoBSC + OsmoMSC * support for 3GPP LCLS (local call local switch) in OsmoBSC + OsmoMSC * support of Osmux in OsmoMGW for BSC and MSC co-located OsmoMGW * support for 3GGPP IuUP in OsmoMGW (for 2G-to-3G calls and vice-versa) 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 rafael at riseup.net Wed Mar 7 03:18:29 2018 From: rafael at riseup.net (Rafael Diniz) Date: Wed, 7 Mar 2018 00:18:29 -0300 Subject: OsmoBsc_Nat with osmux configuration example In-Reply-To: <20180306184414.GA29872@nataraja> References: <20180306184414.GA29872@nataraja> Message-ID: <2f8c70f5-bf5e-fdbd-350c-1e4d08238510@riseup.net> Hi Harald, Thanks for the detailed explanation. I understand that house keeping is very important in a growing code base like the Osmocom mobile phone stack. The plans for osmux really match the use cases of sat. backhaul for rural communities. Btw, one question I have, with LCLS, is it possible to have zero voice traffic to MSC in a local call, right? Thanks, Rafael Diniz On 03/06/2018 03:44 PM, Harald Welte wrote: > Hi Rafael, > > On Tue, Mar 06, 2018 at 10:17:32AM -0300, Rafael Diniz wrote: >> Does anyone have a working OsmoBsc_Nat with osmux working example? I >> just want to take a look in osmux, so it doesn't matter if it's with old >> NITB-era stack or new split stack. > > osmux was originally implemented in osmo-bsc + osmo-bsc_nat for SCCP-Lite > > You will need a MSC that implement SCCP-Lite in order to set it up. > > The "new" osmo-bsc and osmo-msc implement the much more recent and officially > 3GPP specified "AoIP" over M3UA instead of SCCPlite. While this setup is > working, there is neither a bsc-nat for AoIP yet, nor is Osmux yet fully > integrated into this configuration. > > The plan is to be able to have osmux as an alternative to native RTP/IP > between the BSC-colocated OsmoMGW and the MSC-colocated OmsoMGW. So basically, > OsmoMGW acts as a converter between classic RTP/IP and OSMUX. In this > case the user plane would be something like > BTS--[RTP]--BSC/MGW--[OSMUX]--MSC/MGW--[RTP]--SIP > > This plan has not been completed yet, but we are actively working > towards it. During past months, progress has been slow due to the large > number of regressions and other bugs, which prompted our main attention > towards implementing testsuites for the various Osmocom elements to > achive higher overall code quality and to be able to maintain that > quality by continuous automatic testing. > > If somebody for some reason wants to have an AoIP bsc-nat, then we would likely > also put an OsmoMGW to it. This would look like: > > BTS--[RTP]--BSC/MGW--[OSMUX]--BSCNAT/MGW--[RTP]--MSC/MGW--[RTP]--SIP > > But currently there is no strong requirement or clear roadmap on this > particular feature/functionality. > > More immediate priorities from current point of view are: > * improve coverage of automatic testing of each Osmocom element > * resolve bugs found by the existing test suites > * automatic testing of dynamic PDCH switching > * automatic testing of intra-BSC hand-over > * support for inter-BSC hand-over on AoIP side in OsmoBSC + OsmoMSC > * support for 3GPP LCLS (local call local switch) in OsmoBSC + OsmoMSC > * support of Osmux in OsmoMGW for BSC and MSC co-located OsmoMGW > * support for 3GGPP IuUP in OsmoMGW (for 2G-to-3G calls and vice-versa) > > Regards, > Harald > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From Jan.Bruckner at escrypt.com Wed Mar 7 11:14:25 2018 From: Jan.Bruckner at escrypt.com (Bruckner Jan (ETAS-SEC/ECT-Mu)) Date: Wed, 7 Mar 2018 11:14:25 +0000 Subject: Problems with A5/3 encryption In-Reply-To: <20180306161003.gixgtlr7kuh3zv5e@ass40.sysmocom.de> References: <1028CB04-C63E-4570-9BB4-B15872D7B556@tomcsanyi.net> <4a6d021926e34f5eb3d1946d80975424@escrypt.com> <20180306161003.gixgtlr7kuh3zv5e@ass40.sysmocom.de> Message-ID: <7dcb09b7cca34de18fb7c9025792f5b2@escrypt.com> Hi Neels, > I see that you only have one Location Updating with A5/1. It should work to switch to A5/3 on-the-fly, but just for curiosity, you could try to detach and re-attach the phone after switching to A5/3. I just tested that. It does not change the behavior. As soon as I switch to A5/3 the BTS never receives a Ciphering Mode Complete, after having sent the Ciphering Mode Command for A5/3 to the MS. This happens for SMS as well as the whole Location Update/Authentication/TMSI-Relocation procedure. Trying to attach the MS after enabling A5/3, the MS is not able to attach successfully and continuously tries to attach until it gives up. Similar to how it keeps trying to send an SMS with A5/3 enabled. I have attached another trace of the attach and detach with A5/0 (works), then A5/1 (works) and finally A5/3 (fails, tried several times). For the A5/3 attach, there is no Authentication Request/Reply. But also in cases where the Authentication is performed the following A5/3 ciphering fails in the same way. > You write that you are using osmo-nitb. Does the problem persist if you use osmo-bsc + osmo-msc + osmo-hlr instead? See: https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In _The_Box I will try to test that setup and let you know if it helps. > If you switch back and forth between A5/3 and /1, do the results remain stable? So it's not your SDR coincidentally clock-unsyncing in the wrong moment by coincidence? I tested it many times, switching between A5/3,1 and 0 and using different phones. A5/1 (and 0 of course) works every single time. A5/3 did not work a single time. I'd say it's safe to assume that it's not the SDR failing in some way. Jan -------------- next part -------------- A non-text attachment was scrubbed... Name: attach_a5_0_1_3.pcapng Type: application/octet-stream Size: 87624 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6732 bytes Desc: not available URL: From pespin at sysmocom.de Wed Mar 7 11:57:04 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 7 Mar 2018 12:57:04 +0100 Subject: OsmoBsc_Nat with osmux configuration example In-Reply-To: <2f8c70f5-bf5e-fdbd-350c-1e4d08238510@riseup.net> References: <20180306184414.GA29872@nataraja> <2f8c70f5-bf5e-fdbd-350c-1e4d08238510@riseup.net> Message-ID: <8a62440e-d3e0-ebcd-dbed-6b25c1e79102@sysmocom.de> Hi Rafael, > The plans for osmux really match the use cases of sat. backhaul for > rural communities. Btw, one question I have, with LCLS, is it possible > to have zero voice traffic to MSC in a local call, right? > Indeed that should possible with LCLS. There are plans toadd support for it in osmocom stack, see https://osmocom.org/versions/128 -- - 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 Mar 7 12:46:42 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 7 Mar 2018 13:46:42 +0100 Subject: GSM tester scenarios and beyond In-Reply-To: <3AB0B903-1FD7-4549-8CD9-A7193A950317@freyther.de> References: <92578B8B-8D5A-4D35-A6A4-50EF4FB6302A@freyther.de> <20180306093310.5aqhhqvhw3tbhw3b@ass40.sysmocom.de> <20180306105924.xlfzakx6hhew4ot5@ass40.sysmocom.de> <3AB0B903-1FD7-4549-8CD9-A7193A950317@freyther.de> Message-ID: <20180307124642.GA5344@my.box> On Tue, Mar 06, 2018 at 05:25:13PM +0000, Holger Freyther wrote: > Anyway... Talk is cheap. Given that a scenario is the merged config, would > you take changes to accept the rename (scenario->config)? A scenario is mainly a selection of which hardware (resources) to use. The finalization of the config templates is just one result of the chosen scenario. I still prefer "scenario" :) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Wed Mar 7 12:56:51 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 7 Mar 2018 13:56:51 +0100 Subject: Problems with A5/3 encryption In-Reply-To: <7dcb09b7cca34de18fb7c9025792f5b2@escrypt.com> References: <1028CB04-C63E-4570-9BB4-B15872D7B556@tomcsanyi.net> <4a6d021926e34f5eb3d1946d80975424@escrypt.com> <20180306161003.gixgtlr7kuh3zv5e@ass40.sysmocom.de> <7dcb09b7cca34de18fb7c9025792f5b2@escrypt.com> Message-ID: <20180307125651.GB5344@my.box> On Wed, Mar 07, 2018 at 11:14:25AM +0000, Bruckner Jan (ETAS-SEC/ECT-Mu) wrote: > I just tested that. It does not change the behavior. As soon as I switch to > A5/3 the BTS never receives a Ciphering Mode Complete The details there are that the Ciphering Mode Command is asking to start ciphering on the air, and the Ciphering Mode Complete is already sent ciphered. So it might be received, but the received data may be discarded as gibberish. It would be good if anyone out there could try to reproduce the error using an SDR based BTS. You're also welcome to create a ticket on the osmocom.org redmine. ~N -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From holger at freyther.de Wed Mar 7 16:37:14 2018 From: holger at freyther.de (Holger Freyther) Date: Wed, 7 Mar 2018 16:37:14 +0000 Subject: MS driver: GSM tester config integration In-Reply-To: References: Message-ID: <50479DDA-8C36-4408-B68E-3BB139BF6815@freyther.de> > On 6. Mar 2018, at 12:20, Pau Espin Pedrol wrote: > > Hi, Hey Neels, Pau, > I guess you are referring to my comment in [1]. You can reuse suite and resources management utilities already present in osmo-gsm-tester. The easiest way to do that would be to create a new implementation for class Modem which would start a mobile process underneath. Then in suite() when requesting a modem add a function to allocate class ModemOfono or ModemOsmoMobile based on config type, similar to how it is done for different bts (see example/resources.conf and src/osmo_gsm_tester/suite.py). thanks to both of you for the detailed responses. I like the idea, it solves the coordination between setting up the core network and the phones. The approach looks generally feasible and I wish we had this idea earlier. Unfortunately I had only planned to do LUA bindings, the orchestration was already an extra and I blew all my time in trying to make asyncio work and the scaling/concurrency issues with python. My intention with the original mail was to find a middle step. Better integration but not full. From my point of view: Middle step: Use the test scenario configuration (maybe even the suite class). Make the UL test reusable (and extend to SMS and Calls) Big step (as proposed): The "scheduling"/slow start is not like any of the existing tests (there are conceptual difference of fail/pass handling when launching 10k procs) The event loops need to be integrated. Not sure how to integrate this with glib loop for glib-dbus? A base class for a MS (or ME) without being ofono specific and simple enough. Currently the lua JSON code is only from MS->Test. Need to add primitive to register a FD so lua can get an answer back. Find a way to set SO_PASSCRED on the socket to have "mobile" reachable by the event server as well. Could be a lua binding or we patch lua socket Have a lua script that forwards the "on/off", "limit to cell XYZ", "Send SMS", "Place Call", "Open Call and read data from this socket" Missing primitives for mobile. But we need them anyway. The middle step is in-reach, the big step will take some real time and I could use some help (e.g. the event loop integration). > I think that CDF functions and IMSI generation and alike are really attach to the test and they are really not resources, so no need to "configure" them. This topic matches with your other mail thread too. The "SIM" card would need to be in the device so IMSI kind of belongs to the resource? From pespin at sysmocom.de Wed Mar 7 17:22:42 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Wed, 7 Mar 2018 18:22:42 +0100 Subject: MS driver: GSM tester config integration In-Reply-To: <50479DDA-8C36-4408-B68E-3BB139BF6815@freyther.de> References: <50479DDA-8C36-4408-B68E-3BB139BF6815@freyther.de> Message-ID: <19169e9f-1754-103b-cbd7-4d27ee69e626@sysmocom.de> Hi Holger, > thanks to both of you for the detailed responses. I like the idea, it > solves the coordination between setting up the core network and the > phones. The approach looks generally feasible and I wish we had this > idea earlier. > > Unfortunately I had only planned to do LUA bindings, the orchestration > was already an extra and I blew all my time in trying to make asyncio > work and the scaling/concurrency issues with python. My intention with > the original mail was to find a middle step. Better integration but > not full. > I know some of the concepts in osmo-gsm-tester are quite complex to grasp (lots of specific stuff like scenarios, resources, etc.), and some of the required stuff is still missing (like better poll loop, managing arfcns, etc. we have tasks created for them). As it's quite a bit amount of work and it was not your primary focus, I don't expect to have everything done in one step. Merging it as a separate env then slowly moving it into osmo-gsm-tester seems fine for me. Personally I was also lacking a better understanding on how mobile operates and the resulting work of the lua bindings, as I didn't play with it yet. Seeing your patches helped me a lot understanding better what is there and where can we go from this first step. > > Middle step: > > Use the test scenario configuration (maybe even the suite class). > > Make the UL test reusable (and extend to SMS and Calls) What do you mean with reusable here? Can you explain it a bit more? Do you mean being able to use other Modem implementations? I agree with that. > > > Big step (as proposed): > > The "scheduling"/slow start is not like any of the existing tests (there > are conceptual difference of fail/pass handling when launching 10k procs) > > The event loops need to be integrated. Not sure how to integrate this with > glib loop for glib-dbus? I think the best would be having our own loop, which then also polls glib loop in the process. As far as I remember glib provides APIs to get poll notifications (via fd?) in case an event from them is triggered. If I recall correctly EFL libs have APIs to do that for apps which want to run efl+glib at the same time.Probably Qt guys do the same. Other possibility would be to have our own loop which is internally implemented using glib one. Having a better loop was not a hard requirement until now because we were fine without fine-grained time lapses and just active polling every 0.1 seconds, but I'd really like having a better loop. I'll try to find some time in next days to have a look at improving the current event loop. > > A base class for a MS (or ME) without being ofono specific and simple enough. > Currently the lua JSON code is only from MS->Test. I can help you with that, given that you provide all the lua specific parts. > The "SIM" card would need to be in the device so IMSI kind of belongs to the resource? An IMSI belongs to the resource, but the generator itself can be used in different tests. The IMSI field in the Modem resource is there for historical reasons (for instance if you'd like to force a specific IMSI by default), but we should rework ModemOfono to get the IMSI from ofono/dbus instead, since we are finally not using the IMSI to identify the modems but its sysfs path. -- - 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 gnumonks.org Wed Mar 7 17:44:30 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 7 Mar 2018 18:44:30 +0100 Subject: OsmoBsc_Nat with osmux configuration example In-Reply-To: <8a62440e-d3e0-ebcd-dbed-6b25c1e79102@sysmocom.de> References: <20180306184414.GA29872@nataraja> <2f8c70f5-bf5e-fdbd-350c-1e4d08238510@riseup.net> <8a62440e-d3e0-ebcd-dbed-6b25c1e79102@sysmocom.de> Message-ID: <20180307174430.GE22178@nataraja> Hi Rafael, in case you want to read more about LCLS, please see http://osmocom.org/projects/cellular-infrastructure/wiki/Local_Call_Local_Switch it links the relevant specs. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From Jan.Bruckner at escrypt.com Thu Mar 8 10:04:24 2018 From: Jan.Bruckner at escrypt.com (Bruckner Jan (ETAS-SEC/ECT-Mu)) Date: Thu, 8 Mar 2018 10:04:24 +0000 Subject: Hardware for 3G Message-ID: <8194ef725330442783c34d0085fabffe@escrypt.com> Hi all, I'm interested in upgrading my 2G setup to also support 3G. My current setup is: USRP N210, osmo-trx, osmo-bts-trx, osmo-nitb, osmo-pcu, osmo-sgsn, osmo-ggsn. On the software side I understand I'd have to migrate from osmo-nitb to the new split components and add the 3G components. Regarding the hardware it seems most people are using the ip.access nano3G femtocell. Is this the same one that's included in the sysmocom 3.5G starter kit? Are there any alternatives I'm not aware of other than using non-Osmocom projects? Thanks, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6732 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Thu Mar 8 22:12:31 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 8 Mar 2018 23:12:31 +0100 Subject: Hardware for 3G In-Reply-To: <8194ef725330442783c34d0085fabffe@escrypt.com> References: <8194ef725330442783c34d0085fabffe@escrypt.com> Message-ID: <20180308221231.GB30588@my.box> On Thu, Mar 08, 2018 at 10:04:24AM +0000, Bruckner Jan (ETAS-SEC/ECT-Mu) wrote: > Hi all, > > > > I'm interested in upgrading my 2G setup to also support 3G. > > My current setup is: USRP N210, osmo-trx, osmo-bts-trx, osmo-nitb, osmo-pcu, > osmo-sgsn, osmo-ggsn. > > On the software side I understand I'd have to migrate from osmo-nitb to the > new split components and add the 3G components. correct. > Regarding the hardware it seems most people are using the ip.access nano3G > femtocell. Is this the same one that's included in the sysmocom 3.5G starter > kit? The nano3G is the cheaper one of the two options we have currently ready for use, the other one being the sysmocell 5000 series. This nano3G is included in the starter kit, correct. > Are there any alternatives I'm not aware of other than using non-Osmocom > projects? Could you rephrase that? :) ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From Jan.Bruckner at escrypt.com Fri Mar 9 08:34:57 2018 From: Jan.Bruckner at escrypt.com (Bruckner Jan (ETAS-SEC/ECT-Mu)) Date: Fri, 9 Mar 2018 08:34:57 +0000 Subject: Hardware for 3G In-Reply-To: <20180308221231.GB30588@my.box> References: <8194ef725330442783c34d0085fabffe@escrypt.com> <20180308221231.GB30588@my.box> Message-ID: Hi Neels, >> Are there any alternatives I'm not aware of other than using >> non-Osmocom projects? >Could you rephrase that? :) Sure :) I looked into other 2G/3G projects, mainly OpenBTS and YateBTS and saw that OpenBTS-UMTS should support 3G with my SDR. But I'd very much prefer sticking to Osmocom, because OpenBTS seems not very active, at least towards the public. So I was wondering if someone might be working on another Osmocom project that I have not come across yet, that might provide an alternative to buying a nano3G. Actually, I just found [1], which also uses the nano3G. So nano3G seems like the way to go right now. Jan [1] https://osmocom.org/projects/cellular-infrastructure/wiki/Accelerate3g5_--_b enoit -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6732 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Fri Mar 9 12:17:28 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 9 Mar 2018 13:17:28 +0100 Subject: Hardware for 3G In-Reply-To: References: <8194ef725330442783c34d0085fabffe@escrypt.com> <20180308221231.GB30588@my.box> Message-ID: <20180309121728.GA2266@my.box> On Fri, Mar 09, 2018 at 08:34:57AM +0000, Bruckner Jan (ETAS-SEC/ECT-Mu) wrote: > Hi Neels, > > >> Are there any alternatives I'm not aware of other than using > >> non-Osmocom projects? > > >Could you rephrase that? :) > > Sure :) > I looked into other 2G/3G projects, mainly OpenBTS and YateBTS and saw that > OpenBTS-UMTS should support 3G with my SDR. But I'd very much prefer > sticking to Osmocom, because OpenBTS seems not very active, at least towards > the public. So I was wondering if someone might be working on another > Osmocom project that I have not come across yet, that might provide an > alternative to buying a nano3G. > Actually, I just found [1], which also uses the nano3G. So nano3G seems like > the way to go right now. Hi Jan, It is not trivial to find femto cells that provide a usable Iuh that is not locked down to specific vendors / networks. It is also not trivial to write a separate RNC that would allow operating Iu proper instead of requiring Iuh, which would open up more possibilities for 3G base station hardware. None of GSM is trivial, but we have no RNC yet :) At Osmocom/sysmocom, we have the sysmoCell 5k series, and have also managed to get the far cheaper nano3G plugged to our osmo-hnbgw; plus at sysmocom we have a certain number of them available. So wherever you look in the Osmocom ecosystem, you will see the nano3G popping up its head. The Accelerate3g5 was specifically launched by sysmocom to get more people involved in Osmocom 3G and, naturally, we gave away nano3G units to about a dozen projects. http://osmocom.org/projects/cellular-infrastructure/wiki/Accelerate3g5 There is an ongoing process of finding more suitable femto cells, and it looks promising, though it's not worth an announcement as of yet. Anyone out there may join the effort and investigate femto cell models available on the market and find ways to unlock them so they become generally usable with Osmocom 3G. If you want to get started, the nano3G indeed is your best bet with Osmocom at the moment. Be aware that not all nano3G you can buy out there are ready to be configured and talk Iuh to any host, so sysmocom is probably the safest source. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From djks74 at gmail.com Fri Mar 9 12:23:30 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Fri, 09 Mar 2018 12:23:30 +0000 Subject: Hardware for 3G In-Reply-To: <20180309121728.GA2266@my.box> References: <8194ef725330442783c34d0085fabffe@escrypt.com> <20180308221231.GB30588@my.box> <20180309121728.GA2266@my.box> Message-ID: Hi Neels, Can we buy the nano3G only from sysmocom and get it working with limesdr for transceiver? I still wondering how it works together wirh sdr, is that possible? Regards, Sandi On Fri, Mar 9, 2018, 19:17 Neels Hofmeyr wrote: > On Fri, Mar 09, 2018 at 08:34:57AM +0000, Bruckner Jan (ETAS-SEC/ECT-Mu) > wrote: > > Hi Neels, > > > > >> Are there any alternatives I'm not aware of other than using > > >> non-Osmocom projects? > > > > >Could you rephrase that? :) > > > > Sure :) > > I looked into other 2G/3G projects, mainly OpenBTS and YateBTS and saw > that > > OpenBTS-UMTS should support 3G with my SDR. But I'd very much prefer > > sticking to Osmocom, because OpenBTS seems not very active, at least > towards > > the public. So I was wondering if someone might be working on another > > Osmocom project that I have not come across yet, that might provide an > > alternative to buying a nano3G. > > Actually, I just found [1], which also uses the nano3G. So nano3G seems > like > > the way to go right now. > > Hi Jan, > > It is not trivial to find femto cells that provide a usable Iuh that is not > locked down to specific vendors / networks. > > It is also not trivial to write a separate RNC that would allow operating > Iu > proper instead of requiring Iuh, which would open up more possibilities > for 3G > base station hardware. None of GSM is trivial, but we have no RNC yet :) > > At Osmocom/sysmocom, we have the sysmoCell 5k series, and have also > managed to > get the far cheaper nano3G plugged to our osmo-hnbgw; plus at sysmocom we > have > a certain number of them available. So wherever you look in the Osmocom > ecosystem, you will see the nano3G popping up its head. The Accelerate3g5 > was > specifically launched by sysmocom to get more people involved in Osmocom 3G > and, naturally, we gave away nano3G units to about a dozen projects. > http://osmocom.org/projects/cellular-infrastructure/wiki/Accelerate3g5 > > There is an ongoing process of finding more suitable femto cells, and it > looks > promising, though it's not worth an announcement as of yet. > > Anyone out there may join the effort and investigate femto cell models > available on the market and find ways to unlock them so they become > generally > usable with Osmocom 3G. > > If you want to get started, the nano3G indeed is your best bet with > Osmocom at > the moment. Be aware that not all nano3G you can buy out there are ready > to be > configured and talk Iuh to any host, so sysmocom is probably the safest > source. > > ~N > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Fri Mar 9 13:48:56 2018 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Fri, 9 Mar 2018 20:48:56 +0700 Subject: [PATCH] trxcon/Dockerfile: use 'fixeria/trx' branch Message-ID: <20180309134856.632-1-axilirator@gmail.com> The 'laforge/trx' branch of OsmocomBB was used to make basic TTCN3 tests, such as the 'max_ta', work ASAP. Now all required changes and some bug fixes have been merged to the 'fixeria/trx'. Change-Id: If86dcd677cd8a8bf62821028e17ebdf99a7a004e --- osmocom-bb-trxcon/Dockerfile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/osmocom-bb-trxcon/Dockerfile b/osmocom-bb-trxcon/Dockerfile index 1d29051..ca8ac2c 100644 --- a/osmocom-bb-trxcon/Dockerfile +++ b/osmocom-bb-trxcon/Dockerfile @@ -2,7 +2,7 @@ FROM laforge/debian-jessie-build MAINTAINER Harald Welte -ARG OSMO_BB_BRANCH="laforge/trx" +ARG OSMO_BB_BRANCH="fixeria/trx" ARG OSMOCOM_REPO="http://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_8.0/" -- 2.16.2 From rafael at riseup.net Fri Mar 9 19:55:26 2018 From: rafael at riseup.net (Rafael Diniz) Date: Fri, 9 Mar 2018 16:55:26 -0300 Subject: Hardware for 3G In-Reply-To: References: <8194ef725330442783c34d0085fabffe@escrypt.com> <20180308221231.GB30588@my.box> <20180309121728.GA2266@my.box> Message-ID: <9081670e-4408-8cd3-0c7a-b5abec3b4d4d@riseup.net> How about this one? http://www.parallelwireless.com/products/converged-wireless-system/ It does support 2G, 3G and 4G. Thanks, Rafael Diniz On 03/09/18 09:23, Sandi Suhendro wrote: > Hi Neels, > Can we buy the nano3G only from sysmocom and get it working with limesdr > for transceiver?? > > I still wondering how it works together wirh sdr, is that possible? > > Regards, > Sandi > > On Fri, Mar 9, 2018, 19:17 Neels Hofmeyr > wrote: > > On Fri, Mar 09, 2018 at 08:34:57AM +0000, Bruckner Jan > (ETAS-SEC/ECT-Mu) wrote: > > Hi Neels, > > > > >> Are there any alternatives I'm not aware of other than using > > >> non-Osmocom projects? > > > > >Could you rephrase that? :) > > > > Sure :) > > I looked into other 2G/3G projects, mainly OpenBTS and YateBTS and > saw that > > OpenBTS-UMTS should support 3G with my SDR. But I'd very much prefer > > sticking to Osmocom, because OpenBTS seems not very active, at > least towards > > the public. So I was wondering if someone might be working on another > > Osmocom project that I have not come across yet, that might provide an > > alternative to buying a nano3G. > > Actually, I just found [1], which also uses the nano3G. So nano3G > seems like > > the way to go right now. > > Hi Jan, > > It is not trivial to find femto cells that provide a usable Iuh that > is not > locked down to specific vendors / networks. > > It is also not trivial to write a separate RNC that would allow > operating Iu > proper instead of requiring Iuh, which would open up more > possibilities for 3G > base station hardware. None of GSM is trivial, but we have no RNC yet :) > > At Osmocom/sysmocom, we have the sysmoCell 5k series, and have also > managed to > get the far cheaper nano3G plugged to our osmo-hnbgw; plus at > sysmocom we have > a certain number of them available. So wherever you look in the Osmocom > ecosystem, you will see the nano3G popping up its head. The > Accelerate3g5 was > specifically launched by sysmocom to get more people involved in > Osmocom 3G > and, naturally, we gave away nano3G units to about a dozen projects. > http://osmocom.org/projects/cellular-infrastructure/wiki/Accelerate3g5 > > There is an ongoing process of finding more suitable femto cells, > and it looks > promising, though it's not worth an announcement as of yet. > > Anyone out there may join the effort and investigate femto cell models > available on the market and find ways to unlock them so they become > generally > usable with Osmocom 3G. > > If you want to get started, the nano3G indeed is your best bet with > Osmocom at > the moment. Be aware that not all nano3G you can buy out there are > ready to be > configured and talk Iuh to any host, so sysmocom is probably the > safest source. > > ~N > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From laforge at gnumonks.org Sat Mar 10 06:45:07 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 10 Mar 2018 07:45:07 +0100 Subject: Hardware for 3G In-Reply-To: <9081670e-4408-8cd3-0c7a-b5abec3b4d4d@riseup.net> References: <8194ef725330442783c34d0085fabffe@escrypt.com> <20180308221231.GB30588@my.box> <20180309121728.GA2266@my.box> <9081670e-4408-8cd3-0c7a-b5abec3b4d4d@riseup.net> Message-ID: <20180310064507.GD7109@nataraja> On Fri, Mar 09, 2018 at 04:55:26PM -0300, Rafael Diniz wrote: > How about this one? > http://www.parallelwireless.com/products/converged-wireless-system/ > > It does support 2G, 3G and 4G. Do you see anywhere that it supports Abis, Iuh, IuCS or IuPS? >From the limited non-technical informatio published, it seems rather that they want to sell you the cell plus some "HetNet Gateway" which seems to imply they might be using an architecture quite far from how a normal 3GPP RAN is specified. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From djks74 at gmail.com Mon Mar 12 07:32:35 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Mon, 12 Mar 2018 14:32:35 +0700 Subject: Send sms to all subscribers DB Message-ID: Dear list, anyone know if osmo-nitb can send sms to all subscribers like blast sms? it would be nice if we can implemented it. Thanks -- Best Regards, DUO -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Mon Mar 12 07:57:33 2018 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 12 Mar 2018 08:57:33 +0100 Subject: GSM 04.08 L2 pseudo length in ACCH System Information messages In-Reply-To: References: Message-ID: <20180312075732.GN7109@nataraja> Hi Vadim, On Thu, Dec 14, 2017 at 01:57:11AM +0700, Vadim Yanitskiy wrote: > I looked at the specifications again, and found out that initially I > refered an outdated 5.3.0 version, which was the first link in Google: > > http://www.etsi.org/deliver/etsi_gts/04/0408/05.03.00_60/gsmts_0408v050300p.pdf > > while the latest one is 7.21.0: > > http://www.etsi.org/deliver/etsi_ts/100900_100999/100940/07.21.00_60/ts_100940v072100p.pdf > > So, I compared the 9.1.37-40 sections of both versions, and bingo! > In the higher version ACCH System Information messages do have the > 'L2 Pseudo Length' (10.5.2.19) field. I think you have to review the matching 04.06 / 44.006 together with it. My suspicion is that earlier, 04.06 might not have specified the B4 frame format for downlink SACCH but simply used a normal B frame format (with length octet at L2). Or specified that the B4 frame format includes the length octet. It looks like what used to be a regular UI frame length octet in L2 has at some point been moved into L3 in order to achieve phase1 compatibility by having a length octet that's shorter than the payload length. Old phones will then only look at the "length" number of bytes, where newer phones will look at the full message. If they kept the length octet in L2, L2 would have automatically calculated the length to the total length of the message, including all phase2 extensions. So I guess that's why they came up with that ugly hack of defining L2 as not having a length (only addr + ctrl on downlink sacch) and the L3 including a length octet. >From the wire format point of view, you always have * two octets L1 header (power control, TA loop) * one octet ADDR * one octet CTRL * one octet [either L2 length or L2 pseudo length] * the actual L3 payloda The question is just whether you group ADDR+CTRL+LEN into L2 or you put LEN+L3 into L3. If my line of thinking is correct (see https://osmocom.org/issues/3059) we need to make sure * the L2 pseudo-length is included in all SACCH downlink L3 info on RSL, see https://gerrit.osmocom.org/#/c/7220/ * fix the wireshark dissector for SACCH, see https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14105 * fix the wireshark RSL dissector for RSL (SACCH FILL, SACCH INFO MODIFY, CHAN ACT) 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 keith at rhizomatica.org Mon Mar 12 07:54:53 2018 From: keith at rhizomatica.org (Keith Whyte) Date: Mon, 12 Mar 2018 08:54:53 +0100 Subject: Send sms to all subscribers DB In-Reply-To: References: Message-ID: On 12/03/18 08:32, Sandi Suhendro wrote: > Dear list, > anyone know if osmo-nitb can send sms to all subscribers like blast sms? > No. > it would be nice if we can implemented it. You /could/ write a function to loop around all subscribers and then look someplace around here: http://cgit.osmocom.org/osmo-msc/tree/src/libmsc/vty_interface_layer3.c#n441 As far as I remember though, you cannot type anything other than 7bit chars into the VTY. rather than doing that, I would use a 3rd party application and submit your bulk SMS via SMPP. It has some minor issues, but It's not difficult to spin something up in python with python-smpplib. k/ From rafael at riseup.net Mon Mar 12 11:57:53 2018 From: rafael at riseup.net (Rafael Diniz) Date: Mon, 12 Mar 2018 08:57:53 -0300 Subject: Hardware for 3G In-Reply-To: <20180310064507.GD7109@nataraja> References: <8194ef725330442783c34d0085fabffe@escrypt.com> <20180308221231.GB30588@my.box> <20180309121728.GA2266@my.box> <9081670e-4408-8cd3-0c7a-b5abec3b4d4d@riseup.net> <20180310064507.GD7109@nataraja> Message-ID: <7357684c-0bf1-68fc-ecd7-e16a9f02323a@riseup.net> Thanks Harald. We'll raise the information if their equipment is compatible with standards 3GPP protocols. Rafael Diniz On 03/10/2018 03:45 AM, Harald Welte wrote: > On Fri, Mar 09, 2018 at 04:55:26PM -0300, Rafael Diniz wrote: >> How about this one? >> http://www.parallelwireless.com/products/converged-wireless-system/ >> >> It does support 2G, 3G and 4G. > > Do you see anywhere that it supports Abis, Iuh, IuCS or IuPS? > >>From the limited non-technical informatio published, it seems rather > that they want to sell you the cell plus some "HetNet Gateway" which > seems to imply they might be using an architecture quite far from how > a normal 3GPP RAN is specified. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From nhofmeyr at sysmocom.de Mon Mar 12 14:46:56 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 12 Mar 2018 15:46:56 +0100 Subject: Hardware for 3G In-Reply-To: References: <8194ef725330442783c34d0085fabffe@escrypt.com> <20180308221231.GB30588@my.box> <20180309121728.GA2266@my.box> Message-ID: <20180312144656.GA1813@my.box> On Fri, Mar 09, 2018 at 12:23:30PM +0000, Sandi Suhendro wrote: > Hi Neels, > Can we buy the nano3G only from sysmocom and get it working with limesdr > for transceiver? > > I still wondering how it works together wirh sdr, is that possible? The nano3G is a piece of hardware and is not related to an SDR in any way. Your question doesn't make a lot of sense, sorry, but I don't know what to answer there besides repeating things written in the original mail. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From djks74 at gmail.com Mon Mar 12 14:52:55 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Mon, 12 Mar 2018 14:52:55 +0000 Subject: Hardware for 3G In-Reply-To: <20180312144656.GA1813@my.box> References: <8194ef725330442783c34d0085fabffe@escrypt.com> <20180308221231.GB30588@my.box> <20180309121728.GA2266@my.box> <20180312144656.GA1813@my.box> Message-ID: Dear Neels, What i mean is 3G hardware is using nano3G only? Or need to combine with sysmoBTS (maybe can replace with SDR) If you only need nano3G to build the network, so my question is nano3G also as a transceiver? Thanks, Sandi On Mon, Mar 12, 2018, 21:46 Neels Hofmeyr wrote: > On Fri, Mar 09, 2018 at 12:23:30PM +0000, Sandi Suhendro wrote: > > Hi Neels, > > Can we buy the nano3G only from sysmocom and get it working with limesdr > > for transceiver? > > > > I still wondering how it works together wirh sdr, is that possible? > > The nano3G is a piece of hardware and is not related to an SDR in any way. > Your > question doesn't make a lot of sense, sorry, but I don't know what to > answer > there besides repeating things written in the original mail. > > ~N > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon Mar 12 21:24:27 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 12 Mar 2018 22:24:27 +0100 Subject: re failing ttcn BTS_Tests / pcuif_proto.h version bump Message-ID: <20180312212427.GB1813@my.box> I have a trivial patch adding the new data item to the PCUIF_Types.ttcn (see branch neels/pcu in osmo-ttcn3-hacks.git), but I can't get the TC_pcu_act_req() to pass. I have trouble understanding where in that the PCUIF version would take effect, I can't find any place where it is populated. That would need a bump to version 9. Maybe that's not needed at all. All I get is 21:13:27.702570 mtc BTS_Tests.ttcn:1883 setverdict(fail): none -> fail reason: "Timeout waiting for PCU R TS.req", new component reason: "Timeout waiting for PCU RTS.req" and I can't figure out why. It doesn't seem related to the pcuif_proto.h anyway. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Tue Mar 13 03:14:27 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 13 Mar 2018 04:14:27 +0100 Subject: Hardware for 3G In-Reply-To: References: <8194ef725330442783c34d0085fabffe@escrypt.com> <20180308221231.GB30588@my.box> <20180309121728.GA2266@my.box> <20180312144656.GA1813@my.box> Message-ID: <20180313031427.GA30253@my.box> On Mon, Mar 12, 2018 at 02:52:55PM +0000, Sandi Suhendro wrote: > Dear Neels, > What i mean is 3G hardware is using nano3G only? Or need to combine with > sysmoBTS (maybe can replace with SDR) > > If you only need nano3G to build the network, so my question is nano3G also > as a transceiver? Wow, that's a wild mix m( I'd appreciate if you could read up on the basic concepts before using our time. Consider: these answers are for free to you, but they cost us time and actually real money. We'll do it any time for *useful* requests. Thanks! I mean, you've been camping the community for long enough to know where all the information can be found. The sysmoBTS is a complete 2G base station, piece of hardware. It has an ethernet plug to feed Abis/GPRS-NS and you get a 2G cell on the air "at the other end". The nano3G is a complete 3G base station, piece of hardware, aka hNodeB aka femto cell. It has an ethernet plug to feed Iuh and you get a 3G cell on the air "at the other end". These two are completely separate and utterly unrelated, and they cannot be plugged into each other in a useful way, besides operating them with a core network that is able to serve both technologies at the same time. Compare: https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From djks74 at gmail.com Tue Mar 13 04:24:17 2018 From: djks74 at gmail.com (Sandi Suhendro) Date: Tue, 13 Mar 2018 04:24:17 +0000 Subject: Hardware for 3G In-Reply-To: <20180313031427.GA30253@my.box> References: <8194ef725330442783c34d0085fabffe@escrypt.com> <20180308221231.GB30588@my.box> <20180309121728.GA2266@my.box> <20180312144656.GA1813@my.box> <20180313031427.GA30253@my.box> Message-ID: Dear Neels, Thanks for explanation, i just confuse before there are 2 hardware for sysmo-NitB 3,5G which as info here https://www.sysmocom.de/products/3g5starterkit/index.html After read it again, i just realize the sysmo-NITB 3,5 hardware is just a host/computer for handling the nano3G. Sorry for your time and thanks Neels. :) Best, Sandi On Tue, Mar 13, 2018, 10:14 Neels Hofmeyr wrote: > On Mon, Mar 12, 2018 at 02:52:55PM +0000, Sandi Suhendro wrote: > > Dear Neels, > > What i mean is 3G hardware is using nano3G only? Or need to combine with > > sysmoBTS (maybe can replace with SDR) > > > > If you only need nano3G to build the network, so my question is nano3G > also > > as a transceiver? > > Wow, that's a wild mix m( > > I'd appreciate if you could read up on the basic concepts before using our > time. Consider: these answers are for free to you, but they cost us time > and > actually real money. We'll do it any time for *useful* requests. Thanks! I > mean, you've been camping the community for long enough to know where all > the > information can be found. > > The sysmoBTS is a complete 2G base station, piece of hardware. It has an > ethernet plug to feed Abis/GPRS-NS and you get a 2G cell on the air "at the > other end". > > The nano3G is a complete 3G base station, piece of hardware, aka hNodeB aka > femto cell. It has an ethernet plug to feed Iuh and you get a 3G cell on > the > air "at the other end". > > These two are completely separate and utterly unrelated, and they cannot be > plugged into each other in a useful way, besides operating them with a core > network that is able to serve both technologies at the same time. > > Compare: > > https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box > > ~N > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Tue Mar 13 09:59:31 2018 From: laforge at gnumonks.org (Harald Welte) Date: Tue, 13 Mar 2018 10:59:31 +0100 Subject: re failing ttcn BTS_Tests / pcuif_proto.h version bump In-Reply-To: <20180312212427.GB1813@my.box> References: <20180312212427.GB1813@my.box> Message-ID: <20180313095931.GO3523@nataraja> Hi Neels, On Mon, Mar 12, 2018 at 10:24:27PM +0100, Neels Hofmeyr wrote: > I have trouble understanding where in that the PCUIF version would take effect, It is apparently not sent nor checked. Feel free to add that, both as * a TTCN-3 test sending arbitrary wrong versions so we can test the BTS (and later BSC, PCU) PCU socket, i.e. expecting it to reject/close * have the TTCN-3 test actually validate the expected version > All I get is > > 21:13:27.702570 mtc BTS_Tests.ttcn:1883 setverdict(fail): none -> fail reason: "Timeout waiting for PCU R > TS.req", new component reason: "Timeout waiting for PCU RTS.req" This is odd. It used to work until a few days ago :/ -- - 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 Fri Mar 16 02:08:03 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 16 Mar 2018 03:08:03 +0100 Subject: ttcn3: BSSGP_Types.ttcn MCC-MNC Message-ID: <20180316020803.GA30265@my.box> In the file BSSGP_Types.ttcn -> ../deps/titan.ProtocolModules.BSSGP_v13.0.0/src/BSSGP_Types.ttcn I notice many PLMN definitions like type record PLMN_Identity { OCT1 iEI, BIT1 ext, LIN2_2a lengthIndicator, HEX1 mccDigit1, HEX1 mccDigit2, HEX1 mccDigit3, HEX1 mncDigit3, HEX1 mncDigit1, HEX1 mncDigit2 } which at first glance looks like they got the MCC-MNC digits ordered wrongly. It is correct as long as the less significant nibble comes first. And using these in PLMN tests gives the expected results. Now I assume that the HEX1 means that it's a nibble, where the less significant nibble comes first, sort of a "network nibble order" if that makes any sense. It is weird, though -- do we need to compose hex strings "reversed" as well?? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Fri Mar 16 02:11:08 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 16 Mar 2018 03:11:08 +0100 Subject: docker-playground to gerrit? Message-ID: <20180316021108.GB30265@my.box> Do I have permission to move the docker-playground.git to gerrit? I have a bunch of patches already in my various branches. I could just push them onto master, but I guess some code review would be good? Should we also add a gerrit job that tests the changes? Kind of hard to make a failure decision though while when some tests are normally failing, like they still are. ~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 gnumonks.org Fri Mar 16 08:30:51 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 16 Mar 2018 09:30:51 +0100 Subject: ttcn3: BSSGP_Types.ttcn MCC-MNC In-Reply-To: <20180316020803.GA30265@my.box> References: <20180316020803.GA30265@my.box> Message-ID: <20180316083051.GF3523@nataraja> Hi Neels, On Fri, Mar 16, 2018 at 03:08:03AM +0100, Neels Hofmeyr wrote: > which at first glance looks like they got the MCC-MNC digits ordered wrongly. > It is correct as long as the less significant nibble comes first. And using > these in PLMN tests gives the expected results. I am not sure why Ericsson wrote those definitions the way they are. I think its stupid (sorry) to define lots of single-length hexstrings rather than one hexstring. > Now I assume that the HEX1 means that it's a nibble, where the less significant > nibble comes first, HEX1 is a hexstring of length(1), see General_Types.ttcn: General_Types.ttcn: type hexstring HEX1 length(1) with {variant "FIELDLENGTH(1)"}; > sort of a "network nibble order" if that makes any sense. The order is not part of the HEX1 definition but it's defined in an attribute/variant of the RAW type. You can use FIELDORDER() to define the encoding order of the fields of a record. You can also use the "BYTEORDER()" and "BITORDER()" or "HEXORDER()" to define the respective parameters, see the TITAN documentation on the RAW coder for more details. > It is weird, though -- do we need to compose hex strings "reversed" as well?? I'm not sure what you're asking here? In the type definitions I wrote I simply use a construct like GSM_RR_Types.ttcn: type hexstring GsmBcdString with { variant "HEXORDER(low)" }; Which Makes sure that something like "123456" is encoded as "213265" like in IMSIs, MSISDNs etc. However, for those type definitions that are provided by Ericsson, I think it makes more sense to use them as-is rather than create our own fork. -- - 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 gnumonks.org Fri Mar 16 08:32:04 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 16 Mar 2018 09:32:04 +0100 Subject: docker-playground to gerrit? In-Reply-To: <20180316021108.GB30265@my.box> References: <20180316021108.GB30265@my.box> Message-ID: <20180316083204.GG3523@nataraja> Hi Neels, On Fri, Mar 16, 2018 at 03:11:08AM +0100, Neels Hofmeyr wrote: > Do I have permission to move the docker-playground.git to gerrit? I have a > bunch of patches already in my various branches. I could just push them onto > master, but I guess some code review would be good? Go ahead. > Should we also add a gerrit job that tests the changes? One could test whether the individual Dockerfiles still build. ("docker build"). -- - 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 gnumonks.org Fri Mar 16 17:27:10 2018 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 16 Mar 2018 18:27:10 +0100 Subject: BSC_Tests.ttcn now needs TITAN 6.3.1 to build Message-ID: <20180316172710.GQ3523@nataraja> Dear all, as I explained in https://osmocom.org/issues/3070 for some reason BSC_Tests.ttcn fails to work under TITAN 6.1.0 anymore. Rather than debugging old TITAN versions, I decided to update to the latest stable release (6.3.1) in the debian-stretch-titan container that we use on jenkins. Please keep this in mind when running tests locally: * for containerized setups, switch to latest docker-playground master and re-build the debain-stretch-titan container before building any of the ttcn3-*-test containers based on it * if you build+run the ttcn-3 code on your native machine/distro, pleaes switch to TITAN 6.3.1. If you run Debian 9, you can use the package from network:osmocom:latest 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 laforge at gnumonks.org Sun Mar 18 13:49:04 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Mar 2018 14:49:04 +0100 Subject: changes in osmo-ttcn3-hacks (logging, external dependencies) Message-ID: <20180318134904.GZ3523@nataraja> Dear all, I've changed some details related to logging: * we now generate per-testcase merged TITAN log files with the same name prefix as the pcap files (Module.Testcase.{pcap,merged}) and remove the hundreds of per-component log files generated by the parallel executor after merging them. * the console log verbosity has been incresed to include all output from explicit "log()" statements. This is particularly useful when running the tests interactively. Unrelated to the above, I removed our own copies of the MTP3/M3UA/SCCP emulation and replaced it with the proper upstream git repositories under 'deps' like most other external modules. This means that you will need to * update your 'deps' (make deps-update) * remove/re-generate your symlinks (gen_links.sh) from e.g. 'bsc' or 'msc' * re-generate the makefile subsequently It may be that the make file dependency logic doesn't pick this up automatically, so if you see some strange build errors, it may be a good idea to clean your local work tree. 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 ron.menez at entropysolution.com Sun Mar 18 14:05:56 2018 From: ron.menez at entropysolution.com (Ron) Date: Sun, 18 Mar 2018 14:05:56 +0000 Subject: OSMO-BTS-TRX: Cannot send payload with invalid length! (expecting 15, received 14) Message-ID: <48CC39D3-26F4-43DA-BC23-FEFF5982D497@entropysolution.com> Hi Support, In Half Rate configuration of OSMO-BSC, is there a way to used ETSI TS 101 318 standard for its RTP Payload Format? As per testing, the RTP Payload format used by OSMO is RFC5993. Can this be configured in OSMO-BSC or OSMO-BTS-TRX? Or the configuration of this is hard coded? Logs from OSMO-BTS-TRX: <0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) <0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0015> trau/osmo_ortp.c:0 Receiving packet with unknown payload type 111.<0006> scheduler_trx.c:543 Cannot send payload with invalid length! (expecting 15, received 14) TIA! Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Mar 18 14:17:27 2018 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 18 Mar 2018 15:17:27 +0100 Subject: OSMO-BTS-TRX: Cannot send payload with invalid length! (expecting 15, received 14) In-Reply-To: <48CC39D3-26F4-43DA-BC23-FEFF5982D497@entropysolution.com> References: <48CC39D3-26F4-43DA-BC23-FEFF5982D497@entropysolution.com> Message-ID: <20180318141727.GA3523@nataraja> Hi ron, On Sun, Mar 18, 2018 at 02:05:56PM +0000, Ron wrote: > In Half Rate configuration of OSMO-BSC, is there a way to used ETSI TS 101 318 standard for its RTP Payload Format? As per testing, the RTP Payload format used by OSMO is RFC5993. This is correct. > Can this be configured in OSMO-BSC or OSMO-BTS-TRX? Or the configuration of this is hard coded? No, this is not configurable at this point. If it should be added, my guess would be that it's best to add to osmo-mgw so it could serve as an "entry point" converting between different RTP payload formats, avoiding that we have to implement it natively in all programs (such as osmo-bts). But in any case, no matter where it's added, somebody would have to develop the related code first and contribute it. -- - 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 Mon Mar 19 00:39:42 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 19 Mar 2018 01:39:42 +0100 Subject: changes in osmo-ttcn3-hacks (logging, external dependencies) In-Reply-To: <20180318134904.GZ3523@nataraja> References: <20180318134904.GZ3523@nataraja> Message-ID: <20180319003942.GB18303@my.box> On Sun, Mar 18, 2018 at 02:49:04PM +0100, Harald Welte wrote: > * we now generate per-testcase merged TITAN log files with the same name > prefix as the pcap files (Module.Testcase.{pcap,merged}) and remove > the hundreds of per-component log files generated by the parallel > executor after merging them. > > * the console log verbosity has been incresed to include all output from > explicit "log()" statements. This is particularly useful when running > the tests interactively. Nice! Thanks for that. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Mon Mar 19 01:00:38 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 19 Mar 2018 02:00:38 +0100 Subject: MSC subscriber conn FSM issues Message-ID: <20180319010038.GA20125@my.box> In recent weeks, many of you have encountered and worked at failures of OsmoMSC's subscriber conn FSM / the conn itself to handle corner cases and/or cleanly handle error situations. I have plans for that FSM to be reviewed, adding probably two more states to it, a) to properly handle the early startup and b) gracefully release in all situations; and to probably more closely glue the conn struct to the FSM. My humble suggestion is to wait for me to review it and not spend more time on it until that is through. I wrote the FSM initially, and it makes sense that I clarify its structuring before all of you need to learn its current quirks. I hope it won't take too long, just need to sort the priorities of this fix versus the other tasks I have... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From nhofmeyr at sysmocom.de Wed Mar 21 23:43:35 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 22 Mar 2018 00:43:35 +0100 Subject: "lai_and_lac" Message-ID: <20180321234335.GA15628@my.box> Hi stsp, I noticed in the recent gsm0808_cell_id_list2 a review item slipped by: A "LAI" is by definition a PLMN (MCC+MNC) plus a LAC. So saying "LAI and LAC" is like saying "My family and my brother". So maybe we want to rename the "lai_and_lac" member of struct gsm0808_cell_id_list2 before it gets tagged for release. Just "lai" would be accurate, as its type (struct osmo_location_area_id) suggests. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ron.menez at entropysolution.com Fri Mar 23 15:09:33 2018 From: ron.menez at entropysolution.com (Ron) Date: Fri, 23 Mar 2018 15:09:33 +0000 Subject: OSMO-BTS-TRX: Cannot send payload with invalid length! (expecting 15, received 14) In-Reply-To: <20180318141727.GA3523@nataraja> References: <48CC39D3-26F4-43DA-BC23-FEFF5982D497@entropysolution.com> <20180318141727.GA3523@nataraja> Message-ID: <95AC6BE3-9E44-496F-8F06-BE967E716EF0@entropysolution.com> Thanks for the confirmation Harald. Best Regard, Ron Menez ron.menez at entropysolution.com On Mar 18, 2018, at 10:17 PM, Harald Welte > wrote: Hi ron, On Sun, Mar 18, 2018 at 02:05:56PM +0000, Ron wrote: In Half Rate configuration of OSMO-BSC, is there a way to used ETSI TS 101 318 standard for its RTP Payload Format? As per testing, the RTP Payload format used by OSMO is RFC5993. This is correct. Can this be configured in OSMO-BSC or OSMO-BTS-TRX? Or the configuration of this is hard coded? No, this is not configurable at this point. If it should be added, my guess would be that it's best to add to osmo-mgw so it could serve as an "entry point" converting between different RTP payload formats, avoiding that we have to implement it natively in all programs (such as osmo-bts). But in any case, no matter where it's added, somebody would have to develop the related code first and contribute it. -- - 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: From ron.menez at entropysolution.com Fri Mar 23 15:24:30 2018 From: ron.menez at entropysolution.com (Ron) Date: Fri, 23 Mar 2018 15:24:30 +0000 Subject: MO-SMS Maximum Number of Characters for OSMO-NITB and OSMO-BSC less than 60? Message-ID: <8038E9A6-485D-4593-8FED-DD6EF74B5EE5@entropysolution.com> Hi All, Can anyone confirm if the maximum MO-SMS that can be sent is less than 60 characters including spaces? For OSMO-NITB, we reach a maximum of 59 characters for MO-SMS, while for OSMO-BSC, we only reach a maximum of 50 characters (MO-SMS). Is this a known issue? TIA. Best Regard, Ron Menez ron.menez at entropysolution.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Fri Mar 23 15:29:30 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Fri, 23 Mar 2018 16:29:30 +0100 Subject: MO-SMS Maximum Number of Characters for OSMO-NITB and OSMO-BSC less than 60? In-Reply-To: <8038E9A6-485D-4593-8FED-DD6EF74B5EE5@entropysolution.com> References: <8038E9A6-485D-4593-8FED-DD6EF74B5EE5@entropysolution.com> Message-ID: Hi Ron, I tested now with my sysmobts running latest osmocom master (201705-nightly). I can send successfuly an SMS with something between 100-160 characters just fine. I also tried sending a large SMS with more than 160 chars, like 200chars, and everything worked fine too. -- - 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 Fri Mar 23 15:33:39 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 23 Mar 2018 16:33:39 +0100 Subject: "lai_and_lac" In-Reply-To: <20180321234335.GA15628@my.box> References: <20180321234335.GA15628@my.box> Message-ID: <20180323153339.GB5111@my.box> I noticed that the CELL_IDENT enum has a similar quirk: CELL_IDENT_LAI_AND_LAC so it probably came from that. I think we should rename it and have a backwards compat: #define CELL_IDENT_LAI_AND_LAC CELL_IDENT_LAI ~N On Thu, Mar 22, 2018 at 12:43:35AM +0100, Neels Hofmeyr wrote: > Hi stsp, > > I noticed in the recent gsm0808_cell_id_list2 a review item slipped by: > A "LAI" is by definition a PLMN (MCC+MNC) plus a LAC. > So saying "LAI and LAC" is like saying "My family and my brother". > > So maybe we want to rename the "lai_and_lac" member of struct > gsm0808_cell_id_list2 before it gets tagged for release. Just "lai" would be > accurate, as its type (struct osmo_location_area_id) suggests. > > ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From keith at rhizomatica.org Sun Mar 25 10:21:56 2018 From: keith at rhizomatica.org (Keith Whyte) Date: Sun, 25 Mar 2018 12:21:56 +0200 Subject: MO-SMS Maximum Number of Characters for OSMO-NITB and OSMO-BSC less than 60? In-Reply-To: <8038E9A6-485D-4593-8FED-DD6EF74B5EE5@entropysolution.com> References: <8038E9A6-485D-4593-8FED-DD6EF74B5EE5@entropysolution.com> Message-ID: On 23/03/18 16:24, Ron wrote: > Hi All, Hi Ron. > > Can anyone confirm if the maximum MO-SMS that can be sent is less than > 60 characters including spaces? I have worked quite extensively with SMS and have not experienced any such limitation at all, or any deviation from standard. AFAIK an SMS payload is 140 bytes, Always. What you get in there depends on other things, like what character are in the message. > > For OSMO-NITB, we reach a maximum of 59 characters for MO-SMS, while > for OSMO-BSC, we only reach a maximum of 50 characters (MO-SMS). Can you elaborate about your setup, what it is you are doing? What is it you are experiencing when you send a longer message? Are you using SMPP, or only inside the nitb/bsc? It is the MS that forms the SMS, not the network. I've never seen anything where the network says "sorry too big, split that SMS into two", I don't believe such a thing exists. From nhofmeyr at sysmocom.de Mon Mar 26 13:18:09 2018 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 26 Mar 2018 15:18:09 +0200 Subject: general review of FSMs across the code base Message-ID: <20180326131809.GA3664@my.box> When libosmocore/contrib/fsm-to-dot.py hinted me at errors in the new gscon FSM in osmo-bsc, I took a moment to render and look at all our FSM definitions. The osmo-bsc ones are fixed by https://gerrit.osmocom.org/7501 I also found OS#3110 and OS#3111 I published the FSM graphs as rendered today at http://people.osmocom.org/neels/osmo_fsm_graphs/ and might do so every now and then. If anyone likes, we could do it from jenkins regularly. ~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 gnumonks.org Wed Mar 28 12:22:13 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 28 Mar 2018 14:22:13 +0200 Subject: git.osmocom.org read-only during migration Message-ID: <20180328122213.GM26197@nataraja> Hi all, I've set git.osmocom.org to read-only while I'm doing the migration to the new server. So don't be surprised if you won't be able to push there (or if gerrit is not able to push there). I'll try to make this quick, should be back within the afternoon. -- - 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 gnumonks.org Wed Mar 28 13:42:17 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 28 Mar 2018 15:42:17 +0200 Subject: git.osmocom.org read-only during migration In-Reply-To: <20180328122213.GM26197@nataraja> References: <20180328122213.GM26197@nataraja> Message-ID: <20180328134217.GN26197@nataraja> Hi all, On Wed, Mar 28, 2018 at 02:22:13PM +0200, Harald Welte wrote: > I've set git.osmocom.org to read-only while I'm doing the migration > to the new server. a brief status update on this: * cgit.osmocom.org is migrated to new machine, including our custom syntax highlighting filter as well as the redmine+gerrit link filter * git+ssh is migrated to new server, while converting from gitosis to gitolite at the same time. All keys + configs have been migrated, so things should simply work like they used to before. Will update the wiki on how to manage this + send mail to the other git admins tnt, neels and xecke. write-permission has been re-enabled in this setup, so both direct push as well as gerrit repository replication should work again. What's not yet migrated (and thus temporarily serves slightly outdated content) is the anonymous git access gia TCP port 9418. I'm having some late lunch now and then will migrate this later this evening. 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 laforge at gnumonks.org Wed Mar 28 16:02:09 2018 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 28 Mar 2018 18:02:09 +0200 Subject: git.osmocom.org read-only during migration In-Reply-To: <20180328134217.GN26197@nataraja> References: <20180328122213.GM26197@nataraja> <20180328134217.GN26197@nataraja> Message-ID: <20180328160209.GQ26197@nataraja> Hi all, On Wed, Mar 28, 2018 at 03:42:17PM +0200, Harald Welte wrote: > What's not yet migrated (and thus temporarily serves slightly outdated content) > is the anonymous git access gia TCP port 9418. I'm having some late lunch now > and then will migrate this later this evening. this migration has now also been completed, git://git.osmocom.org/ is now also being served from the new machine / container. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From michaelspahn.osmo at gmail.com Thu Mar 29 06:43:20 2018 From: michaelspahn.osmo at gmail.com (Michael Spahn) Date: Thu, 29 Mar 2018 08:43:20 +0200 Subject: nanoBTS constantly restarting Message-ID: Hello all, I have recently tried migrating an OsmoNITB setup to the new standard using mostly this guide right here: https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_In_The_Box However, while my nanoBTS works perfectly fine in the old setup, it just doesn not work at all in the new one. When I start osmo-bsc the LED on the BTS starts flashing green after a few seconds and then stops flashing and just stays green all the time, which is the expected behaviour. Unfortunately though, after another couple of seconds, the LED starts flashing green again and then turns red. This is what the log shows: BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=l2_bch.c:1154 **** ** l2_bch.c#1154:BCHbcchSItypeValid( prim_p->infoType ) ** IPA_SW_FATAL_ERROR ** In task "TRX Proc:L2_BCH" @ (1063). **** ? . BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=TRX Proc:L2_BCH:l2_bch.c#1154 (1063). BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#255:TRX has logged the error: ? . BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#256:TRX Proc:L2_BCH:l2_bch.c#1154 (1063) . BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=BCHbcchSItypeValid( prim_p->infoType ). BTS 0: Failure Event Report: Type=processing failure, Severity=warning level failure, Probable cause=Manufacturer specific values: Software warning, Additional Text=31385:WARN:OAM_RES:trx_fatal_error_log.c#260:BCHbcchSItypeValid( prim_p->infoType ) ? 20180328072641280 DLINP <0013> input/ipaccess.c:247 Sign link vanished, dead socket 20180328072641281 DLINP <0013> input/ipaccess.c:71 Forcing socket shutdown with no signal link set 20180328072641282 DCTRL <000e> osmo_bsc_ctrl.c:160 No more BTS connected, sending TRAP. ? Now I'm not claiming that my config is already 100% correct but I feel like this isn't a configuration issue. I'm using the most recent nightly builds of the entire osmocom library. Does anyone know what could be at fault here? Kind regards, Michael Spahn -------------- next part -------------- An HTML attachment was scrubbed... URL: From pespin at sysmocom.de Thu Mar 29 10:26:57 2018 From: pespin at sysmocom.de (Pau Espin Pedrol) Date: Thu, 29 Mar 2018 12:26:57 +0200 Subject: nanoBTS constantly restarting In-Reply-To: References: Message-ID: Hi Michael, I've personally been running a nanoBTS (1900 band) with latest master of all standard components a few days ago, and everything seems fine. Furthermore, osmo-gsm-tester is running nowadays tests against 2 nanoBTS (1 in 1900 band, one in 900 band) successfully with latest osmocom master in https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run-prod. Of course it could be that your network configuration is not correct, or you may want to look at the possibility to change/update the firmware in your nanoBTS. Check also with wirehsark the communication between the nanoBTS and osmo-bsc, you may be able to find some error reported in there which may give you some information. Cheers, -- - 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 gnumonks.org Thu Mar 29 10:30:01 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 29 Mar 2018 12:30:01 +0200 Subject: nanoBTS constantly restarting In-Reply-To: References: Message-ID: <20180329103001.GW26197@nataraja> Hi Michael, On Thu, Mar 29, 2018 at 08:43:20AM +0200, Michael Spahn wrote: > BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=BCHbcchSItypeValid( prim_p->infoType ). It seems that the nanoBTS, at least in the firmware version you are using, is not supporting a certain system information type that OsmoBSC is sending. We have no documentation on those nanoBTS, but it might be something like SI2ter / SI2quater that it doesn't like. You could try to disable generation/sending of those. I think we simply iterate over all SI types and send an empty system information as BCCH INFO via RSL to make sure that the BTS doesn't transmit any SI that it might have cached from state initialized before the current RSL connection. So OsmoBSC might suppress some of those, depending on bts-model nanobts/osmobts. Interesting side-note: We have recently added nanoBTS support to osmo-gsm-tester, i.e. we're contintuously testing SMS and call signalling with latest 'master' of all osmocom code against two nanoBTSs that are connected to the osmo-gsm-tester setup. @Pau: Do we see any indication that our setup is showing the same issues? If we don't see it in our setup, it most likely depends on the specific firmware release installed on the nanoBTS. Without knowing when exactly the support for the related SI types was introduced, it's difficult to automatically determine if we should send SI2ter/SI2quater, or if we should not send it -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From michaelspahn.osmo at gmail.com Thu Mar 29 10:42:52 2018 From: michaelspahn.osmo at gmail.com (Michael Spahn) Date: Thu, 29 Mar 2018 12:42:52 +0200 Subject: nanoBTS constantly restarting In-Reply-To: <20180329103001.GW26197@nataraja> References: <20180329103001.GW26197@nataraja> Message-ID: <4B0ED677-75BF-4AA2-A8B6-E17CF14AD22B@gmail.com> Hi Harald, Hi Pau, So I?m trying to find out which firmware is installed on our nanoBTS right now and I?m also going to try and contact our supplier and ask if they can provide us with the most recent firmware version. I?m also going to look at the communication between osmoBSC and the BTS with Wireshark. I?ll get back to you when I have the results. Thank you all very much! > On 29. Mar 2018, at 12:30, Harald Welte wrote: > > Hi Michael, > > On Thu, Mar 29, 2018 at 08:43:20AM +0200, Michael Spahn wrote: >> BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=BCHbcchSItypeValid( prim_p->infoType ). > > It seems that the nanoBTS, at least in the firmware version you are using, is not supporting > a certain system information type that OsmoBSC is sending. We have no documentation on those > nanoBTS, but it might be something like SI2ter / SI2quater that it doesn't like. > > You could try to disable generation/sending of those. I think we simply iterate over > all SI types and send an empty system information as BCCH INFO via RSL to make sure > that the BTS doesn't transmit any SI that it might have cached from state initialized > before the current RSL connection. > > So OsmoBSC might suppress some of those, depending on bts-model nanobts/osmobts. > > Interesting side-note: > > We have recently added nanoBTS support to osmo-gsm-tester, i.e. we're contintuously > testing SMS and call signalling with latest 'master' of all osmocom code against > two nanoBTSs that are connected to the osmo-gsm-tester setup. > > @Pau: Do we see any indication that our setup is showing the same issues? > > If we don't see it in our setup, it most likely depends on the specific firmware > release installed on the nanoBTS. Without knowing when exactly the support for the > related SI types was introduced, it's difficult to automatically determine > if we should send SI2ter/SI2quater, or if we should not send it > > -- > - Harald Welte http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) From biruei.chiu at gmail.com Thu Mar 29 10:58:53 2018 From: biruei.chiu at gmail.com (Chiu Bi-Ruei) Date: Thu, 29 Mar 2018 18:58:53 +0800 Subject: New (but unofficial) asn1c has been applied to osmo-iuh Message-ID: Dear All, I have just uploaded my modified osmo-iuh, which a new version asn1c is applied, to : https://github.com/brchiu/osmo-iuh/tree/new-asn1c Code generated by this new asn1c can handle necessary ASN.1 information object class feature used in several 3gpp specs, thus it remove the need of asn1tostruct.py. Because Lev Walkin has not accepted corresponding pull requests yet, it should be built from Velchkov's repository : https://github.com/velichkov/asn1c/tree/s1ap And link to new libasn1c : https://github.com/brchiu/libasn1c/tree/new-asn1c I use RANAP 14.1.0, RUA 14.0.0 and HNBAP 14.0.0 to generate files. There are still several compilation error which are irrelevant to this new asn1c. https://gist.github.com/brchiu/17b5d306dd3e95f5e7b255a7dbb81344 Hope someone can help solving them. Because I do not have test environment nor have no time to verify this porting, you are welcomed to use this result on your own. thanks. regards, Bi-Ruei, Chiu. -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Mar 29 15:07:48 2018 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 29 Mar 2018 17:07:48 +0200 Subject: New (but unofficial) asn1c has been applied to osmo-iuh In-Reply-To: References: Message-ID: <20180329150748.GB26197@nataraja> Hi Chiu Bi-Ruei, On Thu, Mar 29, 2018 at 06:58:53PM +0800, Chiu Bi-Ruei wrote: > I have just uploaded my modified osmo-iuh, which a new version asn1c is > applied, to : > > https://github.com/brchiu/osmo-iuh/tree/new-asn1c thanks a lot for all of your work on asn1c. I've been following it from the distance, and I'm happy to see IOC + APER is finfally being worked on. > Because Lev Walkin has not accepted corresponding pull requests yet, it > should be built from Velchkov's repository : Thanks. What is missing to get this merged/included? Is there now a testsuite for APER, similar to UPER? > Because I do not have test environment nor have no time to verify this > porting, you are welcomed to use this result on your own. The bigger effort is unfortunately not removing asn1tostruct.py from the osmo-iuh repository, but it is porting over all the existing code in not only osmo-iuh.git, but also osmo-msc.git and osmo-sgsn.git. The layout and naming of the C struct's has changed, and all needs to be adjusted accordingly. It's also likely that some of the allocation/memory-ownership patterns have changed and also need to be adjusted. It would be great if somebody had an interest in working on this. I personally am way too overloaded already to do this, sorry. Unrelated to the above: If you are interested in getting a femtocell compatible with osmo-iuh so you can build an Osmocom 3G network for testing: I'm happy to give away the related hardware for free. We've done that in the past for other people in the community working on the Osmocom 3G stack, see the "accelerate 3G5" project on the osmocom wiki. 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 ssperling at sysmocom.de Mon Mar 26 10:54:45 2018 From: ssperling at sysmocom.de (Stefan Sperling) Date: Mon, 26 Mar 2018 12:54:45 +0200 Subject: "lai_and_lac" In-Reply-To: <20180323153339.GB5111@my.box> References: <20180321234335.GA15628@my.box> <20180323153339.GB5111@my.box> Message-ID: <20180326105445.GW44210@ted.stsp.name> On Fri, Mar 23, 2018 at 04:33:39PM +0100, Neels Hofmeyr wrote: > I noticed that the CELL_IDENT enum has a similar quirk: > CELL_IDENT_LAI_AND_LAC > so it probably came from that. Yes, this is where it came from. > I think we should rename it and have a backwards compat: > #define CELL_IDENT_LAI_AND_LAC CELL_IDENT_LAI The standard from 1999 (TS 08.08 section 3.2.2.27 "Cell Identifier list") calls it just "LAI": "Location Area Identification, LAI, is used to identify all cells within a Location Area" So I would agree with your proposal.