From nhofmeyr at sysmocom.de  Mon Jul  2 13:49:08 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 2 Jul 2018 15:49:08 +0200
Subject: osmo-bsc refactoring / inter-BSC handover
In-Reply-To: <20180625135754.GW3565@nataraja>
References: <20180615113908.GM20729@nataraja> <20180618055056.GA8364@my.box>
 <20180625135754.GW3565@nataraja>
Message-ID: <20180702134908.GA31318@my.box>

On Mon, Jun 25, 2018 at 03:57:54PM +0200, Harald Welte wrote:
> > I tried for very long to resolve
> > "BSC_Tests.ttcn:2755.13-2756.31: error: Message type `@BSSAP_CodecPort.BSSAP_N_CONNECT_req' is not present on the outgoing list of port type `@BSSMAP_Emulation.BSSAP_Conn_PT'"
> > but it feels like a brick wall...
> 
> This specific error message tells you that the BSSAP_N_CONNECT_req type
> is not listed in the singature of the BSSAP_Conn_PT.  Let's look at its
> definition:
> 
> /* port between individual per-connection components and this dispatcher */
> type port BSSAP_Conn_PT message {
> 		/* BSSAP or direct DTAP messages from/to clients */
> 	inout	PDU_BSSAP, PDU_DTAP_MO, PDU_DTAP_MT,
> 		/* misc indications / requests between SCCP and client */
> 		BSSAP_Conn_Prim,
> 		/* Client requests us to create SCCP Connection */
> 		BSSAP_Conn_Req,
> 		/* MGCP, only used for IPA SCCPlite (MGCP in IPA mux) */
> 		MgcpCommand, MgcpResponse;
> } with { extension "internal" };
> 
> and this definition clearly doesn't list the related type in its
> signature.  So you're sending something to the port which it doesn't
> support.

Exactly, and I tried to add it, but couldn't figure out how to make it work. I
don't remember the details anymore, but I felt very dumb...

In short, can you help me out by making this part compile?

private function f_tc_ho_into_this_bsc(charstring id) runs on MSC_ConnHdlr {
	BSSAP.send(ts_BSSAP_CONNECT_req(g_bssap.sccp_addr_peer, g_bssap.sccp_addr_own, 2342,
			ts_BSSMAP_HandoverRequest()));
	BSSAP.receive(tr_BSSAP_CONNECT_cfm(2342, omit));
}

(the ts_BSSMAP_HandoverRequest definition is in https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9674/4/library/BSSMAP_Templates.ttcn )

That would be great.

~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/20180702/e4ab54f9/attachment.bin>

From laforge at gnumonks.org  Mon Jul  2 14:16:45 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 2 Jul 2018 16:16:45 +0200
Subject: osmo-bsc refactoring / inter-BSC handover
In-Reply-To: <20180702134908.GA31318@my.box>
References: <20180615113908.GM20729@nataraja> <20180618055056.GA8364@my.box>
 <20180625135754.GW3565@nataraja> <20180702134908.GA31318@my.box>
Message-ID: <20180702141645.GE30063@nataraja>

Hi Neels,

On Mon, Jul 02, 2018 at 03:49:08PM +0200, Neels Hofmeyr wrote:
> In short, can you help me out by making this part compile?

No, sorry ;)  

Your solution is to send "BSSAP_Conn_Req" through the BSSAP_Conn_PT, not
ts_BSSAP_CONNET_req.  The latter is a primitive of the BSSAP_CodecPort, and not the BSSAP_Conn_PT.

-- 
- Harald Welte <laforge at gnumonks.org>           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 Jul  4 14:16:34 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 4 Jul 2018 16:16:34 +0200
Subject: cancellation of build1.osmocom.org
Message-ID: <20180704141634.GB30063@nataraja>

Hi!

We've not used the old build1.osmocom.org machine since late April, so I
am finally pulling the plug and cancelling the contract as of tomorrow.

I manually looked around and the only parts that looked worth backing
up was ~osmocom-build/neels which I've now copied over to
build2.osmocom.org:~root/neels/from_build1/

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


From babarbuttgrt at yahoo.com  Wed Jul 11 16:53:54 2018
From: babarbuttgrt at yahoo.com (Babar Ali)
Date: Wed, 11 Jul 2018 16:53:54 +0000 (UTC)
Subject: Osmotrx compatibility with LimeSDR mini
In-Reply-To: <20180711163253.GA3266@nataraja>
References: <49239867.2046373.1531238431928.ref@mail.yahoo.com>
 <49239867.2046373.1531238431928@mail.yahoo.com>
 <20180711163253.GA3266@nataraja>
Message-ID: <339906985.2767692.1531328034552@mail.yahoo.com>



Anyone has an experience of Setuping 2G Network using NITB & LimeSDR Mini, which version of osmotrx is working fine with LimeSDR Mini.






Thank You




Regards

Babar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180711/3d8c27ea/attachment.htm>

From laforge at gnumonks.org  Wed Jul 11 20:26:05 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 11 Jul 2018 22:26:05 +0200
Subject: Osmotrx compatibility with LimeSDR mini
In-Reply-To: <339906985.2767692.1531328034552@mail.yahoo.com>
References: <49239867.2046373.1531238431928.ref@mail.yahoo.com>
 <49239867.2046373.1531238431928@mail.yahoo.com>
 <20180711163253.GA3266@nataraja>
 <339906985.2767692.1531328034552@mail.yahoo.com>
Message-ID: <20180711202605.GA5894@nataraja>

On Wed, Jul 11, 2018 at 04:53:54PM +0000, Babar Ali wrote:
> Anyone has an experience of Setuping 2G Network using NITB & LimeSDR Mini, which version of osmotrx is working fine with LimeSDR Mini.

We have seen very good results using the new osmo-trx-lms with LimeSDR-mini.

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


From babarbuttgrt at yahoo.com  Wed Jul 11 23:36:57 2018
From: babarbuttgrt at yahoo.com (Babar Ali)
Date: Wed, 11 Jul 2018 23:36:57 +0000 (UTC)
Subject: Osmotrx compatibility with LimeSDR mini
In-Reply-To: <20180711202605.GA5894@nataraja>
References: <49239867.2046373.1531238431928.ref@mail.yahoo.com>
 <49239867.2046373.1531238431928@mail.yahoo.com>
 <20180711163253.GA3266@nataraja>
 <339906985.2767692.1531328034552@mail.yahoo.com>
 <20180711202605.GA5894@nataraja>
Message-ID: <1578242801.2996172.1531352217810@mail.yahoo.com>

Hi Harald
Thank very much for your support please, i?ll test & share the results.
Further kindly let me clear one more thing please, can I build osmotrx on RaspbianOS, I have already tried to build osmotrx v0.3 on RasbianOS it was build successfully but when I run osmo-trx ?help, it shows only one option that is -C which I can use with osmo-trx, no other options are available, is it cannot be build completely on raspberry pi 3? or what?s gone wrong? any suggestions/comments in this regard please.
Thank you for your support & time please.

Regards?
Babar

On Thursday, July 12, 2018, 1:26 AM, Harald Welte <laforge at gnumonks.org> wrote:

On Wed, Jul 11, 2018 at 04:53:54PM +0000, Babar Ali wrote:
> Anyone has an experience of Setuping 2G Network using NITB & LimeSDR Mini, which version of osmotrx is working fine with LimeSDR Mini.

We have seen very good results using the new osmo-trx-lms with LimeSDR-mini.

-- 
- Harald Welte <laforge at gnumonks.org>? ? ? ? ? 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: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180711/650f9ae3/attachment.htm>

From pespin at sysmocom.de  Thu Jul 12 09:05:05 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Thu, 12 Jul 2018 11:05:05 +0200
Subject: Osmotrx compatibility with LimeSDR mini
In-Reply-To: <1578242801.2996172.1531352217810@mail.yahoo.com>
References: <49239867.2046373.1531238431928.ref@mail.yahoo.com>
 <49239867.2046373.1531238431928@mail.yahoo.com>
 <20180711163253.GA3266@nataraja>
 <339906985.2767692.1531328034552@mail.yahoo.com>
 <20180711202605.GA5894@nataraja>
 <1578242801.2996172.1531352217810@mail.yahoo.com>
Message-ID: <813be941-d018-5465-b8f2-d1e2538f5889@sysmocom.de>

Hi Babar,

If you want to use a LimeSDR-mini, you should build latest master, and 
use osmo-trx-lms binary. To generate that binary, you first need to 
build and install latest LimeSuite master [1], and then build osmo-trx 
with --with-lms configure flag. As you are building for raspberry pi3, 
you may want to enable instruction set optimizations as explained in the 
user manual section "12 OsmoTRX hardware architecture support" [2]. Have 
a look at the wiki page too for further information [3].

Also a reminder: we have osmo-trx-lms already available as a debian 
package for debian9 [4], but I think we don't enable NEON on that build.

[1] https://github.com/myriadrf/LimeSuite
[2] http://ftp.osmocom.org/docs/latest/osmotrx-usermanual.pdf
[3] https://osmocom.org/projects/osmotrx/wiki/OsmoTRX
[4] 
https://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_9.0/

On 12/07/18 01:36, Babar Ali wrote:
> Hi Harald
> 
> Thank very much for your support please, i?ll test & share the results.
> 
> Further kindly let me clear one more thing please, can I build osmotrx 
> on RaspbianOS, I have already tried to build osmotrx v0.3 on RasbianOS 
> it was build successfully but when I run osmo-trx ?help, it shows only 
> one option that is -C which I can use with osmo-trx, no other options 
> are available, is it cannot be build completely on raspberry pi 3? or 
> what?s gone wrong? any suggestions/comments in this regard please.
> 
> Thank you for your support & time please.
> 
> Regards
> Babar
> 
> On Thursday, July 12, 2018, 1:26 AM, Harald Welte <laforge at gnumonks.org> 
> wrote:
> 
>     On Wed, Jul 11, 2018 at 04:53:54PM +0000, Babar Ali wrote:
> 
>      > Anyone has an experience of Setuping 2G Network using NITB &
>     LimeSDR Mini, which version of osmotrx is working fine with LimeSDR
>     Mini.
> 
> 
>     We have seen very good results using the new osmo-trx-lms with
>     LimeSDR-mini.
> 
>     -- 
>     - Harald Welte <laforge at gnumonks.org <mailto:laforge at gnumonks.org>>
>     http://laforge.gnumonks.org/
>     ============================================================================
>     "Privacy in residential applications is a desirable marketing option."
>      ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (ETSI EN 300
>     175-7 <tel:300%20175-7> Ch. A6)
> 

-- 
- 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


From antony at funquality.be  Thu Jul 12 11:33:20 2018
From: antony at funquality.be (Antony Lemmens)
Date: Thu, 12 Jul 2018 13:33:20 +0200
Subject: Multi-arfcn multiplexing over same physical channel
Message-ID: <CAD3eK9QCJtKcoWVm03Fs6XNQ0V0QdZ_wVsSOqCbFSs9t1GJsmQ@mail.gmail.com>

Hi there,
I'm really happy to make my LimeSDR working with the master branch, good
job guys!


I'm now trying to enable the multi-arfcn multiplexed over one physical
channel but I do not succeed to have it working (No response from
transceiver for phy0.1 (CMD RXTUNE 894000)).


Do I need to configure or pass some parameters (see further for what I'm
doing)?


I am starting osmo-bts-trx with "-t 2" option, and here is the extract of
part of my configuration file:

----- osmo-trx-lms.cfg
trx
 multi-arfcn enable
 swap-channels disable
 egprs enable
 tx-sps 4
 rx-sps 4
 chan 0
  tx-path BAND1
  rx-path LNAW


----- osmo-bts-trx.cfg
phy 0
 instance 0
  osmotrx rx-gain 10

phy 0
 instance 1
  osmotrx rx-gain 10

bts 0
 band 900
 trx 0
  phy 0 instance 0
 trx 1
  phy 0 instance 1


----- osmo-bsc.cfg
 bts 0
  type sysmobts
  band GSM900
  trx 0
   arfcn 10
  trx 1
   arfcn 20


Thanks in advance,
Antony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180712/f4bcdd9f/attachment.htm>

From antony at funquality.be  Thu Jul 12 13:45:35 2018
From: antony at funquality.be (Antony Lemmens)
Date: Thu, 12 Jul 2018 15:45:35 +0200
Subject: Multiple osmo-trx-xxx
Message-ID: <CAD3eK9QTqj_5GTirUDtve=bhtWDnNuNGkKaCvyt1oKcHiqaO2A@mail.gmail.com>

Hello,
I am trying some setup to have multiple channels working all together: I
have an UmTRX and a LimeSDR boards working fine.
The problem is that I cannot launch osmo-trx-uhd and osmo-trx-lms at the
same time as the VTY TCP port are defined in libosmocore.

Is it a way of disabling the VTY or change the TCP port it listen to?


Have a nice day,
Antony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180712/5db7fa59/attachment.htm>

From pespin at sysmocom.de  Thu Jul 12 14:04:37 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Thu, 12 Jul 2018 16:04:37 +0200
Subject: Multi-arfcn multiplexing over same physical channel
In-Reply-To: <CAD3eK9QCJtKcoWVm03Fs6XNQ0V0QdZ_wVsSOqCbFSs9t1GJsmQ@mail.gmail.com>
References: <CAD3eK9QCJtKcoWVm03Fs6XNQ0V0QdZ_wVsSOqCbFSs9t1GJsmQ@mail.gmail.com>
Message-ID: <dfd90c8d-a811-a502-62f3-fdda3b5fc4b9@sysmocom.de>

Hi Antony,

I didn't test myself this kind of setup and I bet nobody confirmed it is 
working for osmo-trx-lms yet.

In any case, I think you need to tell osmo-trx to enable 2 channels, by 
adding a "chan 1" node to your config, same as with you have with "chan 
0", but with RX/TX paths set accordingly.

-- 
- 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


From pespin at sysmocom.de  Thu Jul 12 14:09:03 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Thu, 12 Jul 2018 16:09:03 +0200
Subject: Multiple osmo-trx-xxx
In-Reply-To: <CAD3eK9QTqj_5GTirUDtve=bhtWDnNuNGkKaCvyt1oKcHiqaO2A@mail.gmail.com>
References: <CAD3eK9QTqj_5GTirUDtve=bhtWDnNuNGkKaCvyt1oKcHiqaO2A@mail.gmail.com>
Message-ID: <6506fa75-6768-979c-373c-7beaacbdee84@sysmocom.de>

Hi Antony,

You can change the IP addr in the VTY config. You can for instance add a 
127.0.0.2 to your loopback iface and then point one of them to use that 
IP addr.

See for an example vty cfg: 
https://git.osmocom.org/osmo-gsm-tester/tree/src/osmo_gsm_tester/templates/osmo-trx.cfg.tmpl

line vty
  bind 127.0.0.2
ctrl
  bind 127.0.0.2

The default value used if not specified is 127.0.0.1

-- 
- 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


From laforge at gnumonks.org  Thu Jul 12 17:51:14 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 12 Jul 2018 19:51:14 +0200
Subject: Osmotrx compatibility with LimeSDR mini
In-Reply-To: <1578242801.2996172.1531352217810@mail.yahoo.com>
References: <49239867.2046373.1531238431928.ref@mail.yahoo.com>
 <49239867.2046373.1531238431928@mail.yahoo.com>
 <20180711163253.GA3266@nataraja>
 <339906985.2767692.1531328034552@mail.yahoo.com>
 <20180711202605.GA5894@nataraja>
 <1578242801.2996172.1531352217810@mail.yahoo.com>
Message-ID: <20180712175114.GB6094@nataraja>

On Wed, Jul 11, 2018 at 11:36:57PM +0000, Babar Ali wrote:

> Further kindly let me clear one more thing please, can I build osmotrx on RaspbianOS, I have already tried to build osmotrx v0.3 on RasbianOS [...]

why work with an old version?

If you want to use the latest features (such as native limesuite support which was
developed in April + May 2018), you cannot use a version tagged in march ;)

please use current git master.

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


From babarbuttgrt at yahoo.com  Sun Jul 15 12:00:37 2018
From: babarbuttgrt at yahoo.com (Babar Ali)
Date: Sun, 15 Jul 2018 12:00:37 +0000 (UTC)
Subject: Osmotrx compatibility with LimeSDR mini
In-Reply-To: <813be941-d018-5465-b8f2-d1e2538f5889@sysmocom.de>
References: <49239867.2046373.1531238431928.ref@mail.yahoo.com>
 <49239867.2046373.1531238431928@mail.yahoo.com>
 <20180711163253.GA3266@nataraja>
 <339906985.2767692.1531328034552@mail.yahoo.com>
 <20180711202605.GA5894@nataraja>
 <1578242801.2996172.1531352217810@mail.yahoo.com>
 <813be941-d018-5465-b8f2-d1e2538f5889@sysmocom.de>
Message-ID: <1634430669.4659157.1531656037586@mail.yahoo.com>

Hi Pedrol
Thank you for your support, I have build following components from source.
1. SoapySDR v0.6.12. Lime Suite v18.06.03. UHD v3.12.0.0-rc14. SoapyUHD v0.3.45. osmo-trx v0.4.0 configure --with-lms
however i have only following options are available with osmo-trx
root at miniBTS:/home/pi/osmocom/osmo-trx# osmo-trx-lms -h
Options:? -h? ? This text? -C? ? Filename The config file to use? -V? ? Print the version of OsmoTRX
why on raspberry all options are not available with osmo-trx
Babar Ali
 

    On Saturday, 14 July 2018, 4:31:43 AM GMT+5, Pau Espin Pedrol <pespin at sysmocom.de> wrote:  
 
 Hi Babar,

If you want to use a LimeSDR-mini, you should build latest master, and 
use osmo-trx-lms binary. To generate that binary, you first need to 
build and install latest LimeSuite master [1], and then build osmo-trx 
with --with-lms configure flag. As you are building for raspberry pi3, 
you may want to enable instruction set optimizations as explained in the 
user manual section "12 OsmoTRX hardware architecture support" [2]. Have 
a look at the wiki page too for further information [3].

Also a reminder: we have osmo-trx-lms already available as a debian 
package for debian9 [4], but I think we don't enable NEON on that build.

[1] https://github.com/myriadrf/LimeSuite
[2] http://ftp.osmocom.org/docs/latest/osmotrx-usermanual.pdf
[3] https://osmocom.org/projects/osmotrx/wiki/OsmoTRX
[4] 
https://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_9.0/

On 12/07/18 01:36, Babar Ali wrote:
> Hi Harald
> 
> Thank very much for your support please, i?ll test & share the results.
> 
> Further kindly let me clear one more thing please, can I build osmotrx 
> on RaspbianOS, I have already tried to build osmotrx v0.3 on RasbianOS 
> it was build successfully but when I run osmo-trx ?help, it shows only 
> one option that is -C which I can use with osmo-trx, no other options 
> are available, is it cannot be build completely on raspberry pi 3? or 
> what?s gone wrong? any suggestions/comments in this regard please.
> 
> Thank you for your support & time please.
> 
> Regards
> Babar
> 
> On Thursday, July 12, 2018, 1:26 AM, Harald Welte <laforge at gnumonks.org> 
> wrote:
> 
>? ? On Wed, Jul 11, 2018 at 04:53:54PM +0000, Babar Ali wrote:
> 
>? ? ? > Anyone has an experience of Setuping 2G Network using NITB &
>? ? LimeSDR Mini, which version of osmotrx is working fine with LimeSDR
>? ? Mini.
> 
> 
>? ? We have seen very good results using the new osmo-trx-lms with
>? ? LimeSDR-mini.
> 
>? ? -- 
>? ? - Harald Welte <laforge at gnumonks.org <mailto:laforge at gnumonks.org>>
>? ? http://laforge.gnumonks.org/
>? ? ============================================================================
>? ? "Privacy in residential applications is a desirable marketing option."
>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (ETSI EN 300
>? ? 175-7 <tel:300%20175-7> Ch. A6)
> 

-- 
- 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180715/53661add/attachment.htm>

From djks74 at gmail.com  Sun Jul 15 13:16:34 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Sun, 15 Jul 2018 20:16:34 +0700
Subject: Osmotrx compatibility with LimeSDR mini
In-Reply-To: <1634430669.4659157.1531656037586@mail.yahoo.com>
References: <49239867.2046373.1531238431928.ref@mail.yahoo.com>
 <49239867.2046373.1531238431928@mail.yahoo.com>
 <20180711163253.GA3266@nataraja>
 <339906985.2767692.1531328034552@mail.yahoo.com>
 <20180711202605.GA5894@nataraja>
 <1578242801.2996172.1531352217810@mail.yahoo.com>
 <813be941-d018-5465-b8f2-d1e2538f5889@sysmocom.de>
 <1634430669.4659157.1531656037586@mail.yahoo.com>
Message-ID: <CANWiJYiKg25V4A7U5W2TT7nscNx2sp4n=xh-Sxuj_9jV7vd=_g@mail.gmail.com>

Hi,
You need to configure and add the following the -C limesdr.cfg after the
osmo-trx-lms command.

example: osmo-trx-lms -C limesdr.cfg

the example configuration can find on the doc from osmo-trx folder.

Thats why no other option since it use -C to fill all option on it.

hope this help.

Best Regards,
Sandi DUO

On Sun, Jul 15, 2018, 19:01 Babar Ali <babarbuttgrt at yahoo.com> wrote:

> Hi Pedrol
>
> Thank you for your support, I have build following components from source.
>
> 1. SoapySDR v0.6.1
> 2. Lime Suite v18.06.0
> 3. UHD v3.12.0.0-rc1
> 4. SoapyUHD v0.3.4
> 5. osmo-trx v0.4.0 configure --with-lms
>
> however i have only following options are available with osmo-trx
>
> *root at miniBTS:/home/pi/osmocom/osmo-trx#* osmo-trx-lms -h
>
> Options:
>   -h    This text
>   -C    Filename The config file to use
>   -V    Print the version of OsmoTRX
>
> *why on raspberry all options are not available with osmo-trx*
>
> *Babar Ali*
>
>
> On Saturday, 14 July 2018, 4:31:43 AM GMT+5, Pau Espin Pedrol <
> pespin at sysmocom.de> wrote:
>
>
> Hi Babar,
>
> If you want to use a LimeSDR-mini, you should build latest master, and
> use osmo-trx-lms binary. To generate that binary, you first need to
> build and install latest LimeSuite master [1], and then build osmo-trx
> with --with-lms configure flag. As you are building for raspberry pi3,
> you may want to enable instruction set optimizations as explained in the
> user manual section "12 OsmoTRX hardware architecture support" [2]. Have
> a look at the wiki page too for further information [3].
>
> Also a reminder: we have osmo-trx-lms already available as a debian
> package for debian9 [4], but I think we don't enable NEON on that build.
>
> [1] https://github.com/myriadrf/LimeSuite
> [2] http://ftp.osmocom.org/docs/latest/osmotrx-usermanual.pdf
> [3] https://osmocom.org/projects/osmotrx/wiki/OsmoTRX
> [4]
> https://download.opensuse.org/repositories/network:/osmocom:
> /nightly/Debian_9.0/
>
> On 12/07/18 01:36, Babar Ali wrote:
> > Hi Harald
> >
> > Thank very much for your support please, i?ll test & share the results.
> >
> > Further kindly let me clear one more thing please, can I build osmotrx
> > on RaspbianOS, I have already tried to build osmotrx v0.3 on RasbianOS
> > it was build successfully but when I run osmo-trx ?help, it shows only
> > one option that is -C which I can use with osmo-trx, no other options
> > are available, is it cannot be build completely on raspberry pi 3? or
> > what?s gone wrong? any suggestions/comments in this regard please.
> >
> > Thank you for your support & time please.
> >
> > Regards
> > Babar
> >
> > On Thursday, July 12, 2018, 1:26 AM, Harald Welte <laforge at gnumonks.org>
>
> > wrote:
> >
> >    On Wed, Jul 11, 2018 at 04:53:54PM +0000, Babar Ali wrote:
> >
> >      > Anyone has an experience of Setuping 2G Network using NITB &
> >    LimeSDR Mini, which version of osmotrx is working fine with LimeSDR
> >    Mini.
> >
> >
> >    We have seen very good results using the new osmo-trx-lms with
> >    LimeSDR-mini.
> >
> >    --
> >    - Harald Welte <laforge at gnumonks.org <mailto:laforge at gnumonks.org>>
>
> >    http://laforge.gnumonks.org/
> >    ============================================================
> ================
> >    "Privacy in residential applications is a desirable marketing option."
> >                                                        (ETSI EN 300
>
> >    175-7 <tel:300%20175-7> Ch. A6)
> >
>
> --
> - 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180715/116c03ac/attachment.htm>

From babarbuttgrt at yahoo.com  Sun Jul 15 23:16:52 2018
From: babarbuttgrt at yahoo.com (Babar Ali)
Date: Sun, 15 Jul 2018 23:16:52 +0000 (UTC)
Subject: Fw: Osmotrx compatibility with LimeSDR mini
In-Reply-To: <334448140.4667108.1531659003599@mail.yahoo.com>
References: <49239867.2046373.1531238431928.ref@mail.yahoo.com>
 <49239867.2046373.1531238431928@mail.yahoo.com>
 <20180711163253.GA3266@nataraja>
 <339906985.2767692.1531328034552@mail.yahoo.com>
 <20180711202605.GA5894@nataraja>
 <1578242801.2996172.1531352217810@mail.yahoo.com>
 <813be941-d018-5465-b8f2-d1e2538f5889@sysmocom.de>
 <334448140.4667108.1531659003599@mail.yahoo.com>
Message-ID: <714474897.4843265.1531696612899@mail.yahoo.com>

I have build following components from source.


1. SoapySDR v0.6.12. Lime Suite?v18.06.03. UHD?v3.12.0.0-rc14. SoapyUHD v0.3.45. osmo-trx v0.4.0 configure --with-lms6. osmo-nitb7. osmo-bts-trx
however i have only following options are available with osmo-trx
root at miniBTS:/home/pi/osmocom/osmo-trx#?osmo-trx-lms -h
Options:? -h? ? This text? -C? ? Filename The config file to use? -V? ? Print the version of OsmoTRX
I have run each instance in separate windows but I cannot show network, log file of following screens along with config files attached. would you please help me whats going wrong, I am newbie?
terminal 1 : osmo-trx-lms -C osmo-trx-limesdr.configterminal 2: osmo-nitb -c openbsc.configterminal 3: osmo-bts-trx? -c osmobts.config
attached config files have grabbed from?https://github.com/myriadrf/cellular-network-configs/tree/master/osmocom
Regards

Babar Ali
 

    On Saturday, 14 July 2018, 4:31:43 AM GMT+5, Pau Espin Pedrol <pespin at sysmocom.de> wrote:  
 
 Hi Babar,

If you want to use a LimeSDR-mini, you should build latest master, and 
use osmo-trx-lms binary. To generate that binary, you first need to 
build and install latest LimeSuite master [1], and then build osmo-trx 
with --with-lms configure flag. As you are building for raspberry pi3, 
you may want to enable instruction set optimizations as explained in the 
user manual section "12 OsmoTRX hardware architecture support" [2]. Have 
a look at the wiki page too for further information [3].

Also a reminder: we have osmo-trx-lms already available as a debian 
package for debian9 [4], but I think we don't enable NEON on that build.

[1] https://github.com/myriadrf/LimeSuite
[2] http://ftp.osmocom.org/docs/latest/osmotrx-usermanual.pdf
[3] https://osmocom.org/projects/osmotrx/wiki/OsmoTRX
[4] 
https://download.opensuse.org/repositories/network:/osmocom:/nightly/Debian_9.0/

On 12/07/18 01:36, Babar Ali wrote:
> Hi Harald
> 
> Thank very much for your support please, i?ll test & share the results.
> 
> Further kindly let me clear one more thing please, can I build osmotrx 
> on RaspbianOS, I have already tried to build osmotrx v0.3 on RasbianOS 
> it was build successfully but when I run osmo-trx ?help, it shows only 
> one option that is -C which I can use with osmo-trx, no other options 
> are available, is it cannot be build completely on raspberry pi 3? or 
> what?s gone wrong? any suggestions/comments in this regard please.
> 
> Thank you for your support & time please.
> 
> Regards
> Babar
> 
> On Thursday, July 12, 2018, 1:26 AM, Harald Welte <laforge at gnumonks.org> 
> wrote:
> 
>? ? On Wed, Jul 11, 2018 at 04:53:54PM +0000, Babar Ali wrote:
> 
>? ? ? > Anyone has an experience of Setuping 2G Network using NITB &
>? ? LimeSDR Mini, which version of osmotrx is working fine with LimeSDR
>? ? Mini.
> 
> 
>? ? We have seen very good results using the new osmo-trx-lms with
>? ? LimeSDR-mini.
> 
>? ? -- 
>? ? - Harald Welte <laforge at gnumonks.org <mailto:laforge at gnumonks.org>>
>? ? http://laforge.gnumonks.org/
>? ? ============================================================================
>? ? "Privacy in residential applications is a desirable marketing option."
>? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? (ETSI EN 300
>? ? 175-7 <tel:300%20175-7> Ch. A6)
> 

-- 
- 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180715/71c3dbb2/attachment.htm>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: osmo-nitb.txt
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180715/71c3dbb2/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: osmo-trx.txt
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180715/71c3dbb2/attachment-0001.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: osmobts.txt
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180715/71c3dbb2/attachment-0002.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-trx-limesdr.cfg
Type: application/octet-stream
Size: 283 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180715/71c3dbb2/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openbsc.cfg
Type: application/octet-stream
Size: 3663 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180715/71c3dbb2/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: osmo-bts.cfg
Type: application/octet-stream
Size: 1934 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180715/71c3dbb2/attachment-0002.obj>

From djks74 at gmail.com  Mon Jul 16 04:06:08 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Mon, 16 Jul 2018 11:06:08 +0700
Subject: Fw: Osmotrx compatibility with LimeSDR mini
In-Reply-To: <714474897.4843265.1531696612899@mail.yahoo.com>
References: <49239867.2046373.1531238431928.ref@mail.yahoo.com>
 <49239867.2046373.1531238431928@mail.yahoo.com>
 <20180711163253.GA3266@nataraja>
 <339906985.2767692.1531328034552@mail.yahoo.com>
 <20180711202605.GA5894@nataraja>
 <1578242801.2996172.1531352217810@mail.yahoo.com>
 <813be941-d018-5465-b8f2-d1e2538f5889@sysmocom.de>
 <334448140.4667108.1531659003599@mail.yahoo.com>
 <714474897.4843265.1531696612899@mail.yahoo.com>
Message-ID: <CANWiJYiF+m7TjepTPkJu2mvE47LhpAp4ioc4_akOUnC1KybzbA@mail.gmail.com>

Hi,
all info is here :
https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_with_Asterisk

regards,
DUO

On Mon, Jul 16, 2018 at 6:16 AM, Babar Ali <babarbuttgrt at yahoo.com> wrote:

> I have build following components from source.
>
>
> 1. SoapySDR v0.6.1
> 2. Lime Suite v18.06.0
> 3. UHD v3.12.0.0-rc1
> 4. SoapyUHD v0.3.4
> 5. osmo-trx v0.4.0 configure --with-lms
> 6. osmo-nitb
> 7. osmo-bts-trx
>
> however i have only following options are available with osmo-trx
>
> *root at miniBTS:/home/pi/osmocom/osmo-trx#* osmo-trx-lms -h
>
> Options:
>   -h    This text
>   -C    Filename The config file to use
>   -V    Print the version of OsmoTRX
>
> I have run each instance in separate windows but I cannot show network,
> log file of following screens along with config files attached. would you
> please help me whats going wrong, I am newbie
>
> terminal 1 : osmo-trx-lms -C osmo-trx-limesdr.config
> terminal 2: osmo-nitb -c openbsc.config
> terminal 3: osmo-bts-trx  -c osmobts.config
>
> *attached config files have grabbed
> from https://github.com/myriadrf/cellular-network-configs/tree/master/osmocom
> <https://github.com/myriadrf/cellular-network-configs/tree/master/osmocom>*
>
> *Regards*
>
>
> *Babar Ali*
>
>
> On Saturday, 14 July 2018, 4:31:43 AM GMT+5, Pau Espin Pedrol <
> pespin at sysmocom.de> wrote:
>
>
> Hi Babar,
>
> If you want to use a LimeSDR-mini, you should build latest master, and
> use osmo-trx-lms binary. To generate that binary, you first need to
> build and install latest LimeSuite master [1], and then build osmo-trx
> with --with-lms configure flag. As you are building for raspberry pi3,
> you may want to enable instruction set optimizations as explained in the
> user manual section "12 OsmoTRX hardware architecture support" [2]. Have
> a look at the wiki page too for further information [3].
>
> Also a reminder: we have osmo-trx-lms already available as a debian
> package for debian9 [4], but I think we don't enable NEON on that build.
>
> [1] https://github.com/myriadrf/LimeSuite
> [2] http://ftp.osmocom.org/docs/latest/osmotrx-usermanual.pdf
> [3] https://osmocom.org/projects/osmotrx/wiki/OsmoTRX
> [4]
> https://download.opensuse.org/repositories/network:/osmocom:
> /nightly/Debian_9.0/
>
> On 12/07/18 01:36, Babar Ali wrote:
> > Hi Harald
> >
> > Thank very much for your support please, i?ll test & share the results.
> >
> > Further kindly let me clear one more thing please, can I build osmotrx
> > on RaspbianOS, I have already tried to build osmotrx v0.3 on RasbianOS
> > it was build successfully but when I run osmo-trx ?help, it shows only
> > one option that is -C which I can use with osmo-trx, no other options
> > are available, is it cannot be build completely on raspberry pi 3? or
> > what?s gone wrong? any suggestions/comments in this regard please.
> >
> > Thank you for your support & time please.
> >
> > Regards
> > Babar
> >
> > On Thursday, July 12, 2018, 1:26 AM, Harald Welte <laforge at gnumonks.org>
>
> > wrote:
> >
> >    On Wed, Jul 11, 2018 at 04:53:54PM +0000, Babar Ali wrote:
> >
> >      > Anyone has an experience of Setuping 2G Network using NITB &
> >    LimeSDR Mini, which version of osmotrx is working fine with LimeSDR
> >    Mini.
> >
> >
> >    We have seen very good results using the new osmo-trx-lms with
> >    LimeSDR-mini.
> >
> >    --
> >    - Harald Welte <laforge at gnumonks.org <mailto:laforge at gnumonks.org>>
>
> >    http://laforge.gnumonks.org/
> >    ============================================================
> ================
> >    "Privacy in residential applications is a desirable marketing option."
> >                                                        (ETSI EN 300
>
> >    175-7 <tel:300%20175-7> Ch. A6)
> >
>
> --
> - 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
>
>


-- 
Best Regards,
Sandi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180716/cec5bd6b/attachment.htm>

From nhofmeyr at sysmocom.de  Mon Jul 16 17:39:47 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 16 Jul 2018 19:39:47 +0200
Subject: BSC LCLS tests
Message-ID: <20180716173947.GC10047@my.box>

Hi Philipp,

I notice that 5 of the LCLS tests in ttcn3_bsc_tests fail saying
"unexpected number of MGW-MDCX transactions"

pass->FAIL BSC_Tests_LCLS.TC_lcls_gcr_bway_connect
pass->FAIL BSC_Tests_LCLS.TC_lcls_gcr_bway_connect_hr
pass->FAIL BSC_Tests_LCLS.TC_lcls_gcr_bway_codec_mismatch
...
pass->FAIL BSC_Tests_LCLS.TC_lcls_connect_break
pass->FAIL BSC_Tests_LCLS.TC_lcls_connect_clear

It appears that your osmo-ttcn3-hacks change
"BSC_Tests: count MGCP operations in as_media"
lacks the proper MGCP operation counts for the LCLS tests?

(The tests have been broken for four days)
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/test_results_analyzer/

Could you fix that plz?
Thanks!

~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/20180716/ae8160ec/attachment.bin>

From pmaier at sysmocom.de  Tue Jul 17 07:16:07 2018
From: pmaier at sysmocom.de (Philipp Maier)
Date: Tue, 17 Jul 2018 09:16:07 +0200
Subject: BSC LCLS tests
In-Reply-To: <20180716173947.GC10047@my.box>
References: <20180716173947.GC10047@my.box>
Message-ID: <13dd91ac-f2e9-6fd0-e85b-d546c5496be5@sysmocom.de>

Hello Neels,

> I notice that 5 of the LCLS tests in ttcn3_bsc_tests fail saying
> "unexpected number of MGW-MDCX transactions"

I noticed that, a fix is currently in review. I will add you as 
reviewer, than it may go faster.

See also:
https://osmocom.org/issues/3292

best regards,
Philipp

-- 
Philipp Maier <pmaier 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 ruben.undheim at gmail.com  Wed Jul 18 15:11:45 2018
From: ruben.undheim at gmail.com (Ruben Undheim)
Date: Wed, 18 Jul 2018 17:11:45 +0200
Subject: 4G / LTE and osmocom
Message-ID: <CA+ChNyVTK1rBLPk4cqmR3fD-3Z-4S8F1qceMLK-p6+Tiua2T_A@mail.gmail.com>

Hi,

The OpenBSC tools have turned into an impressive collection of tools.
It is great to see this huge effort being done successfully! I was
searching around on the osmocom site for information about LTE.
Either, I am very bad at searching, or there is not so much
information about that subject. I was wondering about the plans for
LTE, if there are any such plans?

I am writing this taking into account that in the country where I
live, the major telecom providers plan to shut down the 3G
infrastructure already next year, leaving only 2G and 4G running. In
some years, they also want to shut down 2G (which I have heard has
already been done some places across the Atlantic)

I found a few other projects related to LTE:  nextepc [1] and srsLTE
[2]. I see that nextepc has been mentioned in a thread related to
OsmoDevCon 2018, but I cannot see so much more information. Is the
plan maybe some time to incorporate srsLTE and nextepc into osmocom
infrastructure? Is there currently any cooperation? Or will there be
some new and fresh LTE code in osmocom?

Mainly, I was just wondering whether you can shed some light on /
discuss this subject.


Thank you very much.

Best regards
Ruben Undheim


[1] https://github.com/acetcom/nextepc / http://nextepc.org/
[2] nhttps://github.com/srsLTE/srsLTE.git


From nhofmeyr at sysmocom.de  Wed Jul 18 21:43:16 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 18 Jul 2018 23:43:16 +0200
Subject: pySim pytlv dependency
Message-ID: <20180718214316.GA4222@my.box>

Hi Philipp,

just now I'm trying to use pySim to read a SIM card, but I notice:
  ImportError: No module named pytlv.TLV

I can find no pytlv in the debian packaging; and I notice this dependency was
added only recently. When going back to
859e0fd1ce08699930064c12fb9f7908ef972b50 I can use pySim fine without that.

a) I think the readme should hint at dependencies that pySim requires, which
should include pytlv and where to find it.

b) In python, it is easy to import pytlv only in case it is actually used,
which would simplify dependencies for users that don't need to "get file/record
length from FCP (USIM)" -- would that make sense?

What are your thoughts?

~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/20180718/5a1929e1/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Jul 18 22:00:03 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 19 Jul 2018 00:00:03 +0200
Subject: 4G / LTE and osmocom
In-Reply-To: <CA+ChNyVTK1rBLPk4cqmR3fD-3Z-4S8F1qceMLK-p6+Tiua2T_A@mail.gmail.com>
References: <CA+ChNyVTK1rBLPk4cqmR3fD-3Z-4S8F1qceMLK-p6+Tiua2T_A@mail.gmail.com>
Message-ID: <20180718220003.GB3377@my.box>

On Wed, Jul 18, 2018 at 05:11:45PM +0200, Ruben Undheim wrote:
> I found a few other projects related to LTE:  nextepc [1] and srsLTE
> [2]. I see that nextepc has been mentioned in a thread related to
> OsmoDevCon 2018, but I cannot see so much more information.

If I remember correctly, Harald has already had an actual LTE cell running
using nextepc with Osmocom, but I'll rather not mention any details since my
memory of that factoid is rather dim.

So far the focus at Osmocom is mostly on 2G, but as soon as funding and/or
development show up, LTE is definitely something that Osmocom at large would be
interested in; we expect interest in LTE+2G pairing to increase continuously.

Unfortunately that's all I can say with certainty, so far been dug deep into 2G
and 3G, only. Maybe others can add to this?

~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/20180719/6c094a80/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Jul 18 22:56:48 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 19 Jul 2018 00:56:48 +0200
Subject: posting changes to existing patches (re large osmo-bsc patch)
Message-ID: <20180718225648.GA7361@my.box>

TLDR: Tried to find another way of managing changes to a large patch on gerrit
by submitting a merge-commit, but turns out not so useful. Just sharing findings.


When I fix and change the current large osmo-bsc refactoring patch, on the one
hand I'd like to squash new changes into it to commit the correct result right
away. On the other hand, I want to keep the new changes in separate reviewable
bits, so that reviewers don't need to read the entire patch again, and so that
the new changes can be reviewed one by one, separately.

So far my strategy was to add a new patch set for each small change. Now I
thought it might make sense to have a non-fast-forward merge combining commits
and review that. I tried it in the sandbox repos.

Turns out that gerrit will have one patch for the merge-commit including the
smaller commits, showing all combined changes. However, there will also be
separate patches in the list for each single part of that merged commit. So
there will be a series of small commits onto current master that need to be
reviewed and merged one-by-one. And in the end that is followed by one
basically useless merge-commit; meaning, if we got as far as accepting the
smaller parts of that merge, we don't need to also merge that empty
merge-commit, master already has gotten the smaller bits as separate commits.

So the conclusion is that indeed pushing new small patch-sets onto the same
large commit makes the most sense, and where changes stand on their own,
separate follow-up patches make sense.

~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/20180719/6172d894/attachment.bin>

From pmaier at sysmocom.de  Thu Jul 19 10:06:39 2018
From: pmaier at sysmocom.de (Philipp Maier)
Date: Thu, 19 Jul 2018 12:06:39 +0200
Subject: pySim pytlv dependency
In-Reply-To: <20180718214316.GA4222@my.box>
References: <20180718214316.GA4222@my.box>
Message-ID: <4df96b78-c4ce-478d-68ff-a59f9d362d7f@sysmocom.de>

Hello Neels,

> just now I'm trying to use pySim to read a SIM card, but I notice:
>    ImportError: No module named pytlv.TLV
> 
> I can find no pytlv in the debian packaging; and I notice this dependency was
> added only recently. When going back to
> 859e0fd1ce08699930064c12fb9f7908ef972b50 I can use pySim fine without that.

Yes, there is no debian package. Those packages have to be installed 
using python-pip.

> a) I think the readme should hint at dependencies that pySim requires, which
> should include pytlv and where to find it.

I have added pyscard and pytlv notes to the readme but I am not sure if 
this is really all.
https://gerrit.osmocom.org/#/c/pysim/+/10046/

> b) In python, it is easy to import pytlv only in case it is actually used,
> which would simplify dependencies for users that don't need to "get file/record
> length from FCP (USIM)" -- would that make sense?

I have tried it out, syomoUSIM-SJS1 currently does not have to look at 
card responses.

I have no experience with optional imports, you mean we should do it 
like this?
https://gerrit.osmocom.org/#/c/pysim/+/10048/

best regards,
Philipp

-- 
Philipp Maier <pmaier 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 gnumonks.org  Thu Jul 19 15:10:45 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 19 Jul 2018 17:10:45 +0200
Subject: pySim pytlv dependency
In-Reply-To: <4df96b78-c4ce-478d-68ff-a59f9d362d7f@sysmocom.de>
References: <20180718214316.GA4222@my.box>
 <4df96b78-c4ce-478d-68ff-a59f9d362d7f@sysmocom.de>
Message-ID: <20180719151045.GB3252@nataraja>

Hi Philipp and Neels,

On Thu, Jul 19, 2018 at 12:06:39PM +0200, Philipp Maier wrote:

> Yes, there is no debian package. Those packages have to be installed using
> python-pip.

I really don't think it is a good idea to depend on modules that are not
part of major distributions, not even debian with its tens of thousands of
packages.

So if we can somehow avoid it without reinventing the wheel (maybe there's
an alternative python module that is shipped?), I would try to avoid it.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           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  Sun Jul 22 23:26:51 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 23 Jul 2018 01:26:51 +0200
Subject: merges to osmo-bsc master
Message-ID: <20180722232651.GA4602@my.box>

Hey guys,

I'm a bit disappointed that I see more merges to osmo-bsc master that tweak
MGCP and codec preferences, moving things around files and so on. Please please
do not merge this kind of stuff now, I really cannot use any of that while I'm
turning insane to finally get the osmo-bsc refactoring out of the door.  It's
really mean to load merge conflicts on top of that.

If fixes really need quick merging, please do everything in your might to AVOID
moving functions around and changing file names. That's ... yeah, you get the
picture.

What is also more than welcome is to work on the branch tip of
neels/inter_bsc_ho and apply cosmetic moves to that. Just please not between
current master and the refactoring.

(And to test that branch would also be welcome, if time permits.)

Another alternative is to *talk* to me.

Many thanks.

~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/20180723/82a582b9/attachment.bin>

From nhofmeyr at sysmocom.de  Mon Jul 23 00:18:32 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 23 Jul 2018 02:18:32 +0200
Subject: merges to osmo-bsc master
In-Reply-To: <20180722232651.GA4602@my.box>
References: <20180722232651.GA4602@my.box>
Message-ID: <20180723001832.GB4602@my.box>

Turns out not so easy to resolve the match_codec_pref() changes with my own.
I had various constifying tweaks and had also moved it to another location.

This illustrates how I feel about it: I'm treading a bicycle against strong
headwinds, trying to pull a horse trailer over a hill, then, along comes a
friend on a trike and puts a stick through my front wheel :P

I'll get over it, but no more sticks please if possible.

~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/20180723/05c6c0d9/attachment.bin>

From laforge at gnumonks.org  Tue Jul 24 04:44:09 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 24 Jul 2018 06:44:09 +0200
Subject: gnumonks.org + people.osmocom.org downtime today
Message-ID: <20180724044409.GN3453@nataraja>

Hi!

I will be doing extensive hardware maintenance + upgrades today in a
data center, which means that gnumonks.org and some other related
systems will be offline for some amount of time today, particularly
during the morning and early afternoon (MESZ time zone).

The only Osmocom system/service affected is people.osmocom.org.

It's just likely that you will receive notifications about e-mail delays
to my personal e-mail address, but those will be automatically
re-transmitted after the systems are back online.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           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  Tue Jul 24 17:10:08 2018
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Wed, 25 Jul 2018 00:10:08 +0700
Subject: The magic behaviour of 'logging level all LEVEL'
Message-ID: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>

Hi all,

A discussion was started during the review of
https://gerrit.osmocom.org/10116/.
The main idea of this change is to fix the behaviour of 'logging level all
LEVEL',
but I think it was also mixed with some additional feature, which I would
like
to discuss here, publicly.

First of all, the change introduces a new special logging level 'unset',
which allows one to reset a given category (i.e. unset its custom value):

  !! Initial logging configuration:
  logging level all error
  logging level mncc debug
  logging level pag notice
  logging level meas debug

  !! Resetting DMNCC:
  # logging level mncc unset

  !! So, now DMNCC has no custom log level, it will use
  !! the default level (in this example it is 'error'):
  logging level all error
  logging level pag notice
  logging level meas debug

This feature looks fine and extremely useful for me.

But (among fixing) this change additionally changes the behaviour
of a command for setting the default logging category (i.e. 'logging
level all LEVEL'):

  !! Initial logging configuration:
  logging level all error
  logging level mncc debug
  logging level pag notice
  logging level meas debug

  !! Changing the default logging level:
  # logging level all debug

  !! Ahhh, I've lost my custom levels :(
  logging level all debug

  !! What I expected to get:
  logging level all debug
  logging level mncc debug
  logging level pag notice
  logging level meas debug

So, together with changing the default logging category,
this command now would also reset all custom settings...

I am not sure this is exactly what one need/expect, so
I would like to share the following ideas:

  1) The category 'all' looks/sounds confusing when it's used
     in such cases like this:

       # logging level all debug

     because one can interpret it like:

       "set all categories to debug".

     despite actually (according to the implementation) this
     is related to the default logging policy.

     Maybe, we should rename it to 'default'?

     So, 'logging level all LEVEL' would *set all categories*
     to a given logging LEVEL, while 'logging level default LEVEL'
     would only affect the default logging level...

  2) Introducing the new command:

       # logging level unset LEVEL

     which is intended to assign a given LEVEL to all categories,
     which have no custom logging level (i.e. have 'unset'), would
     make the idea of having default logging policy meaningless.

     Setting logging level(s) for all possible categories (using this
     command), looks like writing iptables rules for all possible
     and impossible cases instead of using the DEFAULT policy...

  3) The introduced behaviour of resetting all categories to 'unset'
     could be implemented in a separate function, and can be
     represented by a separate command:

       # logging level unset-all

     The name of this command clearly defines the expected behaviour.
     Moreover, it doesn't affect the default logging level, which can be
     still changed by a separate command.

As we (me and Pau) have different opinions, or we simply don't
understand each other, let's make this discussion public, and
let's see what others think about this...

With best regards,
Vadim Yanitskiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/ed2cbac8/attachment.htm>

From xload.es at gmail.com  Wed Jul 25 07:36:14 2018
From: xload.es at gmail.com (Ernesto Sanchez)
Date: Wed, 25 Jul 2018 09:36:14 +0200
Subject: Reflashing ip.access nano3G
Message-ID: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>

Hello,

I bougth one ip.access nano3G in ebay, it seem to have a custom firmware
for an operator that does not work in my country I want to know how to
reflash it with the correct firmware to run openbsc. Can anybody help me?

Best regards and a lot of thanks in advance.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/f2b88986/attachment.htm>

From mykola at razormaker.com  Wed Jul 25 07:41:28 2018
From: mykola at razormaker.com (Mykola Shchetinin)
Date: Wed, 25 Jul 2018 10:41:28 +0300
Subject: Reflashing ip.access nano3G
In-Reply-To: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
References: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
Message-ID: <CANm+Ygn8iWmJAwCrjMDDeP-jcahv=4FnNc4KLQVxU23vOVnUPg@mail.gmail.com>

Good day, Ernesto

>  it seem to have a custom firmware for an operator that does not work in
my country

How have you found that out? What actions have you taken? Have you
performed a factory reset?

If you expand on the description of your problem, then it will be much
easier for someone here to help you.

With best wishes, Mykola
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/221113d4/attachment.htm>

From xload.es at gmail.com  Wed Jul 25 08:34:37 2018
From: xload.es at gmail.com (Ernesto Sanchez)
Date: Wed, 25 Jul 2018 10:34:37 +0200
Subject: Reflashing ip.access nano3G
In-Reply-To: <CANm+Ygn8iWmJAwCrjMDDeP-jcahv=4FnNc4KLQVxU23vOVnUPg@mail.gmail.com>
References: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
 <CANm+Ygn8iWmJAwCrjMDDeP-jcahv=4FnNc4KLQVxU23vOVnUPg@mail.gmail.com>
Message-ID: <CAEDoHijuV3Sg0MfV31QS=N2Aw1UuhckpJeeU=kHRMs9-EGjU6w@mail.gmail.com>

A lot of thanks Mykola, I tried to:
- Find the nano3G ip address, I found it and create a rule in my dhcp
server to assign a fixed ip address.
- Ping the nano3G: 0% packet loss.
- Scan all TCP ports with nmap: there is no open port
- Capture all network traffic from nano3Gwith tcpdump: it connect to a
T-mobile to perform a isakmp handshake without any result, also get the
date and time from some ntp servers.
- Perform a factory reset but I think that this action just restore the
custom operator firmware, at this step the nano3g also connect to ip.access
servers and download some crl certificates, then also try the isakmp
handshake with T-mobile server.

Best regards

2018-07-25 9:41 GMT+02:00 Mykola Shchetinin <mykola at razormaker.com>:

> Good day, Ernesto
>
> >  it seem to have a custom firmware for an operator that does not work in
> my country
>
> How have you found that out? What actions have you taken? Have you
> performed a factory reset?
>
> If you expand on the description of your problem, then it will be much
> easier for someone here to help you.
>
> With best wishes, Mykola
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/99dc5eae/attachment.htm>

From pespin at sysmocom.de  Wed Jul 25 09:16:46 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Wed, 25 Jul 2018 11:16:46 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
Message-ID: <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>

Hi Vadim,

Find my answers in place with your lines.

On 24/07/18 19:10, Vadim Yanitskiy wrote:
> Hi all,
> 
> A discussion was started during the review of 
> https://gerrit.osmocom.org/10116/.
> The main idea of this change is to fix the behaviour of 'logging level 
> all LEVEL',
> but I think it was also mixed with some additional feature, which I 
> would like
> to discuss here, publicly.
> 
> First of all, the change introduces a new special logging level 'unset',
> which allows one to reset a given category (i.e. unset its custom value):
> 
>  ? !! Initial logging configuration:
>  ? logging level all error
>  ? logging level mncc debug
>  ? logging level pag notice
>  ? logging level meas debug
> 
>  ? !! Resetting DMNCC:
>  ? # logging level mncc unset
> 
>  ? !! So, now DMNCC has no custom log level, it will use
>  ? !! the default level (in this example it is 'error'):
>  ? logging level all error
>  ? logging level pag notice
>  ? logging level meas debug
> 
> This feature looks fine and extremely useful for me.
> 

Everything's correct up to here, and I agree.

> But?(among fixing) this change additionally changes the behaviour
> of a command for setting the default logging category (i.e. 'logging
> level all LEVEL'):
> 
>  ? !! Initial logging configuration:
>  ? logging level all error
>  ? logging level mncc debug
>  ? logging level pag notice
>  ? logging level meas debug
> 
>  ? !! Changing the default logging level:
>  ? # logging level all debug

As per current code with the mentioned patchset, you should use here 
"logging level unset debug" to accomplish what you want in this example. 
Then you get you expected behavior.

> 
>  ? !! Ahhh, I've lost my custom levels :(
>  ? logging level all debug
> 
>  ? !! What I expected to get:
>  ? logging level all debug
>  ? logging level mncc debug
>  ? logging level pag notice
>  ? logging level meas debug
> 
> So, together with changing the default logging category,
> this command now would also reset all custom settings...
> 
> I am not sure this is exactly what one need/expect, so
> I would like to share the following ideas:
> 
>  ? 1) The category 'all' looks/sounds confusing when it's used
>  ???? in such cases like this:
> 
>  ?????? # logging level all debug
> 
>  ???? because one can interpret it like:
> 
>  ?????? "set all categories to debug".
> 
>  ???? despite actually (according to the implementation) this
>  ???? is related to the default logging policy.
> 
>  ???? Maybe, we should rename it to 'default'?
> 
>  ???? So, 'logging level all LEVEL' would *set all categories*
>  ???? to a given logging LEVEL, while 'logging level default LEVEL'
>  ???? would only affect the default logging level...
> 

Ok so afaiu what you say is that current "unset" becomes "default". Then 
in "all" we loop over categories and set each with loglevel.

>  ? 2) Introducing the new command:
> 
>  ?????? # logging level unset LEVEL
> 
>  ???? which is intended to assign a given LEVEL to all categories,
>  ???? which have no custom logging level (i.e. have 'unset'), would
>  ???? make the idea of having default logging policy meaningless.

Currently (with patchset), "unset" actually sets the target loglevel, 
aka the default, so it doesn't make default meaningless because it uses 
it. The difference with current "all" is that it doesn't reset the 
categories to unset.

> 
>  ???? Setting logging level(s) for all possible categories (using this
>  ???? command), looks like writing iptables rules for all possible
>  ???? and impossible cases instead of using the DEFAULT policy...

I don't get your point here. You can do both.

> 
>  ? 3) The introduced behaviour of resetting all categories to 'unset'
>  ???? could be implemented in a separate function, and can be
>  ???? represented by a separate command:
> 
>  ?????? # logging level unset-all
> 
>  ???? The name of this command clearly defines the expected behaviour.
>  ???? Moreover, it doesn't affect the default logging level, which can be
>  ???? still changed by a separate command.
> 
> As we (me and Pau) have different opinions, or we simply don't
> understand each other, let's make this discussion public, and
> let's see what others think about this...
> 
> With best regards,
> Vadim Yanitskiy.

So, after your comments and thinking about it, here's my proposal:
1- Take my current patchset
2- Modification: "logging level all <loglevel>" sets the loglevel 
foreach category, not the target loglevel (aka the default loglevel).
3- Modification: "logging level unset <loglevel>" is renamed to "logging 
level default <loglevel>"
4- Addition: New VTY cmd "logging level unset-all" is introduced, which 
sets all categories to UNSET (basically re-use the current loop we have 
in current patchset handling the "all").

For num.4, we could actually use "logging level all unset", which makes 
perfectly sense and matches with expectations.

Agree?

-- 
- 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


From mykola at razormaker.com  Wed Jul 25 09:17:30 2018
From: mykola at razormaker.com (Mykola Shchetinin)
Date: Wed, 25 Jul 2018 12:17:30 +0300
Subject: Reflashing ip.access nano3G
In-Reply-To: <CAEDoHijuV3Sg0MfV31QS=N2Aw1UuhckpJeeU=kHRMs9-EGjU6w@mail.gmail.com>
References: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
 <CANm+Ygn8iWmJAwCrjMDDeP-jcahv=4FnNc4KLQVxU23vOVnUPg@mail.gmail.com>
 <CAEDoHijuV3Sg0MfV31QS=N2Aw1UuhckpJeeU=kHRMs9-EGjU6w@mail.gmail.com>
Message-ID: <CANm+YgnKP+wAdwm9qqSupw+dFfjV2oBz0hkcskKmgkjWdhYkpQ@mail.gmail.com>

Have you tried connecting to the commissioning web page of the FAP right
after performing the factory reset? (You need to connect to it directly via
Ethernet)

It is somewhat described in the section 5 of this document:
https://fccid.io/QGGIPA237C/User-Manual/User-manual-1470788

I use this process when configuring the FAP. (After that it pulls the
configuration from my ACS server)

If that doesn?t work, then I hope somebody other will help you :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/54719f3c/attachment.htm>

From choukoumoun at gmail.com  Wed Jul 25 09:24:37 2018
From: choukoumoun at gmail.com (Choukou Moun)
Date: Wed, 25 Jul 2018 11:24:37 +0200
Subject: Reflashing ip.access nano3G
In-Reply-To: <CANm+YgnKP+wAdwm9qqSupw+dFfjV2oBz0hkcskKmgkjWdhYkpQ@mail.gmail.com>
References: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
 <CANm+Ygn8iWmJAwCrjMDDeP-jcahv=4FnNc4KLQVxU23vOVnUPg@mail.gmail.com>
 <CAEDoHijuV3Sg0MfV31QS=N2Aw1UuhckpJeeU=kHRMs9-EGjU6w@mail.gmail.com>
 <CANm+YgnKP+wAdwm9qqSupw+dFfjV2oBz0hkcskKmgkjWdhYkpQ@mail.gmail.com>
Message-ID: <CA+StwqnmdzVZPuZEE_3G21Z0asWVJ3xAUv0Bc3jMMwfVdB0n8A@mail.gmail.com>

Hello.

I have the same problem.

For me I don't have the webadmin password. I think we won't the nanobts
proprietary software for reset it.

Thanks.

Le mer. 25 juil. 2018 ? 11:17, Mykola Shchetinin <mykola at razormaker.com> a
?crit :

> Have you tried connecting to the commissioning web page of the FAP right
> after performing the factory reset? (You need to connect to it directly via
> Ethernet)
>
> It is somewhat described in the section 5 of this document:
> https://fccid.io/QGGIPA237C/User-Manual/User-manual-1470788
>
> I use this process when configuring the FAP. (After that it pulls the
> configuration from my ACS server)
>
> If that doesn?t work, then I hope somebody other will help you :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/6e435df8/attachment.htm>

From nhofmeyr at sysmocom.de  Wed Jul 25 14:22:09 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 25 Jul 2018 16:22:09 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
Message-ID: <20180725142209.GB22664@my.box>

Hi all,

for logging changes, I would welcome a comprehensive approach and maybe add an
all new set of logging commands, to not confuse with the current logging
behavior; keep and deprecate the old ones for users that were fine with those.
(I was the one responsible for the death of 'logging level all everything', and
I've stumped at least one user who now keeps patching it back in manually;
let's not repeat that.)

Maybe we can come up with more meaningful wording that more accurately indicate
what is happening? But if the current command set suffices without confusion,
we can also keep that, and maybe resurrect the 'logging level all everything'??

Here are the handles / use cases that come up -- I've embedded implementation
choices and command names in this proposal, but it's intended as a blueprint to
incorporate everyone else's bikesheds:

 A) The hardcoded logging landscape on program startup without config.
    (Maybe this isn't all that important, including it nevertheless.)
   1) a command to reset all to hardcoded defaults?

 B) A "normal" logging behavior configured by the user. We need:
   1) a command to set all categories at once
   2) a command to tweak individual categories

 C) Temporarily reducing the logging on all categories: silence the log.
    Even though a category is "normally" set to INFO, after this command it can
    be forced down to only log e.g. NOTICE. But if a category is already on
    ERROR, leave it down there and do not lift it up to NOTICE.
   1) a command to temporarily reduce all categories.
   2) a command to temporarily reduce individual categories.

 D) Temporarily increasing the logging on all categories: show everything.
    Even though a category is "normally" set to ERROR, after this command it
    can be forced up to e.g. INFO. But if a category is already up at DEBUG,
    don't reduce it to NOTICE.
   1) a command to temporarily increase all categories.
   2) a command to temporarily increase individual categories.
   3) we need to decide whether temporarily increasing is stronger/weaker than
      temporarily reducing. Depending on the implementation, it could also be
      "last one wins" (which IMHO would be best).

 T) Maybe we also want to unconditionally set temporary levels, whether they
    increase or reduce.

 E) Remove temporary logging to go back to the "normal" logging landscape.
   1) a command to put everything back to "normal",
   2) a command to put individual categories back to "normal",
   3) a separate command to only remove temporary reduction, i.e lift the
      temporary changes only if they cause less logging than normal,
   4) a separate command to only remove temporary verbosity, i.e. only lift the
      temporary changes if they cause more logging than normal.

 F) Set a specific log context, and silence all messages (regardless of their
    logging category setting) unless they match the context filter:
        logging filter imsi 123456789123456
    Though this feature has probably never been properly implemented through
    all code paths, it is potentially very powerful for live debugging.
    Especially with the new FSMs around everywhere, there is a good chance that
    we can fairly easily improve on the current 'logging filter foo'
    experience. During congress, I really yearned for this to work well.
   0) In the current implementation, on each individual log message, this
      decides whether the context matches, and if not, the message is
      discarded.
   1) Instead of discarding, we may want a level to reduce to.
   2) Or maybe we want to leave the logging landscape unchanged, but lift the
      level for all logs that match the set context?
   3) disable individual filters
   4) disable all filters. This is currently 'logging filter all 1' but that is
      confusing, we could use a meaningful synonym, and separate from filters.

 G) toggle all logging in the telnet vty
   1) silence logging (currently 'logging filter all 0', confusing)
   2) continue logging (currently 'logging filter all 1', confusing)


A bit of a meaningless image of different logging layers:

                           level
                             ^
        Hardcoded defaults.. | ... - ======    =....
  Normal logging landscape== | == .==  ... ==...  --
          Temporary levels-- | -- =....   ...== -  =
                             |   =  --   ----  -===
                             |________________________> categories

  	Same image with actual current logging overlayed:

                           level
                             ^
                             | ... # =###==    =....
                             | == .==  ... ==...  ##
         Resulting levels ## | ## #....   ...## #  =
                             |   #  ##   ####  #=#=
                             |________________________> categories

  - the hardcoded defaults are immutable.
  - the normal landscape can be freely chosen.
  - Some categories may have temporary tweaks. Where there are temporary
    tweaks, they take precedence as-is. The vty command ("make stronger" or
    "make weaker") decided whether to put a temporary level in place or not.


Can you guys explain the current patch proposals in terms of above features?
(like, use the capital letters A-G for reference)

Feel free to change this vty transcript proposal i've tossed up as I went:

! A.1) hardcoded defaults
  logging hard-reset rsl,chan,msc
  logging hard-reset

! B) set normal categories
! B.1) all
  logging set notice all
! B.2) individual
  logging set notice rsl,chan,msc

! C) Temporarily reducing
! C.1) all
  logging reduce notice all
! C.2) individual
  logging reduce error l1p,nm,cc

! D) Temporarily increasing
! D.1) all
  logging increase info all
! D.2) individual
  logging increase debug mm,rr

! D.3) last one wins
  logging reduce error l1p,mm,rr
  logging increase debug mm,rr
  logging reduce notice rr
! result: l1p=error mm=debug rr=notice

! T) set temporary level unconditionally
  logging set-temp error all
  logging set-temp error mm,rr
  ! logging (recrease|induce) ;)

! E.3) remove temporary verbosity
  no logging reduce nm,cc
  no logging reduce all
! E.4) remove temporary silencing
  no logging increase nm,cc
  no logging increase all
! E.2) snap back to normal levels
  logging reset rsl,nm,rr
! E.1) ...for all categories
  logging reset all

! F.0) context filter
  logging filter imsi 123456789123456
! F.1) choose context filter behavior
  logging filter-reduce error
  logging filter-discard
! F.2)
  logging filter-increase debug
! F.3) disable filter
  no logging filter imsi
! F.4)
  no logging filter

! G.1)
  logging [on]
  logging 1
! G.2)
  no logging
  logging 0

Using a .TEXT argument, we could easily allow a space separator for category
lists, as in "l1p mm cc". (nice would be to invent a VTY argument type that
allows any number of the same kind, so far we have weird constructs like seen
in bsc_vty.c, cfg_bts_codec0_cmd thru cfg_bts_codec4_cmd each with a different
nr of same argument)

A test program should define logging categories and a context filter, issue
each of above commands and then log once all across each level and category to
see what logging we still see.

As a final step, we should figure out how the current logging commands match
these features, and make them still do the things they always did as best as
makes sense.

What do you guys think?

About bikesheds: if we can't agree, we could put out a patch contest, where
everyone that cares implements a proposal, and we vote in the end. I hope we
don't waste time by deadlocking in the end ;)

~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/20180725/5081dbc4/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Jul 25 14:33:22 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 25 Jul 2018 16:33:22 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
Message-ID: <20180725143322.GC22664@my.box>

On Wed, Jul 25, 2018 at 11:16:46AM +0200, Pau Espin Pedrol wrote:
> 2- Modification: "logging level all <loglevel>" sets the loglevel foreach
> category, not the target loglevel (aka the default loglevel).
> 3- Modification: "logging level unset <loglevel>" is renamed to "logging
> level default <loglevel>"

I find both 'logging level unset <level>' and 'logging level default <level>'
confusing. Did you mean to say '<category>'?

> For num.4, we could actually use "logging level all unset", which makes
> perfectly sense and matches with expectations.

IMHO "level unset" doesn't spark a meaningful image. Sounds like "allow any
level", or next best meaning is "back to hardcoded defaults".

~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/20180725/6979149a/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Jul 25 14:47:32 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 25 Jul 2018 16:47:32 +0200
Subject: Reflashing ip.access nano3G
In-Reply-To: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
References: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
Message-ID: <20180725144732.GE22664@my.box>

Hi all,

the nano3G come with various firmwares, and it is not trivial to get them to
act as hNodeB ready to connect to osmo-hnbgw. It is highly unlikely that you
will find on the market a nano3G that is usable for osmocom as-is.

Sysmocom has nano3G on offer that are ready to connect to osmo-hnbgw, but we
obviously cannot legally distribute the firmware. So this has to end in: sorry
folks, you will likely not have any fun with your nano3G :(

~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/20180725/28bbdcd8/attachment.bin>

From xload.es at gmail.com  Wed Jul 25 15:08:35 2018
From: xload.es at gmail.com (Ernesto Sanchez)
Date: Wed, 25 Jul 2018 17:08:35 +0200
Subject: Reflashing ip.access nano3G
In-Reply-To: <20180725144732.GE22664@my.box>
References: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
 <20180725144732.GE22664@my.box>
Message-ID: <CAEDoHiiqiAEkZOUAjS77-B6TRmKyOro5qVXeb8-VUmHj_pX4MQ@mail.gmail.com>

Hi Neels, a lot of thanks, I think that is not a good idea work in an open
proyect with proprietary hardware, and proprietary firmware... The result
is: I don't own my hardware, I paid for hardware that I can not use, I can
understand pay a fee for the "new" license but no more than this.

BTW: how much cost the nano3G that sysmocom offers? You can write me if you
can not the the price in public.

We are still working :)

2018-07-25 16:47 GMT+02:00 Neels Hofmeyr <nhofmeyr at sysmocom.de>:

> Hi all,
>
> the nano3G come with various firmwares, and it is not trivial to get them
> to
> act as hNodeB ready to connect to osmo-hnbgw. It is highly unlikely that
> you
> will find on the market a nano3G that is usable for osmocom as-is.
>
> Sysmocom has nano3G on offer that are ready to connect to osmo-hnbgw, but
> we
> obviously cannot legally distribute the firmware. So this has to end in:
> sorry
> folks, you will likely not have any fun with your nano3G :(
>
> ~N
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/ea7f9b85/attachment.htm>

From pespin at sysmocom.de  Wed Jul 25 15:08:45 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Wed, 25 Jul 2018 17:08:45 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <20180725143322.GC22664@my.box>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725143322.GC22664@my.box>
Message-ID: <210e9b06-783b-1345-cb36-d9e6f4fefd90@sysmocom.de>



On 25/07/18 16:33, Neels Hofmeyr wrote:
> On Wed, Jul 25, 2018 at 11:16:46AM +0200, Pau Espin Pedrol wrote:
>> 2- Modification: "logging level all <loglevel>" sets the loglevel foreach
>> category, not the target loglevel (aka the default loglevel).
>> 3- Modification: "logging level unset <loglevel>" is renamed to "logging
>> level default <loglevel>"
> 
> I find both 'logging level unset <level>' and 'logging level default <level>'
> confusing. Did you mean to say '<category>'?

No, I meant what I wrote.

So after my proposal (from my last email):

* "logging level default <level>": Sets default log level (the loglevel 
for unset categories, aka the logtarget loglevel) to <level>.

* "logging level all <level>": Sets each (all) category to use log level 
<level>, without modifying the default log level (aka logtarget loglevel).

* "logging level (all|<category>) unset": Unsets given category log 
level, and as a result log messages for that category are handled by 
default log level (aka logtarget loglevel).

* "logging level (all|<category>) <level>": Sets given category to given 
log level. As a result, messages for that category are handled by this 
log level and not the default log level.


Regarding your last comment: unsetting doesn't mean going to initially 
per-category set defaults during startup of the application. It means to 
fallback to default log level (aka logtarget loglevel). Initial 
hardcoded values set per-category are basically the same as if you went 
through the VTY setting "log level <category> <level>" before parsing 
the cfg file.



-- 
- 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


From pespin at sysmocom.de  Wed Jul 25 15:31:59 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Wed, 25 Jul 2018 17:31:59 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <20180725142209.GB22664@my.box>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725142209.GB22664@my.box>
Message-ID: <341eacf7-a154-0031-1b00-6555e703dc55@sysmocom.de>

Hi Neels,

The aim here was to fix and have a useful set of commands as close as 
possible to the previously existing set of commands. So my aim here is 
not to re-implement the whole logging system, deprecate entire command 
sets or add a big bunch of new ones. I want it to be as compatible as 
possible with older ones.

With the current patchset + few extra ideas exposed in last emails from me:

A) It's already there as it is now, no need to change. When you start a 
program, code harcoded categories are set with a given loglevel.

B)
1) logging level all <loglevel>
2) logging level <category> <loglevel>

C) D) T) E)
I fins all this "temporary" stuff something really not there in current 
code, too complex and not really required. You can do whatever config 
setup you want with following command:
logging level (all|default|<category>) (unset|<loglevel>)

F) Not sure what's the current state for this, but not directly related 
to the improvements I'm doing (I'm doing nothing filter related)

G) Agree that the naming is confusing, but not directly related to the 
improvements I'm doing (I'm doing nothing filter related)

Current proposed system is basically (and very similar to old system, 
just a bit better sort out imho):

* You have a logtarget loglevel. Each logtarget instance (VTY, stderr, 
gsmtap, etc.) has one. This is also called the "default" log level.
* Each category can be either set with a loglevel or unset.
* If category is set with a loglevel, this loglevel is used to resolve 
printing.
* If category is unset, default log level (logtarget loglevel) is used.
* If you add harcoded per-category values in code, then those are 
applied at startup, which means these categories won't use the default 
loglevel until unset.

-- 
- 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


From nhofmeyr at sysmocom.de  Wed Jul 25 16:12:59 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 25 Jul 2018 18:12:59 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <341eacf7-a154-0031-1b00-6555e703dc55@sysmocom.de>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725142209.GB22664@my.box>
 <341eacf7-a154-0031-1b00-6555e703dc55@sysmocom.de>
Message-ID: <20180725161259.GB25809@my.box>

On Wed, Jul 25, 2018 at 05:31:59PM +0200, Pau Espin Pedrol wrote:
> A) It's already there as it is now, no need to change. When you start a
> program, code harcoded categories are set with a given loglevel.

But currently no way to get back to it, IIUC. Not important anyway.

> C) D) T) E)
> I fins all this "temporary" stuff something really not there in current
> code, too complex and not really required.

We actually supported temporary logging increase, even though I never grokked
how it was supposed to work, hence I broke it by removing the logging level all
everything.

This is an attempt to bring it back in an obvious and finely tunable way. It is
not really complex, is it!?

> Current proposed system is basically (and very similar to old system, just a
> bit better sort out imho):

A problem there is that it is changing the meaning of a logging command that
has been there for a decade. Because I fail to understand why exactly it isn't
doing what I want and why it was implemented this way, and because I accept
that other users might rely on exactly the current behavior to do what they
want, I would prefer keeping it unchanged and to add new command names that
make proper sense to us (to not repeat my past mistake).

> You can do whatever config setup you want with following command:
> logging level (all|default|<category>) (unset|<loglevel>)

no, can't do whatever config setup:

> * You have a logtarget loglevel. Each logtarget instance (VTY, stderr,
> gsmtap, etc.) has one. This is also called the "default" log level.
> * Each category can be either set with a loglevel or unset.

This does not allow for the 'logging level all everything' use case:

- I have setup a detailed logging landscape, i.e. not one default level for all
  categories, but a fine grained selection: some on error, some on notice, some
  on info, ...
- Now for a minute I want to quickly see all debug logging.
  logging increase debug all
- Later I want to go back to the detailed landscape.
  logging reset all

I'd like to provide a way to define a fine grained selection of logging levels
as the default, more than just one level across the board. IIUC that can't be
done with the current 'default' and 'unset'?

Besides it changing an old vty command and it still missing an important use
case, I totally agree that your patch is a usability improvement :)

~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/20180725/e6fdb1a9/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Jul 25 16:17:24 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 25 Jul 2018 18:17:24 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <210e9b06-783b-1345-cb36-d9e6f4fefd90@sysmocom.de>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725143322.GC22664@my.box>
 <210e9b06-783b-1345-cb36-d9e6f4fefd90@sysmocom.de>
Message-ID: <20180725161724.GC25809@my.box>

> No, I meant what I wrote.
> 
> So after my proposal (from my last email):
[...]

Ok, I understand now. So our main difference is that in your patch we have one
single default log level, while I aim to allow separate default log levels for
each category (and on each target).

Let's discuss in the other thread leaf and end this one.

~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/20180725/0a4966cd/attachment.bin>

From pespin at sysmocom.de  Wed Jul 25 16:25:55 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Wed, 25 Jul 2018 18:25:55 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <20180725161724.GC25809@my.box>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725143322.GC22664@my.box>
 <210e9b06-783b-1345-cb36-d9e6f4fefd90@sysmocom.de>
 <20180725161724.GC25809@my.box>
Message-ID: <e3a1501d-4266-3016-1ab3-4dec0278b0ff@sysmocom.de>



On 25/07/18 18:17, Neels Hofmeyr wrote:
>> No, I meant what I wrote.
>>
>> So after my proposal (from my last email):
> [...]
> 
> Ok, I understand now. So our main difference is that in your patch we have one
> single default log level, while I aim to allow separate default log levels for
> each category (and on each target).

Just to make sure: We already have a default differentiate log level on 
each target. Not only 1 for the whole app.
It's true that we don't have one per category.



-- 
- 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


From xload.es at gmail.com  Wed Jul 25 16:37:25 2018
From: xload.es at gmail.com (Ernesto Sanchez)
Date: Wed, 25 Jul 2018 18:37:25 +0200
Subject: Reflashing ip.access nano3G
In-Reply-To: <CANm+YgnKP+wAdwm9qqSupw+dFfjV2oBz0hkcskKmgkjWdhYkpQ@mail.gmail.com>
References: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
 <CANm+Ygn8iWmJAwCrjMDDeP-jcahv=4FnNc4KLQVxU23vOVnUPg@mail.gmail.com>
 <CAEDoHijuV3Sg0MfV31QS=N2Aw1UuhckpJeeU=kHRMs9-EGjU6w@mail.gmail.com>
 <CANm+YgnKP+wAdwm9qqSupw+dFfjV2oBz0hkcskKmgkjWdhYkpQ@mail.gmail.com>
Message-ID: <CAEDoHihJVa3wqZkHFAbo220HvY7AqMr0QV2mW6m9ypnaPY1mEA@mail.gmail.com>

Hello Mykola,

I tried it, It shown a login/password screen:
https://i.imgur.com/G2TgoHS.png unfortunately I don't know it.

Best regards

2018-07-25 11:17 GMT+02:00 Mykola Shchetinin <mykola at razormaker.com>:

> Have you tried connecting to the commissioning web page of the FAP right
> after performing the factory reset? (You need to connect to it directly via
> Ethernet)
>
> It is somewhat described in the section 5 of this document:
> https://fccid.io/QGGIPA237C/User-Manual/User-manual-1470788
>
> I use this process when configuring the FAP. (After that it pulls the
> configuration from my ACS server)
>
> If that doesn?t work, then I hope somebody other will help you :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/ea0a9a06/attachment.htm>

From choukoumoun at gmail.com  Wed Jul 25 16:38:39 2018
From: choukoumoun at gmail.com (Choukou Moun)
Date: Wed, 25 Jul 2018 18:38:39 +0200
Subject: Reflashing ip.access nano3G
In-Reply-To: <CAEDoHihJVa3wqZkHFAbo220HvY7AqMr0QV2mW6m9ypnaPY1mEA@mail.gmail.com>
References: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
 <CANm+Ygn8iWmJAwCrjMDDeP-jcahv=4FnNc4KLQVxU23vOVnUPg@mail.gmail.com>
 <CAEDoHijuV3Sg0MfV31QS=N2Aw1UuhckpJeeU=kHRMs9-EGjU6w@mail.gmail.com>
 <CANm+YgnKP+wAdwm9qqSupw+dFfjV2oBz0hkcskKmgkjWdhYkpQ@mail.gmail.com>
 <CAEDoHihJVa3wqZkHFAbo220HvY7AqMr0QV2mW6m9ypnaPY1mEA@mail.gmail.com>
Message-ID: <CA+StwqmXwRYdGJfhwhYEGebFibnudtOJjuTd+Sc_cNaxysRTBA@mail.gmail.com>

Hello

I think the password this not the same by nanobts. All nanobts have their
password.



Le mer. 25 juil. 2018 ? 18:37, Ernesto Sanchez <xload.es at gmail.com> a
?crit :

> Hello Mykola,
>
> I tried it, It shown a login/password screen:
> https://i.imgur.com/G2TgoHS.png unfortunately I don't know it.
>
> Best regards
>
> 2018-07-25 11:17 GMT+02:00 Mykola Shchetinin <mykola at razormaker.com>:
>
>> Have you tried connecting to the commissioning web page of the FAP right
>> after performing the factory reset? (You need to connect to it directly via
>> Ethernet)
>>
>> It is somewhat described in the section 5 of this document:
>> https://fccid.io/QGGIPA237C/User-Manual/User-manual-1470788
>>
>> I use this process when configuring the FAP. (After that it pulls the
>> configuration from my ACS server)
>>
>> If that doesn?t work, then I hope somebody other will help you :)
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/e863778f/attachment.htm>

From xload.es at gmail.com  Wed Jul 25 16:44:29 2018
From: xload.es at gmail.com (Ernesto Sanchez)
Date: Wed, 25 Jul 2018 18:44:29 +0200
Subject: Reflashing ip.access nano3G
In-Reply-To: <CA+StwqmXwRYdGJfhwhYEGebFibnudtOJjuTd+Sc_cNaxysRTBA@mail.gmail.com>
References: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
 <CANm+Ygn8iWmJAwCrjMDDeP-jcahv=4FnNc4KLQVxU23vOVnUPg@mail.gmail.com>
 <CAEDoHijuV3Sg0MfV31QS=N2Aw1UuhckpJeeU=kHRMs9-EGjU6w@mail.gmail.com>
 <CANm+YgnKP+wAdwm9qqSupw+dFfjV2oBz0hkcskKmgkjWdhYkpQ@mail.gmail.com>
 <CAEDoHihJVa3wqZkHFAbo220HvY7AqMr0QV2mW6m9ypnaPY1mEA@mail.gmail.com>
 <CA+StwqmXwRYdGJfhwhYEGebFibnudtOJjuTd+Sc_cNaxysRTBA@mail.gmail.com>
Message-ID: <CAEDoHiiKTDCqcB=YzNxzcZaxc_Na8bMwZYsgaoq-cchoPKbeWQ@mail.gmail.com>

I don't know if there is a generic login/password or it's a custom pair for
each device.

Best regards.

2018-07-25 18:38 GMT+02:00 Choukou Moun <choukoumoun at gmail.com>:

> Hello
>
> I think the password this not the same by nanobts. All nanobts have their
> password.
>
>
>
> Le mer. 25 juil. 2018 ? 18:37, Ernesto Sanchez <xload.es at gmail.com> a
> ?crit :
>
>> Hello Mykola,
>>
>> I tried it, It shown a login/password screen:
>> https://i.imgur.com/G2TgoHS.png unfortunately I don't know it.
>>
>> Best regards
>>
>> 2018-07-25 11:17 GMT+02:00 Mykola Shchetinin <mykola at razormaker.com>:
>>
>>> Have you tried connecting to the commissioning web page of the FAP right
>>> after performing the factory reset? (You need to connect to it directly via
>>> Ethernet)
>>>
>>> It is somewhat described in the section 5 of this document:
>>> https://fccid.io/QGGIPA237C/User-Manual/User-manual-1470788
>>>
>>> I use this process when configuring the FAP. (After that it pulls the
>>> configuration from my ACS server)
>>>
>>> If that doesn?t work, then I hope somebody other will help you :)
>>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/70e03a89/attachment.htm>

From nhofmeyr at sysmocom.de  Wed Jul 25 16:45:24 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 25 Jul 2018 18:45:24 +0200
Subject: Reflashing ip.access nano3G
In-Reply-To: <CAEDoHiiqiAEkZOUAjS77-B6TRmKyOro5qVXeb8-VUmHj_pX4MQ@mail.gmail.com>
References: <CAEDoHihYir22yS4AL4pxey5v+o6+Hk6+mJmODKWBM6dMcYbjeg@mail.gmail.com>
 <20180725144732.GE22664@my.box>
 <CAEDoHiiqiAEkZOUAjS77-B6TRmKyOro5qVXeb8-VUmHj_pX4MQ@mail.gmail.com>
Message-ID: <20180725164524.GE25809@my.box>

On Wed, Jul 25, 2018 at 05:08:35PM +0200, Ernesto Sanchez wrote:
> Hi Neels, a lot of thanks, I think that is not a good idea work in an open
> proyect with proprietary hardware, and proprietary firmware... The result
> is: I don't own my hardware, I paid for hardware that I can not use, I can
> understand pay a fee for the "new" license but no more than this.

Sorry, but preaching Open Source to Osmocom is quite misplaced. Small companies
across the world have made considerable investment in effort and money to get
3G support into the Open, and besides sysmocom offering the much more expensive
SysmoCell5000 series, it's a major highlight that the much cheaper nano3G was
also made to work with Osmocom, specifically to allow remotely affordable Open
Source 3G hacking. Sysmocom also gave away quite a few of them for free during
the Accelerate3G5 project. I see it as a major achievement to whip all of this
up while being a (small) company that is still able to pay wages and taxes. So
please, hold your horses there, seriously.

One key item that is not in Open Source yet is the RNC. If we then add an SDR
implementation for a UMTS transceiver, we could do completely without
proprietarily licensed hardware.

Open Source lives by contribution, so you are more than welcome to bring in
your part and implement these (or fund someone to do so).

Feel free to browse http://sysmocom.de and/or enquire at sales at sysmocom.de
about 3G hardware to go with Osmocom. I'm a developer, not familiar with the
sales details. Or maybe you can persuade ip.access to hand out Free firmware?

~N

-- 
- Neels Hofmeyr <nhofmeyr 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
* 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: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180725/f86d775d/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Jul 25 17:00:26 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 25 Jul 2018 19:00:26 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <e3a1501d-4266-3016-1ab3-4dec0278b0ff@sysmocom.de>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725143322.GC22664@my.box>
 <210e9b06-783b-1345-cb36-d9e6f4fefd90@sysmocom.de>
 <20180725161724.GC25809@my.box>
 <e3a1501d-4266-3016-1ab3-4dec0278b0ff@sysmocom.de>
Message-ID: <20180725170026.GG25809@my.box>

> Just to make sure: We already have a default differentiate log level on each
> target. Not only 1 for the whole app.
> It's true that we don't have one per category.

Sure, everything I say and plan is on the premise of completely independent log
targets, each log target has its own configuration for every single aspect
(sharing only the hardcoded default category levels from the .c files).

~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/20180725/995b30a6/attachment.bin>

From ron.menez at entropysolution.com  Thu Jul 26 08:39:06 2018
From: ron.menez at entropysolution.com (Ron)
Date: Thu, 26 Jul 2018 08:39:06 +0000
Subject: Cell Broadcast Feature
Message-ID: <5EE733C6-39B5-4152-AC36-98987E1D2A93@entropysolution.com>

Hi Community,

Does anyone tried to use the Cell Broadcast feature in osmo?

https://osmocom.org/projects/cellular-infrastructure/wiki/Cell_Broadcast

Is there specific SDRs that supports this feature?

Best Regard,

Ron Menez
ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180726/a6430167/attachment.htm>

From pespin at sysmocom.de  Thu Jul 26 09:04:25 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Thu, 26 Jul 2018 11:04:25 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <20180725161259.GB25809@my.box>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725142209.GB22664@my.box>
 <341eacf7-a154-0031-1b00-6555e703dc55@sysmocom.de>
 <20180725161259.GB25809@my.box>
Message-ID: <f6fce37d-1350-a95a-3280-19a7f9b95102@sysmocom.de>



On 25/07/18 18:12, Neels Hofmeyr wrote:
> On Wed, Jul 25, 2018 at 05:31:59PM +0200, Pau Espin Pedrol wrote:
>> A) It's already there as it is now, no need to change. When you start a
>> program, code harcoded categories are set with a given loglevel.
> 
> But currently no way to get back to it, IIUC. Not important anyway.

No, we cannot, we would probably require a new API to store them as 
"harcoded categories", and some VTY command to set them. If somebody 
thinks it's needed and really useful, patches welcome. I think it's not 
that useful and I want to keep the logging system as simple as possible 
while still providing useful ways to fine-grain loglvels.

> 
>> C) D) T) E)
>> I fins all this "temporary" stuff something really not there in current
>> code, too complex and not really required.
> 
> We actually supported temporary logging increase, even though I never grokked
> how it was supposed to work, hence I broke it by removing the logging level all
> everything.
> 
> This is an attempt to bring it back in an obvious and finely tunable way. It is
> not really complex, is it!?

Same as my last above comment. My intention with this patchset was to 
have the logging working again trying not to touch that much, and avoid 
spending much time on it. If at some point we supported the feature, 
it's not the case anymore nowadays. If somebody wants to re-add that 
feature and change the logging system, patches welcome.

> 
>> Current proposed system is basically (and very similar to old system, just a
>> bit better sort out imho):
> 
> A problem there is that it is changing the meaning of a logging command that
> has been there for a decade. Because I fail to understand why exactly it isn't
> doing what I want and why it was implemented this way, and because I accept
> that other users might rely on exactly the current behavior to do what they
> want, I would prefer keeping it unchanged and to add new command names that
> make proper sense to us (to not repeat my past mistake).

I think current behavior (for logging level all) is imho totally broken 
and the patchset I'm proposing changes behavior of old commands only 
minimally.


> - I have setup a detailed logging landscape, i.e. not one default level for all
>    categories, but a fine grained selection: some on error, some on notice, some
>    on info,  > - Now for a minute I want to quickly see all debug logging.
>    logging increase debug all
> - Later I want to go back to the detailed landscape.
>    logging reset all

Someone can always add these feature on top of present patchset if 
there's enough use for it. This feature is not there now, so I'm not 
removing it with presented patchset. I personally think the scenario you 
presented can be workarounded pretty easily in different ways, so I 
personally think there's no urgent need for it:
1- Open a new VTY, then call logging level all debug
2- Write down the commands you used to set the logging, then paste them 
after running "logging level default debug; logging level all unset" to 
see all logging for a while.


-- 
- 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


From nhofmeyr at sysmocom.de  Thu Jul 26 14:20:40 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 26 Jul 2018 16:20:40 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <f6fce37d-1350-a95a-3280-19a7f9b95102@sysmocom.de>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725142209.GB22664@my.box>
 <341eacf7-a154-0031-1b00-6555e703dc55@sysmocom.de>
 <20180725161259.GB25809@my.box>
 <f6fce37d-1350-a95a-3280-19a7f9b95102@sysmocom.de>
Message-ID: <20180726142040.GC25092@my.box>

On Thu, Jul 26, 2018 at 11:04:25AM +0200, Pau Espin Pedrol wrote:
> 
> 
> On 25/07/18 18:12, Neels Hofmeyr wrote:
> > On Wed, Jul 25, 2018 at 05:31:59PM +0200, Pau Espin Pedrol wrote:
> > > A) It's already there as it is now, no need to change. When you start a
> > > program, code harcoded categories are set with a given loglevel.
> > 
> > But currently no way to get back to it, IIUC. Not important anyway.
> 
> No, we cannot, we would probably require a new API to store them as
> "harcoded categories"

The information is always there, the default categories log_info_cat struct are
const. Remeber, each log target has its own category-level settings, so
obviously the hardcoded defaults remain available. It's a simple thing.

And still not really important :)

> Same as my last above comment. My intention with this patchset was to have
> the logging working again trying not to touch that much, and avoid spending
> much time on it. If at some point we supported the feature, it's not the
> case anymore nowadays. If somebody wants to re-add that feature and change
> the logging system, patches welcome.

And same as my last comment, you are changing a decade old vty command.
Last time I did this it was the wrong choice.

> Someone can always add these feature on top of present patchset if there's
> enough use for it.

Introducing a common default level actually also closes the door on
fine-grained default levels. I mean the VTY UI you are introducing would have
to be deprecated to introduce fine-grained defaults.

It is actually not practical to have all categories on the same level, unless
it is, say, ERROR.

So the patch does what you want and is better than current 'logging level all
xxx' indeed, but changes old UI and has limits. As much as I'd like to let it
go ahead, I'm still -1, sorry.

> 1- Open a new VTY, then call logging level all debug

true. Any opinions on this one, Keith maybe?

> 2- Write down the commands you used to set the logging, then paste them
> after running "logging level default debug; logging level all unset" to see
> all logging for a while.

I had the same idea once, but it's not practical. Copy pasting and stuff is not
something we want to require the user to do.

~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/20180726/792254c8/attachment.bin>

From pespin at sysmocom.de  Thu Jul 26 14:40:49 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Thu, 26 Jul 2018 16:40:49 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <20180726142040.GC25092@my.box>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725142209.GB22664@my.box>
 <341eacf7-a154-0031-1b00-6555e703dc55@sysmocom.de>
 <20180725161259.GB25809@my.box>
 <f6fce37d-1350-a95a-3280-19a7f9b95102@sysmocom.de>
 <20180726142040.GC25092@my.box>
Message-ID: <4e6ee514-c5f4-09de-5e8b-913a1c3c88a7@sysmocom.de>

Hi,
find answers in place.

On 26/07/18 16:20, Neels Hofmeyr wrote:

>> No, we cannot, we would probably require a new API to store them as
>> "harcoded categories"
> 
> The information is always there, the default categories log_info_cat struct are
> const. Remeber, each log target has its own category-level settings, so
> obviously the hardcoded defaults remain available. It's a simple thing.

Ok, no need for new API, since it's already done using a specific API 
(log_init). But we'd need to change the implementation to account in 
that function that for each category the value being copied is the 
"hardcoded default" instead of a regular level being set.

> 
> And same as my last comment, you are changing a decade old vty command.
> Last time I did this it was the wrong choice.

Ok so let's leave it broken and useless then? Deprecate it and write an 
entire new system? No, thanks.

> 
>> Someone can always add these feature on top of present patchset if there's
>> enough use for it.
> 
> Introducing a common default level actually also closes the door on
> fine-grained default levels. I mean the VTY UI you are introducing would have
> to be deprecated to introduce fine-grained defaults.
> 

What do you mean with fine-grained default levels? Having a way to go 
back to hardcoded initial values? You can have that as long as you store 
the values in log_init in a new var default_loglevel for each category.

If you still want more temporary levels (increase/decrease or whatever 
you call it) per logtarget or even per category, you can add them later 
and check them before the other levels in should_log_to_target(), then 
change them with new VTY commands.

> 
> So the patch does what you want and is better than current 'logging level all
> xxx' indeed, but changes old UI and has limits. As much as I'd like to let it
> go ahead, I'm still -1, sorry.

It's compatible with old UI. All programs using the API continue to work 
fine as well as old cfg files. It adds new parameter "logging level 
default <loglevel>" and "logging level <category> unset", that's all. So 
it fixes broken logging level all and adds extra feature to make it useful.

> 
>> 1- Open a new VTY, then call logging level all debug
> 
> true. Any opinions on this one, Keith maybe?

You can even just re-open the session you have opened, no need to open a 
second one.


-- 
- 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


From nhofmeyr at sysmocom.de  Thu Jul 26 17:20:37 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 26 Jul 2018 19:20:37 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <4e6ee514-c5f4-09de-5e8b-913a1c3c88a7@sysmocom.de>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725142209.GB22664@my.box>
 <341eacf7-a154-0031-1b00-6555e703dc55@sysmocom.de>
 <20180725161259.GB25809@my.box>
 <f6fce37d-1350-a95a-3280-19a7f9b95102@sysmocom.de>
 <20180726142040.GC25092@my.box>
 <4e6ee514-c5f4-09de-5e8b-913a1c3c88a7@sysmocom.de>
Message-ID: <20180726172037.GG25092@my.box>

Before this echoing of the same arguments over and over continues between you
and me, Pau, let's stop this here and let me do my homework in the logging
code. I'll try to clarify what I mean, but I see I need to prove my points.

> Ok so let's leave it broken and useless then? Deprecate it and write an
> entire new system? No, thanks.

Introducing new commands that work properly is IMO the only viable solution to
fix old broken UI. IIUC your patch adds new commands?

So I'd like to clarify how the implementation affects what old commands did,
and whether it permits implementing per-category defaults without problems.

> What do you mean with fine-grained default levels?

Still not clear, is it? I want to set various categories to various log levels
to taste, then go to say DEBUG on some/all of them, then later go back to
exactly the levels selected before.

It's like your default log level, just not one across all categories, but one
level per category.

Your suggestion:

                           level
                             ^
                             |     -
  Normal logging landscape== | =====================
          Temporary levels-- | --               -
                             |      --   ----  -
                             |________________________> categories


What I'd like to support:

                           level
                             ^
                             |     - ======    =
  Normal logging landscape== | ==  ==      ==     --
          Temporary levels-- | -- =          == -  =
                             |   =  --   ----  -===
                             |________________________> categories


This includes the possibility of having all of them at the same level, so it
seems we are just very verbosely arguing about the implementation and UI
details.

> Having a way to go back to hardcoded initial values?

Please let go of the hardcoded defaults, they aren't important, I did say so a
number of times now.

> If you still want more temporary levels (increase/decrease or whatever you
> call it)

Do I read a dismissive tone here? :P

> per logtarget

Everything is always inherently per logtarget!

> or even per category,

exactly

> you can add them later and
> check them before the other levels in should_log_to_target(), then change
> them with new VTY commands.

If you introduce one common default level for all categories, I fear that it
conflicts with the use case to have separate defaults for each category. I
still need to prove that.

> It's compatible with old UI. All programs using the API continue to work
> fine as well as old cfg files. It adds new parameter "logging level default
> <loglevel>" and "logging level <category> unset", that's all. So it fixes
> broken logging level all and adds extra feature to make it useful.

Don't the code changes modify how 'logging level all foo' behaves?
I have to do my homework to strengthen my argument here.

> > > 1- Open a new VTY, then call logging level all debug
> > 
> > true. Any opinions on this one, Keith maybe?

If monitoring e.g. BTS or PCU on a slow ARM, opening multiple log targets
might impact stability.

> You can even just re-open the session you have opened, no need to open a
> second one.

But then you lose the specific logging selection that you want to keep.

~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/20180726/aec5d858/attachment.bin>

From axilirator at gmail.com  Thu Jul 26 18:31:31 2018
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Fri, 27 Jul 2018 01:31:31 +0700
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <20180726172037.GG25092@my.box>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725142209.GB22664@my.box>
 <341eacf7-a154-0031-1b00-6555e703dc55@sysmocom.de>
 <20180725161259.GB25809@my.box>
 <f6fce37d-1350-a95a-3280-19a7f9b95102@sysmocom.de>
 <20180726142040.GC25092@my.box>
 <4e6ee514-c5f4-09de-5e8b-913a1c3c88a7@sysmocom.de>
 <20180726172037.GG25092@my.box>
Message-ID: <CAPEnp=bsOxx7UtYU9oDedZSgrmJU+Ut28ZCSWi_Gi=-5_LjhCg@mail.gmail.com>

Hi Pau, Neels, and all,

It seems, the reason of my misunderstanding was that confusing
'all' keyword. I have been interpretting it as 'default', but
actually it is far from this meaning...

> So after my proposal (from my last email):
> ...
> logging level (all|default|<category>) (unset|<loglevel>)
> ...
> Agree?

Yep, finally I am ;)

In order to have a clean commit history, I suggest the following
algorithm (one high level point represents one single change):

1. Introduce 'unset' keyword first;
2. Introduce 'default' logging category ('logging level default'):
2.1. Modify the 'logging level' command (by adding 'default');
2.2. Correct memory allocation in log_vty_command_string();
2.3. Write *exactly 'default'* (not 'all') to the configuration;
3. Fix the behaviour of 'default' (i.e. target's) logging category:
3.1. In other words, correct the loging in should_log_to_target();
4. Correct the behaviour of 'logging level all LEVEL';
5. Testing coverage ;)
6. <New features> ...

> And same as my last comment, you are changing a decade old vty command.
> Last time I did this it was the wrong choice.

Regarding to changing the behaviour of 'logging level all LEVEL'
command, I think we need to make this step. Let's have a look
at OsmoHLR configuration, shipped as an example:

log stderr
  ! ...
  ! Set *default* log level 'debug' for stderr
  logging level all debug
  logging level linp error

What would we get now (before merging the patch set)?

The 'debug' becomes default, but since the logging is broken,
the hardcoded values will be used for all categories,
excluding 'linp'. The 'all' remains confusing...

If one saves the current configuration, the result would be:

log stderr
  ! ...
  ! Set *default* log level 'debug' for stderr
  logging level all debug
  logging level linp error
  logging level foo <hardcoded>
  logging level bar <hardcoded>
  ! all other categories...

What would we get after this patch set?

The first command is now interpreted as it should be interpreted.
So, we have no 'default' logging level (i.e. it becomes 'unset'),
all categories, excluding 'linp', are set to 'debug'.

If one saves the current configuration now, the result would be
similar, i.e. it will also dump all possible categories, but
instead of <hardcoded> values 'debug' would be used:

log stderr
  ! ...
  ! Set *default* log level 'debug' for stderr
  logging level default debug
  logging level linp error
  logging level foo debug
  logging level bar debug
  ! all other categories...

How to avoid this after merging the patch set?

Update the configuration examples, replacing 'all' by 'default'.
Either, doing 'logging level all unset' before saving to file.

This way one would get the original configuration untouched,
i.e. without dumping all possible categories...


Then we can think about new features, and this is what do I
think about some of them (described by Neels):

> A.1. A command to reset all to hardcoded defaults?

I like the idea of Neels about resetting the logging levels.
Additionally to the hardcoded logging settings, would be great
to have a possibility to reset to the logging settings from
the current configuration...

I assume the following syntax for that:

  logging level (all|default|<category>) reset

> C) Temporarily reducing the logging
> D) Temporarily increasing the logging
> E) Remove temporary logging to go back
>    to the "normal" logging landscape.

Regarding to the 'temporary' staff, I think one can interpret
the current ('running') modified configuration as 'temporary'.
You're free to change everything, and if you like the current
logging configuration - you can write it to a file. Otherwise,
your idea about resetting fits here just fine, so one would be
able to restore the current configuration from file at runtime.

> F) ... silence all messages ... unless they match
>    the context filter: logging filter imsi 123456789123456
> ...
> 3) enable / disable individual filters
> 4) disable all filters

I think it's useful feature. I didn't even know about this :)
Another interesting idea is to introduce a RegExp based filter
(if not yet), like we have in the talloc context
introspection command. Examples:

  logging filter regexp (failed|unable|couldn't)
  logging filter regexp ^BTS[0-9]+

BTW: I also find 'logging filter all 1' confusing ;)

With best regards,
Vadim Yanitskiy.


From keith at rhizomatica.org  Fri Jul 27 11:42:11 2018
From: keith at rhizomatica.org (Keith)
Date: Fri, 27 Jul 2018 13:42:11 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <20180726142040.GC25092@my.box>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725142209.GB22664@my.box>
 <341eacf7-a154-0031-1b00-6555e703dc55@sysmocom.de>
 <20180725161259.GB25809@my.box>
 <f6fce37d-1350-a95a-3280-19a7f9b95102@sysmocom.de>
 <20180726142040.GC25092@my.box>
Message-ID: <f4430626-396c-2a0a-e2e9-92792b3d9d3e@rhizomatica.org>



On 26/07/2018 16:20, Neels Hofmeyr wrote:
>
> true. Any opinions on this one, Keith maybe?
>

I have now got used to using a number of pre-prepared expect
scripts to open VTYs for various logging scenarios.

Rather than changing the logging in an open VTY, I would
probably open another and change it there, or copy and
modify the script to setup that logging config. I haven't
got around to it yet, but I am planning on making this just
one script that accepts params like "msc" or "mgw" as well
as logging configs concepts as I can never remember the
ports now with all the programs, although I have this:

sudo netstat -tapn | egrep 'LISTEN.*osmo' | awk '{print $4,
$7}' | awk -F "[:/ ]" '{print $2,"- " $4}' | grep 42 | sort -n

I did not particularly have a problem with "logging level
all everything" and "logging level all debug" and yes, as
Neels mentioned have been patching libosmocore to revert to
allowing "logging level all everything" - Despite some
strange resistance to belief from some parties, this
actually worked (works) as a temporary ON/OFF switch to set
all categorys to debug, then revert to individual per
category levels. I've explained that before, here on the
list with Max, I think.
The semantics off "logging level all everything" was no more
difficult that anything else in GSM's world of acronyms etc.
It was simply a case of learning what it does.

I think it might be nice to have a default VTY logging
storable in the config as we do for stderr.
Otherwise, I'm kind of OK with using expect to setup what I
want.

K.





From nhofmeyr at sysmocom.de  Fri Jul 27 14:59:46 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 27 Jul 2018 16:59:46 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <f4430626-396c-2a0a-e2e9-92792b3d9d3e@rhizomatica.org>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725142209.GB22664@my.box>
 <341eacf7-a154-0031-1b00-6555e703dc55@sysmocom.de>
 <20180725161259.GB25809@my.box>
 <f6fce37d-1350-a95a-3280-19a7f9b95102@sysmocom.de>
 <20180726142040.GC25092@my.box>
 <f4430626-396c-2a0a-e2e9-92792b3d9d3e@rhizomatica.org>
Message-ID: <20180727145946.GA1653@my.box>

On Fri, Jul 27, 2018 at 01:42:11PM +0200, Keith wrote:
> Neels mentioned have been patching libosmocore to revert to
> allowing "logging level all everything"

So you're saying you're no longer doing that and going with opening separate
VTY telnets instead?

> I think it might be nice to have a default VTY logging
> storable in the config as we do for stderr.

There's an interesting feature request. Maybe easier would be a vty command to
adopt in the current telnet the logging config from stderr (or any other log
target).

> Otherwise, I'm kind of OK with using expect to setup what I
> want.

What's "using expect"?

~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/20180727/42809351/attachment.bin>

From laforge at gnumonks.org  Sun Jul 29 09:33:41 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 29 Jul 2018 11:33:41 +0200
Subject: Rationale behind ipa_ccm_idtag_parse_off() ?
Message-ID: <20180729093341.GI5720@nataraja>

Hi Holger,

I'm getting back to the following libosmocore commit introduced in 2015:

> commit f558ed4bb9c0f00997b8f97c2b251a574c1a64c4
> Author: Holger Hans Peter Freyther <holger at moiji-mobile.com>
> Date:   Tue Jun 2 15:52:06 2015 +0200

I can see what you are doing, but I have absolutely no idea as to why.

AFAICT, the IPA CCM ID TLVs have the following structure:

* 16bit length field
* one byte tag
* optional payload

The length field *includes* the tag, so the actual payload length is the value
encoded in the length field minus one.

This means that the existing/classic ipa_ccm_idtag_parse() always returns one
byte too much for the length of the IPA payload.  I'm trying to address this in
https://gerrit.osmocom.org/#/c/libosmocore/+/10216/

Your commit introduces ipa_ccm_idtag_parse_off(), which introduces a noffset field.
However, that offset is used not only to compute the actual "payload" size, but
it's also used for computing the subsequent CCM information elements.  Hence, I cannot
use any non-zero offset to parse a CCM blob.

I also don't see any of our code using the ipa_ccm_idtag_parse_off() function, except
the test case - where the test case seems to use a different encoding as seen on the
wire, i.e. it uses only a single-byte length field.

So if the function was just added for that test case, why not structure the data
used in the test to reflect the on-the-wire protocol reality?

There must be some genius rationale behind it, but I'm unable to figure it out.

Maybe you still remember? Thanks!

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


From holger at freyther.de  Sun Jul 29 10:11:13 2018
From: holger at freyther.de (Holger Freyther)
Date: Sun, 29 Jul 2018 11:11:13 +0100
Subject: Rationale behind ipa_ccm_idtag_parse_off() ?
In-Reply-To: <20180729093341.GI5720@nataraja>
References: <20180729093341.GI5720@nataraja>
Message-ID: <B3262DAA-858D-4871-89EF-103322083227@freyther.de>



> On 29. Jul 2018, at 10:33, Harald Welte <laforge at gnumonks.org> wrote:
> 
> 
> I'm getting back to the following libosmocore commit introduced in 2015:
> 
>> commit f558ed4bb9c0f00997b8f97c2b251a574c1a64c4
>> Author: Holger Hans Peter Freyther <holger at moiji-mobile.com>
>> Date:   Tue Jun 2 15:52:06 2015 +0200
> 
> I can see what you are doing, but I have absolutely no idea as to why.


> So if the function was just added for that test case, why not structure the data
> used in the test to reflect the on-the-wire protocol reality?
> 
> There must be some genius rationale behind it, but I'm unable to figure it out.
> 
> Maybe you still remember? Thanks!

I might not have time until next week to replicate it (and my nanobts is not
with me right now either). IIRC (my first memory but the commit message points
me to it as well): I struggled a lot to parse ipaccess-find (IPAC_MSGT_ID_GET)
from the nanoBTS.

It seemed it was disobeying a reasonable TLV structure and the closest I found
back then seemed to have been this patch? Could you check if the testcase matches
an ipaccess-find result?

I will try to find some next during the week to have a look.


holger

From laforge at gnumonks.org  Sun Jul 29 10:51:47 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 29 Jul 2018 12:51:47 +0200
Subject: Rationale behind ipa_ccm_idtag_parse_off() ?
In-Reply-To: <B3262DAA-858D-4871-89EF-103322083227@freyther.de>
References: <20180729093341.GI5720@nataraja>
 <B3262DAA-858D-4871-89EF-103322083227@freyther.de>
Message-ID: <20180729105147.GK5720@nataraja>

Hi Holger,

On Sun, Jul 29, 2018 at 11:11:13AM +0100, Holger Freyther wrote:
> I might not have time until next week to replicate it (and my nanobts is not
> with me right now either). IIRC (my first memory but the commit message points
> me to it as well): I struggled a lot to parse ipaccess-find (IPAC_MSGT_ID_GET)
> from the nanoBTS.

Ah. ok. I've not looked at ipaccess-find/UDP in a long time. Only at the normal
procedure at OML/RSL start-up.

> It seemed it was disobeying a reasonable TLV structure and the closest I found
> back then seemed to have been this patch? Could you check if the testcase matches
> an ipaccess-find result?

Yes, I will check for that.  The test case definitely does not match the IPA CCM
seen inside OML/RSL from a nanoBTS, not even from the first traces I have from 2010.

> I will try to find some next during the week to have a look.

I think the pointer to ipaccess-find was sufficient, thanks.

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


From holger at freyther.de  Sun Jul 29 11:15:55 2018
From: holger at freyther.de (Holger Freyther)
Date: Sun, 29 Jul 2018 12:15:55 +0100
Subject: Rationale behind ipa_ccm_idtag_parse_off() ?
In-Reply-To: <20180729105147.GK5720@nataraja>
References: <20180729093341.GI5720@nataraja>
 <B3262DAA-858D-4871-89EF-103322083227@freyther.de>
 <20180729105147.GK5720@nataraja>
Message-ID: <42627BD5-258A-4F56-8311-AA4DD9D2E17C@freyther.de>



> On 29. Jul 2018, at 11:51, Harald Welte <laforge at gnumonks.org> wrote:
> 
> Hi Holger,
> 

> 
> I think the pointer to ipaccess-find was sufficient, thanks.

One more thing came to mind. It was when I implemented the sysmobts-mgr.

sysmobts_mgr_nl.c has this comment:

/*
 * The TLV structure in IPA messages in UDP packages is a bit
 * weird. First the header appears to have an extra NULL byte
 * and second the L16 of the L16TV needs to include +1 for the
 * tag. The default msgb/tlv and libosmo-abis routines do not
 * provide this.
 */

It is entirely possible that I missed something in the ipaccess
protocol... it seemed weird (or an attribute of writing strings
into there).




From axilirator at gmail.com  Mon Jul 30 17:56:10 2018
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Tue, 31 Jul 2018 00:56:10 +0700
Subject: Cell Broadcast Feature
Message-ID: <CAPEnp=aF=j0M3rP55dED=fGkRia2mk7HtZBsdBTK0LVQu_ECVw@mail.gmail.com>

Hi Ron,

> Does anyone tried to use the Cell Broadcast feature in osmo?
> Is there specific SDRs that supports this feature?

I have not tried personally, but I would like to clarify one thing.

CBCH is implemented in the higher *software* layers, so it doesn't
depend on a specific SDR device. The problem is that it isn't (yet)
implemented for osmo-bts-trx, a BTS variant for SDR devices...

Moreover, I believe it should be quite easy to implement this,
so any patches are welcome ;)

With best regards,
Vadim Yanitskiy.


From laforge at gnumonks.org  Mon Jul 30 18:25:34 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 30 Jul 2018 20:25:34 +0200
Subject: Cell Broadcast Feature
In-Reply-To: <5EE733C6-39B5-4152-AC36-98987E1D2A93@entropysolution.com>
References: <5EE733C6-39B5-4152-AC36-98987E1D2A93@entropysolution.com>
Message-ID: <20180730182534.GK30570@nataraja>

Hi Ron,

On Thu, Jul 26, 2018 at 08:39:06AM +0000, Ron wrote:
> Does anyone tried to use the Cell Broadcast feature in osmo?
> https://osmocom.org/projects/cellular-infrastructure/wiki/Cell_Broadcast

Me (and several others from the Osmocom developers) have used it successfully
in the past.  We demonstrated this many years ago at one of the CCC congresses.

We tested it (AFAIK) with nanoBTS and sysmoBTS.

> Is there specific SDRs that supports this feature?

As Vadim has already pointed out, it's not a SDR feature.  THe problem is
osmo-bts-trx (used by all SDR hardware). See http://osmocom.org/issues/1617

Unfortunately, the amount of contributions we get towards osmo-bts-trx is
still lower than compared to other BTS models where the respective BTS vendors
(or some large customers) have a more pressing need to have features supported.

See http://osmocom.org/versions/122 for more TOOD items for osmo-bts-trx
compared to other BTS backends.

-- 
- Harald Welte <laforge at gnumonks.org>           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  Mon Jul 30 18:28:22 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 30 Jul 2018 20:28:22 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <20180727145946.GA1653@my.box>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725142209.GB22664@my.box>
 <341eacf7-a154-0031-1b00-6555e703dc55@sysmocom.de>
 <20180725161259.GB25809@my.box>
 <f6fce37d-1350-a95a-3280-19a7f9b95102@sysmocom.de>
 <20180726142040.GC25092@my.box>
 <f4430626-396c-2a0a-e2e9-92792b3d9d3e@rhizomatica.org>
 <20180727145946.GA1653@my.box>
Message-ID: <20180730182822.GL30570@nataraja>

On Fri, Jul 27, 2018 at 04:59:46PM +0200, Neels Hofmeyr wrote:
> What's "using expect"?

I guess Keith referst to the good old expect program, used by many of us
for decades for automating shell like interfaces.

	"apt-get install expect && man 1 expect" ?

-- 
- Harald Welte <laforge at gnumonks.org>           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  Mon Jul 30 18:39:19 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 30 Jul 2018 20:39:19 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
Message-ID: <20180730183919.GM30570@nataraja>

Hi Vadim,

as I'm back from holidays, I'm catching up with mails, including this thread here.

On Wed, Jul 25, 2018 at 12:10:08AM +0700, Vadim Yanitskiy wrote:
> First of all, the change introduces a new special logging level 'unset',
> which allows one to reset a given category (i.e. unset its custom value):
> 
> [..]

>   !! Resetting DMNCC:
>   # logging level mncc unset
> 
>   !! So, now DMNCC has no custom log level, it will use
>   !! the default level (in this example it is 'error'):

but what is the "default level"?  I assume as you're talking about interactive
changes, you are talking about logging to a VTY.  What is the default that you
fall-back to?  Unlike file/syslog targets, the VTY doesn't have any configurable
defaults

> But (among fixing) this change additionally changes the behaviour
> of a command for setting the default logging category (i.e. 'logging
> level all LEVEL'):
> 
>   !! Initial logging configuration:
>   logging level all error
>   logging level mncc debug
>   logging level pag notice
>   logging level meas debug
> 
>   !! Changing the default logging level:
>   # logging level all debug
> 
>   !! Ahhh, I've lost my custom levels :(
>   logging level all debug
> 
>   !! What I expected to get:
>   logging level all debug
>   logging level mncc debug
>   logging level pag notice
>   logging level meas debug
> 
> So, together with changing the default logging category,
> this command now would also reset all custom settings...

To be honest, I don't think I have any idea at all what "logging level all" does,
I have never used it.  I find it quite confusing that there are other things than
setting the per-subsystem levels.  Setting per-subsystem categories makes sense to me,
everything else seems strange...

> I am not sure this is exactly what one need/expect, so
> I would like to share the following ideas:
> 
>   1) The category 'all' looks/sounds confusing when it's used
>      in such cases like this:
> 
>        # logging level all debug
> 
>      because one can interpret it like:
> 
>        "set all categories to debug".
> 
>      despite actually (according to the implementation) this
>      is related to the default logging policy.
> 
>      Maybe, we should rename it to 'default'?

>      So, 'logging level all LEVEL' would *set all categories*
>      to a given logging LEVEL, 

I agree this is more intuitive from the meaning of the word "all",
but I think that would be only ever used to set a global "sane" logging
level like NOTICE or ERROR.  You certainly don't want to set DEBUG on
all categories, as otherwise you're going to be spammed and will drown
in too much information.

> while 'logging level default LEVEL'
>      would only affect the default logging level...

What is the "default logging level" ?  The level compiled-into the struct
log_info?

>   3) The introduced behaviour of resetting all categories to 'unset'
>      could be implemented in a separate function, and can be
>      represented by a separate command:
> 
>        # logging level unset-all
> 
>      The name of this command clearly defines the expected behaviour.
>      Moreover, it doesn't affect the default logging level, which can be
>      still changed by a separate command.

How would you ever change the default?  I thought that's the compiled-in part?

Resetting the current logging masks to those default compiled-in ones by a single
command seems like a useful feature to me.  My practical work-around for this is to simply
close + re-open the VTY session...

-- 
- Harald Welte <laforge at gnumonks.org>           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  Mon Jul 30 18:43:05 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 30 Jul 2018 20:43:05 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
Message-ID: <20180730184305.GN30570@nataraja>

On Wed, Jul 25, 2018 at 11:16:46AM +0200, Pau Espin Pedrol wrote:
> So, after your comments and thinking about it, here's my proposal:
> 1- Take my current patchset
> 2- Modification: "logging level all <loglevel>" sets the loglevel foreach
> category, not the target loglevel (aka the default loglevel).

I think the "target loglevel" should/could be abandoned completely.

> 3- Modification: "logging level unset <loglevel>" is renamed to "logging
> level default <loglevel>"

IMHO it should be "logging level SUBSYSTEM unset" or "logging level
SUBSYSTEM default" which would then revert back to the compiled-in level
for that particular subsystem?

I understand you can un-set or fall-back to the compiled-in default
of a given sub-system.  But how can you un-set a given *level* ?!?

-- 
- Harald Welte <laforge at gnumonks.org>           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  Mon Jul 30 18:50:21 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 30 Jul 2018 20:50:21 +0200
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <20180725142209.GB22664@my.box>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <3118212c-1c40-4848-7887-7410bce41a5b@sysmocom.de>
 <20180725142209.GB22664@my.box>
Message-ID: <20180730185021.GO30570@nataraja>

Hi Neels,

On Wed, Jul 25, 2018 at 04:22:09PM +0200, Neels Hofmeyr wrote:
>  A) The hardcoded logging landscape on program startup without config.
>     (Maybe this isn't all that important, including it nevertheless.)
>    1) a command to reset all to hardcoded defaults?

ACK

>  B) A "normal" logging behavior configured by the user. We need:
>    1) a command to set all categories at once

to set all to one level, or to set all to one set of (configurable) defaults,
like a template?

>    2) a command to tweak individual categories

ACK.

>  C) Temporarily reducing the logging on all categories: silence the log.
>     Even though a category is "normally" set to INFO, after this command it can
>     be forced down to only log e.g. NOTICE. But if a category is already on
>     ERROR, leave it down there and do not lift it up to NOTICE.
>    1) a command to temporarily reduce all categories.
>    2) a command to temporarily reduce individual categories.

Not sure for what one would use that.  You could switch off logging completely
and re-enable it later?

>  D) Temporarily increasing the logging on all categories: show everything.
>     Even though a category is "normally" set to ERROR, after this command it
>     can be forced up to e.g. INFO. But if a category is already up at DEBUG,
>     don't reduce it to NOTICE.
>    1) a command to temporarily increase all categories.
>    2) a command to temporarily increase individual categories.
>    3) we need to decide whether temporarily increasing is stronger/weaker than
>       temporarily reducing. Depending on the implementation, it could also be
>       "last one wins" (which IMHO would be best).

Sounds incredibly complicated to me.

>  T) Maybe we also want to unconditionally set temporary levels, whether they
>     increase or reduce.

?!?

>  E) Remove temporary logging to go back to the "normal" logging landscape.
>    1) a command to put everything back to "normal",
>    2) a command to put individual categories back to "normal",
>    3) a separate command to only remove temporary reduction, i.e lift the
>       temporary changes only if they cause less logging than normal,
>    4) a separate command to only remove temporary verbosity, i.e. only lift the
>       temporary changes if they cause more logging than normal.

WTF? Why all that complexity?

Honestly, I'm stopping at that point.  Just finishing to read that one e-mail,
let alone the entire thread will cost me hours.

To me, it boils down to a hypthetical luxury problem, unless there's
somebody who is actually funding/contributing the amount of time
required to designing, debating, implementing, reviewing and merging and
overhaul of the logging sub-system.

-- 
- Harald Welte <laforge at gnumonks.org>           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  Mon Jul 30 19:14:18 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 30 Jul 2018 21:14:18 +0200
Subject: 4G / LTE and osmocom
In-Reply-To: <CA+ChNyVTK1rBLPk4cqmR3fD-3Z-4S8F1qceMLK-p6+Tiua2T_A@mail.gmail.com>
References: <CA+ChNyVTK1rBLPk4cqmR3fD-3Z-4S8F1qceMLK-p6+Tiua2T_A@mail.gmail.com>
Message-ID: <20180730191418.GQ30570@nataraja>

Hi Ruben,

sorry for the delayed response, I've been on holidays.

On Wed, Jul 18, 2018 at 05:11:45PM +0200, Ruben Undheim wrote:

> The OpenBSC tools have turned into an impressive collection of tools.
> It is great to see this huge effort being done successfully! I was
> searching around on the osmocom site for information about LTE.
> Either, I am very bad at searching, or there is not so much
> information about that subject. I was wondering about the plans for
> LTE, if there are any such plans?

All Osmocom development happens where we get contributions, either in
form of code, or in terms of funding for implementing certain bits and
features.  Despite my huge interest in the 4G area, we have not been
getting either of the two in Osmocom so far.

As had been mentioned before, I've been playing around with nextepc
as core and srsLTE as well as proprietary LTE eNodeBs in autumn last
year.  I think there is plenty of good FOSS projects for LTE out there.

I've always been quite vocal about my disappointment in OAI in any number
of ways, whether on the side that their (RAN) license is not a Free Software
nor an Open Source license, or whether on the coding style side of things.

So my personal recommendation is to stay away from OAI, and instead focus
on srsLTE and nextepc instead.

> I found a few other projects related to LTE:  nextepc [1] and srsLTE
> [2]. I see that nextepc has been mentioned in a thread related to
> OsmoDevCon 2018, but I cannot see so much more information. Is the
> plan maybe some time to incorporate srsLTE and nextepc into osmocom
> infrastructure? 

As you may know, there is quite a bit of common architecture between 2G
and 3G, but there's virtually nothing in common between 2G+3G on the one
hand side and 4G on the other hand side.

So there's not really much to "incorporate" from the Osmocom point of
view.

I personally would love to have introduced some of the C-language
infrastructure we have created in Osmocom (osmo_fsm, vty, logging
sub-system) into nextepc, but unfortunately nextepc decided against
it.

In terms of "using Osmocom for GSM/UMTS and nextepc+srsLTE for 4G in a
single network", there are the following areas of interaction:

a) mutual broad-casting of neighbor cells

OsmoBSC + OsmoBTS have received SI2ter + SI2quater support quite some
time ago, allowing to broadcast LTE neighbor cells from Osmocom
networks.  So I think this is done.

b) common HLR / HSS for subscriber data

In order to have one shared subscriber database between Osmocom and LTE,
we would have to implement a so-called GSUP-to-DIAMETER IWf
(inter-working function).  This could go either of the two ways:
* translating GSUP to DIAMETER and using a DIAMETER HSS such as that
  of nextepc [which is unfortunately the part about nextepc I like the
  least due to it's dependency to node.js], or
* translating DIAMETER to GSUP and using OsmoHLR from a 4G network

Or, if somebody wants to do it properly, write a new HLR/HSS with proper
separation between the database store and the protocol modules, which
then would offer both GSUP and DIMETER (and/or possibly MAP).  Would be
great to see work or funding in that area, but I'm not seeing any.

c) circuit-switched fall-back, SMS-over-SGs

If your LTE network doesn't have/support IMS, or if you have phones that
don't do VoLTE, then CSFB to 2G/3G is needed.  For that, we'd have to
add a SGS interface.

See http://osmocom.org/projects/osmomsc/wiki/SGs_Interface and
http://osmocom.org/issues/2583

> Is there currently any cooperation? 

Unfortunately not.  There is nobody contributing to Osmocom in any of
the above-mentioned areas at this point, whether in terms of code or
funding.

> Or will there be some new and fresh LTE code in osmocom?

I don't think so.  There's no point in re-inventing the wheel.

My priorities would be in the folloiwing order (highest prio first)

1) GSUP-to-DIAMETER gateway or a new HLR+HSS
2) SGs interface in OsmoMSC
3) GTPv2 support in OsmoGGSN, or test OsmoSSGN with ergw to keep
   PDP/EPS bearer alive during RAT changes

Regards,
	Harald

-- 
- Harald Welte <laforge at gnumonks.org>           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 Jul 30 19:59:36 2018
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Tue, 31 Jul 2018 02:59:36 +0700
Subject: The magic behaviour of 'logging level all LEVEL'
In-Reply-To: <20180730183919.GM30570@nataraja>
References: <CAPEnp=bTMJ--pSsYWDPUa9OVidfGV8Z2FNTo3HiHBq-rkDccYA@mail.gmail.com>
 <20180730183919.GM30570@nataraja>
Message-ID: <CAPEnp=a-vh+tk6SefNFURxhZHvvkLpGJvN1h7m8vOb9UkG0BEw@mail.gmail.com>

Hi Harald,

> as I'm back from holidays, I'm catching up with mails,
> including this thread here.

Nice to see you are back :)

I didn't expect this thread would grow so much. Probably,
because we started to discuss the new features...
But let's focus on the initial thread topic.

> but what is the "default level"?
> What is the default that you fall-back to?

I mean the global log level of a logging target, please see:

https://git.osmocom.org/libosmocore/tree/include/osmocom/core/logging.h#n243

At the moment, it can be set with 'logging level all LEVEL',
but anyway it doesn't work as expected, please see:

https://osmocom.org/issues/3409

and this change by Pau which still mixes new features with
actual bugfixing (src/logging.c#479):

https://gerrit.osmocom.org/10116/

For some reason, I do associate libosmocore's logging subsystem
with iptables. Please don't think I am crazy, there are really
some similarities:

  - Instead of filtering packets, we are filtering
    the logging messages;

  - Logging target (e.g. stderr, or a file) is like a chain;

  - The global log level of a logging target (I usually
    refer this as 'the default logging level') is like
    the default policy of a chain;

  - If a logging category (e.g. 'meas' or 'l1c') has a custom
    logging level (e.g. 'debug'), one may interpret this as a
    rule in a chain. If there is no rule for a given category
    the default logging level can be used (like default policy).

> To be honest, I don't think I have any idea at all
> what "logging level all" does,

Meanwhile, we do have this line in some sample configuration
files, and if there is no this line, we always have the
following result of calling 'show running-config' or 'write file':

  logging level all everything

This is why we (at least me and Pau) would like to introduce
an idea of a bit more self-explaining command:

  logging level default debug

> Setting per-subsystem categories makes sense to me,
> everything else seems strange...

Well, I think it makes sense to have some global / default
logging level (e.g. 'error'), and a set of per-subsystem
levels. For example, I would like to debug some particular
subsystem / category (e.g. DMNCC), and silence all other:

  logging level default error
  logging level mncc debug

Another important feature (I think) is a possibility to
unset either a particular subsystem / category, or all
subsystems / categories, which would fall-back to value
of the default logging level for the current target.

For example, I am running a program with the following
logging configuration:

  logging level default notice
  logging level mncc debug
  logging level pag error
  logging level l1c debug
  logging level l1d info
  ...

and now I would like to debug DPAG at run-time, so I could
unset all custom values from VTY, and set DPAG to 'debug':

  (VTY)# logging level default error
  (VTY)# logging level all unset
  (VTY)# logging level pag debug

Result:

  logging level default error
  logging level pag debug

Finally, let's conclude my ideas in short all in one place:

  - Introduce 'unset' keyword;

  - Introduce self-explaining 'logging level default ...'
    which is aimed to set the (default / global) log
    level of a given logging target (e.g. 'stderr');

  - Modify the behaviour of 'logging level all ...' to
    affect all logging categories (e.g. 'logging level
    all unset' would unset all custom user-defined levels,
    'logging level all error' would sett all to 'error').

P.S. Sorry for 'the default', I hope this explaination is better.

With best regards,
Vadim Yanitskiy.


From laforge at gnumonks.org  Mon Jul 30 20:03:23 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 30 Jul 2018 22:03:23 +0200
Subject: Rationale behind ipa_ccm_idtag_parse_off() ?
In-Reply-To: <20180729105147.GK5720@nataraja>
References: <20180729093341.GI5720@nataraja>
 <B3262DAA-858D-4871-89EF-103322083227@freyther.de>
 <20180729105147.GK5720@nataraja>
Message-ID: <20180730200323.GR30570@nataraja>

Hi Holger,

On Sun, Jul 29, 2018 at 12:51:47PM +0200, Harald Welte wrote:
> On Sun, Jul 29, 2018 at 11:11:13AM +0100, Holger Freyther wrote:
>
> > It seemed it was disobeying a reasonable TLV structure and the closest I found
> > back then seemed to have been this patch? Could you check if the testcase matches
> > an ipaccess-find result?
> 
> Yes, I will check for that.  The test case definitely does not match the IPA CCM
> seen inside OML/RSL from a nanoBTS, not even from the first traces I have from 2010.

I think the solution to the problem is that your test case parses the
IDENTITY REQUESET format, which has 8bit length fields, while the function
is normally (without the offset) used for the IDENTITY RESPONSE packets, where
there are 16bit length fields.

See attached pcap file that I just created.

I'll look into this once I find time and make sure we have test cases for both,
as well as fix the bug about the extraneous byte that my patch
https://gerrit.osmocom.org/#/c/libosmocore/+/10216/ attempts to fix - and which
is required to make external USSD entities in osmo-hlr work.

Regards,
	Harald
-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nanobts-abisip-find.pcap
Type: application/vnd.tcpdump.pcap
Size: 313 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180730/d854d3e6/attachment.bin>

From holger at freyther.de  Mon Jul 30 22:25:47 2018
From: holger at freyther.de (Holger Freyther)
Date: Mon, 30 Jul 2018 23:25:47 +0100
Subject: Rationale behind ipa_ccm_idtag_parse_off() ?
In-Reply-To: <20180730200323.GR30570@nataraja>
References: <20180729093341.GI5720@nataraja>
 <B3262DAA-858D-4871-89EF-103322083227@freyther.de>
 <20180729105147.GK5720@nataraja> <20180730200323.GR30570@nataraja>
Message-ID: <D0E7B162-D0B6-41E8-9688-78FD58865D0F@freyther.de>



> On 30. Jul 2018, at 21:03, Harald Welte <laforge at gnumonks.org> wrote:
> 
> Hi Holger,
> 

Hey!

> I think the solution to the problem is that your test case parses the
> IDENTITY REQUESET format, which has 8bit length fields, while the function
> is normally (without the offset) used for the IDENTITY RESPONSE packets, where
> there are 16bit length fields.

nothing genius in the end just poking in the blind trying to understand a
binary protocol and getting it wrong... When looking at the traces I wondered
if they got \0 termination of strings wrong and didn't consider that
request/response would use different length fields. But 16bit length fields
seem to make sense.

Nice find! We can clean this up in the osmo-bts code as well.


> I'll look into this once I find time and make sure we have test cases for both,
> as well as fix the bug about the extraneous byte that my patch
> https://gerrit.osmocom.org/#/c/libosmocore/+/10216/ attempts to fix - and which
> is required to make external USSD entities in osmo-hlr work.

It looks like we can throw away the entire ipa_ccm_idtag_parse_off and time to
create a TLV_TYPE_L16TV?

holger

From ron.menez at entropysolution.com  Tue Jul 31 02:15:25 2018
From: ron.menez at entropysolution.com (Ron)
Date: Tue, 31 Jul 2018 02:15:25 +0000
Subject: Cell Broadcast Feature
In-Reply-To: <CAPEnp=aF=j0M3rP55dED=fGkRia2mk7HtZBsdBTK0LVQu_ECVw@mail.gmail.com>
References: <CAPEnp=aF=j0M3rP55dED=fGkRia2mk7HtZBsdBTK0LVQu_ECVw@mail.gmail.com>
Message-ID: <33D88F46-008D-437C-903C-5896DE4D586C@entropysolution.com>

Thanks for the info Vadim.

Best Regard,

Ron Menez
ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>

On Jul 31, 2018, at 1:56 AM, Vadim Yanitskiy <axilirator at gmail.com<mailto:axilirator at gmail.com>> wrote:

Hi Ron,

Does anyone tried to use the Cell Broadcast feature in osmo?
Is there specific SDRs that supports this feature?

I have not tried personally, but I would like to clarify one thing.

CBCH is implemented in the higher *software* layers, so it doesn't
depend on a specific SDR device. The problem is that it isn't (yet)
implemented for osmo-bts-trx, a BTS variant for SDR devices...

Moreover, I believe it should be quite easy to implement this,
so any patches are welcome ;)

With best regards,
Vadim Yanitskiy.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180731/9fcfe7cf/attachment.htm>

From ron.menez at entropysolution.com  Tue Jul 31 02:16:26 2018
From: ron.menez at entropysolution.com (Ron)
Date: Tue, 31 Jul 2018 02:16:26 +0000
Subject: Cell Broadcast Feature
In-Reply-To: <20180730182534.GK30570@nataraja>
References: <5EE733C6-39B5-4152-AC36-98987E1D2A93@entropysolution.com>
 <20180730182534.GK30570@nataraja>
Message-ID: <097EDAA8-EF75-4EEC-9B49-255F99A5346A@entropysolution.com>

Noted and thanks for the info as well Harald.

Best Regard,

Ron Menez
ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>




On Jul 31, 2018, at 2:25 AM, Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>> wrote:

Hi Ron,

On Thu, Jul 26, 2018 at 08:39:06AM +0000, Ron wrote:
Does anyone tried to use the Cell Broadcast feature in osmo?
https://osmocom.org/projects/cellular-infrastructure/wiki/Cell_Broadcast

Me (and several others from the Osmocom developers) have used it successfully
in the past.  We demonstrated this many years ago at one of the CCC congresses.

We tested it (AFAIK) with nanoBTS and sysmoBTS.

Is there specific SDRs that supports this feature?

As Vadim has already pointed out, it's not a SDR feature.  THe problem is
osmo-bts-trx (used by all SDR hardware). See http://osmocom.org/issues/1617

Unfortunately, the amount of contributions we get towards osmo-bts-trx is
still lower than compared to other BTS models where the respective BTS vendors
(or some large customers) have a more pressing need to have features supported.

See http://osmocom.org/versions/122 for more TOOD items for osmo-bts-trx
compared to other BTS backends.

--
- Harald Welte <laforge at gnumonks.org<mailto:laforge at gnumonks.org>>           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: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180731/64332736/attachment.htm>