From minh-quang.nguyen at nutaq.com  Mon May  2 13:32:12 2016
From: minh-quang.nguyen at nutaq.com (Minh-Quang Nguyen)
Date: Mon, 2 May 2016 09:32:12 -0400
Subject: PCU sends invalid block number to L1
Message-ID: <86E210CFD3EEDE46A58DE4793CFA6C3F038D4F09@NTWAEX01.interne.lyrtech.com>

Hi All,

 

We have noticed that the PCU sends invalid block number to L1 in DSP leading to unexpected message warning in DSP "GsmL1_PhDataReq(1) : Unexpected burst (Invalid blockNumber) [2!=1, SAPI 21-21]]".

 

After an investigation, we observe that the 'pcu_rx_rts_req' function in pcu_l1_if.cpp receives invalid block number from BTS.

Looking at the BTS side, the calculation of L1SAP_FN2PTCCHBLOCK defined as '#define L1SAP_FN2PTCCHBLOCK(fn) ((fn / 52) & 7)' does not seem to be valid for expected PTCCH block numbers B0, B1,B2,B3 defined in Table 6 in TS 05.02 version 8.11.0.

 

What do you think about re-define the calculation of the L1SAP_FN2PTCCHBLOCK?  

 

Regards,

 

Minh-Quang Nguyen

 

Concepteur logiciel  |  Software designer GSM/Network



 

T. 418 914-7484 x2296  |  1 855 914-7484  |  F. 418 914-9477
2150, Cyrille-Duquet, Qu?bec (Qu?bec)  G1N 2G3 CANADA



 

minh-quang.nguyen at nutaq.com <mailto:minh-quang.nguyen at nutaq.com> 
www.nutaq.com <http://www.nutaq.com/>  

 

QUEBEC MONTREAL NEW YORK <http://www.nutaq.com/signature/nutaq_q_m_ny.jpg> 

 

Facebook <http://www.facebook.com/pages/Nutaq-Innovation/351864938229900>  Twitter <https://twitter.com/NutaqInnovation>  LinkedIn <http://www.linkedin.com/company/Nutaq>  YouTube <http://www.youtube.com/NutaqInnovation> 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/osmocom-net-gprs/attachments/20160502/09836164/attachment.htm>

From laforge at gnumonks.org  Mon May  2 16:48:13 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 2 May 2016 18:48:13 +0200
Subject: PCU sends invalid block number to L1
In-Reply-To: <86E210CFD3EEDE46A58DE4793CFA6C3F038D4F09@NTWAEX01.interne.lyrtech.com>
References: <86E210CFD3EEDE46A58DE4793CFA6C3F038D4F09@NTWAEX01.interne.lyrtech.com>
Message-ID: <20160502164813.GN1619@nataraja>

Hi Minh,

first of all, thanks for helping out in terms of OsmoPCU/OsmoBTS bug
hunting, it is much appreciated.  It is a collaborative project, after
all :)

On Mon, May 02, 2016 at 09:32:12AM -0400, Minh-Quang Nguyen wrote:
> After an investigation, we observe that the 'pcu_rx_rts_req' function
> in pcu_l1_if.cpp receives invalid block number from BTS.
> 
> Looking at the BTS side, the calculation of L1SAP_FN2PTCCHBLOCK
> defined as '#define L1SAP_FN2PTCCHBLOCK(fn) ((fn / 52) & 7)' does not
> seem to be valid for expected PTCCH block numbers B0, B1,B2,B3 defined
> in Table 6 in TS 05.02 version 8.11.0.
> 
> What do you think about re-define the calculation of the L1SAP_FN2PTCCHBLOCK?  

If you find the existing calculation is not agreeing with the
specification (I'd have to re-read the spec, but I trust you when you
say that), I would appreciate if you could send a patch (or patch
series) that changes it to be within the spec.  If the calculation is
more complex, better use a separate function than the simplistic macro.

Thanks in advance!

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 holger at freyther.de  Mon May  2 19:40:33 2016
From: holger at freyther.de (Holger Freyther)
Date: Mon, 2 May 2016 21:40:33 +0200
Subject: PCU sends invalid block number to L1
In-Reply-To: <86E210CFD3EEDE46A58DE4793CFA6C3F038D4F09@NTWAEX01.interne.lyrtech.com>
References: <86E210CFD3EEDE46A58DE4793CFA6C3F038D4F09@NTWAEX01.interne.lyrtech.com>
Message-ID: <4778EEE3-61D2-4518-82C1-2B5709F925F7@freyther.de>


> On 02 May 2016, at 15:32, Minh-Quang Nguyen <minh-quang.nguyen at nutaq.com> wrote:
> 
> Hi All,
>  
> We have noticed that the PCU sends invalid block number to L1 in DSP leading to unexpected message warning in DSP ?GsmL1_PhDataReq(1) : Unexpected burst (Invalid blockNumber) [2!=1, SAPI 21-21]]?.
>  
> After an investigation, we observe that the ?pcu_rx_rts_req? function in pcu_l1_if.cpp receives invalid block number from BTS.
> Looking at the BTS side, the calculation of L1SAP_FN2PTCCHBLOCK defined as ?#define L1SAP_FN2PTCCHBLOCK(fn) ((fn / 52) & 7)? does not seem to be valid for expected PTCCH block numbers B0, B1,B2,B3 defined in Table 6 in TS 05.02 version 8.11.0.

How do you execute the PCU? By opening the PDCH queue directly or by getting all information from the BTS?

holger



From minh-quang.nguyen at nutaq.com  Mon May  2 19:53:51 2016
From: minh-quang.nguyen at nutaq.com (Minh-Quang Nguyen)
Date: Mon, 2 May 2016 15:53:51 -0400
Subject: PCU sends invalid block number to L1
References: <86E210CFD3EEDE46A58DE4793CFA6C3F038D4F09@NTWAEX01.interne.lyrtech.com>
 <4778EEE3-61D2-4518-82C1-2B5709F925F7@freyther.de>
Message-ID: <86E210CFD3EEDE46A58DE4793CFA6C3F038D50A7@NTWAEX01.interne.lyrtech.com>

Hi Holger,

The PDCH queue is directly connected to the PCU ( the PCU was compiled with direct L1 communication)


Minh-Quang Nguyen

Concepteur logiciel??|??Software designer GSM/Network


T. 418 914-7484 x2296??|??1 855 914-7484??|??F. 418 914-9477
2150, Cyrille-Duquet, Qu?bec (Qu?bec)??G1N 2G3 CANADA


minh-quang.nguyen at nutaq.com
www.nutaq.com 

 QUEBEC MONTREAL NEW YORK

Facebook Twitter LinkedIn YouTube


-----Original Message-----
From: Holger Freyther [mailto:holger at freyther.de] 
Sent: Monday, May 02, 2016 3:41 PM
To: Minh-Quang Nguyen
Cc: osmocom-net-gprs at lists.osmocom.org; Yves Godin
Subject: Re: PCU sends invalid block number to L1


> On 02 May 2016, at 15:32, Minh-Quang Nguyen <minh-quang.nguyen at nutaq.com> wrote:
> 
> Hi All,
>  
> We have noticed that the PCU sends invalid block number to L1 in DSP leading to unexpected message warning in DSP ?GsmL1_PhDataReq(1) : Unexpected burst (Invalid blockNumber) [2!=1, SAPI 21-21]]?.
>  
> After an investigation, we observe that the ?pcu_rx_rts_req? function in pcu_l1_if.cpp receives invalid block number from BTS.
> Looking at the BTS side, the calculation of L1SAP_FN2PTCCHBLOCK defined as ?#define L1SAP_FN2PTCCHBLOCK(fn) ((fn / 52) & 7)? does not seem to be valid for expected PTCCH block numbers B0, B1,B2,B3 defined in Table 6 in TS 05.02 version 8.11.0.

How do you execute the PCU? By opening the PDCH queue directly or by getting all information from the BTS?

holger


From holger at freyther.de  Tue May 10 07:19:34 2016
From: holger at freyther.de (Holger Freyther)
Date: Tue, 10 May 2016 09:19:34 +0200
Subject: OpenBSC and related projects moved to Gerrit
Message-ID: <01F3D763-A977-4F41-BCBD-9E22CFC995AD@freyther.de>

Hi,

as discussed at OsmoDevCon and the mails from last week. The following list of projects have moved to use gerrit for codereview:

	* libosmocore.git
	* libosmo-abis.git
	* libosmo-netif.git
	* libosmo-sccp.git
	* libsmpp34.git
	* openbsc.git
	* osmo-bts.git
	* osmo-iuh.git
	* osmo-pcu.git
	* cellmgr-ng.git
	* osmo-sip-connector.git


I have created this[1] page with the minimum to set-up gerrit as git-remote, register, configure the account and then hopefully the most frequently used comments.

kind regards
	holger


[1] http://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit

From Prasad.Kaup at radisys.com  Wed May 25 11:52:28 2016
From: Prasad.Kaup at radisys.com (Prasad Kaup)
Date: Wed, 25 May 2016 11:52:28 +0000
Subject: latest sysmobts-mgr  failure on NURAN 1.0
Message-ID: <BN3PR08MB12376970B004A0A24E2CC26DE6400@BN3PR08MB1237.namprd08.prod.outlook.com>

Hi All,
	We are trying to cross compile and test  latest osmo-pcu,  osmo-bts,  openbsc, osmo-sgsn , and ggsn.  One issue  we see with latest sysmobts-mgr 
 (Commit ed494443cc1e9732b43ef99cccf187d17ac931ef) on Nuran 1.0 is as below.
	- PA is off
	- Signal is very low 
	- No signal on slave.
With  sysmobts-mgr   preloaded(older commit version) on board,   the setup works fine.

Please help us in resolving this issue seen in master branch of osmo-bts latest commit.

Regards
Prasad


From msuraev at sysmocom.de  Thu May 26 09:31:23 2016
From: msuraev at sysmocom.de (Max)
Date: Thu, 26 May 2016 11:31:23 +0200
Subject: MS behavior with dysfunctional GPRS
Message-ID: <5746C26B.5020002@sysmocom.de>

Hi.

Imagine following configuration:
- GSM network advertises GPRS capabilities in System Information messages
- It's not actually available (SGSN crashed, all the timeslots are
occupied by TCH etc)

What would be expected behavior for MS in this scenario?

Shall it switch to alternative network in hope of getting promised GPRS?
Shall it hang on the currently camped network providing voice/sms only?
Which spec(s) cover that? What could be decision factors for the MS? SIM
entries, some data in SI, some timeout somewhere, smth else?

-- 
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: Holger Freyther, Harald Welte 



From laforge at gnumonks.org  Fri May 27 06:41:23 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 27 May 2016 15:41:23 +0900
Subject: MS behavior with dysfunctional GPRS
In-Reply-To: <5746C26B.5020002@sysmocom.de>
References: <5746C26B.5020002@sysmocom.de>
Message-ID: <20160527064122.GF5602@nataraja>

Hi Max,

On Thu, May 26, 2016 at 11:31:23AM +0200, Max wrote:
> What would be expected behavior for MS in this scenario?

I'm not entirely sure what the expected behavior is.

> Shall it switch to alternative network in hope of getting promised GPRS?

If it is a PS-only device, this might make sense. Not sure if it is
mandated anywhere.

The problem is if it is a CS + PS device, and if CS registration worked
on the cell, but PS doesn't. In that case I've not seen any phone ever
considering to select a different cell, let aside a different network.

> Shall it hang on the currently camped network providing voice/sms only?
> Which spec(s) cover that? What could be decision factors for the MS? SIM
> entries, some data in SI, some timeout somewhere, smth else?

Cell (re)selection is traditionally specified in 03.22. Not sure where
it got moved later (when transitioning to post-rel99). Not sure why
23.022 was withdrawn, but there is now 23.122 which has superseeded it.
http://www.etsi.org/deliver/etsi_ts/123100_123199/123122/13.04.00_60/ts_123122v130400p.pdf
is the link to the latest release.  But it's quite complex with 2G/3G/4G
and all the optional features like ProSe, CSG, ...

There's also the 2G-only successor of 03.22: 43.022 at
http://www.etsi.org/deliver/etsi_ts/143000_143099/143022/13.00.00_60/ts_143022v130000p.pdf

-- 
- 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 lynxis at fe80.eu  Tue May 31 12:47:54 2016
From: lynxis at fe80.eu (Alexander Couzens)
Date: Tue, 31 May 2016 14:47:54 +0200
Subject: [PATCH] ggsn/cmdline: remove unused variable check_required
Message-ID: <20160531124754.3107-1-lynxis@fe80.eu>

fix an unused warning
---
 ggsn/cmdline.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/ggsn/cmdline.c b/ggsn/cmdline.c
index 31c0744..2ef87cb 100644
--- a/ggsn/cmdline.c
+++ b/ggsn/cmdline.c
@@ -609,14 +609,12 @@ cmdline_parser_internal (
   
   int override;
   int initialize;
-  int check_required;
   int check_ambiguity;
   
   package_name = argv[0];
   
   override = params->override;
   initialize = params->initialize;
-  check_required = params->check_required;
   check_ambiguity = params->check_ambiguity;
 
   if (initialize)
-- 
2.8.3



From laforge at gnumonks.org  Tue May 31 12:54:41 2016
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 31 May 2016 14:54:41 +0200
Subject: Status of GEA issues in OsmoSGSN
Message-ID: <20160531125441.GB30831@nataraja>

Dear all,

Deater has been investigating which issues currently prevent us from
using GEA in OsmoSGSN.  His mail has been sitting in my inbox too long,
and hence I'm forwarding his results here to the mailing list for
further discussion / follow-up.

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

libosmo-crypt-gea12/src/osmocom.c
---------------------------------

GEA1_stream() and GEA2_stream() operate with bits and not bytes. This
is how they have to be used:

static int gea1_run(uint8_t *out, uint16_t len, uint64_t kc, uint32_t iv,
		     enum gprs_cipher_direction direction)
{
	uint8_t dir;
	uint8_t bits_input[32];
	uint8_t bits_kc[64];
	int i;

	// get 32 input bits
  
	for(i = 0; i < 32; i++)
	{
		bits_input[i] = (BYTE)((iv >> i) & 1);
	}
  
	// get 64 key bits
  
	for(i = 0; i < 64; i++)
	{
	#if 0 // reverse Kc byte order ("reverse" compared to Calypso test code)
		bits_kc[i] = (BYTE)((kc >> i) & 1);
	#else // "normal" Kc byte order (whatever "normal" is)
		bits_kc[i] = (BYTE)((kc >> (((7 - (i / 8)) * 8) + (i % 8))) & 1);
	#endif
	}

	if (direction == GPRS_CIPH_MS2SGSN)
		dir = DIRECTION_UPLINK;
	else
		dir = DIRECTION_DOWNLINK;

	GEA1_stream(bits_kc, bits_input, dir, len, out);

	return 0;
}

static int gea2_run(uint8_t *out, uint16_t len, uint64_t kc, uint32_t iv,
		     enum gprs_cipher_direction direction)
{
	uint8_t dir;
	uint8_t bits_input[32];
	uint8_t bits_kc[64];
	int i;

	// get 32 input bits
  
	for(i = 0; i < 32; i++)
	{
		bits_input[i] = (BYTE)((iv >> i) & 1);
	}
  
	// get 64 key bits
  
	for(i = 0; i < 64; i++)
	{
	#if 0 // reverse Kc byte order ("reverse" compared to Calypso test code)
		bits_kc[i] = (BYTE)((kc >> i) & 1);
	#else // "normal" Kc byte order (whatever "normal" is)
		bits_kc[i] = (BYTE)((kc >> (((7 - (i / 8)) * 8) + (i % 8))) & 1);
	#endif
	}

	if (direction == GPRS_CIPH_MS2SGSN)
		dir = DIRECTION_UPLINK;
	else
		dir = DIRECTION_DOWNLINK;

	GEA2_stream(bits_kc, bits_input, dir, len, out);

	return 0;
}


libosmo-crypt-a53/src/osmocom.c
-------------------------------

The length of the key is in bits and not in bytes:

static int gea3_run(uint8_t *out, uint16_t len, uint64_t kc, uint32_t iv,
		     enum gprs_cipher_direction direction)
{
	uint8_t dir;

	if (direction == GPRS_CIPH_MS2SGSN)
		dir = 0;
	else
		dir = 1;

	GEA3((uint8_t *)&kc, sizeof(kc) * 8, iv, dir, out, len);

	return 0;
}


openbsc/openbsc/src/gprs/gprs_llc.c
-----------------------------------

Frame encryption in gprs_llc_tx_ui() doesn't work:

	/* encrypt information field + FCS, if needed! */
	if (lle->llme->algo != GPRS_ALGO_GEA0) {
		uint32_t iov_ui = 0; /* FIXME: randomly select for TLLI */
		uint16_t crypt_len = (fcs + 3) - (llch + 3);
		uint8_t cipher_out[GSM0464_CIPH_MAX_BLOCK];
		uint32_t iv;
		int rc, i;
		uint64_t kc = *(uint64_t *)&lle->llme->kc;

		/* Compute the 'Input' Paraemeter */
		iv = gprs_cipher_gen_input_ui(iov_ui, sapi, nu, oc);

		/* Compute the keystream that we need to XOR with the data */
		rc = gprs_cipher_run(cipher_out, crypt_len, lle->llme->algo,
				     kc, iv, GPRS_CIPH_SGSN2MS);
		if (rc < 0) {
			LOGP(DLLC, LOGL_ERROR, "Error crypting UI frame: %d\n", rc);
			msgb_free(msg);
			return rc;
		}

		/* Mark frame as encrypted */
		#if 1 // Dieter: recalculate checksum after properly setting the flag
		llch[2] |= 0x02;
		fcs_calc = gprs_llc_fcs(llch, fcs - llch);
		fcs[0] = fcs_calc & 0xff;
		fcs[1] = (fcs_calc >> 8) & 0xff;
		fcs[2] = (fcs_calc >> 16) & 0xff;
		#endif

		/* XOR the cipher output with the information field + FCS */
		for (i = 0; i < crypt_len; i++)
			*(llch + 3 + i) ^= cipher_out[i];

		/* Mark frame as encrypted */
		#if 0 // Dieter: This won't work
		ctrl[1] |= 0x02;
		#endif
	}

Frame decryption in gprs_llc_rcvmsg() doesn't work:

	/* decrypt information field + FCS, if needed! */
	if (llhp.is_encrypted) {
		uint32_t iov_ui = 0; /* FIXME: randomly select for TLLI */
		uint16_t crypt_len = llhp.data_len + 3;
		uint8_t cipher_out[GSM0464_CIPH_MAX_BLOCK];
		uint32_t iv;
		uint64_t kc = *(uint64_t *)&lle->llme->kc;
		int rc, i;

		if (lle->llme->algo == GPRS_ALGO_GEA0) {
			LOGP(DLLC, LOGL_NOTICE, "encrypted frame for LLC that "
				"has no KC/Algo! Dropping.\n");
			return 0;
		}

		iv = gprs_cipher_gen_input_ui(iov_ui, lle->sapi, llhp.seq_tx,
						lle->oc_ui_recv);
		rc = gprs_cipher_run(cipher_out, crypt_len, lle->llme->algo,
				     kc, iv, GPRS_CIPH_MS2SGSN);
		if (rc < 0) {
			LOGP(DLLC, LOGL_ERROR, "Error decrypting frame: %d\n",
			     rc);
			return rc;
		}

		/* XOR the cipher output with the information field + FCS */
		for (i = 0; i < crypt_len; i++)
			*(llhp.data + i) ^= cipher_out[i];

		#if 1 // Dieter: FCS is encrypted, gprs_llc_hdr_parse() should be called again
		llhp.fcs = *(llhp.data + crypt_len - 3);
		llhp.fcs |= *(llhp.data + crypt_len - 2) << 8;
		llhp.fcs |= *(llhp.data + crypt_len - 1) << 16;
		#endif
	} else {
		if (lle->llme->algo != GPRS_ALGO_GEA0) {
			LOGP(DLLC, LOGL_NOTICE, "unencrypted frame for LLC "
				"that is supposed to be encrypted. Dropping.\n");
			return 0;
		}
	}


Open issues:
############

openbsc/openbsc/src/gprs/gprs_llc.c
-----------------------------------

When creating an LLME "on the fly" in lle_for_rx_by_tlli_sapi() kc and algo
of the LLME have to be set to the ones used for the subscriber.


In general:
-----------

Management of GEA algorithm and KC for a subscriber. The algorithm has to
be selected according to the capabilities of the MS. Some affected functions
are gprs_llgmm_assign() and gsm48_tx_gmm_auth_ciph_req(). 


Handling of IOV (initialisation vector), currently most of the time IOV is
set to 0, but gprs_llgmm_reset() and gprs_llgmm_reset_oldmsg() use a random
IOV and would probably cause problems when called.


Using uint64_t as the type for Kc in the GEA libraries is not a good choice,
uint8_t[8] would be better and cause less troubles (e.g. endian issues and
incompatibility with the test vectors, where the order of Kc has to be
reversed). Attention: this change might require to adjust the byte order of
Kc in the GEA libraries.

From msuraev at sysmocom.de  Tue May 31 12:59:50 2016
From: msuraev at sysmocom.de (Max)
Date: Tue, 31 May 2016 14:59:50 +0200
Subject: Status of GEA issues in OsmoSGSN
In-Reply-To: <20160531125441.GB30831@nataraja>
References: <20160531125441.GB30831@nataraja>
Message-ID: <574D8AC6.8020501@sysmocom.de>

> Using uint64_t as the type for Kc in the GEA libraries is not a good choice

This has already been fixed in libosmocore.

-- 
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: Holger Freyther, Harald Welte 



From lynxis at fe80.eu  Tue May 31 12:42:38 2016
From: lynxis at fe80.eu (Alexander Couzens)
Date: Tue, 31 May 2016 14:42:38 +0200
Subject: [PATCH] gtp/queue/queue_seqdel(): fix element check which always was
 true
Message-ID: <20160531124238.29585-1-lynxis@fe80.eu>

Iterate over all member until the correct member found, remove it
and rearrange the seqnext pointer
---
 gtp/queue.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/gtp/queue.c b/gtp/queue.c
index 5b4d849..fbfa1ec 100644
--- a/gtp/queue.c
+++ b/gtp/queue.c
@@ -105,8 +105,7 @@ static int queue_seqdel(struct queue_t *queue, struct qmsg_t *qmsg)
 		printf("Begin queue_seqdel seq = %d\n", (int)qmsg->seq);
 
 	for (qmsg2 = queue->hashseq[hash]; qmsg2; qmsg2 = qmsg2->seqnext) {
-		/* FIXME: this is always true !?! */
-		if (qmsg == qmsg) {
+		if (qmsg == qmsg2) {
 			if (!qmsg_prev)
 				queue->hashseq[hash] = qmsg2->seqnext;
 			else
-- 
2.8.3



From msuraev at sysmocom.de  Tue May 31 13:15:30 2016
From: msuraev at sysmocom.de (Max)
Date: Tue, 31 May 2016 15:15:30 +0200
Subject: [PATCH] ggsn/cmdline: remove unused variable check_required
In-Reply-To: <20160531124754.3107-1-lynxis@fe80.eu>
References: <20160531124754.3107-1-lynxis@fe80.eu>
Message-ID: <574D8E72.8080509@sysmocom.de>

I think we should drop ggsn/cmdline.* from git and add compile-time
dependency on gengetopt. It's available everywhere anyway and this would
match the way we deal with generated code in libosmocore.

On 05/31/2016 02:47 PM, Alexander Couzens wrote:
> fix an unused warning
> ---
>  ggsn/cmdline.c | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/ggsn/cmdline.c b/ggsn/cmdline.c
> index 31c0744..2ef87cb 100644
> --- a/ggsn/cmdline.c
> +++ b/ggsn/cmdline.c
> @@ -609,14 +609,12 @@ cmdline_parser_internal (
>    
>    int override;
>    int initialize;
> -  int check_required;
>    int check_ambiguity;
>    
>    package_name = argv[0];
>    
>    override = params->override;
>    initialize = params->initialize;
> -  check_required = params->check_required;
>    check_ambiguity = params->check_ambiguity;
>  
>    if (initialize)

-- 
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: Holger Freyther, Harald Welte