From michaelspahn.osmo at gmail.com  Tue Apr  3 08:30:55 2018
From: michaelspahn.osmo at gmail.com (Michael Spahn)
Date: Tue, 3 Apr 2018 10:30:55 +0200
Subject: nanoBTS constantly restarting
In-Reply-To: <20180329103001.GW26197@nataraja>
References: <D7603E08-A05A-4640-80BC-453F32EC0CA9@gmail.com>
 <20180329103001.GW26197@nataraja>
Message-ID: <651EDA38-D7AE-4740-9913-23179A8C7FAE@gmail.com>

Hi, 

so I?ve disabled sending of System Information Types and now the BTS isn?t rebooting anymore and the log doesn?t seem to show any errors. However, as long as osmo-bsc is running my phone endlessly scans for networks. The scan only ends when I stop osmo-bsc. I guess that?s a configuration issue of some sort?

Kind regards,

Michael

> On 29. Mar 2018, at 12:30, Harald Welte <laforge at gnumonks.org> wrote:
> 
> Hi Michael,
> 
> On Thu, Mar 29, 2018 at 08:43:20AM +0200, Michael Spahn wrote:
>> BTS 0: Failure Event Report: Type=processing failure, Severity=critical failure, Probable cause=Manufacturer specific values: Fatal software error, Additional Text=BCHbcchSItypeValid( prim_p->infoType ). 
> 
> It seems that the nanoBTS, at least in the firmware version you are using, is not supporting
> a certain system information type that OsmoBSC is sending.  We have no documentation on those
> nanoBTS, but it might be something like SI2ter / SI2quater that it doesn't like.
> 
> You could try to disable generation/sending of those.  I think we simply iterate over
> all SI types and send an empty system information as BCCH INFO via RSL to make sure
> that the BTS doesn't transmit any SI that it might have cached from state initialized
> before the current RSL connection.
> 
> So OsmoBSC might suppress some of those, depending on bts-model nanobts/osmobts.
> 
> Interesting side-note:
> 
> We have recently added nanoBTS support to osmo-gsm-tester, i.e. we're contintuously
> testing SMS and call signalling with latest 'master' of all osmocom code against
> two nanoBTSs that are connected to the osmo-gsm-tester setup.
> 
> @Pau: Do we see any indication that our setup is showing the same issues?
> 
> If we don't see it in our setup, it most likely depends on the specific firmware
> release installed on the nanoBTS.  Without knowing when exactly the support for the
> related SI types was introduced, it's difficult to automatically determine
> if we should send SI2ter/SI2quater, or if we should not send it
> 
> -- 
> - Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                  (ETSI EN 300 175-7 Ch. A6)



From laforge at gnumonks.org  Tue Apr  3 08:57:20 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 3 Apr 2018 10:57:20 +0200
Subject: nanoBTS constantly restarting
In-Reply-To: <651EDA38-D7AE-4740-9913-23179A8C7FAE@gmail.com>
References: <D7603E08-A05A-4640-80BC-453F32EC0CA9@gmail.com>
 <20180329103001.GW26197@nataraja>
 <651EDA38-D7AE-4740-9913-23179A8C7FAE@gmail.com>
Message-ID: <20180403085720.GI3545@nataraja>

On Tue, Apr 03, 2018 at 10:30:55AM +0200, Michael Spahn wrote:
> Hi, 
> 
> so I?ve disabled sending of System Information Types 

which of the types did you disable, and which are still sent?

> and now the BTS isn?t rebooting anymore and the log doesn?t seem to show any errors. However, as long as osmo-bsc is running my phone endlessly scans for networks. The scan only ends when I stop osmo-bsc. I guess that?s a configuration issue of some sort?

You will need SI2/3/4 as a minimum.  And those of course shouldn't contain any indication that other SI types are present, as otherwise the phone will wait for that SI to appear.

-- 
- 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 michaelspahn.osmo at gmail.com  Tue Apr  3 10:04:29 2018
From: michaelspahn.osmo at gmail.com (Michael Spahn)
Date: Tue, 3 Apr 2018 12:04:29 +0200
Subject: nanoBTS constantly restarting
In-Reply-To: <20180403085720.GI3545@nataraja>
References: <D7603E08-A05A-4640-80BC-453F32EC0CA9@gmail.com>
 <20180329103001.GW26197@nataraja>
 <651EDA38-D7AE-4740-9913-23179A8C7FAE@gmail.com>
 <20180403085720.GI3545@nataraja>
Message-ID: <415BBE2D-3650-4C0A-8A47-8CBFFB402E55@gmail.com>

Nevermind, it?s working perfectly now, I accidentally disabled all SI types?.
So the only type I disabled is SI2quater and now everything seems to work completely fine.
Doesn?t SI2quater handle 3G-related information? I could see why that would cause problems on a 2G cell.

> On 3. Apr 2018, at 10:57, Harald Welte <laforge at gnumonks.org> wrote:
> 
> On Tue, Apr 03, 2018 at 10:30:55AM +0200, Michael Spahn wrote:
>> Hi, 
>> 
>> so I?ve disabled sending of System Information Types 
> 
> which of the types did you disable, and which are still sent?
> 
>> and now the BTS isn?t rebooting anymore and the log doesn?t seem to show any errors. However, as long as osmo-bsc is running my phone endlessly scans for networks. The scan only ends when I stop osmo-bsc. I guess that?s a configuration issue of some sort?
> 
> You will need SI2/3/4 as a minimum.  And those of course shouldn't contain any indication that other SI types are present, as otherwise the phone will wait for that SI to appear.
> 
> -- 
> - 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 pespin at sysmocom.de  Tue Apr  3 11:50:44 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Tue, 3 Apr 2018 13:50:44 +0200
Subject: nanoBTS constantly restarting
In-Reply-To: <415BBE2D-3650-4C0A-8A47-8CBFFB402E55@gmail.com>
References: <D7603E08-A05A-4640-80BC-453F32EC0CA9@gmail.com>
 <20180329103001.GW26197@nataraja>
 <651EDA38-D7AE-4740-9913-23179A8C7FAE@gmail.com>
 <20180403085720.GI3545@nataraja>
 <415BBE2D-3650-4C0A-8A47-8CBFFB402E55@gmail.com>
Message-ID: <c91c45b8-dc59-ce7c-31ea-000f249261d6@sysmocom.de>

For reference in case you are interested, it's probably not the same 
issue but I also noticed a few days ago some issues when using nanoBTS 
with SI 2ter. See https://osmocom.org/issues/3063

In this case sending the SI2ter prevents some phones from registering to 
my network.
I didn't have time to give it a deeper look yet.

-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte


From laforge at gnumonks.org  Tue Apr  3 13:08:34 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 03 Apr 2018 15:08:34 +0200
Subject: nanoBTS constantly restarting
In-Reply-To: <c91c45b8-dc59-ce7c-31ea-000f249261d6@sysmocom.de>
References: <D7603E08-A05A-4640-80BC-453F32EC0CA9@gmail.com>
 <20180329103001.GW26197@nataraja>
 <651EDA38-D7AE-4740-9913-23179A8C7FAE@gmail.com>
 <20180403085720.GI3545@nataraja>
 <415BBE2D-3650-4C0A-8A47-8CBFFB402E55@gmail.com>
 <c91c45b8-dc59-ce7c-31ea-000f249261d6@sysmocom.de>
Message-ID: <EE1D543C-8854-404B-84F6-D62DC42D64EC@gnumonks.org>

From reading the osmocom redmine bug 3063, it seems to me yoiu simply suppressed si5ter, not si2ter?
-- 
Sent from a mobile device. Please excuse my brevity.


From choukoumoun at gmail.com  Tue Apr  3 13:49:49 2018
From: choukoumoun at gmail.com (Choukoumoun)
Date: Tue, 3 Apr 2018 15:49:49 +0200
Subject: [OPENBSC] IP.ACCESS nano3G Model # 239C
Message-ID: <72695758-cf1f-e631-8783-af17e87a3fa9@gmail.com>

Hello,


The? IP.ACCESS nano3G Model # 239C is compatible with openbsc 2G or
osmocom 3g APPS ?



Thank you.




From laforge at gnumonks.org  Tue Apr  3 14:12:56 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 3 Apr 2018 16:12:56 +0200
Subject: [OPENBSC] IP.ACCESS nano3G Model # 239C
In-Reply-To: <72695758-cf1f-e631-8783-af17e87a3fa9@gmail.com>
References: <72695758-cf1f-e631-8783-af17e87a3fa9@gmail.com>
Message-ID: <20180403141256.GQ3545@nataraja>

On Tue, Apr 03, 2018 at 03:49:49PM +0200, Choukoumoun wrote:
> The? IP.ACCESS nano3G Model # 239C is compatible with openbsc 2G or
> osmocom 3g APPS ?

A 3G femtocell can never be compatible with a 2G core network, only with a 3G.

Does the specific nano3G unit and its installed software/firmware implement Iuh?
In that case, it is very likely to work with osmo-iuh.

-- 
- 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 Jan.Bruckner at escrypt.com  Wed Apr  4 10:14:02 2018
From: Jan.Bruckner at escrypt.com (Bruckner Jan (ETAS-SEC/ECT-Mu))
Date: Wed, 4 Apr 2018 10:14:02 +0000
Subject: Missing dependency libosmo-mgcp0 when installing osmo-mgw
Message-ID: <dadb9b23be3e45879d9085bb9adada96@escrypt.com>

Hi all,

When trying to install the osmo-mgw package from the Latest repository, the
package cannot be installed because the dependency libosmo-mgcp0 is not
found.
The message is: "osmo-mgw : Depends: libosmo-mgcp0 but it is not
installable"

I'm using the Debian 9 repository and my OS is Debian 9.4.

Looking into the dependencies, I see that osmo-mgw depends on both
libosmo-mgcp0 and libosmo-mgcp1. Are both of these actually necessary or
should the libosmo-mgcp0 dependency be removed?
Installing the libosmo-legacy-mgcp0 package does not help either.

Thanks,
Jan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6732 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180404/08c65793/attachment.bin>

From laforge at gnumonks.org  Wed Apr  4 11:11:12 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 4 Apr 2018 13:11:12 +0200
Subject: Missing dependency libosmo-mgcp0 when installing osmo-mgw
In-Reply-To: <dadb9b23be3e45879d9085bb9adada96@escrypt.com>
References: <dadb9b23be3e45879d9085bb9adada96@escrypt.com>
Message-ID: <20180404111112.GA3545@nataraja>

Hi Jan,

On Wed, Apr 04, 2018 at 10:14:02AM +0000, Bruckner Jan (ETAS-SEC/ECT-Mu) wrote:
> When trying to install the osmo-mgw package from the Latest repository, the
> package cannot be installed because the dependency libosmo-mgcp0 is not
> found.

sorry for that.

> Looking into the dependencies, I see that osmo-mgw depends on both
> libosmo-mgcp0 and libosmo-mgcp1. Are both of these actually necessary or
> should the libosmo-mgcp0 dependency be removed?

without looking at the details, my initial gut feeling is that the
dependency to libosmo-mgcp0 is wrong and only libosmo-mgcp1 should be
there.

-- 
- 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  Wed Apr  4 13:10:18 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 4 Apr 2018 15:10:18 +0200
Subject: log rotation in libosmocore?
Message-ID: <20180404131018.GA13571@my.box>

I client of ours has the desire to merge a patch to libosmocore that adds
simplistic log rotation functionality.

Our first response was against it: we have the SIGHUP handling that allows
logrotate to tell osmocom programs to re-open their log file(s).

However, the system in question is based on BusyBox, which lacks logrotate. I
haven't yet investigated why it can't just be installed, but there seems to be
some or other issue about that.

The next best idea is to cook up a shell script that does more or less what
logrotate does ... and probably run into problems that logrotate already
solves better. The script needs to clean old files and invoke SIGHUP...

So I'd like to ask around, maybe it is acceptable to merge a poor-man's log
rotation functionality to libosmocore after all?

The patch needs some improvements (VTY configurability for starters), but so
far goes something like this:


 static void _file_output(struct log_target *target, unsigned int level,
 			 const char *log)
 {
-	fprintf(target->tgt_file.out, "%s", log);
-	fflush(target->tgt_file.out);
+	int n;
+
+	if (target->tgt_file.out) {
+
+		n = fprintf(target->tgt_file.out, "%s", log);
+		fflush(target->tgt_file.out);
+#ifdef stderr
+		/* don't try try to roll stderr */
+		if (target->tgt_file.out != stderr)
+#endif
+		{
+			if (n > 0) {
+				target->tgt_file.written_count += n;
+
+				if (target->tgt_file.roll_count != 0 &&
+					target->tgt_file.written_count > target->tgt_file.roll_count) {
+
+					/* Create filename */
+					char rotname[strlen(target->tgt_file.fname) + 3];
+
+					strcpy(rotname, target->tgt_file.fname);
+					strcat(rotname, ".1");
+
+					/* Rename the current log, then reopen the log to start new file */
+					rename(target->tgt_file.fname, rotname);
+					log_target_file_reopen(target);
+				}
+			}
+		}
+	}
 }


Note, this follows a simplistic approach to removing old log files: there is
always exactly one rotated-away file, 'mylogfile.1', which gets overwritten in
each rotation.

Any rotation features more elaborate than this should better be solved with
logrotate, but would everyone accept this kind of patch merged to libosmocore?

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/20180404/8c97597c/attachment.bin>

From nhofmeyr at sysmocom.de  Wed Apr  4 13:41:04 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Wed, 4 Apr 2018 15:41:04 +0200
Subject: Missing dependency libosmo-mgcp0 when installing osmo-mgw
In-Reply-To: <20180404111112.GA3545@nataraja>
References: <dadb9b23be3e45879d9085bb9adada96@escrypt.com>
 <20180404111112.GA3545@nataraja>
Message-ID: <20180404134104.GB13571@my.box>

Taking a look in the git history:

osmo-mgw has since moved to not installing libosmo-mgcp at all, but keeping it
as a local lib.
http://git.osmocom.org/osmo-mgw/commit/?id=19d640e806919b61ae7ef2b53a588491725a48f6

(There are related patches before that, made obsolete by the above, like
http://git.osmocom.org/osmo-mgw/commit/?id=641c4d47b90b408dd0f7f7657648e62bce38944e )

The conclusion is that we should urgently update the latest feeds:
http://osmocom.org/issues/2834

~N

On Wed, Apr 04, 2018 at 01:11:12PM +0200, Harald Welte wrote:
> Hi Jan,
> 
> On Wed, Apr 04, 2018 at 10:14:02AM +0000, Bruckner Jan (ETAS-SEC/ECT-Mu) wrote:
> > When trying to install the osmo-mgw package from the Latest repository, the
> > package cannot be installed because the dependency libosmo-mgcp0 is not
> > found.
> 
> sorry for that.
> 
> > Looking into the dependencies, I see that osmo-mgw depends on both
> > libosmo-mgcp0 and libosmo-mgcp1. Are both of these actually necessary or
> > should the libosmo-mgcp0 dependency be removed?
> 
> without looking at the details, my initial gut feeling is that the
> dependency to libosmo-mgcp0 is wrong and only libosmo-mgcp1 should be
> there.
> 
> -- 
> - 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)

-- 
- 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/20180404/d07fc55e/attachment.bin>

From laforge at gnumonks.org  Wed Apr  4 14:15:31 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 4 Apr 2018 16:15:31 +0200
Subject: log rotation in libosmocore?
In-Reply-To: <20180404131018.GA13571@my.box>
References: <20180404131018.GA13571@my.box>
Message-ID: <20180404141531.GD3545@nataraja>

Hi Neels,

I'm not fundamentally opposed, but I still believe it is the wrong thing to merge
a patch like this.

Any reasonably advanced embedded Linux system will be running more than just the
osmocom daemons/processes, and most if not all of them are going to be writing some
logs somewhere.  Yes, that one particular user might not need it *now*. But what if
they add another standard program later? Does this program then also need to be patched
with a custom log-rotate reimplementation?

So whether you use logrotate, or journald, or whatever other mechanism of dealing
with logs and related rotation, the task will always be the same.

So I'm actually more in favor of helping to make logrotate work with busybox, or
writing a small "micro logrotate" in C that can either become part of libosmocore
or be distributed as separate program/project.   This way the related functionality
is not only limited to Osmocom programs, but potentially any other log-file-writing
program out there.

If you reduce configurability to a minimum, that program wouldn't be
doing much, after all, right?

btw: This post on the busybox mailing list suggest to log to stderr and pipe that
to svlogd, which allegedly has the vcapability yo rotate logs:
	http://lists.busybox.net/pipermail/busybox/2011-January/074413.html

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 michaelspahn.osmo at gmail.com  Thu Apr  5 06:12:33 2018
From: michaelspahn.osmo at gmail.com (Michael Spahn)
Date: Thu, 5 Apr 2018 08:12:33 +0200
Subject: How to find IMSI for OsmoHLR
Message-ID: <D0083081-1587-4A11-A576-8640A26BC8AE@gmail.com>

Hi,

I am currently having some problems in adding new subscribers to OsmoHLR, particularly, in finding the IMSI of the devices.
From what I gathered from the wiki, the OsmoHLR log is supposed to show the IMSI of any mobile stations trying to connect to my network without being subscribers. However, the log does not show any indication of that whatsoever. 

I had previously imported an old database from our previous OsmoNITB setup and all devices that had been added as subscribers with SimpleHLR back then were able to connect to the new setup flawlessly, but now I have decided to delete an MS from the database to learn how to add new subscribers but like I?ve said before, I am not able to find the IMSI in any log. 

These are the logging settings in my OsmoHLR config:
log stderr
  logging filter all 1
  logging color 1
  logging print category 1
  logging timestamp 1
  logging print extended-timestamp 1
  logging level all debug
  logging level linp error

I?d really appreciate if someone could help me out here.

Kind regards,

Michael Spahn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180405/95856faf/attachment.htm>

From djks74 at gmail.com  Thu Apr  5 12:05:05 2018
From: djks74 at gmail.com (Sandi Suhendro)
Date: Thu, 05 Apr 2018 12:05:05 +0000
Subject: How to find IMSI for OsmoHLR
In-Reply-To: <D0083081-1587-4A11-A576-8640A26BC8AE@gmail.com>
References: <D0083081-1587-4A11-A576-8640A26BC8AE@gmail.com>
Message-ID: <CANWiJYiyEX_r7-zReLRYsvvDKe=X3Ykghxu9uPDreRZ4MrmmOg@mail.gmail.com>

Go to Vty via telnet then subs id 1 show

Regards,
DUO

On 13:12, Thu, Apr 5, 2018 Michael Spahn <michaelspahn.osmo at gmail.com>
wrote:

> Hi,
>
> I am currently having some problems in adding new subscribers to OsmoHLR,
> particularly, in finding the IMSI of the devices.
> From what I gathered from the wiki, the OsmoHLR log is supposed to show
> the IMSI of any mobile stations trying to connect to my network without
> being subscribers. However, the log does not show any indication of that
> whatsoever.
>
> I had previously imported an old database from our previous OsmoNITB setup
> and all devices that had been added as subscribers with SimpleHLR back then
> were able to connect to the new setup flawlessly, but now I have decided to
> delete an MS from the database to learn how to add new subscribers but like
> I?ve said before, I am not able to find the IMSI in any log.
>
> These are the logging settings in my OsmoHLR config:
>
> log stderr
>   logging filter all 1
>   logging color 1
>   logging print category 1
>   logging timestamp 1
>   logging print extended-timestamp 1
>   logging level all debug
>   logging level linp error
>
>
> I?d really appreciate if someone could help me out here.
>
> Kind regards,
>
> Michael Spahn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180405/b60c29be/attachment.htm>

From antony at funquality.be  Fri Apr  6 08:36:06 2018
From: antony at funquality.be (Antony Lemmens)
Date: Fri, 6 Apr 2018 10:36:06 +0200
Subject: Bug #1617 CBCH implementation for osmo-bts-trx
Message-ID: <CAD3eK9SrNBVdro336OegrWM1s4wHAVNeNfucVBwSCrBWjiD8kQ@mail.gmail.com>

Hello,
I'm currently working on a proof of concept for a foreign customer. We have
a Fairwaves UmTRX board and we would like to send Cell Broadcast message
(SMS-CB).
I have a full working osmocom chain (trx, bts-trx, bsc, stp, msc, hlr) that
woks fine for SMS sending by example.

I have made a fix in rsl.c because all SMSCB commands where rejected (see
at bottom of this message).

I have dig into the code and found the place where the SMS CB are queued
(rsl.c : bts_process_smscb_cmd) and the code to extract them as MAC blocks
(rsl.c : bts_cbch_get).

I have also found the handler of the scheduler (scheduler_trx.c
: tx_data_fn) where to put the block data.

I have read articles about the superframe mechanism but I do not figure out
how to advertise the CBCH functionality on the BCCH, nor how to adapt the
scheduler to enable the CB channel.


Is it someone also interrested in this and/or working on the Bug 1617?
Or is it someone that can me give a track to start the implementation?


Have a nice day,
Antony


-----------------------------------------------------------------------------------------------------------
Fix in rsl.c :
-----------------------------------------------------------------------------------------------------------
replaced :
        if (chan_nr_is_dchan(cch->chan_nr))
               return rsl_reject_unknown_lchan(msg);

       msg->lchan = lchan_lookup(trx, cch->chan_nr, "RSL rx CCHAN: ");
       if (!msg->lchan) {
               LOGP(DRSL, LOGL_ERROR, "Rx RSL %s for unknown lchan\n",
                       rsl_msg_name(cch->c.msg_type));
               return rsl_reject_unknown_lchan(msg);
      }

-----------------------------------------------------------------------------------------------------------
by:
if (chan_nr_is_dchan(cch->chan_nr))
        {
            printf("Message NOT for DCHAN\n");
            //return rsl_reject_unknown_lchan(msg);
        }
        else
        {
            printf("Message for DCHAN\n");

            // Only check channel validity if  it is a dedicated channel
call.
            msg->lchan = lchan_lookup(trx, cch->chan_nr, "RSL rx CCHAN: ");
            if (!msg->lchan) {
                    LOGP(DRSL, LOGL_ERROR, "Rx RSL %s for unknown lchan\n",
                            rsl_msg_name(cch->c.msg_type));
                    return rsl_reject_unknown_lchan(msg);
            }
        }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180406/d8872e9c/attachment.htm>

From laforge at gnumonks.org  Fri Apr  6 08:59:05 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 6 Apr 2018 10:59:05 +0200
Subject: Bug #1617 CBCH implementation for osmo-bts-trx
In-Reply-To: <CAD3eK9SrNBVdro336OegrWM1s4wHAVNeNfucVBwSCrBWjiD8kQ@mail.gmail.com>
References: <CAD3eK9SrNBVdro336OegrWM1s4wHAVNeNfucVBwSCrBWjiD8kQ@mail.gmail.com>
Message-ID: <20180406085905.GS4305@nataraja>

Hi Antony,

On Fri, Apr 06, 2018 at 10:36:06AM +0200, Antony Lemmens wrote:
> I have read articles about the superframe mechanism but I do not figure out
> how to advertise the CBCH functionality on the BCCH, 

The Osmocom stack should take care of this "automatically" if
the osmo-bts-trx low-level code gets the required support.

As you may have seen, CBCH operation is already supported with several other
BTS back-ends inside osmo-bts.  Unfortunately, for osmo-bts-trx nobody has
been contributing the related code so far.

> nor how to adapt the scheduler to enable the CB channel.

This boils down to the tables in osmo-bts/src/scheduler_mframe.c where
you can e.g. find "static const struct trx_sched_frame frame_bcch[51]"
which defines the 51-multiframe for the non-combined BCCH and "static
const struct trx_sched_frame frame_bcch_sdcch4[102]" for the combined
BCCH, as well as "static const struct trx_sched_frame frame_sdcch8"

AFAIR, the BCCH can be on a combined BCCH or on a SDCCH/8.  You would
have to create copies of "frame_bcch_sdcch4" and "frame_sdcch8" and edit
those copies to confirm with the way how the respective multiframe is
specified when CBCH is enabled.  As far as I remember from memory, it's
always the second sub-channel that's replaced with CBCH instead of
SDCCH.  See the related specs, I think mostly 3GPP TS 45.002

> Is it someone also interrested in this and/or working on the Bug 1617?

I'm interested but seriously have no time to work on this.  At sysmocm
we could work on it as a development project under contract, but we also
have quite a backlog so it might be best if somebody else works on this.

> Or is it someone that can me give a track to start the implementation?

My notes above should help with implementing it.

-- 
- 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 antony at funquality.be  Fri Apr  6 09:19:58 2018
From: antony at funquality.be (Antony Lemmens)
Date: Fri, 6 Apr 2018 11:19:58 +0200
Subject: Bug #1617 CBCH implementation for osmo-bts-trx
In-Reply-To: <20180406085905.GS4305@nataraja>
References: <CAD3eK9SrNBVdro336OegrWM1s4wHAVNeNfucVBwSCrBWjiD8kQ@mail.gmail.com>
 <20180406085905.GS4305@nataraja>
Message-ID: <CAD3eK9TG3O6PS71E_2tixCagZFLQj30k+Bfupf+yD6aPaQ8nNw@mail.gmail.com>

Hello Harald,
thanks for you quick answer, I'll take a look on that.

Have a nice day,
Antony

On Fri, Apr 6, 2018 at 10:59 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Antony,
>
> On Fri, Apr 06, 2018 at 10:36:06AM +0200, Antony Lemmens wrote:
> > I have read articles about the superframe mechanism but I do not figure
> out
> > how to advertise the CBCH functionality on the BCCH,
>
> The Osmocom stack should take care of this "automatically" if
> the osmo-bts-trx low-level code gets the required support.
>
> As you may have seen, CBCH operation is already supported with several
> other
> BTS back-ends inside osmo-bts.  Unfortunately, for osmo-bts-trx nobody has
> been contributing the related code so far.
>
> > nor how to adapt the scheduler to enable the CB channel.
>
> This boils down to the tables in osmo-bts/src/scheduler_mframe.c where
> you can e.g. find "static const struct trx_sched_frame frame_bcch[51]"
> which defines the 51-multiframe for the non-combined BCCH and "static
> const struct trx_sched_frame frame_bcch_sdcch4[102]" for the combined
> BCCH, as well as "static const struct trx_sched_frame frame_sdcch8"
>
> AFAIR, the BCCH can be on a combined BCCH or on a SDCCH/8.  You would
> have to create copies of "frame_bcch_sdcch4" and "frame_sdcch8" and edit
> those copies to confirm with the way how the respective multiframe is
> specified when CBCH is enabled.  As far as I remember from memory, it's
> always the second sub-channel that's replaced with CBCH instead of
> SDCCH.  See the related specs, I think mostly 3GPP TS 45.002
>
> > Is it someone also interrested in this and/or working on the Bug 1617?
>
> I'm interested but seriously have no time to work on this.  At sysmocm
> we could work on it as a development project under contract, but we also
> have quite a backlog so it might be best if somebody else works on this.
>
> > Or is it someone that can me give a track to start the implementation?
>
> My notes above should help with implementing it.
>
> --
> - Harald Welte <laforge at gnumonks.org>
> http://laforge.gnumonks.org/
> ============================================================
> ================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch.
> A6)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180406/c678826a/attachment.htm>

From radiarisainanasitraka at yahoo.fr  Fri Apr  6 09:27:20 2018
From: radiarisainanasitraka at yahoo.fr (Radiarisainana Sitraka)
Date: Fri, 6 Apr 2018 09:27:20 +0000 (UTC)
Subject: SS7 on osmocom-3G
References: <1311210579.165909.1523006840433.ref@mail.yahoo.com>
Message-ID: <1311210579.165909.1523006840433@mail.yahoo.com>

My quesitonn is , with the osmocom-3G and the box nanocell3G for example; it is possible to send ss7 message like sri-for-sm, ...!?


Chears,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180406/64dc75b2/attachment.htm>

From laforge at gnumonks.org  Fri Apr  6 12:10:26 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 6 Apr 2018 14:10:26 +0200
Subject: SS7 on osmocom-3G
In-Reply-To: <1311210579.165909.1523006840433@mail.yahoo.com>
References: <1311210579.165909.1523006840433.ref@mail.yahoo.com>
 <1311210579.165909.1523006840433@mail.yahoo.com>
Message-ID: <20180406121026.GT4305@nataraja>

On Fri, Apr 06, 2018 at 09:27:20AM +0000, Radiarisainana Sitraka wrote:
> My quesitonn is , with the osmocom-3G and the box nanocell3G for example; it is possible to send ss7 message like sri-for-sm, ...!?

FYI: SRI-for-SM is not a SS7 Message, but a MAP message.   MAP runs several
layers on top of SS7.  However, SS7 is used for much more than just MAP.

In the osmocom stack, we currently do not support TCAP/MAP.

There have been several attempts in the past, like

* C language libosmo-tcap + libosmo-map (abandoned ~ 2012)
* Erlang language "signerl" used in some real-world scenarios but 
  development discontinued in 2013):
  http://git.osmocom.org/erlang/signerl/

* A Smalltalk implementation that Holger did (I don't have a source code
  link around)

There has never been any contribution (in terms of code or funding) to have
a proper MAP implementation in the Osmocom stack.  Today, the best approach
to do this is to implement a proxy between the GSUP protocol and TCAP/MAP
on the other side.

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 Apr 10 01:27:47 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Tue, 10 Apr 2018 03:27:47 +0200
Subject: How to find IMSI for OsmoHLR
In-Reply-To: <D0083081-1587-4A11-A576-8640A26BC8AE@gmail.com>
References: <D0083081-1587-4A11-A576-8640A26BC8AE@gmail.com>
Message-ID: <20180410012747.GA29276@my.box>

Hi Michael,

unknown IMSIs should in fact be logged in the AUC logging category, like this:

  osmo-hlr.log:20180316135557286 DAUC INFO db_auc.c:98 IMSI='123412341234123': No such subscriber

and/or

  osmo-hlr.log:20180311013340990 DAUC NOTICE hlr.c:83 123412341234123: IMSI not known

I've found before that sometimes 'logging level all debug' doesn't seem to give
expected results, haven't figured out quite why yet. So maybe try to explicitly pass:

  logging level auc info

Hope that helps...

So, IMSI should work (but looking for the IMEI is no longer possible at the
moment: in osmo-nitb times, some followed the practice of watching out for a
specific IMEI in the logs, but it is not logged by osmo-hlr nor osmo-msc.)

~N

On Thu, Apr 05, 2018 at 08:12:33AM +0200, Michael Spahn wrote:
> Hi,
> 
> I am currently having some problems in adding new subscribers to OsmoHLR, particularly, in finding the IMSI of the devices.
> From what I gathered from the wiki, the OsmoHLR log is supposed to show the IMSI of any mobile stations trying to connect to my network without being subscribers. However, the log does not show any indication of that whatsoever. 
> 
> I had previously imported an old database from our previous OsmoNITB setup and all devices that had been added as subscribers with SimpleHLR back then were able to connect to the new setup flawlessly, but now I have decided to delete an MS from the database to learn how to add new subscribers but like I?ve said before, I am not able to find the IMSI in any log. 
> 
> These are the logging settings in my OsmoHLR config:
> log stderr
>   logging filter all 1
>   logging color 1
>   logging print category 1
>   logging timestamp 1
>   logging print extended-timestamp 1
>   logging level all debug
>   logging level linp error
> 
> I?d really appreciate if someone could help me out here.
> 
> Kind regards,
> 
> Michael Spahn

-- 
- 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/20180410/50a0cacd/attachment.bin>

From choukoumoun at gmail.com  Wed Apr 11 18:20:36 2018
From: choukoumoun at gmail.com (Choukoumoun)
Date: Wed, 11 Apr 2018 20:20:36 +0200
Subject: [OPENBSC] IP.ACCESS nano3G Model # 239C
In-Reply-To: <72695758-cf1f-e631-8783-af17e87a3fa9@gmail.com>
References: <72695758-cf1f-e631-8783-af17e87a3fa9@gmail.com>
Message-ID: <73a6a00f-83a4-03a4-fb18-d34a39d77579@gmail.com>

Hello.


Im looking for the? commissioning user name and the password of the
nano3G 239C.

Anybody ?

Thank you.


Le 03/04/2018 ? 15:49, Choukoumoun a ?crit?:
> Hello,
>
>
> The? IP.ACCESS nano3G Model # 239C is compatible with openbsc 2G or
> osmocom 3g APPS ?
>
>
>
> Thank you.
>
>

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

From philipp.maier at runningserver.com  Wed Apr 11 19:12:25 2018
From: philipp.maier at runningserver.com (Philipp Maier)
Date: Wed, 11 Apr 2018 21:12:25 +0200
Subject: Siemens BS11 for local pickup in Berlin
Message-ID: <58d97089-22ea-c35c-8474-eacf6265de03@runningserver.com>

Hello Folks,

I managed to get something smaller to perform the experiments I 
occasionally do. Because of this, I want to pass on my BS11 to someone 
else. I am giving away the equipment for free. However I have an 
interest in giving it to someone who has an honest interest in in 
GSM/osmocom topics. I think the BS11 is suitable for beginners as it is 
very well documented in the wiki and there are many people out there who 
have some experience with this type of equipment.

The BS11 comes ready to use with a somewhat outdated osmo-nitb 
installation on a small PC that also houses the E1 card. So in theory 
one just needs to switch it on and the GSM network is ready to use. 
However, there will be some work required to install a recent 
OS/osmo-nitb to catch up with the current state.

The BS11 is located in the north of Berlin and has to be picked up by 
someone locally.

If you are interested, please get in contact with me.

Here are some pictures of the equipment:
http://pub.runningserver.com/pics/bs11/

best regards,
Philipp Maier


From laforge at gnumonks.org  Wed Apr 11 20:22:08 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Wed, 11 Apr 2018 22:22:08 +0200
Subject: Save the Date: OsmoCon 2018 on October 18-19, 2018
Message-ID: <20180411202208.GD28162@nataraja>

== OsmoCon 2018 ==

OsmoCon (Osmocom Conference) 2018 is the technical conference for
Osmocom users, operators and developers!

We are happy to announce the date of OsmoCon 2018. It has been scheduled
on October 18 + 19, 2018 and will happen in Berlin, Germany.

For the second time, the Osmocom Conference brings together users,
operators and developers of the Osmocom Open Source cellular
infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN
and others.

Join us for two days of presentations and discussions with the main
developers behind Open Source Mobile Communications, as well as
commercial and non-profit users of the Osmocom cellular infrastructure
software.

You can find some initial information in our wiki at
http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018
which will be updated as more information becomes available.


== Call for Participation ==

We're also at the same time announcing the Call for Participation and
call on everyone with experiences to share around the Osmocom member
projects to submit talks, workshops, discussions or other proposals.

You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp

We are particularly looking for contributions about:

* updates on features/functionality/status of individual Osmocom projects
* success stories on how Osmocom projects are deployed in practice
* migration from OsmoNITB to the post-NITB architecture
* tutorials / workshops on how to setup / analyze Osmocom projects
* statistics, reporting, operations aspects of Osmocom projects
* third-party open source utilities to be used with Osmocom projects

Looking forward to meeting many existing and new Osmocom users at OsmCon
this October!

Regards,
	Harald Welte

-- 
- 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 Apr 12 13:09:26 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 12 Apr 2018 15:09:26 +0200
Subject: [OPENBSC] IP.ACCESS nano3G Model # 239C
In-Reply-To: <73a6a00f-83a4-03a4-fb18-d34a39d77579@gmail.com>
References: <72695758-cf1f-e631-8783-af17e87a3fa9@gmail.com>
 <73a6a00f-83a4-03a4-fb18-d34a39d77579@gmail.com>
Message-ID: <20180412130926.GA1700@my.box>

did you look at the wiki?
http://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_ipaccess_nano3G
ymmv though

~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/20180412/3748ec7c/attachment.bin>

From choukoumoun at gmail.com  Thu Apr 12 13:12:56 2018
From: choukoumoun at gmail.com (Choukou Moun)
Date: Thu, 12 Apr 2018 13:12:56 +0000
Subject: [OPENBSC] IP.ACCESS nano3G Model # 239C
In-Reply-To: <20180412130926.GA1700@my.box>
References: <72695758-cf1f-e631-8783-af17e87a3fa9@gmail.com>
 <73a6a00f-83a4-03a4-fb18-d34a39d77579@gmail.com>
 <20180412130926.GA1700@my.box>
Message-ID: <CA+StwqkmOzRcnV6OwQErUtu-2-eAVWxcv___vN06oYrd2W3LXA@mail.gmail.com>

I did, thanks!
But when you reset the BTS. You have only a 60 second web-interface open to
configure your BTS and you need the password.

Do you have another hard reset procedure?

Thank you.

Le jeu. 12 avr. 2018 ? 15:09, Neels Hofmeyr <nhofmeyr at sysmocom.de> a ?crit :

> did you look at the wiki?
>
> http://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_ipaccess_nano3G
> ymmv though
>
> ~N
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180412/486627a9/attachment.htm>

From info at tech-mobil.com  Thu Apr 12 14:02:13 2018
From: info at tech-mobil.com (=?utf-8?B?0KLQtdGHINCc0L7QsdC40Ls=?=)
Date: Thu, 12 Apr 2018 17:02:13 +0300
Subject: Service Category Information Element
In-Reply-To: <1402951523540016@web10g.yandex.ru>
Message-ID: <902021523541733@web45g.yandex.ru>


Dear all,

At the moment we are doing some development works on the basis of ?Osmocom/OpenBTS? project.
May you kindly advise if it is possible to get Service Category Information Element for a call (description in TS 124 008 V13.7.0 10.5.4.33)?
If it is possible could you please tell what variable or function to search?
As far as we get it, it is somewhere within gsm_04_08.c

Thank you very much in advance.



From axilirator at gmail.com  Sat Apr 14 23:27:23 2018
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Sun, 15 Apr 2018 06:27:23 +0700
Subject: Service Category Information Element
Message-ID: <CAPEnp=bW5ivCUTj9CotjnEq6_eh4899bPoXZ+Qc0aw=g-m-A7w@mail.gmail.com>

Hi,

> get Service Category Information Element for a call
> (description in TS 124 008 V13.7.0 10.5.4.33)

According to the mentioned specification, this IE is an optional
part of SETUP message. So, your assumption:

> it is somewhere within gsm_04_08.c

is correct. Have a look at the gsm48_cc_rx_setup():

> /* emergency setup is identified by msg_type */
> if (msg_type == GSM48_MT_CC_EMERG_SETUP)

Emergency calls are also handled there.

The following IEs are handled:

> if (TLVP_PRESENT(&tp, GSM48_IE_BEARER_CAP)) ...
> if (TLVP_PRESENT(&tp, GSM48_IE_FACILITY)) ...
> if (TLVP_PRESENT(&tp, GSM48_IE_CALLED_BCD)) ...
> if (TLVP_PRESENT(&tp, GSM48_IE_USER_USER)) ...
> if (TLVP_PRESENT(&tp, GSM48_IE_SS_VERS)) ...
> if (TLVP_PRESENT(&tp, GSM48_IE_CLIR_SUPP)) ...
> if (TLVP_PRESENT(&tp, GSM48_IE_CLIR_INVOC)) ...
> if (TLVP_PRESENT(&tp, GSM48_IE_CC_CAP)) ...

So, you need to implement checking for the Service Category IE
yourself. It has 0x2e tag, and doesn't seem to be supported by
libosmocore. You would also need to implement parsing of the
payload yourself.

Contributions are welcome ;)

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

From ron.menez at entropysolution.com  Mon Apr 16 02:55:08 2018
From: ron.menez at entropysolution.com (Ron)
Date: Mon, 16 Apr 2018 02:55:08 +0000
Subject: MO-SMS Maximum Number of Characters for OSMO-NITB and OSMO-BSC
 less than 60?
In-Reply-To: <eacd58cf-d630-7636-032e-7786d837c2fd@rhizomatica.org>
References: <8038E9A6-485D-4593-8FED-DD6EF74B5EE5@entropysolution.com>
 <eacd58cf-d630-7636-032e-7786d837c2fd@rhizomatica.org>
Message-ID: <8036A439-26AC-4305-97E2-8C2960E703A1@entropysolution.com>

Hi Pau and Keith,

We updated to the latest version and the SMS for both osmo-nitb and osmo-bsc are now working fine.

Thanks for the advised.

Best Regard,

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




On Mar 25, 2018, at 6:21 PM, Keith Whyte <keith at rhizomatica.org<mailto:keith at rhizomatica.org>> wrote:



On 23/03/18 16:24, Ron wrote:
Hi All,
Hi Ron.


Can anyone confirm if the maximum MO-SMS that can be sent is less than
60 characters including spaces?

I have worked quite extensively with SMS and have not experienced any
such limitation at all, or any deviation from standard. AFAIK an SMS
payload is 140 bytes, Always. What you get in there depends on other
things, like what character are in the message.


For OSMO-NITB, we reach a maximum of 59 characters for MO-SMS, while
for OSMO-BSC, we only reach a maximum of 50 characters (MO-SMS).

Can you elaborate about your setup, what it is you are doing?
What is it you are experiencing when you send a longer message?
Are you using SMPP, or only inside the nitb/bsc?
It is the MS that forms the SMS, not the network. I've never seen
anything where the network says "sorry too big, split that SMS into
two", I don't believe such a thing exists.










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

From ron.menez at entropysolution.com  Mon Apr 16 06:40:33 2018
From: ron.menez at entropysolution.com (Ron)
Date: Mon, 16 Apr 2018 06:40:33 +0000
Subject: OSMO-BSC: Segmentation fault (core dumped)
Message-ID: <AF1FCC72-2976-4AC2-904C-FA0A211583BC@entropysolution.com>

Hi All,

We are experiencing Segmentation Fault intermittently in OSMO-BSC.

We were able to create a crash file and enabled the debug in all logs of OSMO-BSC.

We are using Ettus B210, intel UPBOARD and running in UBUNTU 16.04.

# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 16.04.4 LTS
Release:  16.04
Codename:  xenial

Attached are the debug log file, core dumped file (URL provided for download), config files used, lshw, and lscpu output.

# lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    1
Core(s) per socket:    4
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 92
Model name:            Intel(R) Pentium(R) CPU N4200 @ 1.10GHz
Stepping:              9
CPU MHz:               800.000
CPU max MHz:           1101.0000
CPU min MHz:           800.0000
BogoMIPS:              2188.79
Virtualization:        VT-x
L1d cache:             24K
L1i cache:             32K
L2 cache:              1024K
NUMA node0 CPU(s):     0-3
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 ds_cpl vmx est tm2 ssse3 sdbg cx16 xtpr pdcm sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave rdrand lahf_lm 3dnowprefetch intel_pt tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust smep erms mpx rdseed smap clflushopt sha_ni xsaveopt xsavec xgetbv1 dtherm ida arat pln pts

We also installed the OSMOCOM elements using source and save in the /usr/local directory.

https://www.dropbox.com/s/pedh1zshhe5kmuc/core?dl=0

Best Regard,

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180416/3a14508b/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OSMO-BSC_CORE_DUMPED.zip
Type: application/zip
Size: 38455 bytes
Desc: OSMO-BSC_CORE_DUMPED.zip
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180416/3a14508b/attachment.zip>

From nhofmeyr at sysmocom.de  Mon Apr 16 11:18:59 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 16 Apr 2018 13:18:59 +0200
Subject: OSMO-BSC: Segmentation fault (core dumped)
In-Reply-To: <AF1FCC72-2976-4AC2-904C-FA0A211583BC@entropysolution.com>
References: <AF1FCC72-2976-4AC2-904C-FA0A211583BC@entropysolution.com>
Message-ID: <20180416111859.5juvettiblw7pkjn@ass40.sysmocom.de>

Hi Ron,

Thanks for your report!

I can try to reproduce the issue, but if you have it available, the
following would be immensely useful:

You've offered the core file as download, but that is of no use without
the exact matching binary. Please instead provide the backtrace like:

  gdb path/to/osmo-bsc core
  > bt

If the failure occurs reliably, you can also run osmo-bsc in gdb

  gdb --args osmo-bsc -c [...]

When the segfault occurs, you'll get a gdb prompt and can do 'bt' to get a
backtrace. If you are reproducing it, a network trace (pcap) of the events
leading up to the failure would also be helpful.

The default compilation should already include the debug symbols, i.e.
CFLAGS containing "-g". Otherwise, the debian feeds also contain packages
with debug symbols included.

Ideally, you would create a new issue on osmocom.org in the OsmoBSC
project and provide the backtrace, pcap and logs as attachments there.
Attaching files to issues is preferable to sending mails with attachments,
since everyone subscribed would receive attached files in their mail
inboxes; we prefer to avoid that, for netiquette.

For creating issues, I will gladly provide permissions to your registered
user. I see Justin Repello and Sonny Lafuente (sharing your email's domain
name) registered at osmocom.org, and just gave those users "Developer"
permissions. Let me know of any other users you would like me to enable.
The enable step is merely to avoid spam, you're more than welcome to join
anytime.

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: 833 bytes
Desc: not available
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180416/197b7001/attachment.bin>

From ron.menez at entropysolution.com  Tue Apr 17 08:48:05 2018
From: ron.menez at entropysolution.com (Ron)
Date: Tue, 17 Apr 2018 08:48:05 +0000
Subject: OSMO-BSC: Segmentation fault (core dumped)
In-Reply-To: <20180416111859.5juvettiblw7pkjn@ass40.sysmocom.de>
References: <AF1FCC72-2976-4AC2-904C-FA0A211583BC@entropysolution.com>
 <20180416111859.5juvettiblw7pkjn@ass40.sysmocom.de>
Message-ID: <CFEF2769-F25C-4930-86CD-85F4B1616207@entropysolution.com>

Hi Neels,

Thanks for your report!

I can try to reproduce the issue, but if you have it available, the
following would be immensely useful:

You've offered the core file as download, but that is of no use without
the exact matching binary. Please instead provide the backtrace like:

 gdb path/to/osmo-bsc core
bt

If the failure occurs reliably, you can also run osmo-bsc in gdb

 gdb --args osmo-bsc -c [...]

When the segfault occurs, you'll get a gdb prompt and can do 'bt' to get a
backtrace. If you are reproducing it, a network trace (pcap) of the events
leading up to the failure would also be helpful.

We?ll be sharing the matching binary for this. We?ll try to replicate the segfault again and share the backtrace.


The default compilation should already include the debug symbols, i.e.
CFLAGS containing "-g". Otherwise, the debian feeds also contain packages
with debug symbols included.

Ideally, you would create a new issue on osmocom.org<http://osmocom.org> in the OsmoBSC
project and provide the backtrace, pcap and logs as attachments there.
Attaching files to issues is preferable to sending mails with attachments,
since everyone subscribed would receive attached files in their mail
inboxes; we prefer to avoid that, for netiquette.

We already registered to osmocom.org<http://osmocom.org> and we?ll share the backtrace, logs, and pcap files to the issue register.

Noted on sending mails with attachments. Apologies for our previous emails.

Best Regard,

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


On Apr 16, 2018, at 7:18 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>> wrote:

Hi Ron,

Thanks for your report!

I can try to reproduce the issue, but if you have it available, the
following would be immensely useful:

You've offered the core file as download, but that is of no use without
the exact matching binary. Please instead provide the backtrace like:

 gdb path/to/osmo-bsc core
bt

If the failure occurs reliably, you can also run osmo-bsc in gdb

 gdb --args osmo-bsc -c [...]

When the segfault occurs, you'll get a gdb prompt and can do 'bt' to get a
backtrace. If you are reproducing it, a network trace (pcap) of the events
leading up to the failure would also be helpful.

The default compilation should already include the debug symbols, i.e.
CFLAGS containing "-g". Otherwise, the debian feeds also contain packages
with debug symbols included.

Ideally, you would create a new issue on osmocom.org<http://osmocom.org> in the OsmoBSC
project and provide the backtrace, pcap and logs as attachments there.
Attaching files to issues is preferable to sending mails with attachments,
since everyone subscribed would receive attached files in their mail
inboxes; we prefer to avoid that, for netiquette.

For creating issues, I will gladly provide permissions to your registered
user. I see Justin Repello and Sonny Lafuente (sharing your email's domain
name) registered at osmocom.org<http://osmocom.org>, and just gave those users "Developer"
permissions. Let me know of any other users you would like me to enable.
The enable step is merely to avoid spam, you're more than welcome to join
anytime.

Thanks!

~N

--
- Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto: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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180417/1654a93b/attachment.htm>

From laforge at gnumonks.org  Tue Apr 17 19:56:09 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 17 Apr 2018 21:56:09 +0200
Subject: osmo-ttcn3-hacks / BSC tests: No mor need for IPA CCM cherry-pick!
Message-ID: <20180417195609.GR27085@nataraja>

Dear fellow Osmocmo developers,

for many months it was required to cherry-pick a "HACK" patch to make
the BSC tests work, presumably to work around a bug in libosmo-abis, see
https://osmocom.org/issues/2718

As it turned out, libosmo-abis was not wrong, but my IPA_Emulation.ttcn,
so it was good to not merge that "HACK" and keep it out of master.

In Change-Id: I6d9eaf0d69457caacc03b9049a8bc57976480617 which was just
merged to osmo-ttcn3-hacks master I have fixed that bug in
IPA_Emulation.ttcn, so now the unmodified master of osmo-ttcn3-hacks
will run fine.

I'll remove the cherry-pick from our Dockerfiles, but please do make
sure you also stop using it in your local clones/branches/scripts.

-- 
- 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 Jan.Bruckner at escrypt.com  Wed Apr 18 13:21:27 2018
From: Jan.Bruckner at escrypt.com (Bruckner Jan (ETAS-SEC/ECT-Mu))
Date: Wed, 18 Apr 2018 13:21:27 +0000
Subject: Problems with A5/3 encryption
In-Reply-To: <20180307125651.GB5344@my.box>
References: <cd52e343997942ca915eaa2485dde5b2@escrypt.com>
 <1028CB04-C63E-4570-9BB4-B15872D7B556@tomcsanyi.net>
 <4a6d021926e34f5eb3d1946d80975424@escrypt.com>
 <20180306161003.gixgtlr7kuh3zv5e@ass40.sysmocom.de>
 <7dcb09b7cca34de18fb7c9025792f5b2@escrypt.com> <20180307125651.GB5344@my.box>
Message-ID: <a2f363baad194e1588190036f8961b31@escrypt.com>

Hi,

I migrated my setup to the new Network In The Box configuration with separated components (from latest, not nightly). I tested whether the described issue with A5/3 is resolved, but it still does not work. Though, the behavior has changed.

In the old setup a Ciphering Mode Command for A5/3 was sent, but a Ciphering Mode Complete was never received. Probably, what was happening is the following:
> The details there are that the Ciphering Mode Command is asking to start ciphering on the air, and the Ciphering Mode Complete is already sent > ciphered.
> So it might be received, but the received data may be discarded as gibberish.

In the new setup not even the Ciphering Mode Command is sent to the MS. Instead the BSC sends a Cipher Mode Reject to the MSC, if I am reading the logs correctly:

<000a> a_iface_bssap.c:629 Rx MSC DT1 BSSMAP CIPHER MODE REJECT
<000a> a_iface_bssap.c:453 BSC sends cipher mode reject (conn_id=65)
<000a> a_iface_bssap.c:457 Cause code is missing -- discarding message!
<0027> sms_queue.c:156 Sending SMS 13 failed 0 times.

The full log is attached to the issue [1].

I am setting the encryption to A5/3 in both the MSC and the BSC. A5/1 continues to work without any problems.

Thanks,
Jan


[1] https://osmocom.org/issues/3043



From ron.menez at entropysolution.com  Thu Apr 19 08:43:56 2018
From: ron.menez at entropysolution.com (Ron)
Date: Thu, 19 Apr 2018 08:43:56 +0000
Subject: OSMO-BSC: Segmentation fault (core dumped)
In-Reply-To: <CFEF2769-F25C-4930-86CD-85F4B1616207@entropysolution.com>
References: <AF1FCC72-2976-4AC2-904C-FA0A211583BC@entropysolution.com>
 <20180416111859.5juvettiblw7pkjn@ass40.sysmocom.de>
 <CFEF2769-F25C-4930-86CD-85F4B1616207@entropysolution.com>
Message-ID: <8C6C6088-6CEC-45A2-91D5-D3F1E8FE2ACA@entropysolution.com>

Hi Neels,

Issue is now in osmocom.org<http://osmocom.org> issues list. Kindly see URL below:

https://osmocom.org/issues/3182

Thanks.

Best Regard,

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

On Apr 17, 2018, at 4:48 PM, Ron <ron.menez at entropysolution.com<mailto:ron.menez at entropysolution.com>> wrote:

Hi Neels,

Thanks for your report!

I can try to reproduce the issue, but if you have it available, the
following would be immensely useful:

You've offered the core file as download, but that is of no use without
the exact matching binary. Please instead provide the backtrace like:

 gdb path/to/osmo-bsc core
bt

If the failure occurs reliably, you can also run osmo-bsc in gdb

 gdb --args osmo-bsc -c [...]

When the segfault occurs, you'll get a gdb prompt and can do 'bt' to get a
backtrace. If you are reproducing it, a network trace (pcap) of the events
leading up to the failure would also be helpful.

We?ll be sharing the matching binary for this. We?ll try to replicate the segfault again and share the backtrace.


The default compilation should already include the debug symbols, i.e.
CFLAGS containing "-g". Otherwise, the debian feeds also contain packages
with debug symbols included.

Ideally, you would create a new issue on osmocom.org<http://osmocom.org/> in the OsmoBSC
project and provide the backtrace, pcap and logs as attachments there.
Attaching files to issues is preferable to sending mails with attachments,
since everyone subscribed would receive attached files in their mail
inboxes; we prefer to avoid that, for netiquette.

We already registered to osmocom.org<http://osmocom.org/> and we?ll share the backtrace, logs, and pcap files to the issue register.

Noted on sending mails with attachments. Apologies for our previous emails.

Best Regard,

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


On Apr 16, 2018, at 7:18 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto:nhofmeyr at sysmocom.de>> wrote:

Hi Ron,

Thanks for your report!

I can try to reproduce the issue, but if you have it available, the
following would be immensely useful:

You've offered the core file as download, but that is of no use without
the exact matching binary. Please instead provide the backtrace like:

 gdb path/to/osmo-bsc core
bt

If the failure occurs reliably, you can also run osmo-bsc in gdb

 gdb --args osmo-bsc -c [...]

When the segfault occurs, you'll get a gdb prompt and can do 'bt' to get a
backtrace. If you are reproducing it, a network trace (pcap) of the events
leading up to the failure would also be helpful.

The default compilation should already include the debug symbols, i.e.
CFLAGS containing "-g". Otherwise, the debian feeds also contain packages
with debug symbols included.

Ideally, you would create a new issue on osmocom.org<http://osmocom.org/> in the OsmoBSC
project and provide the backtrace, pcap and logs as attachments there.
Attaching files to issues is preferable to sending mails with attachments,
since everyone subscribed would receive attached files in their mail
inboxes; we prefer to avoid that, for netiquette.

For creating issues, I will gladly provide permissions to your registered
user. I see Justin Repello and Sonny Lafuente (sharing your email's domain
name) registered at osmocom.org<http://osmocom.org/>, and just gave those users "Developer"
permissions. Let me know of any other users you would like me to enable.
The enable step is merely to avoid spam, you're more than welcome to join
anytime.

Thanks!

~N

--
- Neels Hofmeyr <nhofmeyr at sysmocom.de<mailto: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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180419/60b79956/attachment.htm>

From nhofmeyr at sysmocom.de  Thu Apr 19 13:18:48 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Thu, 19 Apr 2018 15:18:48 +0200
Subject: Problems with A5/3 encryption
In-Reply-To: <a2f363baad194e1588190036f8961b31@escrypt.com>
References: <cd52e343997942ca915eaa2485dde5b2@escrypt.com>
 <1028CB04-C63E-4570-9BB4-B15872D7B556@tomcsanyi.net>
 <4a6d021926e34f5eb3d1946d80975424@escrypt.com>
 <20180306161003.gixgtlr7kuh3zv5e@ass40.sysmocom.de>
 <7dcb09b7cca34de18fb7c9025792f5b2@escrypt.com>
 <20180307125651.GB5344@my.box>
 <a2f363baad194e1588190036f8961b31@escrypt.com>
Message-ID: <20180419131848.GA5226@my.box>

On Wed, Apr 18, 2018 at 01:21:27PM +0000, Bruckner Jan (ETAS-SEC/ECT-Mu) wrote:
> Hi,
> 
> I migrated my setup to the new Network In The Box configuration with separated components (from latest, not nightly). I tested whether the described issue with A5/3 is resolved, but it still does not work. Though, the behavior has changed.
> 
> In the old setup a Ciphering Mode Command for A5/3 was sent, but a Ciphering Mode Complete was never received. Probably, what was happening is the following:
> > The details there are that the Ciphering Mode Command is asking to start ciphering on the air, and the Ciphering Mode Complete is already sent > ciphered.
> > So it might be received, but the received data may be discarded as gibberish.
> 
> In the new setup not even the Ciphering Mode Command is sent to the MS.

Commented in OS#3043 on the reason why A5/3 gets rejected.
I'm continuing discussion there instead of duplicating on the mailing list.

> Instead the BSC sends a Cipher Mode Reject to the MSC, if I am reading the logs correctly:
>
> <000a> a_iface_bssap.c:629 Rx MSC DT1 BSSMAP CIPHER MODE REJECT
> <000a> a_iface_bssap.c:453 BSC sends cipher mode reject (conn_id=65)

This bit confuses me: how can the BSC reject a Cipher Mode if the MSC never
sent a Cipher Mode Command?

The BSC would send a Cipher Mode Reject if it finds the algorithm requested by
the MSC not supported in the osmo-bsc.cfg. Maybe we also do that if A5/0 (no
encryption) is not listed in osmo-bsc.cfg??

> <000a> a_iface_bssap.c:457 Cause code is missing -- discarding message!

Interesting. I have identified https://osmocom.org/issues/3186 and https://osmocom.org/issues/3187

> A5/1 continues to work without any problems.

The root cause for all of this is most probably above missing-classmark
problem, but it turns out to be a good thing that it helped us uncover a bunch
of errors in error handling.

Thanks for your reports!

~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/20180419/7438f34b/attachment.bin>

From antony at funquality.be  Mon Apr 23 11:35:21 2018
From: antony at funquality.be (Antony Lemmens)
Date: Mon, 23 Apr 2018 13:35:21 +0200
Subject: VLR problem
Message-ID: <CAD3eK9SUknV9PGhjOMx-Gk5r34rWnozBw2Lyg3Lvkt7W4xraRA@mail.gmail.com>

Hello folks,
I have a strange behavior when the a MS send a Location Update, it is often
rejected.

I think the the problem is the "Rx GSUP LU Result without LU in progress"
(see log further).

It's weird because in the point of view of the HLR it seems OK :

   - message 0x04 Update Location Request followed by 0x10 Insert
   Subscriber Data Request
   - message 0x12 Insert Subscriber Data Result followed by 0x06 Update
   Location Result


Is anyone experiencing the same problem?

I will investigate in the code to see if I found something with the state
machines or timers, if I found more detail, I will post them.

Have a nice day,
Antony



Here is a extract of the logs of osmo-msc :

20180423132534278 DBSSAP <0010> a_iface_bssap.c:268 Rx BSSMAP COMPLETE L3
INFO (conn_id=4)
20180423132534278 DVLR <000e> vlr.c:388 New subscr, TMSI: 0xb35bd0aa
20180423132534278 DMSC <0006> a_iface_bssap.c:351 User has been accepted by
MSC.
20180423132534748 DVLR <000e> gsm_04_08.c:3729 SUBSCR(MSISDN:1) VLR: update
for IMSI=206012225318490 (MSISDN=1, used=2)
20180423132534748 DVLR <000e> vlr.c:769 SUBSCR(MSISDN:1) Rx GSUP LU Result
without LU in progress
20180423132539279 DMM <0002> subscr_conn.c:110
Subscr_Conn(LU:3009138858)[0x1387410]{SUBSCR_CONN_S_AUTH_CIPH}: Close
event, cause: CONGESTION
20180423132539279 DMM <0002> gsm_04_08.c:217 Subscriber
IMSI:206012225318490: LOCATION UPDATING REJECT
20180423132539279 DMM <0002> vlr_lu_fsm.c:728
Subscr_Conn(LU:3009138858)[0x1387410]{SUBSCR_CONN_S_RELEASING}: Event
SUBSCR_CONN_E_CN_CLOSE not permitted
20180423132539279 DBSSAP <0010> a_iface.c:419 (subscr IMSI:206012225318490,
conn_id 4) Tx BSSMAP CLEAR COMMAND to BSC
20180423132539281 DBSSAP <0010> a_iface_bssap.c:241 (subscr
IMSI:206012225318490, conn_id 4) Rx BSSMAP CLEAR COMPLETE, releasing SCCP
connection
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180423/8a1960c2/attachment.htm>

From nhofmeyr at sysmocom.de  Mon Apr 23 21:42:26 2018
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 23 Apr 2018 23:42:26 +0200
Subject: VLR problem
In-Reply-To: <CAD3eK9SUknV9PGhjOMx-Gk5r34rWnozBw2Lyg3Lvkt7W4xraRA@mail.gmail.com>
References: <CAD3eK9SUknV9PGhjOMx-Gk5r34rWnozBw2Lyg3Lvkt7W4xraRA@mail.gmail.com>
Message-ID: <20180423214226.GB2642@my.box>

Hi Antony,

thanks for reporting!

I haven't seen the behavior you describe.

The VLR wants to first send a GSUP Update Location Request to the HLR before it
receives a reply to it. From the short logs that you sent it's hard to figure
out whether that was the case, or if not, why.

Does this happen only sporadically or do you have a sure-shot way to reproduce
the failure?

If you have an account on osmocom.org, I can enable permissions for you to
create an issue, to attach all logs and a network trace.

~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/20180423/71a856fc/attachment.bin>

From laforge at gnumonks.org  Tue Apr 24 06:14:02 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 24 Apr 2018 08:14:02 +0200
Subject: reporting issues in osmocom.org (Re: VLR problem)
In-Reply-To: <20180423214226.GB2642@my.box>
References: <CAD3eK9SUknV9PGhjOMx-Gk5r34rWnozBw2Lyg3Lvkt7W4xraRA@mail.gmail.com>
 <20180423214226.GB2642@my.box>
Message-ID: <20180424061402.GK5235@nataraja>

Side Note:\

On Mon, Apr 23, 2018 at 11:42:26PM +0200, Neels Hofmeyr wrote:

> If you have an account on osmocom.org, I can enable permissions for you to
> create an issue, to attach all logs and a network trace.

I think issue creation / reporting is public, i.e. works after self-registration
of an user account.  Only editing wiki pages requires an explicit permission, as
we had too many problems with wiki spam.


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


From laforge at gnumonks.org  Tue Apr 24 06:19:14 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 24 Apr 2018 08:19:14 +0200
Subject: GSUP dissector merged to wireshark mainline
Message-ID: <20180424061914.GM5235@nataraja>

Hi!

In case anyone wants to analyze GSUP protocol traces of Osmocom networks: The
related dissector has just been merged mainline two days ago:
https://code.wireshark.org/review/25477

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 antony at funquality.be  Tue Apr 24 07:28:40 2018
From: antony at funquality.be (Antony Lemmens)
Date: Tue, 24 Apr 2018 09:28:40 +0200
Subject: VLR problem
In-Reply-To: <20180423214226.GB2642@my.box>
References: <CAD3eK9SUknV9PGhjOMx-Gk5r34rWnozBw2Lyg3Lvkt7W4xraRA@mail.gmail.com>
 <20180423214226.GB2642@my.box>
Message-ID: <CAD3eK9RtufbUANPesHczLOUiYUTMhUxg9sykRRQJSn85wA_brA@mail.gmail.com>

Hello,
I will do a more in deep analysis of the behavior, gather all logs and
traces and post them back :-)
It is happening really often in my setup when I get out my phone from my
osmo gsm network  and put it back just after.

On Mon, Apr 23, 2018 at 11:42 PM, Neels Hofmeyr <nhofmeyr at sysmocom.de>
wrote:

> Hi Antony,
>
> thanks for reporting!
>
> I haven't seen the behavior you describe.
>
> The VLR wants to first send a GSUP Update Location Request to the HLR
> before it
> receives a reply to it. From the short logs that you sent it's hard to
> figure
> out whether that was the case, or if not, why.
>
> Does this happen only sporadically or do you have a sure-shot way to
> reproduce
> the failure?
>
> If you have an account on osmocom.org, I can enable permissions for you to
> create an issue, to attach all logs and a network trace.
>
> ~N
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/openbsc/attachments/20180424/1b664906/attachment.htm>

From snehasish.cse at LIVE.COM  Thu Apr 26 08:50:56 2018
From: snehasish.cse at LIVE.COM (Snehasish Kar)
Date: Thu, 26 Apr 2018 08:50:56 +0000
Subject: Opensbc support of 165CU
Message-ID: <PN1PR0101MB203108D580C30E9A389289A5888E0@PN1PR0101MB2031.INDPRD01.PROD.OUTLOOK.COM>

Hi


Does the current openbsc version doesn't support ipaccess nanobts 165cu (Equipment_Version='165c029_67', result in abisip-find) ?? I am getting some unsupported error while running osmo-nitb. I have installed following from this link.

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



BR

Snehasish

Build from Source - Cellular Network Infrastructure - Open ...<https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source>
osmocom.org
External dependencies?. If you want to build on specific Linux distros, you might need to install additional dependencies before the build will succeed


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

From pespin at sysmocom.de  Thu Apr 26 20:43:04 2018
From: pespin at sysmocom.de (Pau Espin Pedrol)
Date: Thu, 26 Apr 2018 22:43:04 +0200
Subject: Opensbc support of 165CU
In-Reply-To: <PN1PR0101MB203108D580C30E9A389289A5888E0@PN1PR0101MB2031.INDPRD01.PROD.OUTLOOK.COM>
References: <PN1PR0101MB203108D580C30E9A389289A5888E0@PN1PR0101MB2031.INDPRD01.PROD.OUTLOOK.COM>
Message-ID: <ff503b95-6618-a108-006a-cee39cf245e6@sysmocom.de>

Hi,

I think it's going to be easier to answer your question if you can 
provide the exact issue you are seeing, as well as specifying which 
revisions of the software are you running.

-- 
- 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 f12.sebastian at gmail.com  Mon Apr 30 10:39:10 2018
From: f12.sebastian at gmail.com (Sebastian F)
Date: Mon, 30 Apr 2018 16:09:10 +0530
Subject: OSmocom-LCS installation/implementation
Message-ID: <CAHMmLCUjon2TtLwM6Lao61ZFvU4eCLqQnHsY19xSa1D3tyejYg@mail.gmail.com>

Hi

How to implement RRLP with Openbsc ? I have read that it can be done
through Osmocom-LCS but it gives error on compiling.
In short how to implement osmocom-LCS with openbsc ?
Osmosom-LCS is not getting compiled !!!


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

From laforge at gnumonks.org  Mon Apr 30 10:50:44 2018
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 30 Apr 2018 12:50:44 +0200
Subject: OSmocom-LCS installation/implementation
In-Reply-To: <CAHMmLCUjon2TtLwM6Lao61ZFvU4eCLqQnHsY19xSa1D3tyejYg@mail.gmail.com>
References: <CAHMmLCUjon2TtLwM6Lao61ZFvU4eCLqQnHsY19xSa1D3tyejYg@mail.gmail.com>
Message-ID: <20180430105044.GE10358@nataraja>

On Mon, Apr 30, 2018 at 04:09:10PM +0530, Sebastian F wrote:
> How to implement RRLP with Openbsc ? I have read that it can be done
> through Osmocom-LCS but it gives error on compiling.

I'm sorry, it has suffered from bit-rot, after nobody has been showing
any interest in using it for more than 5 years.

We're more than happy to receive any contributions in this area.

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