From osmith at sysmocom.de  Tue Feb  5 09:34:04 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Tue, 5 Feb 2019 10:34:04 +0100
Subject: GSUP: E-interface messages for inter-MSC HO
In-Reply-To: <20190114020356.GA12467@my.box>
References: <20190114020356.GA12467@my.box>
Message-ID: <68c91be8-dce9-de0f-65ad-03494d919fa9@sysmocom.de>

On 1/14/19 3:03 AM, Neels Hofmeyr wrote:
> I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho:
> http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/ho

In your draft, you describe the handover_number IE like this:

> handover_number:                    (MSC-A <-- MSC-B, Handover Request Ack)
>         extension: [Extension=0|NoExtension=1] (1 bit; should currently always be == 1)
>         nature_of_nr: [GSM340_TYPE_NATIONAL|GSM340_TYPE_INTERNATIONAL|...] (3 bit)
>         number_plan: GSM340_PLAN_ISDN (4 bit)
>         msisdn: BCD

GSUP already has a msisdn IE:

https://git.osmocom.org/libosmocore/tree/include/osmocom/gsm/gsup.h?id=ae7966d145965452a325a33ca6334b6d6fe061a6#n244
Can we use that, and simplify the handover_number to only have
extension, nature_of_nr and number_plan?

Thanks,
Oliver

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


From laforge at gnumonks.org  Tue Feb  5 10:13:27 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 5 Feb 2019 11:13:27 +0100
Subject: GSUP: E-interface messages for inter-MSC HO
In-Reply-To: <68c91be8-dce9-de0f-65ad-03494d919fa9@sysmocom.de>
References: <20190114020356.GA12467@my.box>
 <68c91be8-dce9-de0f-65ad-03494d919fa9@sysmocom.de>
Message-ID: <20190205101326.GJ24515@nataraja>

Hi Oliver,

On Tue, Feb 05, 2019 at 10:34:04AM +0100, Oliver Smith wrote:
> On 1/14/19 3:03 AM, Neels Hofmeyr wrote:
> > I placed the draft in osmo-msc/doc/interMSC_HO_GSUP_msgs.txt on my branch neels/ho:
> > http://git.osmocom.org/osmo-msc/tree/doc/interMSC_HO_GSUP_msgs.txt?h=neels/ho
> 
> In your draft, you describe the handover_number IE like this:
> 
> > handover_number:                    (MSC-A <-- MSC-B, Handover Request Ack)
> >         extension: [Extension=0|NoExtension=1] (1 bit; should currently always be == 1)
> >         nature_of_nr: [GSM340_TYPE_NATIONAL|GSM340_TYPE_INTERNATIONAL|...] (3 bit)
> >         number_plan: GSM340_PLAN_ISDN (4 bit)
> >         msisdn: BCD
> 
> GSUP already has a msisdn IE:
> 
> https://git.osmocom.org/libosmocore/tree/include/osmocom/gsm/gsup.h?id=ae7966d145965452a325a33ca6334b6d6fe061a6#n244
> Can we use that, and simplify the handover_number to only have
> extension, nature_of_nr and number_plan?

I would argue we should introduce a new "global title" IE which contains
* BCD digits
* nature of address / type of number
* numbering plan indicator

This would basically correspond to a SCCP global title, see osmo_sccp_gt in sccp_sap.h
This is the most flexible way to encode any MSISDN, IMSI, ...

just my thoughts...

-- 
- 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 osmith at sysmocom.de  Tue Feb  5 15:26:54 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Tue, 5 Feb 2019 16:26:54 +0100
Subject: GSUP: E-interface messages for inter-MSC HO
In-Reply-To: <20190205101326.GJ24515@nataraja>
References: <20190114020356.GA12467@my.box>
 <68c91be8-dce9-de0f-65ad-03494d919fa9@sysmocom.de>
 <20190205101326.GJ24515@nataraja>
Message-ID: <859e16e6-ace8-1692-2ce1-c6ab2c6a425e@sysmocom.de>

Hi Harald,

On 2/5/19 11:13 AM, Harald Welte wrote:
> I would argue we should introduce a new "global title" IE which contains
> * BCD digits
> * nature of address / type of number
> * numbering plan indicator
> 
> This would basically correspond to a SCCP global title, see osmo_sccp_gt in sccp_sap.h
> This is the most flexible way to encode any MSISDN, IMSI, ...
> 
> just my thoughts...

this sounds good to me. But I'm also curious about Neels' opinion about
the matter, since he had drafted all these new messages.

Where would the "extension" bit go, if we use the "global title" IE?

Oliver

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


From gullik.webjorn at corevalue.se  Tue Feb  5 15:54:49 2019
From: gullik.webjorn at corevalue.se (Gullik Webjorn)
Date: Tue, 5 Feb 2019 16:54:49 +0100
Subject: Limesdr mini on Orange Pi Zero
In-Reply-To: <e9ad56ee-1f12-88de-ffde-f23f3a02a6e1@corevalue.se>
References: <f9fd9679-6762-59f9-e2d7-ae100b5bf98f@corevalue.se>
 <20190123103914.GP30886@nataraja>
 <3fe3f42b-6b82-25cd-388a-c732b60fea42@corevalue.se>
 <3e8a27ec-d9fa-886f-b201-b0edf18d8e09@corevalue.se>
 <20190126111446.GG3930@nataraja>
 <e9ad56ee-1f12-88de-ffde-f23f3a02a6e1@corevalue.se>
Message-ID: <6f626e2d-b361-4566-f12a-8d041bba9dc0@corevalue.se>

Findings so far:

I changed timing the RXlower thread, measuring the time it takes from 
exiting the
readSamples function in Transceiver, to the entry just before the call 
to the LimeSuite,
and these are the 32 last values in uSeconds :

$1 = {236, 190, 267, 4226, 4173, 5822, 3881, 56079, 7598, 7085, 4959, 
7832, 7808, 7772, 5079, 222, 199, 222, 202, 201, 191, 209, 210, 198, 
211, 188, 203, 175, 239, 177, 215,
 ? 215}??? ( the index is 15? )

The 3 first samples, and the 17 last, shows that it is typically 
possible to execute all code in RXlower ( not including recvStream )
in about 200 uSeconds.

There are 12 values in sequence beginning with 4.226 mS and including 
56.079 mS, where "nonblocking" code is interrupted by
other activity in the Orange Pi Zero / Armbian 9. Whatever this is, it 
runs at greater priority than -19, and causes the FIFO on
board the LimeSDR mini to fill, until we get a report of "dropped by HW".

 From this point the error is not recoverable, and can only be cleared 
by Transceiver restarting ( with new timestamps ).

The conclusion is that there is no problem with Transceiver ( except for 
detection of this condition) and as long as the Transceiver
process gets enough cpu, all works as expected. However "something runs 
for 122 mS" severely degrading the latency. There IS
processing time available for Transceiver, but the reduction in 
available cpu cycles is to severe for proper operation.

The 2500 bytes read corresponds to 625 bits, i.e. 4 slots, for a total 
of 2.307 mS, which is the rate we must keep on average
to keep the LimeSDR happy, we can tolerate several "misses", since we 
can complete the loop in c:a 200 uS, but if the condition
persists to long, the LimeSDR will overwrite it's FIFO, log dropped 
packets, and Transceiver will hit error #3339 or exit.
IF Transceiver *always* got about 200 uS of running time each 2.3 mS we 
would be fine.....

No on to finding the culprit....or just change HW / OS.....this combo 
has lousy RT characteristics.....

Regards,
Gullik

On 2019-01-29 12:20, Gullik Webjorn wrote:
> I have tried to investigate *where* the type #3339 bug occurs. I was 
> thinking in terms either
> Lime hw / fw / driver drops packets, or something screws up the 
> timestamp leading to the
> perception of lost data.
>
> I have added some debug printouts, where LMS_GetStreamStatus is 
> called, and as the error occurs,
> I also get dropped packets. The explanation from the API is that
> droppedPackets = "Number of dropped packets by HW."
>
> To me this indicates that the program / usb driver / usb is not 
> emptying the on board fifo frequently enough,
> and that this is the cause of the problem ( as Harald indicated he 
> suspected )
>
> At least I have convinced myself that:
> 1??? Packets are lost within the Lime board ( since it reports them) 
> and not in the higher levels of code.
> 2??? That it is indeed "lowlevel" i.e. Lime driver or usb driver bug, 
> or just the fact we do not get time to process quick enough,
> ????? which I feel we should have plenty of cpu to compensate for.
>
> Gullik
>
> And yes, we should not confuse bits and symbols :-)
>



From laforge at gnumonks.org  Tue Feb  5 18:03:28 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 5 Feb 2019 19:03:28 +0100
Subject: Limesdr mini on Orange Pi Zero
In-Reply-To: <6f626e2d-b361-4566-f12a-8d041bba9dc0@corevalue.se>
References: <f9fd9679-6762-59f9-e2d7-ae100b5bf98f@corevalue.se>
 <20190123103914.GP30886@nataraja>
 <3fe3f42b-6b82-25cd-388a-c732b60fea42@corevalue.se>
 <3e8a27ec-d9fa-886f-b201-b0edf18d8e09@corevalue.se>
 <20190126111446.GG3930@nataraja>
 <e9ad56ee-1f12-88de-ffde-f23f3a02a6e1@corevalue.se>
 <6f626e2d-b361-4566-f12a-8d041bba9dc0@corevalue.se>
Message-ID: <20190205180328.GR24515@nataraja>

Hi Gullik,

thanks a lot for your excellent analysis and for sharing it here.

It is by far the most in-depth study of LimeSDR<->osmo-trx related
problems that I've seen. Great.

Now the interesting question of course is how to anylyze this further.

Linux has received *tons* of tracing mechanisms during the last decade,
[un]fortuantely I've only read docs/tutorials and never had to use any
of it so far.  But there for sure are tools that allow to analyze where
the latency is coming from.

It may be some particularly nasty driver on your platform.  It may be
thermal throttling due to insufficient cooling of the CPU, ...

I guess you already deactivated virtually anything that's not required
on the system and running in the background?  I'm not so much worried
about other background tasks at normal priorities, but more about what
kind of peripherals they might interact through which device drivers

Another idea is to exclude any influence of the block layer by ensuring
that there are no log files written either directly from osmo-trx, nor
indirectly via stdio redirection / syslog or the like.  Otherwise the
occasional flush to the block device might be a possible cause.

On Tue, Feb 05, 2019 at 04:54:49PM +0100, Gullik Webjorn wrote:
> No on to finding the culprit....or just change HW / OS.....this combo has
> lousy RT characteristics.....

People have observed the same pattern also on other hardware, so finding
a way to systematically debug this kind of issue will help not only on your
particular platform today.

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  Tue Feb  5 23:29:19 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 6 Feb 2019 00:29:19 +0100
Subject: coding style: fixed indenting vs align-with-brace
Message-ID: <20190205232919.GA23979@my.box>

Recently, fixeria brought up that it would be better to not align wrapped lines
with an opening brace, but rather have a constant indent for wrapped lines.

I'd like to ask for the general opinion / kernel style compliance.
What indenting is acceptable?

For a long time my opinion was that opening brace alignment is better for
readability, but my opinion has shifted. I now find it more desirable to keep a
constant indent.

Consider:

unsigned int my_function_signature(int a_very_long_parameter,
				   int wrapped_line,
				   int another_line);

If a patch modifies the return value or the name, the patch either touches
three lines or leaves inconsistent indenting behind:

int my_func(int a_very_long_parameter,
				   int wrapped_line,
				   int another_line);

Also, a very long function name wastes a lot of usable linewidth for indent for
all arguments.

I've submitted a lot of patches over the years that touch more lines than
necessary, and left quite a few inconsistent indents behind, because an
automatic find-replace doesn't fix subsequent indenting.

I'm currently editing a lot of the osmo-msc sources and changing my mind about
API, so this line indenting due to renames issue comes up. I thought I could
pick a constant indent now while I'm at it.

If we had a single tab as indent, the function signatures' indenting would be
independent from the length of the name, and a find-replace leaves behind
consistent indenting / no whitespace changes needed for renames:

unsigned int my_function_signature(int a_very_long_parameter,
	int wrapped_line,
	int another_line);

int my_func(int a_very_long_parameter,
	int wrapped_line,
	int another_line);

I finally understood the vim cindent options to achieve this:

	:se cino=(1s,u1s
	
(Forgive me if this is a bit too vim specific for your taste; I definitely want
vim to automatically give me the desired indenting.)

My problem with that is that it also affects if- and for- statements: 'if' and
'for' will never change their name, so aligning with opening-brace is unlikely
to ever cause unnecessary whitespace change. What was:

// vim: cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(0,u0,/0,:0

int my_func(int a_very_long_parameter,
	    int wrapped_line,
	    int another_line)
{
	if (a_very_long_parameter == 3 || a_very_long_parameter < 0
	    || wrapped_line == 7
	    || (one_level_deeper
		&& (one_level_deeper
		    || foo)))
		return 5;
}

Now becomes:

// vim: cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(1s,u1s,/0,:0

int my_func(int a_very_long_parameter,
	int wrapped_line,
	int another_line)
{
	if (a_very_long_parameter == 3 || a_very_long_parameter < 0
		|| wrapped_line == 7
		|| (one_level_deeper
			&& (one_level_deeper
				|| foo)))
		return 5;
}

(The cino=k0 parameter does control 'if', 'for' and 'while' separately, but
there is no way to tell it to brace-align while the '(' option is set to
'(1s', stupid quirk in cinoptions.)

IMHO aligning with opening brace improves readability of the nested conditions
and uses more of the line width. But I could get used to that, I guess. I think
I've seen this used a lot in Osmocom, too.

Another thing to consider:

	if (a_very_long_parameter == 3 || a_very_long_parameter < 0
		|| wrapped_line == 7)
		return has_same_indent_as_condition(" :/ ");

I could use two tabs for in-brace indenting, but I haven't seen that anywhere
before, and it makes wrapped conditions waste a lot of line width:

// vim: cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(2s,u1s,/0,:0

int my_function_signature(int a_very_long_parameter,
		int wrapped_line,
		int another_line)
{
	if (a_very_long_parameter == 3 || a_very_long_parameter < 0
			|| wrapped_line == 7
			|| (one_level_deeper
				&& (one_level_deeper
					|| foo)))
		return 5;

	if (a_very_long_parameter == 3 || a_very_long_parameter < 0
			|| wrapped_line == 7)
		return 5;
}


I think I'll adopt fixed single-tab indenting in my patches from now on:
:se cino=>1s,e0,f0,{0,}0,=1s,t0,c3,+1s,(1s,u1s,k0,/0,:0

Any (strong) opinions on / best practices for this?
Which one is more consistent with linux kernel style?

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/20190206/5a6c5ff1/attachment.bin>

From nhofmeyr at sysmocom.de  Tue Feb  5 23:52:58 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 6 Feb 2019 00:52:58 +0100
Subject: GSUP: E-interface messages for inter-MSC HO
In-Reply-To: <859e16e6-ace8-1692-2ce1-c6ab2c6a425e@sysmocom.de>
References: <20190114020356.GA12467@my.box>
 <68c91be8-dce9-de0f-65ad-03494d919fa9@sysmocom.de>
 <20190205101326.GJ24515@nataraja>
 <859e16e6-ace8-1692-2ce1-c6ab2c6a425e@sysmocom.de>
Message-ID: <20190205235258.GB23979@my.box>

On Tue, Feb 05, 2019 at 04:26:54PM +0100, Oliver Smith wrote:
> Hi Harald,
> 
> On 2/5/19 11:13 AM, Harald Welte wrote:
> > I would argue we should introduce a new "global title" IE which contains
> > * BCD digits
> > * nature of address / type of number
> > * numbering plan indicator
> > 
> > This would basically correspond to a SCCP global title, see osmo_sccp_gt in sccp_sap.h
> > This is the most flexible way to encode any MSISDN, IMSI, ...
> > 
> > just my thoughts...
> 
> this sounds good to me. But I'm also curious about Neels' opinion about
> the matter, since he had drafted all these new messages.

I thought I had modeled this after the ASN.1 in 3GPP TS 29.002 for
handoverNumber, which says:

	PrepareHO-Res ::= [3] SEQUENCE {
		handoverNumber [0] ISDN-AddressString

and

   ISDN-AddressString ::= AddressString (SIZE (1..maxISDN-AddressLength))
	-- This type is used to represent ISDN numbers.
   maxISDN-AddressLength INTEGER ::= 9

But my GSUP spec is certainly not an ISDN-AddressString.
Instead, I got this from our live inter-MSC handover trace, where I see in
wireshark:

handoverNumber: 91940000000032
    1... .... = Extension: No Extension
    .001 .... = Nature of number: International Number (0x1)
    .... 0001 = Number plan: ISDN/Telephony Numbering (Rec ITU-T E.164) (0x1)
    E.164 number (MSISDN): 490000000023
        Country Code: Germany (49)

Now I'm a bit confused about the discrepancy between the spec's ASN.1 and the
trace we got (notably, also wireshark's dissector).

What we see in the trace seems to match this instead, also 29.002:

AddressString ::= OCTET STRING (SIZE (1..maxAddressLength))
-- This type is used to represent a number for addressing
-- purposes. It is composed of
-- a) one octet for nature of address, and numbering plan indicator.
-- b) digits of an address encoded as TBCD-String.

-- a) The first octet includes a one bit extension indicator, a
-- 3 bits nature of address indicator and a 4 bits numbering
-- plan indicator, encoded as follows:
-- bit 8: 1 (no extension)
--
-- bits 765: nature of address indicator
-- 000 unknown
-- 001 international number
-- 010 national significant number
-- 011 network specific number
-- 100 subscriber number
-- 101 reserved
-- 110 abbreviated number
-- 111 reserved for extension
--
-- bits 4321: numbering plan indicator
--
[...]

> Where would the "extension" bit go, if we use the "global title" IE?

I don't even know what this "1 = Extension: No Extension" is supposed to mean.
Above, it simply defines that the bit should always be 1 and mean "no
extension". wtf. If it's always 1 anyway, it wouldn't matter if we drop it.

Now you know all the facts that I know, I'm currently not certain what would be
the best to do. Can you figure it out?

~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/20190206/56579d8c/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Feb  6 01:06:10 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 6 Feb 2019 02:06:10 +0100
Subject: Build failure of network:osmocom:nightly/libosmocore in
 xUbuntu_18.04/i586
In-Reply-To: <5c5899dfbe4a2_7f84b266009795@build.opensuse.org>
References: <build-e343091e356cb3142912b058976b2c84@build.opensuse.org>
 <5c5899dfbe4a2_7f84b266009795@build.opensuse.org>
Message-ID: <20190206010610.GC23979@my.box>

hopefully fixed by https://gerrit.osmocom.org/c/libosmocore/+/12841

~N

On Mon, Feb 04, 2019 at 08:00:24PM +0000, OBS Notification wrote:
> Visit https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/libosmocore/xUbuntu_18.04/i586
> 
> Package network:osmocom:nightly/libosmocore failed to build in xUbuntu_18.04/i586
> 
> Check out the package for editing:
>   osc checkout network:osmocom:nightly libosmocore
> 
> Last lines of build log:
> [  369s] - --> N (configured as T-2147483648 18446744073709551615 s) rc=0;	state=N T=-2147483648, 2147483647.000000 s remaining
> [  369s] + --> N (configured as T-2147483648 4294967295 s) rc=0;	state=N T=-2147483648, 2147483647.000000 s remaining
> [  369s]  - test T=0:
> [  369s]   --> O (no timer configured for this state)
> [  369s]  - test no timer:
> [  369s]   --> X (no timer configured for this state)
> [  369s]  - test undefined timer, using default_val arg of osmo_tdef_fsm_inst_state_chg(), here passed as 999:
> [  369s] - --> Y (configured as T666 18446744073709551615 -) rc=0;	state=Y T=666, 999.000000 s remaining
> [  369s] + --> Y (configured as T666 4294967295 -) rc=0;	state=Y T=666, 999.000000 s remaining
> [  369s]  - test disallowed transition:
> [  369s]   --> Z (no timer configured for this state)
> [  369s]   --> B (configured as T2 100 ms) rc=0;	state=B T=2, 1.000000 s remaining
> [  369s] 52. testsuite.at:329: 52. tdef (testsuite.at:329): FAILED (testsuite.at:332)
> [  369s] debian/rules:26: recipe for target 'override_dh_auto_test' failed
> [  369s] make[1]: *** [override_dh_auto_test] Error 1
> [  369s] make[1]: Leaving directory '/usr/src/packages/BUILD'
> [  369s] debian/rules:15: recipe for target 'build' failed
> [  369s] make: *** [build] Error 2
> [  369s] dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2
> [  369s] 
> [  369s] cloud122 failed "build libosmocore_1.0.1.26.0fd6.dsc" at Mon Feb  4 19:59:58 UTC 2019.
> [  369s] 
> [  369s] ### VM INTERACTION START ###
> [  372s] [  336.663635] sysrq: SysRq : Power Off
> [  372s] [  336.707211] reboot: Power down
> [  377s] ### VM INTERACTION END ###
> [  377s] 
> [  377s] cloud122 failed "build libosmocore_1.0.1.26.0fd6.dsc" at Mon Feb  4 20:00:06 UTC 2019.
> [  377s] 
> 
> -- 
> Configure notifications at https://build.opensuse.org/user/notifications
> openSUSE Build Service (https://build.opensuse.org/)

-- 
- 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/20190206/fd11662d/attachment.bin>

From gullik.webjorn at corevalue.se  Wed Feb  6 09:05:44 2019
From: gullik.webjorn at corevalue.se (Gullik Webjorn)
Date: Wed, 6 Feb 2019 10:05:44 +0100
Subject: Limesdr mini on Orange Pi Zero
In-Reply-To: <20190205180328.GR24515@nataraja>
References: <f9fd9679-6762-59f9-e2d7-ae100b5bf98f@corevalue.se>
 <20190123103914.GP30886@nataraja>
 <3fe3f42b-6b82-25cd-388a-c732b60fea42@corevalue.se>
 <3e8a27ec-d9fa-886f-b201-b0edf18d8e09@corevalue.se>
 <20190126111446.GG3930@nataraja>
 <e9ad56ee-1f12-88de-ffde-f23f3a02a6e1@corevalue.se>
 <6f626e2d-b361-4566-f12a-8d041bba9dc0@corevalue.se>
 <20190205180328.GR24515@nataraja>
Message-ID: <655fcb01-181f-0ad0-5fae-bf57d184358c@corevalue.se>

Closing this thread.

On 2019-02-05 19:03, Harald Welte wrote:
> It may be some particularly nasty driver on your platform.  It may be
> thermal throttling due to insufficient cooling of the CPU, ...
>

> Regards,
> 	Harald
Well, now the puzzle is solved for this platform. The Orange Pi Zero in 
conjunction
with Armbian has a cpu temperature governor. Reducing the max cpu speed down
to 816 Mhz, the cpu utilization goes up, to 200% ( out of 400 ). This 
lowers the
temperature by c:a 10 C. When the cpu temperature exceeds some value, the
governor downshifts clock, and execution of Transceiver is disturbed, 
and I am now convinced
this is the cause of the problem with this platform.

It does not make complete sense from a mathematical point of view, but I 
do not have the
insight into the inner workings of the "governor".? Reducing the maximum 
rate and increasing
the minimum rate I have reached stability over night. A heat sink has 
also been added to the cpu.
Using armbianmonitor -m, the critical temperature seems to be c:a 65 C.

MY earlier observations is that the bug was hit "randomly" , sometimes 
after 30 seconds, sometimes
not for several hours. This randomness is most probably due to room 
temperature, drafts from entering
or exiting the lab and air flow around the system.

With regards to osmo-bts software, the changes I propose are:

1)??? ALARM LOG in

void LMSDevice::update_stream_stats(size_t chan, bool * underrun, bool * 
overrun)
{
 ??? lms_stream_status_t status;
 ??? if (LMS_GetStreamStatus(&m_lms_stream_rx[chan], &status) == 0) {
 ??? ??? if (status.underrun > m_last_rx_underruns[chan])
 ??? ??? ??? *underrun = true;
 ??? ??? m_last_rx_underruns[chan] = status.underrun;

 ??? ??? if (status.overrun > m_last_rx_overruns[chan])
 ??? ??? ??? *overrun = true;
 ??? ??? m_last_rx_overruns[chan] = status.overrun;
*// if the radio drops packets it is good information to know it, this 
is a FATAL condition with regards to stable operation of Transceiver 
this + 4 more lines**
**??? ??? if (status.droppedPackets != 0) {**
**??? ??? ??? dropped = dropped + status.droppedPackets;**
**??? ??? ??? LOGC(DDEV, ALERT) << "Dropped " << status.droppedPackets 
<< " Total dropped " << dropped;**
**??? ??? }*
 ??? }
}

2) Possibly causing this condition to either cause Transceiver exit or 
controlled restart ( which happens anyway, but many seconds later )

Now on to "balancing LimeSDR up/down links"......

Regards,

Gullik




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

From mykola at pentonet.com  Wed Feb  6 11:03:06 2019
From: mykola at pentonet.com (Mykola Shchetinin)
Date: Wed, 6 Feb 2019 13:03:06 +0200
Subject: Osmo-SGSN/3G PS unstable behavior question
Message-ID: <CANm+YgmeeoJWZFhbNUFgJpcgWHWsTS4D91CHdi5KUihiKFDoNQ@mail.gmail.com>

Hello, dear Osmocom community,

Has somebody been looking at the issue https://osmocom.org/issues/1977 recently?

Or, in other words: has anybody got the 3G Packet Switched network
working in Osmocom reliably?

I am looking for hints that might help me to fix the issue or for
possible hacks/fixes if somebody has implemented something like that
in their setups.

Thank you!

Kind regards, Mykola


From nhofmeyr at sysmocom.de  Wed Feb  6 12:25:10 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 6 Feb 2019 13:25:10 +0100
Subject: Osmo-SGSN/3G PS unstable behavior question
In-Reply-To: <CANm+YgmeeoJWZFhbNUFgJpcgWHWsTS4D91CHdi5KUihiKFDoNQ@mail.gmail.com>
References: <CANm+YgmeeoJWZFhbNUFgJpcgWHWsTS4D91CHdi5KUihiKFDoNQ@mail.gmail.com>
Message-ID: <20190206122510.GB7826@my.box>

On Wed, Feb 06, 2019 at 01:03:06PM +0200, Mykola Shchetinin wrote:
> Has somebody been looking at the issue https://osmocom.org/issues/1977 recently?
> 
> Or, in other words: has anybody got the 3G Packet Switched network
> working in Osmocom reliably?

Nothing implemented or analysed from my side, only vague ideas and nothing to
show for it... Would be really great if that were resolved.

~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/20190206/d5cec8b4/attachment.bin>

From laforge at gnumonks.org  Wed Feb  6 12:34:02 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 6 Feb 2019 13:34:02 +0100
Subject: coding style: fixed indenting vs align-with-brace
In-Reply-To: <20190205232919.GA23979@my.box>
References: <20190205232919.GA23979@my.box>
Message-ID: <20190206123401.GB31017@nataraja>

Hi Neels,

On Wed, Feb 06, 2019 at 12:29:19AM +0100, Neels Hofmeyr wrote:
> I'd like to ask for the general opinion / kernel style compliance.
> What indenting is acceptable?

My personal opinion is that the indent should match the opening brace, or
at least the nearest tab very close to it.

In the kernel (thought I don't spend much time in it anymore) I haven't
seen anything else but opening brace.

I would appreciate if we could keep it that way and focus our energy on actual
implementation work.  Of course, if you guys want to discuss it, you are free.
The above is just my point of view.

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  Wed Feb  6 14:44:39 2019
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Wed, 6 Feb 2019 21:44:39 +0700
Subject: coding style: fixed indenting vs align-with-brace
In-Reply-To: <20190206123401.GB31017@nataraja>
References: <20190205232919.GA23979@my.box> <20190206123401.GB31017@nataraja>
Message-ID: <CAPEnp=Y=ckO8MXjOHdAyRid08nAYzKBZc7Skz8Bw-8t8iWcZng@mail.gmail.com>

Hi Neels,

> Recently, fixeria brought up that it would be better to not
> align wrapped lines with an opening brace [...]

as you've already mentioned, I am not a big fun of such alignment.
IMHO, this coding style neither improves nor decreases the total
readability - it's just the matter of taste.

Why don't we align variable assignments then? Like this:

struct msgb   *msg     = (struct msgb *) data;
unsigned long  msg_len = msgb_length(msg);
uint8_t       *ptr     = msg->data + 3;

Yes, it's aligned, but is it easier to read? Thanks to the code
highlighting, I don't see significant readability changes. But,
if we add a new variable with longer length, we would have to
realign all surrounding definitions. So, as a result we have
~same readability, but additional responsibility?

At the same time, I like the alignment we use for value_string
definitions, and for osmo_fsm definitions, because it actually
changes the readability in a better way, and doesn't require
us to realign everything in the most cases.

> My problem with that is that it also affects if- and for-
> statements: 'if' and 'for' will never change their name, so
> aligning with opening-brace is unlikely to ever cause
> unnecessary whitespace change.

Agree, for both mentioned statements we really need to distinguish
between their body and their definition, otherwise e.g. a wrapped
part of some condition may look like a part of the code to be
executed. But, there is no such problem for function definitions.

> Any (strong) opinions on / best practices for this?

Sure, we should focus on actual implementation work, but since this
question arises from time to time during this implementation work,
let's discuss it once and for all.

I would like to propose some of my ideas:

1. let's don't enforce the "opening brace alignment" during code review;
1.a. if a new file is to be introduced, the alignment style is up to the author;
1.b. the alignment style should be consistent in the whole file,
1.b. ... but if the function name is too long, let's allow a single tab;

2. let's avoid the "opening brace alignment" for the function calls, e.g.

   vty_out(vty,
           "Alignment makes out code great ...\n");

   let's just use a single tab.

3. we should neither submit patches like "align function definitions",
   nor "use a single space for alignment" to the existing code;
3.a. excepting the cases, when arguments left misaligned after the
     function name change and look ugly after that;

With best regards,
Vadim Yanitskiy.


From osmith at sysmocom.de  Wed Feb  6 15:22:50 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Wed, 6 Feb 2019 16:22:50 +0100
Subject: GSUP: E-interface messages for inter-MSC HO
In-Reply-To: <20190205235258.GB23979@my.box>
References: <20190114020356.GA12467@my.box>
 <68c91be8-dce9-de0f-65ad-03494d919fa9@sysmocom.de>
 <20190205101326.GJ24515@nataraja>
 <859e16e6-ace8-1692-2ce1-c6ab2c6a425e@sysmocom.de>
 <20190205235258.GB23979@my.box>
Message-ID: <0ad9afd9-55c4-36c9-4320-f00805502fa0@sysmocom.de>

On 2/6/19 12:52 AM, Neels Hofmeyr wrote:
> Now you know all the facts that I know, I'm currently not certain what would be
> the best to do. Can you figure it out?

After looking into the Wireshark dissector code, I came to the
conclusion that the ISDN-AddressString is exactly what you are seeing in
the dump. Furthermore, it is the same as the MSISDN.

Then I've looked up the existing MSISDN IE in the GSUP spec [1]:

> ISDN-AddressString / MSISDN / Called Party BCD Number
> 
> The MSISDN is encoded as an ISDN-AddressString in 3GPP TS 09.02 and Called Party
> BCD Number in 3GPP TS 04.08. It will be stored by the SGSN or VLR and then passed as is
> to the GGSN during the activation of the primary PDP Context.

(It also has a graph that looks like what you see in Wireshark.)

So my conclusion is, that we can just drop the handover_number IE and
use the existing msisdn_enc IE instead.

Regards,
Oliver

[1]:
https://git.osmocom.org/osmo-gsm-manuals/tree/common/chapters/gsup.adoc?id=68bbdc5f02d891133123573c422202f61923ebdf#n1062

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


From nhofmeyr at sysmocom.de  Wed Feb  6 18:12:28 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 6 Feb 2019 19:12:28 +0100
Subject: coding style: fixed indenting vs align-with-brace
In-Reply-To: <CAPEnp=Y=ckO8MXjOHdAyRid08nAYzKBZc7Skz8Bw-8t8iWcZng@mail.gmail.com>
References: <20190205232919.GA23979@my.box> <20190206123401.GB31017@nataraja>
 <CAPEnp=Y=ckO8MXjOHdAyRid08nAYzKBZc7Skz8Bw-8t8iWcZng@mail.gmail.com>
Message-ID: <20190206181228.GA5406@my.box>

On Wed, Feb 06, 2019 at 09:44:39PM +0700, Vadim Yanitskiy wrote:
> 1. let's don't enforce the "opening brace alignment" during code review;

If we decided on this, then the next one would be a problem:

> 1.a. if a new file is to be introduced, the alignment style is up to the author;

I will not change my cinoptions according to .c file, I will pick one style and
always use that. The only way I would accept to adopt single-tab indent would
be to allow it anywhere, even when mixing style in files; i.e. allow both.

I still agree that a single-tab indenting is better for using the line width
and for having less whitespace changes in patches. I also have a number of
other preferences in coding style.

But in coding style questions, I'm taking Harald's and Holger's opinions as the
benchmark and last word on things...  So I guess it was worth a try, but I'll
just continue as before, then.

~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/20190206/8ac669b4/attachment.bin>

From holger at freyther.de  Thu Feb  7 11:05:23 2019
From: holger at freyther.de (Holger Freyther)
Date: Thu, 7 Feb 2019 11:05:23 +0000
Subject: coding style: fixed indenting vs align-with-brace
In-Reply-To: <20190206123401.GB31017@nataraja>
References: <20190205232919.GA23979@my.box> <20190206123401.GB31017@nataraja>
Message-ID: <CDE76D90-247B-4F99-BA90-DE8508B50BD0@freyther.de>



> On 6. Feb 2019, at 12:34, Harald Welte <laforge at gnumonks.org> wrote:
> 

> I would appreciate if we could keep it that way and focus our energy on actual
> implementation work.  Of course, if you guys want to discuss it, you are free.
> The above is just my point of view.

I have been using clang-format for a while. It is quite relieving to just type and let the tool format the code according to the agreed style. We can use the kernel .clang-format and modify it for our changes.

This can be integrated into the jenkins tests to fail verification if clang-format would introduce a diff.

holger

From osmith at sysmocom.de  Thu Feb  7 11:12:23 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Thu, 7 Feb 2019 12:12:23 +0100
Subject: coding style: fixed indenting vs align-with-brace
In-Reply-To: <CDE76D90-247B-4F99-BA90-DE8508B50BD0@freyther.de>
References: <20190205232919.GA23979@my.box> <20190206123401.GB31017@nataraja>
 <CDE76D90-247B-4F99-BA90-DE8508B50BD0@freyther.de>
Message-ID: <520f0e40-210c-4a3b-b009-28d46264cd52@sysmocom.de>

On 2/7/19 12:05 PM, Holger Freyther wrote> I have been using
clang-format for a while. It is quite relieving to just type and let the
tool format the code according to the agreed style. We can use the
kernel .clang-format and modify it for our changes.
> 
> This can be integrated into the jenkins tests to fail verification if clang-format would introduce a diff.

This would be my favorite approach, especially with enforcing through
jenkins.

Oliver

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


From mykola at pentonet.com  Thu Feb  7 13:39:29 2019
From: mykola at pentonet.com (Mykola Shchetinin)
Date: Thu, 7 Feb 2019 15:39:29 +0200
Subject: Neighboring femtocells
Message-ID: <CANm+YgkoUow5pFDVk=xAYmmr5RxsTABCrwCepSaeRe43K2r7Tg@mail.gmail.com>

Dear Osmocom community,

Does somebody have experience using multiple 3G femtocells connected to a single
HNBGW? Do cell reselection and handover work properly? How did you configure it?

Also, Osmocom (or Syscmocom?) used 3G networks at Congress 35c3. Were you using
multiple femtocells?

Were they connected to the same HNBGW? How did you configure them for cell
reselection and handover to work smoothly?

Thank you!

Kind regards, Mykola


From nhofmeyr at sysmocom.de  Thu Feb  7 14:43:08 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 7 Feb 2019 15:43:08 +0100
Subject: Neighboring femtocells
In-Reply-To: <CANm+YgkoUow5pFDVk=xAYmmr5RxsTABCrwCepSaeRe43K2r7Tg@mail.gmail.com>
References: <CANm+YgkoUow5pFDVk=xAYmmr5RxsTABCrwCepSaeRe43K2r7Tg@mail.gmail.com>
Message-ID: <20190207144308.GA2835@ass40.box>

On Thu, Feb 07, 2019 at 03:39:29PM +0200, Mykola Shchetinin wrote:
> Dear Osmocom community,
> 
> Does somebody have experience using multiple 3G femtocells connected to a single
> HNBGW? Do cell reselection and handover work properly? How did you configure it?
> 
> Also, Osmocom (or Syscmocom?) used 3G networks at Congress 35c3. Were you using
> multiple femtocells?
> 
> Were they connected to the same HNBGW? How did you configure them for cell
> reselection and handover to work smoothly?

35c3 GSM team used multiple femto cells, but handover requires MSC
interaction (inter-"BSC" or inter-RAT handover procedures) which I am only
just adding to osmo-msc now, in the course of inter-MSC handover support.

So we simply attached N nano3G to a single hnbgw and the msc, and did not
support 3G handover.

Once we might support that: I'm not sure how to tell a nano3G about
neighbors, nor am I sure about 3G handover procedures. I know though that
the RTP is forwarded femto <-> MSC, so *something* needs to switch it.

Cell reselection should work AFAICT, though I didn't test for that
specifically. What I did see working well on 35c3 is that a phone for
which the CN disallowed 3G access camped over to 2G and vice versa.

~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/20190207/6d9f534b/attachment.bin>

From msuraev at sysmocom.de  Thu Feb  7 14:51:02 2019
From: msuraev at sysmocom.de (Max)
Date: Thu, 7 Feb 2019 15:51:02 +0100
Subject: coding style: fixed indenting vs align-with-brace
In-Reply-To: <CDE76D90-247B-4F99-BA90-DE8508B50BD0@freyther.de>
References: <20190205232919.GA23979@my.box> <20190206123401.GB31017@nataraja>
 <CDE76D90-247B-4F99-BA90-DE8508B50BD0@freyther.de>
Message-ID: <2f1838e9-4abd-26f6-959b-78c4a715a270@sysmocom.de>

Hi.

In general though, I'm pretty happy with the current alignment we use 
right now because my editor automatically does that for me. Yes, some 
patches changing only some of the parameters might introduce 
inconsistencies but it doesn't seem like a big deal to me. Either 
relaxing patch review to allow realignment in the same patch as 
functional change or having separate cosmetic patch would fix that.

So personally I don't see any need to change anything right now.

07.02.19 12:05, Holger Freyther ?????:
>
> I have been using clang-format for a while. It is quite relieving to just type and let the tool format the code according to the agreed style. We can use the kernel .clang-format and modify it for our changes.
>
> This can be integrated into the jenkins tests to fail verification if clang-format would introduce a diff.
>
> holger

Wouldn't we need to fix formatting of all the files first?

Otherwise patches fixing current "incorrect" formatting to whatever we 
agree on would fail the tests.

-- 
- Max Suraev <msuraev 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 Directors: Harald Welte



From laforge at gnumonks.org  Fri Feb  8 08:06:04 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 8 Feb 2019 09:06:04 +0100
Subject: coding style: fixed indenting vs align-with-brace
In-Reply-To: <CDE76D90-247B-4F99-BA90-DE8508B50BD0@freyther.de>
References: <20190205232919.GA23979@my.box> <20190206123401.GB31017@nataraja>
 <CDE76D90-247B-4F99-BA90-DE8508B50BD0@freyther.de>
Message-ID: <20190208080604.GD32225@nataraja>

Hi Holger,

I'm personally not convinced any related tools would improve my personal workflow,
but if it helps others, I'm of course happy about related suggestions.

On Thu, Feb 07, 2019 at 11:05:23AM +0000, Holger Freyther wrote:
> This can be integrated into the jenkins tests to fail verification if clang-format would introduce a diff.

wireshark has somwthing like a pre-commit hook in their repository that
prevents you from even pushing changes that don't pass validation (such
as non-terminated value_string arrays). I've never studied it in detail
how they do it, but it works out of the box after cloning the
repository.  I don't recall having to manually configure something to
get this.

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  Fri Feb  8 21:21:25 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 8 Feb 2019 22:21:25 +0100
Subject: coding style: fixed indenting vs align-with-brace
In-Reply-To: <20190208080604.GD32225@nataraja>
References: <20190205232919.GA23979@my.box> <20190206123401.GB31017@nataraja>
 <CDE76D90-247B-4F99-BA90-DE8508B50BD0@freyther.de>
 <20190208080604.GD32225@nataraja>
Message-ID: <20190208212125.GB11249@my.box>

On Fri, Feb 08, 2019 at 09:06:04AM +0100, Harald Welte wrote:
> wireshark has somwthing like a pre-commit hook in their repository that
> prevents you from even pushing changes that don't pass validation (such
> as non-terminated value_string arrays).

probably a pre-push hook in the upstream repos.
Things like coding style / value strings validation would be ok for that.
(obviously not full CI runs that take minutes and longer)

Also I wonder whether gerrit's java git stack allows having a pre-push hook.

I kind of like the idea of using a code formatting linter,
it (hopefully) completely cuts out all discussion.

I remember some blog post about that ... don't know where. The point was, any
and all of these little things should be enforced by CI, it creates a clear
situation and cuts out endless discussions.

Would be trivial to run a code reformatting command before submitting to
gerrit.

However, the hard part would be to get a reliable code formatter that doesn't
do nonsense. For example, I think dexter once used such tool that produced a
bit of nonsense indenting / formatting every now and then.

But... I'm heading back to inter-MSC handover now.

~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/20190208/802863c8/attachment.bin>

From pespin at sysmocom.de  Fri Feb  8 22:34:41 2019
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Fri, 8 Feb 2019 23:34:41 +0100
Subject: coding style: fixed indenting vs align-with-brace
In-Reply-To: <20190208212125.GB11249@my.box>
References: <20190205232919.GA23979@my.box> <20190206123401.GB31017@nataraja>
 <CDE76D90-247B-4F99-BA90-DE8508B50BD0@freyther.de>
 <20190208080604.GD32225@nataraja> <20190208212125.GB11249@my.box>
Message-ID: <80c1bcb0-a6d6-84bd-df89-46ad3e96b0f1@sysmocom.de>

Hi,

I used to work in an environment where we used uncrustify [1] to check 
formatting during CI time (github + jenkins iirc).

In general it worked quite well but sometimes indeed it did some 
unexpected stuff.

So I'd say I'm not for or against using this kind of tooling during CI 
to check formatting. It has good stuff (avoid adding whitespace 
artifacts and bad formatting), but on the other side it has issues (more 
time spent on formatting, sometimes it adds its own formatting artifacts).

Furthermore, that means probably we need to run it once over all the 
code base and submit patches to fix it so we can then use it as a base 
to check the changes.

[1] http://uncrustify.sourceforge.net/

-- 
- 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 gullik.webjorn at corevalue.se  Tue Feb 12 11:17:40 2019
From: gullik.webjorn at corevalue.se (Gullik Webjorn)
Date: Tue, 12 Feb 2019 12:17:40 +0100
Subject: osmo-bsc show connections
Message-ID: <fda1a087-d4eb-81f6-33cf-b3cb3afedf6d@corevalue.se>

Hi,

I cannot find a description of this command in the manual. This is very 
useful to debug
ms, antennas and radio.

OsmoBSC> show conn
Active subscriber connections:
conn ID=232, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1 at mgw
BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F
 ? Connection: 1, State: ESTABLISHED
 ? BS Power: 0 dBm, MS Power: 10 dBm
 ? Channel Mode / Codec: SPEECH_V1
 ? No Subscriber
 ? Bound IP: 192.168.1.75 Port 16404 RTP_TYPE2=0 CONN_ID=0
 ? Conn. IP: 192.168.1.70 Port 4084 RTP_TYPE=3 SPEECH_MODE=0x00
 ? Measurement Report:
 ??? Flags:
 ??? MS Timing Offset: 0
 ??? L1 MS Power: 10 dBm, Timing Advance: 4
 ??? RXL-FULL-dl:? -73 dBm, RXL-SUB-dl:? -73 dBm RXQ-FULL-dl: 0, 
RXQ-SUB-dl: 0
 ??? RXL-FULL-ul:? -57 dBm, RXL-SUB-ul:? -58 dBm RXQ-FULL-ul: 0, 
RXQ-SUB-ul: 0

I guess "dl" means downlink, from BTS to MS, and "ul" means uplink, MS 
to BTS.

But, what is the difference between FULL and SUB ? What does the two 
rightmost items mean,
those which are 0 in the above? What does the "No Subscriber" mean, 
should that be IMSI ?

Still on the subject of LimeSDR Mini, now debugging radio and antenna 
arrangements.

Regards,
Gullik


From nhofmeyr at sysmocom.de  Tue Feb 12 13:44:20 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 12 Feb 2019 14:44:20 +0100
Subject: osmo-bsc show connections
In-Reply-To: <fda1a087-d4eb-81f6-33cf-b3cb3afedf6d@corevalue.se>
References: <fda1a087-d4eb-81f6-33cf-b3cb3afedf6d@corevalue.se>
Message-ID: <20190212134420.GA31343@my.box>

I can answer one of the questions:

On Tue, Feb 12, 2019 at 12:17:40PM +0100, Gullik Webjorn wrote:
> What does the "No Subscriber" mean, should
> that be IMSI ?

Yes.

osmo-bsc doesn't know the subscriber's IMSI most of the time: the L3 containing
it mostly passes through. There is a message to officially tell osmo-bsc the
IMSI (Common Id) but so far we are not sending it from osmo-msc...

https://osmocom.org/issues/2969

~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/20190212/ed3b79eb/attachment.bin>

From k at rhizomatica.org  Tue Feb 12 15:50:11 2019
From: k at rhizomatica.org (k at rhizomatica.org)
Date: Tue, 12 Feb 2019 15:50:11 +0000
Subject: osmo-bsc show connections
In-Reply-To: <fda1a087-d4eb-81f6-33cf-b3cb3afedf6d@corevalue.se>
References: <fda1a087-d4eb-81f6-33cf-b3cb3afedf6d@corevalue.se>
Message-ID: <8DDD0461-2B32-4B6E-937D-2B5AA1160276@rhizomatica.org>

http://www.telecomsource.net/showthread.php?293-What-is-the-diffrerence-between-FULL-and-SUB-values

Ah.. internet...
?

On February 12, 2019 11:17:40 AM UTC, Gullik Webjorn <gullik.webjorn at corevalue.se> wrote:
>Hi,
>
>I cannot find a description of this command in the manual. This is very
>
>useful to debug
>ms, antennas and radio.
>
>OsmoBSC> show conn
>Active subscriber connections:
>conn ID=232, MSC=0, hodec2_fail=0, mgw_ep=rtpbridge/1 at mgw
>BTS 1, TRX 0, Timeslot 1, Lchan 0: Type TCH_F
> ? Connection: 1, State: ESTABLISHED
> ? BS Power: 0 dBm, MS Power: 10 dBm
> ? Channel Mode / Codec: SPEECH_V1
> ? No Subscriber
> ? Bound IP: 192.168.1.75 Port 16404 RTP_TYPE2=0 CONN_ID=0
> ? Conn. IP: 192.168.1.70 Port 4084 RTP_TYPE=3 SPEECH_MODE=0x00
> ? Measurement Report:
> ??? Flags:
> ??? MS Timing Offset: 0
> ??? L1 MS Power: 10 dBm, Timing Advance: 4
> ??? RXL-FULL-dl:? -73 dBm, RXL-SUB-dl:? -73 dBm RXQ-FULL-dl: 0, 
>RXQ-SUB-dl: 0
> ??? RXL-FULL-ul:? -57 dBm, RXL-SUB-ul:? -58 dBm RXQ-FULL-ul: 0, 
>RXQ-SUB-ul: 0
>
>I guess "dl" means downlink, from BTS to MS, and "ul" means uplink, MS 
>to BTS.
>
>But, what is the difference between FULL and SUB ? What does the two 
>rightmost items mean,
>those which are 0 in the above? What does the "No Subscriber" mean, 
>should that be IMSI ?
>
>Still on the subject of LimeSDR Mini, now debugging radio and antenna 
>arrangements.
>
>Regards,
>Gullik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190212/4dae21af/attachment.htm>

From gullik.webjorn at corevalue.se  Tue Feb 12 19:05:54 2019
From: gullik.webjorn at corevalue.se (Gullik Webjorn)
Date: Tue, 12 Feb 2019 20:05:54 +0100
Subject: osmo-bsc show connections
In-Reply-To: <20190212134420.GA31343@my.box>
References: <fda1a087-d4eb-81f6-33cf-b3cb3afedf6d@corevalue.se>
 <20190212134420.GA31343@my.box>
Message-ID: <fce22bcb-5fff-797e-e841-143a93be6ef6@corevalue.se>

Thanks,

I think it would be useful to snoop the IMSI or pass it downstream from 
MSC, at least
for debugging / logging purposes. I am lucky to just try ONE phone at 
the time...

Gullik

On 2019-02-12 14:44, Neels Hofmeyr wrote:
> I can answer one of the questions:
>
> On Tue, Feb 12, 2019 at 12:17:40PM +0100, Gullik Webjorn wrote:
>> What does the "No Subscriber" mean, should
>> that be IMSI ?
> Yes.
>
> osmo-bsc doesn't know the subscriber's IMSI most of the time: the L3 containing
> it mostly passes through. There is a message to officially tell osmo-bsc the
> IMSI (Common Id) but so far we are not sending it from osmo-msc...
>
> https://osmocom.org/issues/2969
>
> ~N



From gullik.webjorn at corevalue.se  Tue Feb 12 19:06:39 2019
From: gullik.webjorn at corevalue.se (Gullik Webjorn)
Date: Tue, 12 Feb 2019 20:06:39 +0100
Subject: osmo-bsc show connections
In-Reply-To: <8DDD0461-2B32-4B6E-937D-2B5AA1160276@rhizomatica.org>
References: <fda1a087-d4eb-81f6-33cf-b3cb3afedf6d@corevalue.se>
 <8DDD0461-2B32-4B6E-937D-2B5AA1160276@rhizomatica.org>
Message-ID: <2a53cc78-e435-0bb5-e44e-c454d945bf94@corevalue.se>

Thanks for the pointer,

Regards,

Gullik

On 2019-02-12 16:50, k at rhizomatica.org wrote:
> http://www.telecomsource.net/showthread.php?293-What-is-the-diffrerence-between-FULL-and-SUB-values
>



From laforge at gnumonks.org  Tue Feb 12 20:59:23 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 12 Feb 2019 21:59:23 +0100
Subject: osmo-bsc show connections
In-Reply-To: <fce22bcb-5fff-797e-e841-143a93be6ef6@corevalue.se>
References: <fda1a087-d4eb-81f6-33cf-b3cb3afedf6d@corevalue.se>
 <20190212134420.GA31343@my.box>
 <fce22bcb-5fff-797e-e841-143a93be6ef6@corevalue.se>
Message-ID: <20190212205923.GC13854@nataraja>

Hi Gullik,

On Tue, Feb 12, 2019 at 08:05:54PM +0100, Gullik Webjorn wrote:

> I think it would be useful to snoop the IMSI or pass it downstream from MSC,
> at least for debugging / logging purposes. I am lucky to just try ONE phone at the time...

Sure.

It's simply not been a priority for anyone working on the code so far :/

We'd be very happy to receive and merge related patches.  The most
"proper" way to do it in line with the specs is to implement the "Common
ID" procedure where the MSC informs the BSC of the IMSI very early after
establishing the SCCP connection.  If that's implemented in both OsmoMSC
and OsmoBSC, it would work reliably at least for this most common use
case.

-- 
- 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 akibsayyed at gmail.com  Wed Feb 13 08:04:56 2019
From: akibsayyed at gmail.com (Akib Sayyed)
Date: Wed, 13 Feb 2019 13:34:56 +0530
Subject: iPhone X and openbsc
Message-ID: <CAMG-S90-J3AUVFCuau5fjRiCYaHCoSqfwDvUgvwNwe61PDfp2Q@mail.gmail.com>

Hi list
Did any1 tested iPhone X and openbsc
I am struggling to get it work. iPhone don't show network.
Other phone is working fine.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20190213/52db9ac8/attachment.htm>

From laforge at gnumonks.org  Wed Feb 13 13:20:40 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 13 Feb 2019 14:20:40 +0100
Subject: OML bringup bugs and compatibility
Message-ID: <20190213132040.GD16305@nataraja>

Dear Osmocom community,

It has recently been uncovered that there are some problems in the OML bringup
sequence between OsmoBSC and OsmoBTS.

Basically, the core of the issue circulates around the RADIO CARRIER managed object.
* OsmoBTS is accepting OPSTART even though no attributes (such as ARFCN) are set
* OsmoBSC is sending OPSTART twice for this MO, while it's only sending it once
  for all other MOs

The problem now is: If we "fix" the BTS side to reject the OPSTART without
prior SET RADIO CARRIER ATTRIBUTES, then older OsmoBSC will stop to work with
newer OsmoBTS.

The underlying issue is that if we OPSTART the transceiver before setting the ARFCN,
then the later setting of attributes is no longer going to do anything, as the radio
has already started with "ARFCN 0".

TS 12.21 is not very clear on *when* attributes are permitted to be set.
The MO can be either locked or unlocked, or it can be enabled or not...
My idea so far was that if you want to change attributes of a MO (such
as the ARFCN), you need to first bring it down somehow (e.g. set it to
"locked"), then make the change and finally bring it online again.

A bit of playing with a nanoBTS revealed that it actually permits the
OPSTART not only before the attributes are set, but also before the
software has even been activated for that MO.  This makes no sense
whatsoever, though.

More details in: https://osmocom.org/issues/3789 and https://osmocom.org/issues/3782,
particularly the last few updates to those tickets.

Any ideas?

-- 
- 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 gullik.webjorn at corevalue.se  Wed Feb 13 16:08:36 2019
From: gullik.webjorn at corevalue.se (Gullik Webjorn)
Date: Wed, 13 Feb 2019 17:08:36 +0100
Subject: LimeSDR rx level and quality
Message-ID: <d373d12f-1899-ddd9-27d5-264e2baf6dae@corevalue.se>

The values reported by the "show connections" command seem suspect to 
me. I frequently have a uplink
value of around -60 dBm, but RXQ values showing 1-4 or so. While I move 
about a lot, I anticipate fading,
but there seems to be a too big BER when compared with the "healthy" 
signal level.

When testing ul / dl on the Mini, I found values that reasonably well 
corresponded between spectrum
analyzer and "show connections".

The downlink is, I assume, reported by the MS. The question comes up how 
to verify the relatively "new"
LimeSDR Mini / and the osmo-trx-lms with regards to this issue.

I have made some improvements to the TX, and now have a nice +10 - +17 
dBm signal which is indicated
by the phones. I have more than 100 m range with regards to the phones ( 
crappy ? ) bargraph indicator,
at least 2 bars in the periphery, and always 5 bars inside the house / 
lab. Antennas are inside, and the house
made of timber. However, reception seems to be the limiting factor right 
now.

Q: I have deduced that RXQ is referenced in abis_rsl.c in the bsc, is it 
just propagated from the sdr up
through Transceiver, where is the actual evaluation done?

Other thoughts on this....

Regards,
Gullik



From gullik.webjorn at corevalue.se  Wed Feb 13 18:24:40 2019
From: gullik.webjorn at corevalue.se (Gullik Webjorn)
Date: Wed, 13 Feb 2019 19:24:40 +0100
Subject: BTS logging RTP clock out of synch...
Message-ID: <7b735a2f-2397-9b79-0a34-8089844b9f04@corevalue.se>

<000e> l1sap.c:144 RTP clock out of sync with lower layer: 2240 vs 160 
(1619189->1619249)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 82592960 vs 
160 (1619505->1619436)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 2240 vs 160 
(1619471->1619531)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 82591360 vs 
160 (1619587->1619475)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 2080 vs 160 
(1619557->1619613)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 82594400 vs 
160 (1620892->1620862)
<000e> l1sap.c:144 RTP clock out of sync with lower layer: 1440 vs 160 
(1620862->1620900)

Very large value, is this a typecast / intsize? problem ??

Gullik



From laforge at gnumonks.org  Wed Feb 13 21:36:14 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 13 Feb 2019 22:36:14 +0100
Subject: LimeSDR rx level and quality
In-Reply-To: <d373d12f-1899-ddd9-27d5-264e2baf6dae@corevalue.se>
References: <d373d12f-1899-ddd9-27d5-264e2baf6dae@corevalue.se>
Message-ID: <20190213213614.GH16305@nataraja>

Hi Gullik,

On Wed, Feb 13, 2019 at 05:08:36PM +0100, Gullik Webjorn wrote:

> Q: I have deduced that RXQ is referenced in abis_rsl.c in the bsc, is
> it just propagated from the sdr up through Transceiver, where is the
> actual evaluation done?

The measurement values are computed by OsmoBTS.  The raw values are
paseed from the BTS-specific part (osmo-bts-trx in your case) via the
L1SAP MPH_INFO indication (sub-type PRIM_INFO_MEAS) to the common part
in src/common, where measurement.c is performing the bulk of the computation.

The values are then reported on Abis every SACCH multiframe as part of the RSL
MEASUREMENT INDICATION messages to the BSC, which uses them as input for
e.g. handover decision making.

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 msuraev at sysmocom.de  Thu Feb 14 09:22:21 2019
From: msuraev at sysmocom.de (Max)
Date: Thu, 14 Feb 2019 10:22:21 +0100
Subject: OML bringup bugs and compatibility
In-Reply-To: <20190213132040.GD16305@nataraja>
References: <20190213132040.GD16305@nataraja>
Message-ID: <f1789607-8a4b-659e-7e8e-142b1babbb08@sysmocom.de>

One possible workaround (unless we find 1-way-fits-all technical 
interpretation of a spec) would be to use notion of major vs. minor 
releases.

We can guarantee backward compatibility within major releases (any 
osmo-bts 1.x.y works with any osmo-bsc 1.a.b) but not between them 
(osmo-bts 1.x.y might not work with osmo-bsc 2.m.n).

On a related note, we can follow the same principle with our libraries: 
any minor libosmocore 1.k.l. release preserve backward compatibility 
while moving to libosmocore 2.q.w. might require some porting efforts.

That would match general expectations set by other free software 
projects like GTK for example - nobody expects application written for 
GTK2.x to work effortlessly with GTK3.y

-- 
- Max Suraev <msuraev 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 Directors: Harald Welte



From laforge at gnumonks.org  Thu Feb 14 10:48:04 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 14 Feb 2019 11:48:04 +0100
Subject: BTS logging RTP clock out of synch...
In-Reply-To: <7b735a2f-2397-9b79-0a34-8089844b9f04@corevalue.se>
References: <7b735a2f-2397-9b79-0a34-8089844b9f04@corevalue.se>
Message-ID: <20190214104804.GL16305@nataraja>

On Wed, Feb 13, 2019 at 07:24:40PM +0100, Gullik Webjorn wrote:
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 2240 vs 160
> (1619189->1619249)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 82592960 vs 160
> (1619505->1619436)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 2240 vs 160
> (1619471->1619531)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 82591360 vs 160
> (1619587->1619475)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 2080 vs 160
> (1619557->1619613)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 82594400 vs 160
> (1620892->1620862)
> <000e> l1sap.c:144 RTP clock out of sync with lower layer: 1440 vs 160
> (1620862->1620900)
> 
> Very large value, is this a typecast / intsize? problem ??

no.  it looks like for some reason you are loosing tons of uplink TCH frames
in you setup.  Every 20 milliseconds we expect one TCH block equalling 
160 sample clocks at the 8kHz audio sample rate used in GSM.

There may be some underflow/overflow issues in the modulo arithmetic of frame numbers.

The important fac is not so much what exact figures you see here, but that
you see such messages regularly at all.  There's something very wrong here.

-- 
- 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 246tnt at gmail.com  Thu Feb 14 13:54:50 2019
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 14 Feb 2019 14:54:50 +0100
Subject: BTS logging RTP clock out of synch...
In-Reply-To: <20190214104804.GL16305@nataraja>
References: <7b735a2f-2397-9b79-0a34-8089844b9f04@corevalue.se>
 <20190214104804.GL16305@nataraja>
Message-ID: <CAHL+j0_kirZDYEiRAzL97Hh4KxKNeV6R4QPy4vSLVA0KJ881vg@mail.gmail.com>

> > <000e> l1sap.c:144 RTP clock out of sync with lower layer: 82592960 vs 160
> > (1619505->1619436)

Looks to me like the UDP packets are being received out-of-order and
it really doesn't like that ...

Cheers,

   Sylvain


From nhofmeyr at sysmocom.de  Fri Feb 15 19:00:04 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 15 Feb 2019 20:00:04 +0100
Subject: OML bringup bugs and compatibility
In-Reply-To: <20190213132040.GD16305@nataraja>
References: <20190213132040.GD16305@nataraja>
Message-ID: <20190215190004.GA15739@my.box>

On Wed, Feb 13, 2019 at 02:20:40PM +0100, Harald Welte wrote:
> The problem now is: If we "fix" the BTS side to reject the OPSTART without
> prior SET RADIO CARRIER ATTRIBUTES, then older OsmoBSC will stop to work with
> newer OsmoBTS.

If we want newer OsmoBTS to enforce a specific order of messages:

Introduce a legacy non-compat config option, sort of like that vi "set
nocompatible".  In the lack of any config, osmo-bts ignores OPSTARTs that came
too early. IIUC a second opstart will follow?

As new example config, we ship with an option like "oml strict", which then
rejects OPSTARTs that came too early, instead of just ignoring.

OTOH, if ignoring too early OPSTARTs works for both old and new osmo-bsc, we
might not even need to be strict about it at all?

If anyone out there is using osmo-bts with a BSC that only sends an early
OPSTART, then this idea of ignorng early OPSTART would break that setup, I
guess.

~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/20190215/34d29f18/attachment.bin>

From nhofmeyr at sysmocom.de  Fri Feb 15 19:03:38 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 15 Feb 2019 20:03:38 +0100
Subject: OML bringup bugs and compatibility
In-Reply-To: <f1789607-8a4b-659e-7e8e-142b1babbb08@sysmocom.de>
References: <20190213132040.GD16305@nataraja>
 <f1789607-8a4b-659e-7e8e-142b1babbb08@sysmocom.de>
Message-ID: <20190215190338.GB15739@my.box>

On Thu, Feb 14, 2019 at 10:22:21AM +0100, Max wrote:
> That would match general expectations set by other free software projects
> like GTK for example - nobody expects application written for GTK2.x to work
> effortlessly with GTK3.y

Yes, but such a compatibility break always brings a lot of overhead and a split
of the user base, as we have seen with the osmo-nitb split. The community is
infinitely slow in taking on the newer incompatible version.

The aim should be to remain compatible.

~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/20190215/6ea3c188/attachment.bin>

From nhofmeyr at sysmocom.de  Fri Feb 15 19:40:20 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 15 Feb 2019 20:40:20 +0100
Subject: iPhone X and openbsc
In-Reply-To: <CAMG-S90-J3AUVFCuau5fjRiCYaHCoSqfwDvUgvwNwe61PDfp2Q@mail.gmail.com>
References: <CAMG-S90-J3AUVFCuau5fjRiCYaHCoSqfwDvUgvwNwe61PDfp2Q@mail.gmail.com>
Message-ID: <20190215194020.GD15739@my.box>

On Wed, Feb 13, 2019 at 01:34:56PM +0530, Akib Sayyed wrote:
> Hi list
> Did any1 tested iPhone X and openbsc
> I am struggling to get it work. iPhone don't show network.
> Other phone is working fine.

Check whether you are using frequency bands that the particular phone does not
support?

~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/20190215/31568db4/attachment.bin>

From msuraev at sysmocom.de  Tue Feb 19 18:10:29 2019
From: msuraev at sysmocom.de (Max)
Date: Tue, 19 Feb 2019 19:10:29 +0100
Subject: OML bringup bugs and compatibility
In-Reply-To: <20190215190338.GB15739@my.box>
References: <20190213132040.GD16305@nataraja>
 <f1789607-8a4b-659e-7e8e-142b1babbb08@sysmocom.de>
 <20190215190338.GB15739@my.box>
Message-ID: <8617aa12-2eed-2029-d369-397d4df6f00d@sysmocom.de>

Hi.

15.02.19 20:03, Neels Hofmeyr ?????:
> Yes, but such a compatibility break always brings a lot of overhead 
> and a split
> of the user base, as we have seen with the osmo-nitb split. The community is
> infinitely slow in taking on the newer incompatible version.

I don't think it's fair comparison: nitb split require users to update 
pretty much everything at once, including updating config files etc. Of 
course it's "a lot of overhead" - it requires manual human labor.

It's a different story when user have to update one or two programs, 
without changing config files. That happens automatically all the time 
on pretty much daily basis.

Yes, we should try to be backward compatible whenever possible. Doesn't 
mean we can't consider introducing incompatible changes if it's really 
necessary.

-- 
- Max Suraev <msuraev 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 Directors: Harald Welte



From jenkins at lists.osmocom.org  Wed Feb 20 02:17:00 2019
From: jenkins at lists.osmocom.org (jenkins at lists.osmocom.org)
Date: Wed, 20 Feb 2019 02:17:00 +0000 (UTC)
Subject: Build failed in Jenkins: Coverity-Upload (jenkins-job-builder) #395
Message-ID: <1548373781.314.1550629020109.JavaMail.jenkins@jenkins.osmocom.org>

See <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/395/display/redirect>

------------------------------------------
Started by timer
Building remotely on build2-deb9build-ansible (ttcn3 osmo-gsm-tester-build osmocom-gerrit-debian9 osmocom-master-debian9 coverity) in workspace <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/>
Wiping out workspace first.
Cloning the remote Git repository
Cloning repository git://git.osmocom.org/osmo-ci
 > git init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/> # timeout=10
ERROR: Error cloning remote repo 'origin'
hudson.plugins.git.GitException: Could not init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/>
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:772)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$2.execute(CliGitAPIImpl.java:564)
	at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:153)
	at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler$1.call(RemoteGitImpl.java:146)
	at hudson.remoting.UserRequest.perform(UserRequest.java:212)
	at hudson.remoting.UserRequest.perform(UserRequest.java:54)
	at hudson.remoting.Request$2.run(Request.java:369)
	at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
	Suppressed: hudson.remoting.Channel$CallSiteStackTrace: Remote call to build2-deb9build-ansible
		at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1741)
		at hudson.remoting.UserRequest$ExceptionResponse.retrieve(UserRequest.java:357)
		at hudson.remoting.Channel.call(Channel.java:955)
		at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.execute(RemoteGitImpl.java:146)
		at sun.reflect.GeneratedMethodAccessor338.invoke(Unknown Source)
		at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
		at java.lang.reflect.Method.invoke(Method.java:498)
		at org.jenkinsci.plugins.gitclient.RemoteGitImpl$CommandInvocationHandler.invoke(RemoteGitImpl.java:132)
		at com.sun.proxy.$Proxy87.execute(Unknown Source)
		at hudson.plugins.git.GitSCM.retrieveChanges(GitSCM.java:1146)
		at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1186)
		at hudson.scm.SCM.checkout(SCM.java:504)
		at hudson.model.AbstractProject.checkout(AbstractProject.java:1208)
		at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:574)
		at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
		at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
		at hudson.model.Run.execute(Run.java:1810)
		at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
		at hudson.model.ResourceController.execute(ResourceController.java:97)
		at hudson.model.Executor.run(Executor.java:429)
Caused by: hudson.plugins.git.GitException: Command "git init <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/"> returned status code 1:
stdout: 
stderr: <https://jenkins.osmocom.org/jenkins/job/osmocom-coverity/ws/.git>: No space left on device

	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1996)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1964)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommandIn(CliGitAPIImpl.java:1960)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.launchCommand(CliGitAPIImpl.java:1597)
	at org.jenkinsci.plugins.gitclient.CliGitAPIImpl$5.execute(CliGitAPIImpl.java:770)
	... 11 more
ERROR: Error cloning remote repo 'origin'


From hwelte at sysmocom.de  Wed Feb 20 08:46:39 2019
From: hwelte at sysmocom.de (Harald Welte)
Date: Wed, 20 Feb 2019 09:46:39 +0100
Subject: Osmocom-Debian-install-test fails for 10 consecutive days!
Message-ID: <20190220084639.GA11466@nataraja>

Dear Osmocom community,

for the last 10 days our "Debian installation test" job is consistently failing,
see https://jenkins.osmocom.org/jenkins/job/Osmocom-Debian-install-latest/

It somehow seems to be related to soapySDR mismatching versions where we use a 0.5 package
from the debian feed:

> Get:358 http://deb.debian.org/debian stretch/main amd64 libsoapysdr0.5-2 amd64 0.5.4-1 [64.4 kB]

and mix that with a 0.7 lms7 module from our feed:

> Get:425 http://download.opensuse.org/repositories/network:/osmocom:/latest/Debian_9.0 ./ soapysdr0.7-module-lms7 19.01.0-1 [49.9 kB]

> Unpacking soapysdr0.7-module-lms7:amd64 (19.01.0-1) ...
> dpkg: error processing archive /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb (--unpack):
>  trying to overwrite '/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.5-2/libLMS7Support.so', which is also in package
...
> Errors were encountered while processing: /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb
> E: Sub-process /usr/bin/dpkg returned an error code (1)
> Build step 'Execute shell' marked build as failure
> Finished: FAILURE

Does anyone know of any change that would have triggered this?

I've created https://osmocom.org/issues/3809 to track this.

Regards,
	Harald
-- 
- Harald Welte <hwelte 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 Feb 20 13:16:27 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 20 Feb 2019 14:16:27 +0100
Subject: less osmo-msc patches
Message-ID: <20190220131627.GA13807@my.box>

Hi everyone,

let me remind you that I am refactoring the RAN connection in osmo-msc to allow
for inter-MSC handover. Patches merged to osmo-msc now are almost guaranteed to
produce merge conflicts. Cosmetic changes to RAN code are likely to be obsolete.

I would prefer if you guys wouldn't bother for another few weeks.

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/20190220/ba3d8b5d/attachment.bin>

From osmith at sysmocom.de  Wed Feb 20 15:20:13 2019
From: osmith at sysmocom.de (Oliver Smith)
Date: Wed, 20 Feb 2019 16:20:13 +0100
Subject: Osmocom-Debian-install-test fails for 10 consecutive days!
In-Reply-To: <20190220084639.GA11466@nataraja>
References: <20190220084639.GA11466@nataraja>
Message-ID: <9108471f-5684-0e31-a368-3c1ff9e5c9b0@sysmocom.de>

Hello,

I have created a short patch to fix this (see the linked issue for
details, reviews welcome).

Now I'm wondering about e-mail notifications for failed builds (so we
can react faster in the future). So far I have created a patch to add
only myself to the list of e-mail receivers:

https://gerrit.osmocom.org/#/c/osmo-ci/+/12978/

Vadim has asked about adding the whole mailing list to the receivers, so
I'm wondering what members of this ML are thinking about that.

Regards,
Oliver


On 2/20/19 9:46 AM, Harald Welte wrote:
> Dear Osmocom community,
> 
> for the last 10 days our "Debian installation test" job is consistently failing,
> see https://jenkins.osmocom.org/jenkins/job/Osmocom-Debian-install-latest/
> 
> It somehow seems to be related to soapySDR mismatching versions where we use a 0.5 package
> from the debian feed:
> 
>> Get:358 http://deb.debian.org/debian stretch/main amd64 libsoapysdr0.5-2 amd64 0.5.4-1 [64.4 kB]
> 
> and mix that with a 0.7 lms7 module from our feed:
> 
>> Get:425 http://download.opensuse.org/repositories/network:/osmocom:/latest/Debian_9.0 ./ soapysdr0.7-module-lms7 19.01.0-1 [49.9 kB]
> 
>> Unpacking soapysdr0.7-module-lms7:amd64 (19.01.0-1) ...
>> dpkg: error processing archive /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb (--unpack):
>>  trying to overwrite '/usr/lib/x86_64-linux-gnu/SoapySDR/modules0.5-2/libLMS7Support.so', which is also in package
> ...
>> Errors were encountered while processing: /tmp/apt-dpkg-install-aYn9qf/398-soapysdr0.7-module-lms7_19.01.0-1_amd64.deb
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>> Build step 'Execute shell' marked build as failure
>> Finished: FAILURE
> 
> Does anyone know of any change that would have triggered this?
> 
> I've created https://osmocom.org/issues/3809 to track this.
> 
> Regards,
> 	Harald
> 

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


From laforge at gnumonks.org  Wed Feb 20 18:09:28 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 20 Feb 2019 19:09:28 +0100
Subject: Osmocom-Debian-install-test fails for 10 consecutive days!
In-Reply-To: <9108471f-5684-0e31-a368-3c1ff9e5c9b0@sysmocom.de>
References: <20190220084639.GA11466@nataraja>
 <9108471f-5684-0e31-a368-3c1ff9e5c9b0@sysmocom.de>
Message-ID: <20190220180927.GC11466@nataraja>

Hi Oliver,

On Wed, Feb 20, 2019 at 04:20:13PM +0100, Oliver Smith wrote:

> I have created a short patch to fix this (see the linked issue for
> details, reviews welcome).

Thanks a lot for the quick follow-up!

> Now I'm wondering about e-mail notifications for failed builds (so we
> can react faster in the future).

> Vadim has asked about adding the whole mailing list to the receivers, so
> I'm wondering what members of this ML are thinking about that.

not this list, as the amount of auto-generated mails would by far outweight the
amount of human-generated mails and basically make this list unusable.

In the past we argued sending the notifications to the commitlog or gerrit-log
lists, but I think there e.g. I would never look at them as I don't read those
lists frequently. 

So maybe yet another list?  This way we can make sure to only notify those people
who have actively signed up.

I guess unless there's significant disagreement, I'll create something like
jenkins-notifications at lists.osmocom.org ?

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 246tnt at gmail.com  Wed Feb 20 19:50:01 2019
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Wed, 20 Feb 2019 20:50:01 +0100
Subject: fsm: Delaying dispatch of events while we're already inside a
 dispatch callback.
Message-ID: <CAHL+j0_kKFhXzoMkTqbYmvKshAsn-PDN6bXoYz6iYkSi07o1uQ@mail.gmail.com>

Hi,

Currently if you call osmo_fsm_dispatch from a function that happens
to have been triggered by another call to dispatch, things can get a
little bit messy (depending on where that callback is in the chain of
even that may/may not change the state of the FSM).

So what I would propose is that any event dispatched to an FSM will be
processed only after the processing of any previous event is fully
completed (in the order they were generated). I have a prototype
implementation for review on gerrit :

https://gerrit.osmocom.org/c/libosmocore/+/12983

Now, this does break some tests, but looking at the breakage, it looks
just like message re-ordering at first glance. I guess running the
whole full range of test on this would be useful.

There are also another consequence is that it's now impossible to
return an error code if that event can't be handled in the current
state (previously dispatch would return -1). But since the actual
dispatch can be deferred ... well, can't do much. Looking at the
codebase, that error code is ignored most of the time. When it's
returned, it seems to always end up being ignored at the end of the
chain (because well ... realistically there isn't much you can do
about it anyway, it's a programming bug if it happens).

Thoughts / Comments ? Useful ? Crazy idea ? ...

Cheers,

    Sylvain


From laforge at gnumonks.org  Thu Feb 21 09:49:21 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Thu, 21 Feb 2019 10:49:21 +0100
Subject: fsm: Delaying dispatch of events while we're already inside a
 dispatch callback.
In-Reply-To: <CAHL+j0_kKFhXzoMkTqbYmvKshAsn-PDN6bXoYz6iYkSi07o1uQ@mail.gmail.com>
References: <CAHL+j0_kKFhXzoMkTqbYmvKshAsn-PDN6bXoYz6iYkSi07o1uQ@mail.gmail.com>
Message-ID: <20190221094921.GO11466@nataraja>

Hi Sylvain,

On Wed, Feb 20, 2019 at 08:50:01PM +0100, Sylvain Munaut wrote:
> Currently if you call osmo_fsm_dispatch from a function that happens
> to have been triggered by another call to dispatch, things can get a
> little bit messy (depending on where that callback is in the chain of
> even that may/may not change the state of the FSM).

Yes, it's not particularly elegant in all cases, but it fits our synchronous
architecture, where we are used to processing one packet (that may become an
event) in one go.

> So what I would propose is that any event dispatched to an FSM will be
> processed only after the processing of any previous event is fully
> completed (in the order they were generated). I have a prototype
> implementation for review on gerrit :

This will break all use cases where the "data" pointer of an event is something
allocated on the stack by the caller, or where it is a msgb or other object
that simply may no longer exist at the time the deferred event is being processed.

Or am I missing something?

So while I trust there are use cases where your proposed behavior is useful,
we must not change the existing semantics.  We could introduce a new
"dispatch_event_deferred()" or something like that which exhibits the new
properties, while the existing API semantics remain unmodified.
Would that help you?

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 246tnt at gmail.com  Thu Feb 21 14:54:10 2019
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Thu, 21 Feb 2019 15:54:10 +0100
Subject: fsm: Delaying dispatch of events while we're already inside a
 dispatch callback.
In-Reply-To: <20190221094921.GO11466@nataraja>
References: <CAHL+j0_kKFhXzoMkTqbYmvKshAsn-PDN6bXoYz6iYkSi07o1uQ@mail.gmail.com>
 <20190221094921.GO11466@nataraja>
Message-ID: <CAHL+j0_yfgSEYkTSnxxVyO7RW-Az89czbqhCXeXHZ8cZNhfdBg@mail.gmail.com>

Hi,

So yeah, it definitely breaks stuff. Both because of those pointers
become invalid and also some code seems to rely on that order.
I pushed another version of the patch which just introduces a new
function with the "queue" semantics, but that might not be the right
approach to solve the initial problem.

So the initial issue is that once a RAN connection is first
established, it goes to the RAN_CONN_S_ACCEPTED state and starts a
timeout. Then when some messages are effectively exchanged,
"something" eventually calls ran_conn_communicating() and this
transitions the fsm to RAN_CONN_S_COMMUNICATING state (via sending a
RAN_CONN_E_COMMUNICATING event) and removed the timeout.

Now for a silent call, there might not be any message exchanged (since
we really have nothing to say) so the options are :

* Brute force approach is to hard code a bypass of the
RAN_CONN_S_ACCEPTED state directly to RAN_CONN_S_COMMUNICATING :

        case RAN_CONN_E_ACCEPTED:
                evaluate_acceptance_outcome(fi, true);
-               osmo_fsm_inst_state_chg(fi, RAN_CONN_S_ACCEPTED,
RAN_CONN_TIMEOUT, 0);
+               if (conn->silent_call)
+                       osmo_fsm_inst_state_chg(fi,
RAN_CONN_S_COMMUNICATING, 0, 0);
+               else
+                       osmo_fsm_inst_state_chg(fi,
RAN_CONN_S_ACCEPTED, RAN_CONN_TIMEOUT, 0);

  Personally not a big fan since you 'distribute' the knowledge of the
silent call around in other part of the code.

* Make it transition from ACCEPTED to COMMUNICATING from silent_call.c.
  To achieve this, what I first tried was to simply call
ran_conn_communicating() from the paging callback. Unfortunately that
doesn't work because if you lookat the current code :

        case RAN_CONN_E_ACCEPTED:
                evaluate_acceptance_outcome(fi, true);
               osmo_fsm_inst_state_chg(fi, RAN_CONN_S_ACCEPTED,
RAN_CONN_TIMEOUT, 0);

    the paging callback is called as part of
"evaluate_acceptance_outcome" and so this comes before the state is
changed to ACCEPTED. Deferring the dispatch of the event by changing
the FSM behavior was an attempt to fix this. (so the new
RAN_CONN_E_COMMUNICATING I generate would only be processed lates).

    But another option that also works is simply to swap the two calls
and change the FSM state first :

        case RAN_CONN_E_ACCEPTED:
               osmo_fsm_inst_state_chg(fi, RAN_CONN_S_ACCEPTED,
RAN_CONN_TIMEOUT, 0);
                evaluate_acceptance_outcome(fi, true);

    I checked and this also works fine.


Cheers,

     Sylvain





Cheers,

   Sylvain


From nhofmeyr at sysmocom.de  Thu Feb 21 15:28:32 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 21 Feb 2019 16:28:32 +0100
Subject: Osmocom-Debian-install-test fails for 10 consecutive days!
In-Reply-To: <20190220180927.GC11466@nataraja>
References: <20190220084639.GA11466@nataraja>
 <9108471f-5684-0e31-a368-3c1ff9e5c9b0@sysmocom.de>
 <20190220180927.GC11466@nataraja>
Message-ID: <20190221152832.GA3457@ass40.box>

> I guess unless there's significant disagreement, I'll create something like
> jenkins-notifications at lists.osmocom.org ?

+1

-------------- 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/20190221/49e3b22b/attachment.bin>

From nhofmeyr at sysmocom.de  Thu Feb 21 16:47:06 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 21 Feb 2019 17:47:06 +0100
Subject: fsm: Delaying dispatch of events while we're already inside a
 dispatch callback.
In-Reply-To: <CAHL+j0_yfgSEYkTSnxxVyO7RW-Az89czbqhCXeXHZ8cZNhfdBg@mail.gmail.com>
References: <CAHL+j0_kKFhXzoMkTqbYmvKshAsn-PDN6bXoYz6iYkSi07o1uQ@mail.gmail.com>
 <20190221094921.GO11466@nataraja>
 <CAHL+j0_yfgSEYkTSnxxVyO7RW-Az89czbqhCXeXHZ8cZNhfdBg@mail.gmail.com>
Message-ID: <20190221164706.GA9157@ass40.box>

On Thu, Feb 21, 2019 at 03:54:10PM +0100, Sylvain Munaut wrote:
>         case RAN_CONN_E_ACCEPTED:
>                osmo_fsm_inst_state_chg(fi, RAN_CONN_S_ACCEPTED,
> RAN_CONN_TIMEOUT, 0);
>                 evaluate_acceptance_outcome(fi, true);

This should be perfectly fine, and the exact same approach has fixed other
sequence-of-events problems earlier: transition the state first, and then
take actions.


Re deferring events:

We can't globally change events to deferred, exactly because of the
reasons mentioned:
- passing along a data pointer to a local variable.
- returning error code if transition is not allowed (evaluated in rare
  cases).

Also, in general, it is safer to use the "more deterministic" way of
immediate event triggering. If events get stored in sequence, maybe some
other message that gets rx'd in-between (maybe it already was in the
select() queue before we added events to be triggered) gets handled in
some intermediate state in-between action and effect; that opens up
variations in code paths that would otherwise be guaranteed to always
happen in exactly identical sequence.

It could still be useful to have some defer() API.

I recently faced the need for a deferred action. My particular scenario
is: a child object tells its parent that it is gone from its FSM cleanup
implementation, and the parent deallocates; which also free()s the child.

In pseudo code:

  struct main_obj {
    struct child_obj *child;
  };

  struct child_obj {
    struct osmo_fsm_inst *fi;
    struct main_obj *parent;
  };

  child_obj_alloc(struct main_obj *parent)
  {
    /* our common "FSM instance owns object" scheme: */
    fi = osmo_fsm_inst_alloc(talloc_ctx = parent);
    child = talloc_zero(talloc_ctx = fi, struct child_obj);
    child->fi = fi;

    parent->child = child;
  }

  child_obj_fsm_cleanup(struct child_obj *child)
  {
    main_obj_remove_child(child)
  }

  main_obj_remove_child(main)
  {
    /* Without children, I have no purpose. Bye. */
    talloc_free(main);
  }

  --> heap use after free in osmo_fsm_inst_term(child->fi),
      after calling child->fi->cleanup().

The point is that the child is allocated as a talloc child of the main
object, and the main object is wired to deallocate itself when no children
are left. When I call osmo_fsm_inst_term() on the child, its cleanup
function tells the parent that it is gone, and the parent completely
deallocates itself, still within the cleanup code path.  But the
osmo_fsm_inst code then continues to talloc_free() the child->fi after it
called the cleanup function -- though the entire object was already freed
in the cleanup function.

(The actual case in osmo-msc:neels/ho: the msc subscriber struct having
MSC-{A,I,T} roles, and as soon as the MSC-A role is gone, or there is
neither an MSC-I nor MSC-T role, the entire subscriber must be released.)

The solution I picked in the end was to also add an FSM instance to the
main_obj, because if the child FSM is an osmo_fsm_inst_alloc_child(), it
will trigger an event to the parent *after* all other handling is done.
So the entire main_obj FSM instance only exists to receive the parent_term
event after the child FSM is deallocated, instead of being notified of a
released child already in the cleanup function.

I considered solving like this instead:

  child_obj_fsm_cleanup(struct child_obj *child)
  {
    defer( main_obj_remove_child, child->parent );
  }

where defer could be implemented as an osmo_timer with zero delay.

Triggering events could work in the same way, i.e. the defer
implementation does not have to be osmo_fsm specific.

But also, in this instance, it is quite possible that something else
happens in-between the child deallocation and the deferred event handling.
If some msg gets handled while the parent still points at the child, that
would pose a use-after-free risk. Of course we could set parent->child =
NULL in the cleanup callback and defer the deallocation ... but the point
being that deferring actions opens up non-determinisms that can be
non-trivial to handle well. Having a separate full FSM instance might be a
bit of overkill, but has the benefit of allocation/deallocation and event
logging.

~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/20190221/96e17f28/attachment.bin>

From keith at rhizomatica.org  Sun Feb 24 16:04:33 2019
From: keith at rhizomatica.org (Keith)
Date: Sun, 24 Feb 2019 17:04:33 +0100
Subject: LimeNET Micro
Message-ID: <fc68cd03-3222-058f-79cb-5ab159737ea7@rhizomatica.org>

The new product from Lime is marked to start shipping tomorrow. As far
as I understand it is basically the LimeSDR mini with a GPS disciplined
clock and a Raspberry Pi module, so it /should/ run osmo-bts +
osmo-trx-lms fine, and without clocking issues.

It also has POE.

I was wondering if anybody else has looked at it, has comments, or has
or is thinking of ordering one?

Thanks!




From laforge at gnumonks.org  Sun Feb 24 19:28:05 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 24 Feb 2019 20:28:05 +0100
Subject: LimeNET Micro
In-Reply-To: <fc68cd03-3222-058f-79cb-5ab159737ea7@rhizomatica.org>
References: <fc68cd03-3222-058f-79cb-5ab159737ea7@rhizomatica.org>
Message-ID: <20190224192805.GF24824@nataraja>

Hi Keith,

On Sun, Feb 24, 2019 at 05:04:33PM +0100, Keith wrote:
> The new product from Lime is marked to start shipping tomorrow. 

That's good news.

> As far as I understand it is basically the LimeSDR mini with a GPS
> disciplined clock and a Raspberry Pi module, so it /should/ run
> osmo-bts + osmo-trx-lms fine, and without clocking issues.

That is about as much as I know about it, yes.

> I was wondering if anybody else has looked at it, has comments, or has
> or is thinking of ordering one?

I have seen early prototypes at a trade show and have been in some
discussion with Lime about it in the past.  However, I don't know any
more about the device other than what's published by Lime.

It's definitely an interesting device to play with.  I'm looking forward
to that.

However, irrespective of the stable enough clock reference we are still
experiencing a couple of issues when using OsmoTRX with LimeSDR (usb and
mini).  It's yet to be determined what exactly is the root cause of all
of this, as we're using a rather low sample rate and slow, ancient
narrow-band systems like GSM/GPRS/EGPRS shouldn't be a challenge at all
for powerful SDR devices.   It's not clear whether those porblems are
caused by the hardware, gateware, USB host controllers, the
kernel/drivers, LimeSuite or OsmoTRX.

Several of the problems users are experiencing are USB related.  IIRC,
the LimeNET micro used some other interface between the LMS-chip and the
Raspi compute module than USB.  So it may be that the USB related
troubles are becoming irrelevant on this new platform.

I'd definitely love to see the Osmocom stack perform better with LimeSDR
based devices, but I have the feeling that a significant amount of
debugging is required, and the number of areas required to understand
make the number of people available to work on them quite small: One
needs to understand the GSM radio interface, the Osmocom stack,
LimeSuite, USB protocol and Linux system level instrumentation /
debugging of realtime/latency issues which is IMHO a rather rare
combination of expert areas to come by :/

Please note I'm not trying to discourage anyone from buying/using
LiemSDR devices.  I'm just saying that so far, particularly with
the Osmocom stack, there are some [so far] hard to resolve problems
with the existing USB-based devices.  Any help in those areas is very
much appreciated!

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 Feb 26 16:03:56 2019
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Tue, 26 Feb 2019 23:03:56 +0700
Subject: Google Summer of Code 2019
In-Reply-To: <20190115161349.GP11166@nataraja>
References: <CAPEnp=amxMBU8DAG-xRuMCGMXfv1Oxxyw1VSRKuvdov+smb-=Q@mail.gmail.com>
 <20190115161349.GP11166@nataraja>
Message-ID: <CAPEnp=Z6puZVUhRppkKmw75yeJdq5yfFsgu0ySRCzfD93MHaqA@mail.gmail.com>

Hi all,

since we have seen more neutral and positive opinions than negative ones,
we've tried to apply as a mentor organization. Unfortunately, our application
has been rejected. Sadly, but not the end of the world ;)

Thanks for your feedback!
... and kudos to Harald!

With best regards,
Vadim Yanitskiy.


From nhofmeyr at sysmocom.de  Tue Feb 26 19:21:53 2019
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 26 Feb 2019 20:21:53 +0100
Subject: static strings -- little fun on the side
Message-ID: <20190226192153.GA21202@my.box>

As a bit of relaxation in-between the serious hacking, I gave a little idea of
mine a spin, which could improve our use of static string buffers.

My idea is to use one common static buffer string, as a ring buffer, for all
our osmo_xxx_name() functions, that returns new chunks of static string every
time. Why?


The point is that we have many osmo_xxx_name() functions that return a string
in one single static buffer. When you call it a second time, it overwrites the
buffer. So this doesn't work:

  printf("PLMN changed from %s to %s\n", 
         osmo_plmn_name(old_plmn),
	 osmo_plmn_name(new_plmn));

No matter what, this will always print the same string twice, and probably
no-one would notice.

For this, I have previously often invented xxx_name2() functions:

  printf("PLMN changed from %s to %s\n",
         osmo_plmn_name(old_plmn),
	 osmo_plmn_name2(new_plmn));

With osmo_plmn_name2() being:

  "Same as osmo_plmn_name(), but returning in a different static buffer."

That is bad for these reasons:

 - each new separate function adds another static buffer to the program size,
   which remains unused all the other time.
 - each new separate function adds more API signatures.

Alternatively we have xxx_buf() functions, but they are more cumbersome to use:

  char buf[123];
  gsm0808_cell_id_list_name_buf(buf, sizeof(buf), cil);
  LOGP(DMSC, LOGL_DEBUG, "%s\n", buf);

Particularly for logging, that would always run even though the logging
category might be switched off.


So I came up with these patches, and changing all of current libosmocore's
static buffers to using this does work:

http://git.osmocom.org/libosmocore/log/?h=neels/static_strings
(second last patch introduces the API, last patch changes all libosmocore callers)

Also pushed to gerrit for easier review:
https://gerrit.osmocom.org/13061


the benefits:

- All osmo_xxx_name() functions can be called N times in a single printf()
  statement, without the need for managing buffers.

- No osmo_xxx_name2() functions for "separate static buffer"

- Just fire off LOGP() args and the code gets skipped if the category / log
  level is switched off:

     LOGP(DMSC, LOGL_DEBUG, 
  	  "PLMN changed from %s to %s, but Fred says it was %s\n",
	  osmo_plmn_name(old_plmn),
	  osmo_plmn_name(new_plmn),
	  osmo_plmn_name(freds_plmn));


I think it would be nice to have this mechanism for easier string hacking,
but not sure if the tradeoffs / vague side effects are worth it.
So this might as well remain a fun idea that never made it.

Thoughts welcome.


Implementation considerations...

At first I thought a plain ring buffer returning the next bit of memory every
time would suffice, but I didn't like the need to vaguely trust that we never
use overlapping memory.

The best I could come up with was to guarantee up to N subsequent static
strings as non-overlapping. See the semantics around the 'recent' members.
But that entails an uncomfortable tradeoff:


I kind of expected to reduce the size of static char buffers in libosmocore,
but if I want to disallow overlapping N uses, the buffer has to be able to hold
N subsequent allocations of the largest buffer, which currently is 4100. So I
end up with a larger static char buffer. The advantage however is that every
libosmocore using program with its own xxx_name() functions can now use the
same static string space and does not need to add more static buffers all over
the place.

To make the buffer smaller, I considered taking the largest buffer callers out
of this, i.e. osmo_hexdump() and msgb_hexdump(). But particularly
osmo_hexdump() is one of the functions that I would like to be able to call
more than once in a printf() arg list. Actually that would in practice be of
smaller size than the maximum 4096 currently allowed. But the 'recent' check
above requires the *largest* size to fully fit N times.

Consider: if I choose a total buffer of 4096 bytes and print one hexdump of
3084 bytes, then I can't print another such buffer: the osmo_static_string()
function can't know that the first printf() has already concluded, and still
considers that large chunk as in-use. So to be able to allow any number of
subsequent printf()s of the same huge size, I need the number-of-recent-checks
times that large size to fit in the static buffer.

So there is a tradeoff between how many previous buffers I can guarantee to be
unchanged vs. the maximum buffer size allowed per allocation.

I would actually like to ensure 10 or more recent buffers, so that a caller can
say: I can use up to 10 various osmo_xxx_name() functions in the same printf()
statement, and libosmocore will barf if I use too much.

I would also like to use less static char buffer -- but is ten times 4096 as
static string buffer really a lot? Not for an x86_64 desktop machine, but what
about embedded targets?

Since in practice the name buffer sizes we use are more like <80 chars each, in
practice we would be totally fine with one 4096 char buffer.
I have never seen a hexdump of 4Kb in practice.

I'm considering actually removing the 'recent' check again and just offloading
the responsibilty for name buffer usage to the caller.

Or I'm considering to reduce the max hexdump / msgb_hexdump size to something
saner like 1024 chars or even 256 chars. (Actually, hexdump could also loop in
chunks of 64 bytes or something like that).


Another consideration was about how to effect bounds checking. I don't want to
evaluate return values in printf() args. So I decided to provide generalized
API that returns NULL pointers if the size did not fit, but for convenience use
have one osmo_static_string() function that OSMO_ASSERT()s as soon as the size
doesn't fit, instead.


~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/20190226/e4031067/attachment.bin>

From laforge at gnumonks.org  Tue Feb 26 22:19:14 2019
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 26 Feb 2019 23:19:14 +0100
Subject: static strings -- little fun on the side
In-Reply-To: <20190226192153.GA21202@my.box>
References: <20190226192153.GA21202@my.box>
Message-ID: <20190226221914.GK27673@nataraja>

Hi Neels,

I haven't yet ready our code, just briefly read your e-mail.

One more radical option (much more costly, for sure) would be to
introcue somthing like a "packet processing talloc context" and use
dynamic allocations:

So basically
1) every time we come out of select() and call a filedescriptor callback,
   we would create a new talloc context.
2) any code, including those that want to print messages to buffers, etc.
   could allocate memory from that context without having to care about
   releasing it
3) once we return from the file descriptor call-back, we talloc_free()
   that "master" context, taking with it all the child allocations hat may have
   been allocated underneath.

This is actually a bit inspired from wireshark, where AFAIK you can also
alloctate dynamic memory within the context of a given packet.

Sure, dynamic allocations are more expensive.  But in the end, aside
from osmo-pcu on ARM926EJS sysmoBTS 1002, we've never really seen real
performance problems in the use cases so far.  And as you indicate, if
the logging is turned off, the allocations would never be made.  And we
can make it OOM free by simply returning a static const char * "<OOM!>"
in case the allocation should ever fail.

One might be able to get similar but slightly different semantics by
attaching those strings to the 'msgb' that's currently being processed.
At some point the msgb will be released.  Depending on the use case, the
memory would be allocated for more than the current fd-callback, e.g. in
case of queueing the msgb somewhere.

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)