From vyanitskiy at sysmocom.de  Wed Jun  3 08:57:12 2020
From: vyanitskiy at sysmocom.de (Vadim Yanitskiy)
Date: Wed, 3 Jun 2020 15:57:12 +0700
Subject: ttcn3-bsc-test: LCLS test cases broken since build #987 (May 29)
In-Reply-To: <7e68d8e6-8fc6-5088-6d28-67eedafd550b@sysmocom.de>
References: <7e68d8e6-8fc6-5088-6d28-67eedafd550b@sysmocom.de>
Message-ID: <cd90649f-0360-9644-0f21-eb8b745b6075@sysmocom.de>

Hi all,

as was noticed during the weekly review, all TTCN-3 BSC test cases from 
LCLS group are failing since build #987 (May 29) [1], so I am trying to 
investigate this.

Until now I thought that it's somehow related to my IPA/RSL refactoring 
patch set, so I spent half of a day reading the code of those test cases 
and trying to figure out what could be the reason. But then I checked 
ttcn3-bsc-test-latest [2]. I should have done this first, of course. 
Magically all LCLS test cases are green there.

So I assume that it's not related to the recent IPA/RSL changes, and 
most likely caused by recent changes to osmo-bsc and/or libosmo-*. I 
already tried to downgrade osmo-bsc to v1.6.0 (Jan 3) with no luck.

If anyone was working on something related to RSL, MGCP or LCLS, please 
let me know - this might help to find the problem faster. Thanks!

[1] https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/
[2] 
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test-latest/

-- 
- Vadim Yanitskiy <vyanitskiy at sysmocom.de>    http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte



From vyanitskiy at sysmocom.de  Wed Jun  3 09:35:45 2020
From: vyanitskiy at sysmocom.de (Vadim Yanitskiy)
Date: Wed, 3 Jun 2020 16:35:45 +0700
Subject: ttcn3-bsc-test: LCLS test cases broken since build #987 (May 29)
In-Reply-To: <cd90649f-0360-9644-0f21-eb8b745b6075@sysmocom.de>
References: <7e68d8e6-8fc6-5088-6d28-67eedafd550b@sysmocom.de>
 <cd90649f-0360-9644-0f21-eb8b745b6075@sysmocom.de>
Message-ID: <77293c4a-f50f-0acd-1603-4d5baf567af8@sysmocom.de>

Hi again,

 > So I assume that it's not related to the recent IPA/RSL changes, and
 > most likely caused by recent changes to osmo-bsc and/or libosmo-*.

reverting [1] "src/input/ipaccess.c: set TCP_NODELAY" (merged on May 28, 
a day before the breakage) makes most of the LCLS test cases pass. No 
idea how this is related, maybe our test cases are somehow not happy 
about this TCP option?

[1] 
https://git.osmocom.org/libosmo-abis/commit/?id=62725d0b58a4842ce96ac9107c565de40fe4e945

-- 
- Vadim Yanitskiy <vyanitskiy at sysmocom.de>    http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte


From laforge at osmocom.org  Wed Jun  3 14:57:56 2020
From: laforge at osmocom.org (Harald Welte)
Date: Wed, 3 Jun 2020 16:57:56 +0200
Subject: updated videos / presentations on setting up Osmocom CNI
Message-ID: <20200603145756.GF182140@nataraja>

Hi!

I just realized that since OsmoCon was discontinued after 2018 didn't
result in sufficient turn-out, and only the 2017 incarnation contained
some entry-level talks, we actually only have introductory level
presentations / videos about a setup that still covers OsmoNITB.
(https://media.ccc.de/v/osmocon17-4002-running_a_basic_circuit_switched_osmocom_gsm_network)

This may or may not be a reason why some people still want to set up OsmoNITB
in 2020.  While our wiki and user manuals all have deprecated OsmoNITB years ago,
people who only look for videos might be mislead.

Also, I'm sure that several other presentation (like the one about 3G / osmo-iuh before
the CNI split) would similarly benefit from an update.

So I think we should try to create/update some slide decks and record related
lectures / tutorials at some point this year.  I wouldn't bother setting up a
virtual conference or some kind of remote interaction at this point.  Recording
some talks and/or screencasts allows us to create and release them one-by-one.

I would like to get started by collecting a list of topics at https://osmocom.org/issues/4578
before we start to actually work on the presentations.

One question is also how to record, but let's first work on the content before
we worry about recording and publication.

Regards,
	Harald
-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From laforge at osmocom.org  Sat Jun 20 20:33:17 2020
From: laforge at osmocom.org (Harald Welte)
Date: Sat, 20 Jun 2020 22:33:17 +0200
Subject: Introducing E1 / Abis support to osmo-mgw
Message-ID: <20200620203317.GO2230002@nataraja>

Hi Philipp (and lurkers on this list),

I've just pushed an update to the @laforge/trau@ branch of libosmo-abis,
which contains the new code modules for E1 / TRAU usage, and also a small
test program and test data.

The test program takes a raw binary dump created from an E1 timeslot with
TRAU frames captured of a BS-11 and converts that to RTP packets.  You can feed
those RTP packets into osmo-gapk to play them back.  The audio is clear, there
are just a few seconds of quiet at the beginning before anything is audible.

The patches also add an "I460" mode to e1_input.  So from the osmo-mgw side,
I think we need to
* link against libosmo-abis and call e1inp_init + e1inp_vty_init()
* use existing VTY code to configure E1 line numbers / drivers / ports
* call e1inp_ts_config_i460() on every timeslot we want to use (this should *not*
  happen on all timeslots, as some of them are used for signalling by the BSC)
* call osmo_i460_subchan_add() / osmo_i460_subchan_del() for each i.460 sub-slot
  we want to use
* build the processing chain like in libosmo-abis/contrib/trau2rtp/trau2rtp.c
  via i460 -> trau_sync -> osmo_trau_frame_decode_16k/osmo_trau_frame_decode_8k -> osmo_trau2rtp

I believe this should be at a stage where it can be integrated into osmo-mgw.  The API
may not be 100% stable yet, but it shouldn't change completely.  The main missing
bits are:
* allow selection of sync pattern in trau_sync.c (or auto-detect?)
* handling of T-bits for alignment of air-interface timing with downlink
  TRAU frame timing

I will next be hacking on a small tool that will speak the 'osmo-e1d' protocol
but use binary capture files that are looped over and over again.  This way
you should be able to use libosmo-abis e1_input without any physical card and
still get TRAU frame data.

At a lower priority, I'd like to look into support for HRv1 and AMR TRAU
frames on 16k sub-slots.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From nick at nickvsnetworking.com  Mon Jun 22 07:45:00 2020
From: nick at nickvsnetworking.com (Nick Jones)
Date: Mon, 22 Jun 2020 17:45:00 +1000
Subject: OsmoCBC Status?
Message-ID: <CALxx1oHkBp_JPhWMZ3mLeShvavaJvxR_KPB3XR6t9dfv+uvU-w@mail.gmail.com>

Hi all,
Just wondering what the status of OsmoCBC is?
I started compiling from source, but I couldn't find any docs on
interfacing with it other than that it's via a HTTP REST API,
If there aren't any docs are there packet captures or examples I can work
from that'd be quicker than trying to reverse it from the source code,
Happy to contribute some docs once I work it out,
Cheers,
Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200622/c072e318/attachment.htm>

From nhofmeyr at sysmocom.de  Tue Jun 23 23:21:28 2020
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 24 Jun 2020 01:21:28 +0200
Subject: shutdown FSM breaks ttcn3-bsc-test
Message-ID: <20200623232128.GA26505@my.box>

dear Pau,

please fix either osmo-bts or ttcn3-bsc-tests so that running ttcn3-bsc-tests works again.
The failure I get for each and every BSC test:

  Verdict: fail reason: "Timeout waiting for BTS0 oml-connection-state ""degraded"

When I downgrade osmo-bts to 580a27e97c3f0e139dfd7b0c10de24463d4b5294 (just
before the shutdown FSM was introduced), the tests work again.
(I didn't bisect, just picked that commit.)

This failure is particularly harmful now because we're currently struggling
with quite a couple of other reasons that cause the ttcn3-bsc-tests to fail. So
when we fix those, jenkins won't show the fix, but yet a different error.

I'm reluctant to revert your patches now, hopefully you can find a fix quickly
to move forward instead.

BTW, I also have introduced another new segfault in osmo-bsc myself, testing
the fix now and merging it directly when successful, so that we don't all go
insane.

~N
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200624/36e18e0b/attachment.bin>

From laforge at osmocom.org  Thu Jun 25 16:32:26 2020
From: laforge at osmocom.org (Harald Welte)
Date: Thu, 25 Jun 2020 18:32:26 +0200
Subject: OsmoCBC Status?
In-Reply-To: <CALxx1oHkBp_JPhWMZ3mLeShvavaJvxR_KPB3XR6t9dfv+uvU-w@mail.gmail.com>
References: <CALxx1oHkBp_JPhWMZ3mLeShvavaJvxR_KPB3XR6t9dfv+uvU-w@mail.gmail.com>
Message-ID: <20200625163226.GS2605027@nataraja>

Dear Nick,

On Mon, Jun 22, 2020 at 05:45:00PM +1000, Nick Jones wrote:
> Hi all,
> Just wondering what the status of OsmoCBC is?

I guess nobody has played with it except myself (the main developer)

> I started compiling from source, but I couldn't find any docs on
> interfacing with it other than that it's via a HTTP REST API,
> If there aren't any docs are there packet captures or examples I can work
> from that'd be quicker than trying to reverse it from the source code,
> Happy to contribute some docs once I work it out,

I am currently buried alive in work and to be honest I don't recall the details.

I remember the BSC + BTS side of Cell Broadcast was fully implemented and working,
and that the CBC was somewhat early stage.  I will try to review the code and
get back as soon as I can.  If you don't get a response in 7 days, please
ping me again.

-- 
- Harald Welte <laforge at osmocom.org>            http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)


From pespin at sysmocom.de  Thu Jun 25 16:57:04 2020
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Thu, 25 Jun 2020 18:57:04 +0200
Subject: shutdown FSM breaks ttcn3-bsc-test
In-Reply-To: <20200623232128.GA26505@my.box>
References: <20200623232128.GA26505@my.box>
Message-ID: <0f05507d-fea8-d4af-cb83-f0c8181e7983@sysmocom.de>

Hi,

should be fixed by osmo-bts.git
a08685a5767d7d0e5f2f330899060c380286d671..7a7168f0a86431a082836f59288cac683c485004,
already merged in master so after tonights run test results should look
better.

Regards,
Pau

-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200625/e6f4c456/attachment.bin>

From cleb at defcon-3.net  Tue Jun 30 22:50:33 2020
From: cleb at defcon-3.net (Caleb Pal)
Date: Tue, 30 Jun 2020 15:50:33 -0700
Subject: Ericsson RBS 6402
Message-ID: <b2f14213-99ec-8e42-88b1-2edba95fc069@defcon-3.net>

Good Afternoon,

I recently acquired a NIB Ericsson RBS 6402. The specific model number
appears to be KRD 901 060/83. I see that the osmocom crew has integrated
this RBS with NextEPC at the 2019 CCC Camp event. I have used other
vendors eNodeB's with NextEPC, and would like to try the RBS with it as
well.

So far, I have booted up the RBS, and set my machine with a 10.1.1.1/24
IP address. The limited documentation I found online said the RBS should
respond to http at 10.1.1.11, at which point an XML site configuration
file can be uploaded. I see arp responses in WireShark from 10.1.1.11,
but cannot ping, or access http @ 10.1.1.11. If I place the RBS on a
network with a DHCP server, it obtains an address,? but in the same
state, no response to pings, and no http access. Also tried ssh on the
standard port, with no response.

I see the wiki has information that appears to be output from a
terminal. Is that SSH or serial to the board itself?

I do have a rasbpi available on the network with a GPS/1PPS source for
timing. Is this as simple as setting opt 042 in the DHCP server that the
RBS will use?

Any guidance is appreciated!

v/r,

Caleb



From xaver1zu at gmail.com  Tue Jun  9 13:50:15 2020
From: xaver1zu at gmail.com (Xaver Zu)
Date: Tue, 09 Jun 2020 13:50:15 -0000
Subject: Support for new SDR devices
Message-ID: <CAAtamJbY4mvdVQLPLygpToA=WzXJ7du4nYxC2jqpAe3dcGL9TQ@mail.gmail.com>

Hi all,
What are the plans to expand support for new SDR devices?
When I check the contents of osmo-trx/Transceiver52M/device/ on the git
master I see the supported lms, uhd and usrp1 devices. For example the XTRX
SDR was presented at OsmoDevCon 2018. I expected it to be included in the
master soon. At this point I see its addition in the fairwaves /
libxtrx-wip branch from 2018. That doesn't give me much encouragement for
my next question.
Would it be possible to add support for PCIe SDR from Amarisoft?
Some information about SDR is here
https://discourse.myriadrf.org/t/amarisoft-sdr-integration-with-oai/2288
Based on the
https://media.ccc.de/v/osmocon2018-82-osmotrx-status-support-for-more-drivers-sdr-apis-like-limesuite
I tried to create support by myself. I've gotten into a state that some MS
with weak requirements for signal quality and timing can connect. My branch
is here https://github.com/XK1ZU/osmo-trx/tree/PCIeSDR-LMSstyle
gr-osmosdr support is here
https://github.com/XK1ZU/gr-osmosdr/commits/PCIeSDR
This osmo-trx is able to run for a few tens of seconds then it quits and I
have to restart it, so I would need a deeper understanding of the timing
and scheduling of processes within osmo-trx. Who should be a clock master
SW stack or SDR device?

I see a lot of log error messages as
0000> Transceiver.cpp:422 [tid=140137319651072][chan=0] dumping STALE burst
in TRX->SDR interface (1:1408722 vs 7:1408723), retrans=0
<0000> Transceiver.cpp:1122 [tid=140137311258368] ClockInterface: sending
IND CLOCK 1408899
or
0000> Transceiver.cpp:280 [tid=140137328043776] Starting the transceiver
<0000> radioInterface.cpp:181 [tid=140137328043776] Starting radio device
<0000> PCIESDRDevice.cpp:199 [tid=140137328043776] PCIESDRDevice::start
<0000> PCIESDRDevice.cpp:205 [tid=140137328043776] starting PCIeSDR...,
sample rate:1.08333e+06
<0000> PCIESDRDevice.cpp:234 [tid=140137328043776] PCIESDRDevice::flush
<0000> PCIESDRDevice.cpp:219 [tid=140137328043776] msdr_start ok:
<0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment
<0000> PCIESDRDevice.cpp:532 [tid=140137328043776] Update Alignment
<0000> radioInterface.cpp:202 [tid=140137328043776] Radio started
<0000> Threads.cpp:119 [tid=140137294472960] Thread 140137294472960 (task
18522) set name: TxLower
<0000> Threads.cpp:119 [tid=140137311258368] Thread 140137311258368 (task
18524) set name: RxUpper0
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
POWERON 0'
<0000> Threads.cpp:119 [tid=140137302865664] Thread 140137302865664 (task
18523) set name: RxLower
<0002> PCIESDRDevice.cpp:363 [tid=140137302865664] rc < 0
<0002> PCIESDRDevice.cpp:364 [tid=140137302865664] Sample buffer: Requested
timestamp is not valid
<0000> Threads.cpp:119 [tid=140137319651072] Thread 140137319651072 (task
18525) set name: TxUpper0
<0002> PCIESDRDevice.cpp:365 [tid=140137302865664] timestamp = 10960,
length = 262144, time_start = 6765960, time_end = 6766960, data_start =
223320, data_end = 224320
<0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:3
rx_overflow_count:0
<0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun
ts_tmp:10976 ts:10960 hwts:6762040
<0000> radioInterface.cpp:334 [tid=140137302865664] Receive error 0
<0000> Transceiver.cpp:1162 [tid=140137302865664] Something went wrong in
thread RxLower, requesting stop
<0002> PCIESDRDevice.cpp:482 [tid=140137294472960] tx_underflow_count:4
rx_overflow_count:0
<0002> PCIESDRDevice.cpp:491 [tid=140137294472960] PCIeSDR: tx underrun
ts_tmp:13476 ts:13460 hwts:6762278
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETRXGAIN 40'
<0000> PCIESDRDevice.cpp:318 [tid=140137328043776] Setting RX gain to 40 dB.
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETRXGAIN 0 40'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETPOWER 0'
<0000> PCIESDRDevice.cpp:297 [tid=140137328043776] Setting TX gain to 60
dB. device:0x1f6e0e0 chan:0
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETPOWER 0 0'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 0 5'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 0 5'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 1 7'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 1 7'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 2 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 2 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 3 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 3 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 4 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 4 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 5 8'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 5 8'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 6 8'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 6 8'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 5 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 5 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 7 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 7 13'
<0001> Transceiver.cpp:778 [tid=140137328043776][chan=0] command is
'SETSLOT 6 13'
<0001> Transceiver.cpp:923 [tid=140137328043776][chan=0] response is 'RSP
SETSLOT 0 6 13'
<0000> osmo-trx.cpp:485 [tid=140137400406720] Shutting down transceiver...
<0000> Transceiver.cpp:338 [tid=140137400406720] Stopping the transceiver
<0000> Transceiver.cpp:351 [tid=140137400406720] Stopping the device
<0000> PCIESDRDevice.cpp:254 [tid=140137400406720] PCIESDRDevice::stop
<0000> PCIESDRDevice.cpp:261 [tid=140137400406720] PCIESDR stopped
<0000> Transceiver.cpp:364 [tid=140137400406720] Transceiver stopped
<0000> PCIESDRDevice.cpp:78 [tid=140137400406720] Closing PCIESDR Device

Yours XK1Zu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20200609/675403b1/attachment.htm>