From laforge at gnumonks.org  Sat Dec 10 19:11:39 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Sat, 10 Dec 2016 20:11:39 +0100
Subject: RFC: OsmoDevCon 2017 planning
Message-ID: <20161210191139.rxtzqrdmsifwgi4s@nataraja>

Dear Osmocom Community,

[please respect the Reply-To and post all follow-up discussion to this
 to openbsc at lists.osmocom.org, so we avoid having long threads
 cross-posted to several mailing lists.]

>From 2012 to 2016 we were running a series of small, invitation-only
Osmocom Developer Conferences.  Access was intentionally restricted
to those community members who have demonstrated an existing track
record of contribution to any of the projects under the Osmocom
umbrella.

This format of a small, tightly knit group of about 20 people has been
successful over the years, and I have received a lot of positive
feedback from past participants.

On the other hand, the Osmocom project has grown in scope and diversity,
and some of those projects don't have all that much relationship to each
other - except being started by people from within the same group.
There's the cellular communications (GSM/GPRS/EDGE/UMTS and hopefully at
some point LTE) protocols which is attracting a lot of professional
users.  And then there's pure community projects like rtl-sdr,
OsmocomBB, OsmocomGMR and many other efforts.

Particularly the cellular infrastructure projects (OsmoBTS, OsmoPCU,
OsmoBTS, OsmoNITB, OsmoSGSN, OpenGGSN, OsmoIuh & co) are somehow
"standing out" of the othe projects in the context of having a wider
user bsae, and in that user base also primarily commercial users.

So I'd like to start a discussion on how to possibly change the event
format to accomodate the various interests and parties.  I definitely
don't want to loose the "annual meeting of old friends" atmosphere,
while at the same time also opening up to other interested parties.

One idea would be to keep OsmoDevCon as-is and have a separate event
where non-contributing/developing users / sysadmins / system integrators
could also be attending.

Another idea would be to split into a 'user day' and 'developer days'
format.  This is something the netfilter developer workshops have been
using for many years, and from my limited insight quite successfully so.
The "user day" is more like a traditional tech conference, with a large
auditorium and talks oriented towards users / sysadmins / integrators of
the software.  The "developer days" are the invitation-only part, for
known contributing developers only, similar to what we have at
OsmoDevCon.

Having both events (or both parts of an event) back-to-back has the
advantage that a large number of potential speakers for the 'user day'
are already present, and they don't have to travel yet another time.

One could even structure it further and say we have one user day, one
public 'Osmocom cellular developer day' and then the closed 'OsmoDevCon
classic', maybe reduced from 4 days to 3 or even 2 days only?

What is the general opinion about this?

Are there people lurking on this list who would be interested in
attending a public 'user day' or even 'developer day' about the Osmocom
cellular projects, with presentations and workshops around topics such
as running Osmocom based cellular networks?

In terms of when/where, I would suggest to keep the tradition of April
in Berlin/Germany.  But I'm of course very happy if somebody wants to
host it some place else...

Regards, and looking forward to meeting you [again] in 2017,
	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  Thu Dec 15 11:45:00 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 15 Dec 2016 12:45:00 +0100
Subject: enum egprs_puncturing_values
Message-ID: <20161215114500.GB26781@ass40.sysmocom.de>

Today I looked at enum egprs_puncturing_values by coincidence:

  /*
   * Valid puncturing scheme values
   * TS 44.060 10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1
   */
  enum egprs_puncturing_values {
          EGPRS_PS_1,
          EGPRS_PS_2,
          EGPRS_PS_3,
          EGPRS_PS_INVALID,
  };

I notice that TS 44.060 10.4.8a.3.1 defines further items besides PS_1, 2 and
3, and that our EGPRS_PS_INVALID occupies the value the spec defines as
"MCS-3/P1". I believe that this is rather unfortunate.

  [[[
  Table 10.4.8a.3.1: Coding and Puncturing Scheme indicator field for Header type 3

  bits
  4321      First block CPS
  ----------------------------
  0000      MCS-4/P1
  0001      MCS-4/P2
  0010      MCS-4/P3
  0011      MCS-3/P1
  0100      MCS-3/P2
  0101      MCS-3/P3
  0110      MCS-3/P1 with padding (MCS-8 retransmission)
  0111      MCS-3/P2 with padding (MCS-8 retransmission)
  1000      MCS-3/P3 with padding (MCS-8 retransmission)
  1001      MCS-2/P1
  1010      MCS-2/P2
  1011      MCS-1/P1
  1100      MCS-1/P2

  NOTE: All the other values are reserved for future use
  The bit numbering is relative to the field position.
  ]]]


I would prefer EGPRS_PS_INVALID=-1 (i.e. outside the spec's value range) and
the other enum values named appropriately, like EGPRS_MSC4_P1, so that our enum
actually reflects the spec as advertised. Is there something I'm missing?

These enum values were added in:
  commit 7a05b039c835868eff34308d861edfeb28d1763b
  Author: Aravind Sirsikar <arvind.sirsikar at radisys.com>
  Date:   Wed Mar 23 18:29:45 2016 +0530

Thanks,

~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: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20161215/e1aee81c/attachment.bin>

From jacob01 at gmx.net  Thu Dec 15 13:36:23 2016
From: jacob01 at gmx.net (Jacob)
Date: Thu, 15 Dec 2016 14:36:23 +0100
Subject: enum egprs_puncturing_values
In-Reply-To: <20161215114500.GB26781@ass40.sysmocom.de>
References: <20161215114500.GB26781@ass40.sysmocom.de>
Message-ID: <854a1453-b2d2-e37b-e4fa-c093d0f25304@gmx.net>

Hi Neels,

AFAICS you are mixing up "puncturing scheme" and "Coding and Puncturing
Scheme", there are still only three puncturing schemes, where up to 3 of
them may be used with a certain MCS. The P scheme has to be changed
(incremented IIRC) after each use.

Nevertheless choosing a safe value for INVALID is probably not bad if
there might be another P in some future spec. But I'd be careful with
negative values in enums.

(I didn't check that against the current version of the code, so I might
be completely out of sync).

HTH Jacob

On 12/15/2016 12:45 PM, Neels Hofmeyr wrote:
> Today I looked at enum egprs_puncturing_values by coincidence:
> 
>   /*
>    * Valid puncturing scheme values
>    * TS 44.060 10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1
>    */
>   enum egprs_puncturing_values {
>           EGPRS_PS_1,
>           EGPRS_PS_2,
>           EGPRS_PS_3,
>           EGPRS_PS_INVALID,
>   };
> 
...
> 
> I would prefer EGPRS_PS_INVALID=-1 (i.e. outside the spec's value range) and
> the other enum values named appropriately, like EGPRS_MSC4_P1, so that our enum
> actually reflects the spec as advertised. Is there something I'm missing?
> 
> These enum values were added in:
>   commit 7a05b039c835868eff34308d861edfeb28d1763b
>   Author: Aravind Sirsikar <arvind.sirsikar at radisys.com>
>   Date:   Wed Mar 23 18:29:45 2016 +0530
> 
> Thanks,
> 
> ~N
> 


From nhofmeyr at sysmocom.de  Fri Dec 16 11:39:32 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 16 Dec 2016 12:39:32 +0100
Subject: comments on enum egprs_puncturing_values and gprs_rlc_mcs_cps()
Message-ID: <20161216113932.GA1481@my.box>

Hi,

in the wake of https://gerrit.osmocom.org/1411 I have some more comments on the
code that seem to large for the gerrit edit field.

I said in that patch comment that gprs_rlc_mcs_cps() must check that it isn't
using INVALID enum values in its bitfield calculations. Furthermore:


The bit fields are obtained by modulo calculation on enum values. This seems
unnecessarily complex and error prone, it is hard to figure out for a reader.
The relation is quite direct though, e.g. for EGPRS_MAX_PS_NUM_2 it means that
PS_1 and PS_3 mean + 0, PS_2 means + 1. I wish that were easier to see. It
would be good to prepare that above the switch() and use it below instead of
duplicating the same calculation numerous times.

Thirdly, for enum egprs_puncturing_values, the comment refers to TS 44.060
10.4.8a.3.1, 10.4.8a.2.1, 10.4.8a.1.1. When reading the first time, I saw table
10.4.8a.3.1 reflecting the names found in the table: PS1, PS2 and PS3. And it
appeared that there are values missing. Typically, when we place a spec
reference on an enum in Osmocom code, it means that this enum *exactly*
represents the given table. This enum, however, is "merely" an internal
indicator, later translated into the table's bit values. The enum definitions
should have a comment sort of like "Puncturing scheme values. See
gprs_rlc_mcs_cps()" without TS table references, and TS refs should be with
that function.

It's also not helpful to place references to two more tables in the comment:
the reader is left guessing what the exact relation is.  If more than one TS
table is involved, the comment should explain the relation.

Cosmetic: the switch() statement in that function has line breaking
that doesn't match Osmocom coding style, making it even harder to read.

These are things we missed when accepting these changes. It would be nice to
get them fixed at some point.

Thanks!
~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: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20161216/b4f658d1/attachment.bin>

From nhofmeyr at sysmocom.de  Fri Dec 16 11:57:36 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 16 Dec 2016 12:57:36 +0100
Subject: enum egprs_puncturing_values
In-Reply-To: <854a1453-b2d2-e37b-e4fa-c093d0f25304@gmx.net>
References: <20161215114500.GB26781@ass40.sysmocom.de>
 <854a1453-b2d2-e37b-e4fa-c093d0f25304@gmx.net>
Message-ID: <20161216115736.GB1481@my.box>

On Thu, Dec 15, 2016 at 02:36:23PM +0100, Jacob wrote:
> Hi Neels,

Hey Jacob!

> AFAICS you are mixing up "puncturing scheme" and "Coding and Puncturing
> Scheme", there are still only three puncturing schemes, where up to 3 of
> them may be used with a certain MCS. The P scheme has to be changed
> (incremented IIRC) after each use.

Well, if it brings you back into Osmocom dev, I might want to start mixing up
things a lot more from now on ;)

Thanks for your remarks, I have since noticed that I let myself be mislead by
the first spec reference in the comment. I find it confusing, but I've posted a
separate mail on that...

> Nevertheless choosing a safe value for INVALID is probably not bad if
> there might be another P in some future spec. But I'd be careful with
> negative values in enums.

I thought negative values in enums are fine? What could be a problem here?
e.g.

  enum my_vals {
  	MY_VAL_INVALID = -1,
	MY_VAL_A = 0,
	MY_VAL_B,
	MY_VAL_C,		
  };

~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: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20161216/6adab280/attachment.bin>

From jacob01 at gmx.net  Fri Dec 16 14:05:35 2016
From: jacob01 at gmx.net (Jacob)
Date: Fri, 16 Dec 2016 15:05:35 +0100
Subject: enum egprs_puncturing_values
In-Reply-To: <20161216115736.GB1481@my.box>
References: <20161215114500.GB26781@ass40.sysmocom.de>
 <854a1453-b2d2-e37b-e4fa-c093d0f25304@gmx.net> <20161216115736.GB1481@my.box>
Message-ID: <bd40ff56-f031-56fe-6285-77411859ca27@gmx.net>

Hi Neels,

On 12/16/2016 12:57 PM, Neels Hofmeyr wrote:
> On Thu, Dec 15, 2016 at 02:36:23PM +0100, Jacob wrote:

> 
> I thought negative values in enums are fine? What could be a problem here?
> e.g.
> 
>   enum my_vals {
>   	MY_VAL_INVALID = -1,
> 	MY_VAL_A = 0,
> 	MY_VAL_B,
> 	MY_VAL_C,		
>   };

I checked that with C99 and you are right. According to ?6.7.2.2 (4) the
compiler must use a signed type for the enum if at least one constant is
a valid negative int. Nevertheless I had some issues with assigning -1
to an enum some time ago, but it might well be that there was no
negative constant involved and I went into some implicit signed/unsigned
conversion hell with differing enum bit sizes or something like that.

Sorry for the noise.

Jacob




> 
> ~N
> 


From nhofmeyr at sysmocom.de  Fri Dec 23 15:46:50 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 23 Dec 2016 16:46:50 +0100
Subject: osmo-pcu: Re: New Defects reported by Coverity Scan for Osmocom
In-Reply-To: <585c18488058e_3540de3334795e3@ss1435.mail>
References: <585c18488058e_3540de3334795e3@ss1435.mail>
Message-ID: <20161223154650.GA9176@my.box>

On Thu, Dec 22, 2016 at 10:15:36AM -0800, scan-admin at coverity.com wrote:

> *** CID 158969:  Null pointer dereferences  (FORWARD_NULL)
> /source-Osmocom/osmo-pcu/src/gprs_rlcmac_sched.cpp: 131 in sched_select_ctrl_msg(unsigned char, unsigned char, unsigned int, unsigned char, gprs_rlcmac_pdch *, gprs_rlcmac_tbf *, gprs_rlcmac_tbf *, gprs_rlcmac_ul_tbf *)()
> 125     	struct msgb *msg = NULL;
> 126     	struct gprs_rlcmac_tbf *tbf = NULL;
> 127     	struct gprs_rlcmac_tbf *next_list[3] = { ul_ass_tbf, dl_ass_tbf, ul_ack_tbf };
> 128     
> 129     	for (size_t i = 0; i < ARRAY_SIZE(next_list); ++i) {
> 130     		tbf = next_list[(pdch->next_ctrl_prio + i) % 3];
> >>>     CID 158969:  Null pointer dereferences  (FORWARD_NULL)
> >>>     Comparing "tbf" to null implies that "tbf" might be null.
> 131     		if (!tbf)
> 132     			continue;
> 133     
> 134     		/*
> 135     		 * Assignments for the same direction have lower precedence,
> 136     		 * because they may kill the TBF when the CONTROL ACK is

Even though coverity triggered on the recent addition of
  tbf->ms()->update_dl_ctrl_msg();
in osmo-pcu da7250ad2c1cd5ddc7d3c6e10435a00b357ef8f7, this problem has existed
before.  This function is handling the tbf pointer improperly. Let's take a
look:


static struct msgb *sched_select_ctrl_msg(
		    uint8_t trx, uint8_t ts, uint32_t fn,
		    uint8_t block_nr, struct gprs_rlcmac_pdch *pdch,
		    struct gprs_rlcmac_tbf *ul_ass_tbf,
		    struct gprs_rlcmac_tbf *dl_ass_tbf,
		    struct gprs_rlcmac_ul_tbf *ul_ack_tbf)
{
	struct msgb *msg = NULL;
	struct gprs_rlcmac_tbf *tbf = NULL;

This NULL init would only make sense if ARRAY_SIZE(next_list) were zero.
Will not happen.

	struct gprs_rlcmac_tbf *next_list[3] = { ul_ass_tbf, dl_ass_tbf, ul_ack_tbf };

	for (size_t i = 0; i < ARRAY_SIZE(next_list); ++i) {
		tbf = next_list[(pdch->next_ctrl_prio + i) % 3];
		if (!tbf)
			continue;

		/*
		 * Assignments for the same direction have lower precedence,
		 * because they may kill the TBF when the CONTROL ACK is
		 * received, thus preventing the others from being processed.
		 */

		if (tbf == ul_ass_tbf && tbf->direction == GPRS_RLCMAC_DL_TBF)
			if (tbf->ul_ass_state ==
					GPRS_RLCMAC_UL_ASS_SEND_ASS_REJ)
				msg = ul_ass_tbf->create_packet_access_reject();
			else
				msg = ul_ass_tbf->create_ul_ass(fn, ts);
		else if (tbf == dl_ass_tbf && tbf->direction == GPRS_RLCMAC_UL_TBF)
			msg = dl_ass_tbf->create_dl_ass(fn, ts);
		else if (tbf == ul_ack_tbf)
			msg = ul_ack_tbf->create_ul_ack(fn, ts);

		if (!msg) {
			tbf = NULL;

If this is not the last for() iteration, setting tbf = NULL makes no sense, it
will be set to next_list[..] at the start of the next iteration.

If this *is* the last iteration, tbf = NULL makes no sense either, because msg
is NULL and tbf will be set to dl_ass_tbf or ul_ass_tbf in the if (!msg) {}
case below.

			continue;
		}

		pdch->next_ctrl_prio += 1;
		pdch->next_ctrl_prio %= 3;
		break;
	}

	if (!msg) {
		/*
		 * If one of these is left, the response (CONTROL ACK) from the
		 * MS will kill the current TBF, only one of them can be
		 * non-NULL
		 */
		if (dl_ass_tbf) {
			tbf = dl_ass_tbf;
			msg = dl_ass_tbf->create_dl_ass(fn, ts);
		} else if (ul_ass_tbf) {
			tbf = ul_ass_tbf;
			msg = ul_ass_tbf->create_ul_ass(fn, ts);
		}
	}

At this point, tbf may be NULL, either from 'if (!tbf) continue;' in the last
iteration, or because dl_ass_tbf or ul_ass_tbf were NULL. Below code assumes
that tbf is non-NULL and will segfault. Add 'if (!tbf) return NULL' here?

	/* any message */
	if (msg) {
		tbf->rotate_in_list();
		LOGP(DRLCMACSCHED, LOGL_DEBUG, "Scheduling control "
			"message at RTS for %s (TRX=%d, TS=%d)\n",
			tbf_name(tbf), trx, ts);
		/* Updates the dl ctrl msg counter for ms */
		tbf->ms()->update_dl_ctrl_msg();
		return msg;
	}
	/* schedule PACKET PAGING REQUEST */
	msg = pdch->packet_paging_request();
	if (msg) {
		LOGP(DRLCMACSCHED, LOGL_DEBUG, "Scheduling paging request "
			"message at RTS for (TRX=%d, TS=%d)\n", trx, ts);

		/* Updates the dl ctrl msg counter for ms */
		tbf->ms()->update_dl_ctrl_msg();
		return msg;
	}

	return NULL;
}


@osmo-pcu tbf folks, please fix this potential segmentation fault ASAP.
Thanks!

~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: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20161223/7e5ee9a5/attachment.bin>

From nhofmeyr at sysmocom.de  Fri Dec 23 22:32:35 2016
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Fri, 23 Dec 2016 23:32:35 +0100
Subject: osmo-pcu: Re: New Defects reported by Coverity Scan for Osmocom
In-Reply-To: <20161223154650.GA9176@my.box>
References: <585c18488058e_3540de3334795e3@ss1435.mail>
 <20161223154650.GA9176@my.box>
Message-ID: <20161223223235.GA7589@my.box>

On Fri, Dec 23, 2016 at 04:46:50PM +0100, Neels Hofmeyr wrote:
> 		if (!msg) {
> 			tbf = NULL;
> 
> If this is not the last for() iteration, setting tbf = NULL makes no sense, it
> will be set to next_list[..] at the start of the next iteration.
> 
> If this *is* the last iteration, tbf = NULL makes no sense either, because msg
> is NULL and tbf will be set to dl_ass_tbf or ul_ass_tbf in the if (!msg) {}
> case below.

Ah, wrong, if both dl_ass_tbf and ul_ass_tbf below are null, this has an
effect.  Maybe it would make slightly more sense to add "else tbf = NULL" below
instead.

> 
> 			continue;
> 		}
> 
> 		pdch->next_ctrl_prio += 1;
> 		pdch->next_ctrl_prio %= 3;
> 		break;
> 	}
> 
> 	if (!msg) {
> 		/*
> 		 * If one of these is left, the response (CONTROL ACK) from the
> 		 * MS will kill the current TBF, only one of them can be
> 		 * non-NULL
> 		 */
> 		if (dl_ass_tbf) {
> 			tbf = dl_ass_tbf;
> 			msg = dl_ass_tbf->create_dl_ass(fn, ts);
> 		} else if (ul_ass_tbf) {
> 			tbf = ul_ass_tbf;
> 			msg = ul_ass_tbf->create_ul_ass(fn, ts);
> 		}
> 	}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20161223/b8579c9b/attachment.bin>