From nhofmeyr at sysmocom.de Fri Nov 1 14:16:35 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 1 Nov 2019 15:16:35 +0100 Subject: contrib: alternative ladder diagram format Message-ID: <20191101141635.GA4637@my.box> Hi all, I wrote a script and am wondering whether it makes sense to publish it in libosmocore/contrib/. For codec negotiation patches, I was writing ladder diagrams manually in the mscgen format, and it was so annoying to type "[label=]" all the time, that I decided to write a script that parses a leaner ladder diagram format and converts it to mscgen format. I was going to use this format in osmo-msc.git, but actually, after I wrote the first osmo-msc codec ladder diagram, I went a step further and automated the process by transcribing an osmo-msc log output directly to a ladder diagram. That script can output to mscgen format, so in the end there is no dependency on that simpler ladder format from my osmo-msc patches. When writing ladder diagrams manually in the future, I'll probably choose my simpler ladder format. I could always submit the converted format instead of that, i.e. keep the simpler format to myself entirely. I could publish the script privately... Any opinions? Does it make sense to put this in libosmocore/contrib/ before any Osmocom git trees actually depend on it? See branch neels/contrib http://git.osmocom.org/libosmocore/commit/?h=neels/contrib&id=f1ec9483de0f9fa2c3321c48eba0673e97403d5d ~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 Sun Nov 3 23:03:22 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 4 Nov 2019 00:03:22 +0100 Subject: osmo-msc: repeatpaging? Message-ID: <20191103230322.GA31275@my.box> I noticed the MSC test that wants osmo-msc to repeat a Paging to the BSC and hNodeB. After fixing the Iu tests, I wanted to get this last ttcn3-msc-test working, so I was about to implement repeated Paging from osmo-msc, but the more I think about it, the less it makes sense to me. The commit log in osmo-ttcn3-hacks says: Repeating will improve the reachability of MS when a Paging is lost or not received because the MS is moving between states. This reasoning seems flawed to me, because the BSC / hNodeB is between the MSC and the MS, and the BSC *does* repeat Paging. That should cover MS moving between states. The link between MSC and {BSC,hNodeB} is considered reliable, and AFAICT nothing really gets better when repeating a Paging request to the BSS. It could make sense to maybe repeat Paging with a larger/more general Cell Identifier List? But why not send the full list in the first place? Also 3GPP TS 48.008 3.1.10 Paging says: A single PAGING message across the MSC to BSS interface contains information on the cells in which the page shall be broadcast. I interpret the "A single" as: there is no repetition of Paging requests toward the BSS, and that's also what makes most sense to me infrastructurally. Is there any spec indicating repeated Paging from the MSC? I would actually remove the test TC_lu_and_mt_sms_paging_repeated. If that's the wrong call, we should specify how osmo-msc should repeat Paging. Before that, having the test makes little sense... What do you guys think? ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at osmocom.org Mon Nov 4 09:50:52 2019 From: laforge at osmocom.org (Harald Welte) Date: Mon, 4 Nov 2019 10:50:52 +0100 Subject: osmo-msc: repeatpaging? In-Reply-To: <20191103230322.GA31275@my.box> References: <20191103230322.GA31275@my.box> Message-ID: <20191104095052.GF6733@nataraja> Hi Neels, I think the main issue is that there appears to be differences between 2G and 3G here, at least with those systems that we use for 3G (mostly nano3G). While according to fixeria, repeating of paging is required on the Iu/3G side to make things work reliably, we wshould not require or do it on the A/2G side - for reasons you have covered in your e-mail. I didn't review the Iu paging related specs. IF they agree with 2G and paging should only be sent once, then maybe we're just looking at an implementation flaw of the nano3G? One could repeat that test with other 3G hNB hardware such as sysmoCell 5000, and compare the results. In the worst case, we could add some kind of vty command, or we could also think of repeating the pagign messages in the hnb-gw, *if* it's only an implementation flaw. 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 axilirator at gmail.com Mon Nov 4 11:12:36 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 4 Nov 2019 18:12:36 +0700 Subject: osmo-msc: repeatpaging? In-Reply-To: <20191104095052.GF6733@nataraja> References: <20191103230322.GA31275@my.box> <20191104095052.GF6733@nataraja> Message-ID: Hi all, > While according to fixeria, repeating of paging is required on the Iu/3G side [...] I have no idea about the Paging requirements in Iu/3G, so most likely Harald meant somebody else ;) With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon Nov 4 13:41:47 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 4 Nov 2019 14:41:47 +0100 Subject: osmo-msc: repeatpaging? In-Reply-To: References: <20191103230322.GA31275@my.box> <20191104095052.GF6733@nataraja> Message-ID: <20191104134147.GA6119@my.box> On Mon, Nov 04, 2019 at 06:12:36PM +0700, Vadim Yanitskiy wrote: > Hi all, > > > While according to fixeria, repeating of paging is required on the Iu/3G > side [...] > > I have no idea about the Paging requirements in Iu/3G, so most likely > Harald meant somebody else ;) That would by lynxis. Ok, thx, now it makes sense where this is coming from. We could remove the paging_repeat test from MSC_Tests and keep it in MSC_Tests_Iu... ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From laforge at osmocom.org Thu Nov 7 13:05:37 2019 From: laforge at osmocom.org (Harald Welte) Date: Thu, 7 Nov 2019 14:05:37 +0100 Subject: Build failures of network:osmocom:nightly/osmo-hlr Message-ID: <20191107130537.GE31315@nataraja> Somehow osmo-hlr is no longer building in OBS for a variety of targets -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) -------------- next part -------------- An embedded message was scrubbed... From: OBS Notification Subject: Build failure of network:osmocom:nightly/osmo-hlr in xUbuntu_16.04/i586 Date: Thu, 07 Nov 2019 08:09:52 +0000 Size: 3692 URL: -------------- next part -------------- An embedded message was scrubbed... From: OBS Notification Subject: Build failure of network:osmocom:nightly/osmo-hlr in Debian_8.0/i586 Date: Thu, 07 Nov 2019 08:12:25 +0000 Size: 3781 URL: -------------- next part -------------- An embedded message was scrubbed... From: OBS Notification Subject: Build failure of network:osmocom:nightly/osmo-hlr in Debian_8.0/x86_64 Date: Thu, 07 Nov 2019 08:12:42 +0000 Size: 3586 URL: -------------- next part -------------- An embedded message was scrubbed... From: OBS Notification Subject: Build failure of network:osmocom:nightly/osmo-hlr in xUbuntu_16.04/x86_64 Date: Thu, 07 Nov 2019 08:13:00 +0000 Size: 3828 URL: From axilirator at gmail.com Thu Nov 7 13:56:28 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 7 Nov 2019 20:56:28 +0700 Subject: Build failures of network:osmocom:nightly/osmo-hlr In-Reply-To: <20191107130537.GE31315@nataraja> References: <20191107130537.GE31315@nataraja> Message-ID: Hi Harald, Neels, > Somehow osmo-hlr is no longer building in OBS for a variety of targets I also faced this problem on my machine. This particular line in db_upgrade_test.sh: echo sqlite3 -header "$db_file" "SELECT ... FROM PRAGMA_TABLE_INFO('$table') ..." seems to be the culprit. Old SQLite3 versions like 3.8.2 raise a "Syntax error". With best regards, Vadim Yanitskiy. From nhofmeyr at sysmocom.de Tue Nov 12 06:53:13 2019 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Tue, 12 Nov 2019 07:53:13 +0100 Subject: Build failures of network:osmocom:nightly/osmo-hlr In-Reply-To: References: <20191107130537.GE31315@nataraja> Message-ID: <20191112065313.GA15086@my.box> On Thu, Nov 07, 2019 at 08:56:28PM +0700, Vadim Yanitskiy wrote: > Hi Harald, Neels, > > > Somehow osmo-hlr is no longer building in OBS for a variety of targets > > I also faced this problem on my machine. This particular line in > db_upgrade_test.sh: > > echo sqlite3 -header "$db_file" "SELECT ... FROM > PRAGMA_TABLE_INFO('$table') ..." Just want to note that I see this, but am not sure how to resolve. One way could be to use sqldiff instead of extracting an alphabetically sorted DB schema? not sure if that would work. The other could be to find backwards compatible way of doing that PRAGMA_TABLE_INFO stuff, which I basically duckducked from the internet and have no idea about otherwise. The other other solution is to require a newer sqlite version on the build slaves?? But I think it is worth the effort to have and keep such a DB equivalence test. ~N -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From osmith at sysmocom.de Tue Nov 12 12:43:58 2019 From: osmith at sysmocom.de (Oliver Smith) Date: Tue, 12 Nov 2019 13:43:58 +0100 Subject: Build failures of network:osmocom:nightly/osmo-hlr In-Reply-To: <20191112065313.GA15086@my.box> References: <20191107130537.GE31315@nataraja> <20191112065313.GA15086@my.box> Message-ID: Let's skip the check for old sqlite versions: https://gerrit.osmocom.org/c/osmo-hlr/+/16048 On 11/12/19 7:53 AM, Neels Hofmeyr wrote: > On Thu, Nov 07, 2019 at 08:56:28PM +0700, Vadim Yanitskiy wrote: >> Hi Harald, Neels, >> >>> Somehow osmo-hlr is no longer building in OBS for a variety of targets >> >> I also faced this problem on my machine. This particular line in >> db_upgrade_test.sh: >> >> echo sqlite3 -header "$db_file" "SELECT ... FROM >> PRAGMA_TABLE_INFO('$table') ..." > > Just want to note that I see this, but am not sure how to resolve. One way > could be to use sqldiff instead of extracting an alphabetically sorted DB > schema? not sure if that would work. > > The other could be to find backwards compatible way of doing that > PRAGMA_TABLE_INFO stuff, which I basically duckducked from the internet and > have no idea about otherwise. > > The other other solution is to require a newer sqlite version on the build > slaves?? > > But I think it is worth the effort to have and keep such a DB equivalence test. > > ~N > -- - Oliver Smith https://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte From axilirator at gmail.com Thu Nov 28 15:22:24 2019 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 28 Nov 2019 22:22:24 +0700 Subject: 36c3: GSM base stations wanted Message-ID: Dear all, 36c3 is going to happen soon, and as usually we're planing to setup our own GSM/UMTS network (LTE is to be discussed). While we do have enough UMTS NodeB units, we're looking for heroes who could sacrifice their GSM base stations (preferably sysmoBTS or nanoBTS) for the duration of the congress. Note that we're not considering SDRs (unless somebody with a strong aspiration wants to ensure proper clock distribution, filtering, power amplification, etc). Please let us know 1) how many (and what kind of) units we could borrow from you, 2) can you bring them to Leipzig before the first day, or can you drop them somewhere in Berlin (Sysmocom? AfRa?). Thanks! On behalf of the GSM team, Vadim Yanitskiy. From laforge at osmocom.org Sat Nov 30 11:51:13 2019 From: laforge at osmocom.org (Harald Welte) Date: Sat, 30 Nov 2019 12:51:13 +0100 Subject: request: osomocom git repo branch cleanup Message-ID: <20191130115113.GN635893@nataraja> Dear Osmocom developers, the number of branches in many repositories (most notably libosmocore) is growing to a rather large number, and I would like to encourage everyone to have a quick look about which branches can be deleted by now (and delete them, if no longer needed). Thanks! Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)