From laforge at gnumonks.org  Fri Mar  3 18:10:24 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 3 Mar 2017 19:10:24 +0100
Subject: Virtual layer 1 - Questions
In-Reply-To: <CALFVOecU3fK6uPAB4=LDNE9OS9CY9vgUV+pwaAJCvC+qtPC+PQ@mail.gmail.com>
References: <CALFVOefg9TXn1bJ=WgNjdE+aNjotJFfzg3WkNg2yavyb94gTyA@mail.gmail.com>
 <20170212230920.epvdsj7jwxzta23w@nataraja>
 <CALFVOedfBVboU4Lk9D9QQNhr-dqybnH=0aNj=Zgucd3FjOJU4g@mail.gmail.com>
 <20170223144124.mdba7w7avdujy23g@nataraja>
 <CALFVOeeB=REeGK6=NaZr+adr7vNUJMzE6wHYMK=XdckFnzazbA@mail.gmail.com>
 <20170228213156.q72chdhhjxtyazy4@nataraja>
 <CALFVOecU3fK6uPAB4=LDNE9OS9CY9vgUV+pwaAJCvC+qtPC+PQ@mail.gmail.com>
Message-ID: <20170303181024.kxpv4pvk5yfmtv7m@nataraja>

Hi Sebastian,

On Fri, Mar 03, 2017 at 05:56:09PM +0100, Sebastian Stumpf wrote:

> > This is likely a result of the MS somehow not receiving/processing the
> > downlink signalling messages. [on TCH]
> 
> I found the reason for that. I thought I need to forward incoming messages
> on TCH/H TCH/F as L1CTL_TRAFFIC_IND if the ACCH flag is not set in the
> GSMTAP header channel type. But in case of a msg on FACCH this is wrong
> and needs to be L1CTL_DATA_IND. As the CM Service Accept is sent on
> FACCH it was not forwarded correctly to l23 and thus not processed.
> 
> Unfortunately I do not know, how to distinguish FACCH from TCH based on
> the information available in the GSMTAP messages.

the reaseon for that is simple: We never forwarded actual traffic/user
data in GSMTAP so far, only signalling messages.  So for now, it is safe
to assume that all TCH data is FACCH.  GSMTAP will have to be
extended with a new channel type if we want to carry voice frames later
on.

> That's because I just implemented some kind of one time scheduler.
> If I do not get frames/data to schedule from the upper layer for a tdma slot,
> I currently do not have any logic that fills these up with empty/idle frames.
> Seems as if I need this, though.

I think it is needed sooner or later, as the BTS will consider the radio
channel dead if it doesn't receive anything.  Also, it will probably
think the radio quality is very poor?  At the very least the SACCH must
be present in uplink.  But maybe not the most important bit right now.

If you have to go for a full scheduler sooner or later, I think it's
worth to "abstract out + recycle" either the scheduler tables from
OsmocomBB layer1 (but I think they're very calypso specific?), or those
from OsmoBTS, so one set of scheduling tables can be used in multiple
places.

> Thanks a lot for your support, I am glad you are taking the time to help me
> out :).

I'm happy if I can help your progress.

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 denver at ossguy.com  Fri Mar 10 13:36:46 2017
From: denver at ossguy.com (Denver Gingerich)
Date: Fri, 10 Mar 2017 08:36:46 -0500
Subject: Complexity of emergency-only baseband development
Message-ID: <20170310133645.xy2faemkt5adygin@ossguy.com>

Hi everyone,

I'm building some FOSS tools that let people send/receive calls/SMS without a cell plan (mainly using VoIP carriers that also offer SMS/MMS).  Eventually I would like to be able to bundle these tools with a phone that runs only free software.

In order to still provide standard emergency calling features (112/999/911 calling/SMS), the phone would require a free baseband (like OsmocomBB), but it would not need to offer any non-emergency phone features, since those would be handled by the aforementioned FOSS tools primarily on wifi.

As I understand it, OsmocomBB can currently be run on certain Calypso-based phones, but does require a larger computer be connected to run part of the baseband.  If one were to only require emergency calling features in OsmocomBB, would that larger computer still be required?  If so, would developing the remaining pieces needed to run directly on the phone be substantially easier for an emergency-only use case than for a complete all-purpose use case?

I'm guessing that there are certain parts of OsmocomBB that would not be required for emergency-only operation (perhaps some of the SIM card communication, for example), but I haven't written baseband software before so I don't have a good sense of how large the differences would be.

So I'd be curious to know if the emergency-only use case is substantially easier to develop for, or if it's roughly the same complexity as developing for the all-purpose use case, or somewhere in between.

My apologies if this isn't the right list for such questions; I'm happy to post elsewhere if that is more appropriate.  Thanks for reading!

Denver
http://soprani.ca/


From nhofmeyr at sysmocom.de  Mon Mar 13 01:24:33 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 13 Mar 2017 02:24:33 +0100
Subject: Complexity of emergency-only baseband development
In-Reply-To: <20170310133645.xy2faemkt5adygin@ossguy.com>
References: <20170310133645.xy2faemkt5adygin@ossguy.com>
Message-ID: <20170313012433.GC25910@my.box>

On Fri, Mar 10, 2017 at 08:36:46AM -0500, Denver Gingerich wrote:
> So I'd be curious to know if the emergency-only use case is substantially easier to develop for, or if it's roughly the same complexity as developing for the all-purpose use case, or somewhere in between.

If I understand OsmocomBB correctly, the main point is getting a handle on the
hardware. When the phone starts, it will run its firmware. The external
computer is needed to hook onto the phone's boot process and make it do other
things than the firmware would. Apart from that, an emergency call shouldn't be
any easier than a normal call, the phone still needs to do all the basic GSM
networking things (signalling etc) before a call is even possible.

But ... this is just a guess from my very feeble knowledge of OsmocomBB.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170313/bda6d089/attachment.bin>

From 246tnt at gmail.com  Mon Mar 13 18:21:21 2017
From: 246tnt at gmail.com (Sylvain Munaut)
Date: Mon, 13 Mar 2017 19:21:21 +0100
Subject: Complexity of emergency-only baseband development
In-Reply-To: <20170313012433.GC25910@my.box>
References: <20170310133645.xy2faemkt5adygin@ossguy.com>
 <20170313012433.GC25910@my.box>
Message-ID: <CAHL+j0-nrVudHoBmRA2s=bageK84dnz9K1mfScZoGQ+DO0Taiw@mail.gmail.com>

>. Apart from that, an emergency call shouldn't be
> any easier than a normal call, the phone still needs to do all the basic GSM
> networking things (signalling etc) before a call is even possible.

+1 to that.

Actually it might even be a bit "harder" because although the normal
call has already been developped and tested, but the emergency code
probably not either. (Or if written it's not tested ... it's not like
we can easily dial the emergency service 50 times to test code paths
on real networks for testing ...)


Cheers,

   Sylvain


From gerardfly9 at gmail.com  Fri Mar 17 09:47:18 2017
From: gerardfly9 at gmail.com (Gerard Pinto)
Date: Fri, 17 Mar 2017 02:47:18 -0700 (MST)
Subject: OsmocomBB MNCC socket implementation without LCR
Message-ID: <1489744038673-4026771.post@n3.nabble.com>

Greetings,

I have been working with Layer23 stack of OsmocomBB since a couple of
months.
I decided to try MNCC socket interface without LCR (I'm aware there is an
implementation embedded in LCR gsm-ms).
I reverse engineered and wrote a simple C application taking mncc.h.

Problem: I'm unable to make a call on live network, although it does channel
allocation, ciphering etc.
Flow:
1. Create MNCC struct and write on to the osmocomBB socket
2. OsmocomBB parses it well and request for channel, ciphering mode, init
MM, sending SETUP etc works great.
3. However, in response to step.2 after sending SETUP it returns with (ms 1)
Received 'RELEASE_COMPL' in CC state INITIATED. Why does it release CC?
4. I further debugged, the reason for release is in fn.
gsm48_cc_rx_release_compl in (gsm8_cc.c) it says mncc-cause =
*GSM48_IE_CAUSE*. with no description.

I really don't know whats causing this issue. Any help would be much
appreciated.
Or It would be very kind if someone could guide me.

My mncc socket create code:
	struct gsm_mncc *mncc;
	int i = 0;
	int call_ref = new_callref++;
	mncc = create_mncc(MNCC_SETUP_REQ, call_ref);

	if (!strncasecmp(number, "emerg", 5)) {
		printf("Make emergency call\n");
		mncc->emergency = 1;
	} else {
		printf("make call to %s\n", number);
		mncc->fields |= MNCC_F_CALLED;

		if(number[0] == '+') {
			number++;
			mncc->called.type = 1; /*international*/
		} else {
			mncc->called.type = 0; /*auto-unknown -prefix must be used*/
		}
		mncc->called.plan = 1;
		strncpy(mncc->called.number, number,
		sizeof(mncc->called.number) - 1);
		printf("Calling number %s\n", mncc->called.number);

		/* bearer capability (mandatory) */
		mncc->fields |= MNCC_F_BEARER_CAP;
		mncc->bearer_cap.coding = 0;
		mncc->bearer_cap.speech_ctm = 0;

		mncc->bearer_cap.radio = 3; /** Support TCH/H also*/
		/** Supported rates **/
		mncc->bearer_cap.speech_ver[i++] = 2; /* support full rate v2 */
		mncc->bearer_cap.speech_ver[i++] = 0; /* support full rate v1 */
		mncc->bearer_cap.speech_ver[i++] = 1; /* support half rate v2 */
		mncc->bearer_cap.speech_ver[i] = -1; /* end of list */
		/** END **/
		
		mncc->bearer_cap.transfer = 0;
		mncc->bearer_cap.mode = 0;

		/* CC capabilities (optional) DTMF */
		mncc->fields |= MNCC_F_CCCAP;
		mncc->cccap.dtmf = 1;

		mncc->fields |= MNCC_F_CCCAP;
		mncc->clir.inv = 1;
		mncc->clir.sup = 1;
	}

	return send_and_free_mncc(mncc->msg_type, mncc);


Looking forward to the reply,
Thanks,
Gerard



--
View this message in context: http://baseband-devel.722152.n3.nabble.com/OsmocomBB-MNCC-socket-implementation-without-LCR-tp4026771.html
Sent from the baseband-devel mailing list archive at Nabble.com.


From laforge at gnumonks.org  Fri Mar 17 15:49:50 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 17 Mar 2017 16:49:50 +0100
Subject: OsmocomBB MNCC socket implementation without LCR
In-Reply-To: <1489744038673-4026771.post@n3.nabble.com>
References: <1489744038673-4026771.post@n3.nabble.com>
Message-ID: <20170317154950.6w24x67abr7cfkjc@nataraja>

hi Gerard,

On Fri, Mar 17, 2017 at 02:47:18AM -0700, Gerard Pinto wrote:
> I have been working with Layer23 stack of OsmocomBB since a couple of
> months.
> I decided to try MNCC socket interface without LCR (I'm aware there is an
> implementation embedded in LCR gsm-ms).

Just a quick note: There's mncc-python at
http://git.osmocom.org/mncc-python/ which you can use to interface from
external programs/scripts, if you'd like.

> Problem: I'm unable to make a call on live network, although it does channel
> allocation, ciphering etc.
> Flow:
> 1. Create MNCC struct and write on to the osmocomBB socket
> 2. OsmocomBB parses it well and request for channel, ciphering mode, init
> MM, sending SETUP etc works great.
> 3. However, in response to step.2 after sending SETUP it returns with (ms 1)
> Received 'RELEASE_COMPL' in CC state INITIATED. Why does it release CC?

It would be best if yo could include GSMTAP protocol traces of such
situations, so one can analyze what happens.

Also, you can compare the traces of working (no mncc?) and non-working
(mncc) cases.

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 laforge at gnumonks.org  Fri Mar 17 20:17:19 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Fri, 17 Mar 2017 21:17:19 +0100
Subject: git.osmocom.org cgit improvements
Message-ID: <20170317201719.r3d6n3ab35wke4mu@nataraja>

Hi all,

today I've deployed some cgit improvements on https://git.osmocom.org/,
in the hope that it makes this tool even more useful:

1) syntax highlighting of source code (requested by Hoernchen)

The source code is now highlighted by pygments.  I don't really
understand why somebody would want to look at source code a lot in a
browser, but well, it was as easy as to enable the existing pygments
based filter plugin.


2) rendering of "about" page from README.md

As you might have noticed, I've introduced a README.md in a number of
repositoires, and cgit is now rendering an about page for every
repository, e.g. at http://git.osmocom.org/libosmo-abis/about/


3) gerrit change-ID hyperlink generation

All gerrit Change-IDs in commit messages are now automatically converted
to hyperlinks to the respective gerrit change, see e.g. the below
example:
http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c446aa563c

Please note that this works for the "Change-Id" line of the actual
change, but also for change-ids in the free text (e.g. "this depends on
change-id ... in libosmocore")


4) Osmocom ticket/issue hyperlink generation

Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is
scanned for occurrences of "OS#(\d+)" which are then amended with
hyperlinks to the respective issue on osmocom.org

Please note the OS# prefix is mandatory, so things like "OS#1614, 1615"
will not work, as can be seen at
http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5b8cc85cd

Please format your commit messages accordingly.

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  Sat Mar 18 15:09:31 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Sat, 18 Mar 2017 16:09:31 +0100
Subject: git.osmocom.org cgit improvements
In-Reply-To: <20170317201719.r3d6n3ab35wke4mu@nataraja>
References: <20170317201719.r3d6n3ab35wke4mu@nataraja>
Message-ID: <20170318150931.GB3272@my.box>

On Fri, Mar 17, 2017 at 09:17:19PM +0100, Harald Welte wrote:
> 2) rendering of "about" page from README.md
> 
> As you might have noticed, I've introduced a README.md in a number of
> repositoires, and cgit is now rendering an about page for every
> repository, e.g. at http://git.osmocom.org/libosmo-abis/about/

It seems like these need some follow-ups in the debian packaging instructions
-- i.e. update to the new .md suffix or mark as installation (or ignore, but I
guess rather installation) file.

> 4) Osmocom ticket/issue hyperlink generation
> 
> Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is
> scanned for occurrences of "OS#(\d+)" which are then amended with
> hyperlinks to the respective issue on osmocom.org

Ah, so when OS#123 appears in the commit log's free text, it isn't linked?
Can we just scan everything for "\<OS#\d+\>"?

All in all these are excellent improvements!
Holger, what's the status of your promise, made one day in a chat, to make
redmine catch the OS#123s?

~N

-- 
- Neels Hofmeyr <nhofmeyr at sysmocom.de>          http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Gesch?ftsf?hrer / Managing Directors: Harald Welte
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170318/c20a9250/attachment.bin>

From holger at freyther.de  Sun Mar 19 20:57:57 2017
From: holger at freyther.de (Holger Freyther)
Date: Sun, 19 Mar 2017 21:57:57 +0100
Subject: git.osmocom.org cgit improvements
In-Reply-To: <20170318150931.GB3272@my.box>
References: <20170317201719.r3d6n3ab35wke4mu@nataraja>
 <20170318150931.GB3272@my.box>
Message-ID: <9437479C-B7C9-4603-B01D-EC775130F164@freyther.de>


> On 18 Mar 2017, at 16:09, Neels Hofmeyr <nhofmeyr at sysmocom.de> wrote:
> 
> 

Hi,


> All in all these are excellent improvements!
> Holger, what's the status of your promise, made one day in a chat, to make
> redmine catch the OS#123s?

lol, I love how we go from a private chat to this CC list. I have not looked at it but maybe this is something for an afternoon at Osmodevcon. It should be fairly simple with redmine.

holger

From nhofmeyr at sysmocom.de  Mon Mar 20 04:36:31 2017
From: nhofmeyr at sysmocom.de (Neels Hofmeyr)
Date: Mon, 20 Mar 2017 05:36:31 +0100
Subject: git.osmocom.org cgit improvements
In-Reply-To: <9437479C-B7C9-4603-B01D-EC775130F164@freyther.de>
References: <20170317201719.r3d6n3ab35wke4mu@nataraja>
 <20170318150931.GB3272@my.box>
 <9437479C-B7C9-4603-B01D-EC775130F164@freyther.de>
Message-ID: <20170320043631.GC12441@my.box>

On Sun, Mar 19, 2017 at 09:57:57PM +0100, Holger Freyther wrote:
> > Holger, what's the status of your promise, made one day in a chat, to make
> > redmine catch the OS#123s?
> 
> lol, I love how we go from a private chat to this CC list.

Hey, if you love it that much, I can come up with plenty more private
conversations between us I could Cc around... ;)

In other words, sorry about disclosing. I kind of remembered it was a public
commitment. And it doesn't need to stick, either, anyone could take a look if
you're busy.

~N

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170320/99ba8078/attachment.bin>

From usamamuneeb at gmail.com  Sat Mar 25 14:39:33 2017
From: usamamuneeb at gmail.com (Usama Muneeb)
Date: Sat, 25 Mar 2017 19:39:33 +0500
Subject: Connecting OSMOCOM to OpenBTS
Message-ID: <CAG8msKacvJE_ssT=Ab-6Gmv4cTgBX0j4aYFkLgT9O4otfqLspw@mail.gmail.com>

I recently set up OpenBTS which is working perfectly. I can make a test
call by calling 2600 using an Android phone.

However when I try "show subscriber" in OSMOCOM, various BTS are listed,
with their MNC and MCC values but OpenBTS is not listed.

Any solution to this?

P.S. I've determined the MNC and MCC values for OpenBTS which are 001 and
01 respectively.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170325/635e7aad/attachment.htm>

From laforge at gnumonks.org  Sun Mar 26 10:36:49 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Sun, 26 Mar 2017 12:36:49 +0200
Subject: Connecting OsmocomBB to OpenBTS
In-Reply-To: <CAG8msKacvJE_ssT=Ab-6Gmv4cTgBX0j4aYFkLgT9O4otfqLspw@mail.gmail.com>
References: <CAG8msKacvJE_ssT=Ab-6Gmv4cTgBX0j4aYFkLgT9O4otfqLspw@mail.gmail.com>
Message-ID: <20170326103649.mouwvljbqbfngzy5@nataraja>

Hi Usama,

"Osmocom" is a very large umbrella project, of which OsmocomBB is only
one small part.  So when referring to OsmocomBB, please always use the
full name, to avoid confusion. Thanks!

On Sat, Mar 25, 2017 at 07:39:33PM +0500, Usama Muneeb wrote:
> I recently set up OpenBTS which is working perfectly. I can make a test
> call by calling 2600 using an Android phone.

In case you're interested, you can also use the Osmocom stack
(OsmoTRX+OsmoBTS+OsmoNITB) on the network side.

> However when I try "show subscriber" in OSMOCOM, various BTS are listed,
> with their MNC and MCC values but OpenBTS is not listed.

I'm puzzled. Why would "show subscriber" list any BTSs ?!?  Please
provide the actual copy+paste output of what you are referring to.

>From what I can tell, "show subscriber" lists the preferred PLMNs and
the forbidden PLMNs as stored on the SIM card.  This makes sense, as
they are attributes related to the subscriber.  But listing visible BTS
on the subscriber somehow wouldn't even make sense, IMHO.

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 usamamuneeb at gmail.com  Sun Mar 26 17:00:59 2017
From: usamamuneeb at gmail.com (Usama Muneeb)
Date: Sun, 26 Mar 2017 22:00:59 +0500
Subject: Connecting OsmocomBB to OpenBTS
In-Reply-To: <20170326103649.mouwvljbqbfngzy5@nataraja>
References: <CAG8msKacvJE_ssT=Ab-6Gmv4cTgBX0j4aYFkLgT9O4otfqLspw@mail.gmail.com>
 <20170326103649.mouwvljbqbfngzy5@nataraja>
Message-ID: <CAG8msKYre1gw3=yv1Dxs_-ab-znAyMt-nhrFTyOAvhy3y_UFSQ@mail.gmail.com>

Dear Harald,

Thank you for the info! Yes that makes sense, since that is exactly what I
am seeing (forbidden PLMNs). I didn't know they are stored on the SIM card.
I mistook these for the available networks (since MNC and MCC is also
listed with these forbidden PLMNs).

I'm guessing I would need to perform surgery on OSMOCOM-BB code in order to
connect it to another network? Is there any in built feature that would
allow me to do so directly?

Lastly, is there any added benefit in using OsmoBTS over OpenBTS when it
comes to connectivity to the network?

Regards,
Usama Muneeb


On Sun, Mar 26, 2017 at 3:36 PM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Usama,
>
> "Osmocom" is a very large umbrella project, of which OsmocomBB is only
> one small part.  So when referring to OsmocomBB, please always use the
> full name, to avoid confusion. Thanks!
>
> On Sat, Mar 25, 2017 at 07:39:33PM +0500, Usama Muneeb wrote:
> > I recently set up OpenBTS which is working perfectly. I can make a test
> > call by calling 2600 using an Android phone.
>
> In case you're interested, you can also use the Osmocom stack
> (OsmoTRX+OsmoBTS+OsmoNITB) on the network side.
>
> > However when I try "show subscriber" in OSMOCOM, various BTS are listed,
> > with their MNC and MCC values but OpenBTS is not listed.
>
> I'm puzzled. Why would "show subscriber" list any BTSs ?!?  Please
> provide the actual copy+paste output of what you are referring to.
>
> From what I can tell, "show subscriber" lists the preferred PLMNs and
> the forbidden PLMNs as stored on the SIM card.  This makes sense, as
> they are attributes related to the subscriber.  But listing visible BTS
> on the subscriber somehow wouldn't even make sense, IMHO.
>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170326/c585fe6e/attachment.htm>

From domi at tomcsanyi.net  Sun Mar 26 17:19:26 2017
From: domi at tomcsanyi.net (=?utf-8?Q?Tomcs=C3=A1nyi_Domonkos?=)
Date: Sun, 26 Mar 2017 19:19:26 +0200
Subject: Connecting OsmocomBB to OpenBTS
In-Reply-To: <CAG8msKYre1gw3=yv1Dxs_-ab-znAyMt-nhrFTyOAvhy3y_UFSQ@mail.gmail.com>
References: <CAG8msKacvJE_ssT=Ab-6Gmv4cTgBX0j4aYFkLgT9O4otfqLspw@mail.gmail.com>
 <20170326103649.mouwvljbqbfngzy5@nataraja>
 <CAG8msKYre1gw3=yv1Dxs_-ab-znAyMt-nhrFTyOAvhy3y_UFSQ@mail.gmail.com>
Message-ID: <0A2F3FAC-9B09-4DF9-8114-1137A80121EA@tomcsanyi.net>

Hi Usama,


> I'm guessing I would need to perform surgery on OSMOCOM-BB code in order to connect it to another network? Is there any in built feature that would allow me to do so directly?

I'm not sure what you mean by performing surgery, but I would encourage you to look at the mobile application that is capable of connecting to a network using an OsmocomBB phone.
http://osmocom.org/projects/baseband/wiki/Mobile <http://osmocom.org/projects/baseband/wiki/Mobile>


> Lastly, is there any added benefit in using OsmoBTS over OpenBTS when it comes to connectivity to the network?

OsmoBTS is one of the many Osmocom projects and it is (in my opinion) a better implementation to run your own network than OpenBTS. OsmoTRX+OsmoBTS+OsmoNITB work together great and they use standard interfaces to communicate. They are widely used to provide GSM connectivity at various events and therefore could be considered a bit more bulletproof and robust than OpenBTS.
However if OpenBTS works well for you and your purposes then it is not necessary to change.

Cheers,

Domi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170326/b5fee3c7/attachment.htm>

From gerardfly9 at gmail.com  Mon Mar 27 09:11:29 2017
From: gerardfly9 at gmail.com (Gerard Pinto)
Date: Mon, 27 Mar 2017 02:11:29 -0700
Subject: OsmocomBB MNCC socket implementation without LCR
In-Reply-To: <20170317154950.6w24x67abr7cfkjc@nataraja>
References: <1489744038673-4026771.post@n3.nabble.com>
 <20170317154950.6w24x67abr7cfkjc@nataraja>
Message-ID: <CAMQrH55oyTC5DuP_QWZxQUhKUgD0JuyFc7CCDtGn2k6X96NNkg@mail.gmail.com>

Hi Herald,

Thanks for the quick response! My apologize for the delay - I was close to
get it working so wanted to put a mail after.
GSM_TAP was the key - Thank you for this help. External CC works well now.

There was no way I could figure it out, if I hadn't enabled GSM_TAP.
It said "Invalid mandatory information"
Just  compared mncc with internal and external CC - Debugged a little
further and realized 1 of the fields of bearer_cap was missing!

mncc-python is good - I read your blog. Made some changes (socket path).
Although it does fail with "Invalid mandatory information" - bearer cap
missing. I will have to look again at the code.


*Just an off topic Question*.
Osmo-sim-auth and pysim both same projects right?
Reason I asked since, I wrote all SIM API's in osmo-sim-auth and was
planning to push upstream and then realized there is a project pysim which
has all of that ?

Thanks,
Gerard


On Fri, Mar 17, 2017 at 8:49 AM, Harald Welte <laforge at gnumonks.org> wrote:

> hi Gerard,
>
> On Fri, Mar 17, 2017 at 02:47:18AM -0700, Gerard Pinto wrote:
> > I have been working with Layer23 stack of OsmocomBB since a couple of
> > months.
> > I decided to try MNCC socket interface without LCR (I'm aware there is an
> > implementation embedded in LCR gsm-ms).
>
> Just a quick note: There's mncc-python at
> http://git.osmocom.org/mncc-python/ which you can use to interface from
> external programs/scripts, if you'd like.
>
> > Problem: I'm unable to make a call on live network, although it does
> channel
> > allocation, ciphering etc.
> > Flow:
> > 1. Create MNCC struct and write on to the osmocomBB socket
> > 2. OsmocomBB parses it well and request for channel, ciphering mode, init
> > MM, sending SETUP etc works great.
> > 3. However, in response to step.2 after sending SETUP it returns with
> (ms 1)
> > Received 'RELEASE_COMPL' in CC state INITIATED. Why does it release CC?
>
> It would be best if yo could include GSMTAP protocol traces of such
> situations, so one can analyze what happens.
>
> Also, you can compare the traces of working (no mncc?) and non-working
> (mncc) cases.
>
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170327/5d08ccd3/attachment.htm>

From laforge at gnumonks.org  Mon Mar 27 09:29:39 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Mon, 27 Mar 2017 11:29:39 +0200
Subject: OsmocomBB MNCC socket implementation without LCR
In-Reply-To: <CAMQrH55oyTC5DuP_QWZxQUhKUgD0JuyFc7CCDtGn2k6X96NNkg@mail.gmail.com>
References: <1489744038673-4026771.post@n3.nabble.com>
 <20170317154950.6w24x67abr7cfkjc@nataraja>
 <CAMQrH55oyTC5DuP_QWZxQUhKUgD0JuyFc7CCDtGn2k6X96NNkg@mail.gmail.com>
Message-ID: <20170327092939.r253gwnh37pyg7e2@nataraja>

Hi Gerard,

On Mon, Mar 27, 2017 at 02:11:29AM -0700, Gerard Pinto wrote:
> GSM_TAP was the key - Thank you for this help. External CC works well now.

great.

> Just  compared mncc with internal and external CC - Debugged a little
> further and realized 1 of the fields of bearer_cap was missing!

> mncc-python is good - I read your blog. Made some changes (socket path).
> Although it does fail with "Invalid mandatory information" - bearer cap
> missing. I will have to look again at the code.

Patches are always welcome.  I guess mncc-python is so far only used
with OsmoNITB, and not with the MS-side MNCC on OsmocomBB.  But it would
be great to have this working, too.

> Osmo-sim-auth and pysim both same projects right?

no.  osmo-sim-auth just performs a (GSM or UMTS) authentication against
a SIM card.

pySim is for programming certain cards where that is possible (like
MagicSIM, sysmoSIM, sysmoUSIM, etc.)

I think there are two distinct purposes and it makes sense to have two
different tools.  But yes, it probably could make sense to merge the
code in one repository and simply have multiple executables for that.

Would you be interested in merging the two, i.e. provide an incremental
patchset against pysim that adds the osmo-sim-auth binary?

> Reason I asked since, I wrote all SIM API's in osmo-sim-auth and was
> planning to push upstream and then realized there is a project pysim which
> has all of that ?

Sorry to hear that. pySim-prog actually existed for much longer time, it
is what we always used to program SIM Cards ever since 2009.

-- 
-- 
- 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 gerardfly9 at gmail.com  Tue Mar 28 07:08:49 2017
From: gerardfly9 at gmail.com (Gerard Pinto)
Date: Tue, 28 Mar 2017 00:08:49 -0700
Subject: OsmocomBB MNCC socket implementation without LCR
In-Reply-To: <20170327092939.r253gwnh37pyg7e2@nataraja>
References: <1489744038673-4026771.post@n3.nabble.com>
 <20170317154950.6w24x67abr7cfkjc@nataraja>
 <CAMQrH55oyTC5DuP_QWZxQUhKUgD0JuyFc7CCDtGn2k6X96NNkg@mail.gmail.com>
 <20170327092939.r253gwnh37pyg7e2@nataraja>
Message-ID: <CAMQrH54fTAdh9rTmMecpVPR11ni2R=t7tj1zyA7YrFvfSMf_FQ@mail.gmail.com>

Hi Herald,

Thank you for your responses. I appreciate you taking out time from your
schedule.
Just a couple of things I would like to share since my interest grew in
telecom.

1) Have you or your team tried to reverse engineer/hacking Over the Air OTA
spec - firmware upgrade (understanding this type of communication) using
OpenNITB and latest phones where bootloaders are locked?

- I was planning to try this! But now I will take up merging osmo-sim-auth
and py-sim. (I'm not a great dev but I'm passionate about osmocom and
willing to contribute my time to learning/contributing the same).

2) I have been trying something different with OsmocomBB, osmo-sim-auth and
Tor lately - I would like to hear your views on the same.
 Attack Model: Geo-Location Anonymous calling in GSM.

Description:
1. The attacker uses OsmocomBB phone to make a call using a sim card
service. (No sim card present in the phone).
2. For this, I have taken the SIM card outside OsmocomBB and re-written all
SIM API's in osmo-sim-auth (which is the sim card service).
3. This sim card service is deployed over Tor network, so no one can
actually know the location of the SIM card service.
4, The osmocombb connects to the network and uses this sim card service for
authentication etc.
5. The whole setup of calling etc is initiated by the sim card service,
which is itself behind Tor.

6. Now, This SIM card service can be used my multiple phones, so now you
are not exactly going to track the phone since if I use the SIM card
service to another phone (cell area) the DB entry in VLR has changed which
says the location has changed.
7. My experiments worked well on a LIVE network, understanding the delay in
Tor the network, still, the BTS was accepting RES response challenge from
the SIM card service behind Tor - I still have to calculate the exact max
acceptable delay in sending RES back to BTS to confirm this!

Look forward to hearing from you!

Thanks,
Gerard



On Mon, Mar 27, 2017 at 2:29 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Gerard,
>
> On Mon, Mar 27, 2017 at 02:11:29AM -0700, Gerard Pinto wrote:
> > GSM_TAP was the key - Thank you for this help. External CC works well
> now.
>
> great.
>
> > Just  compared mncc with internal and external CC - Debugged a little
> > further and realized 1 of the fields of bearer_cap was missing!
>
> > mncc-python is good - I read your blog. Made some changes (socket path).
> > Although it does fail with "Invalid mandatory information" - bearer cap
> > missing. I will have to look again at the code.
>
> Patches are always welcome.  I guess mncc-python is so far only used
> with OsmoNITB, and not with the MS-side MNCC on OsmocomBB.  But it would
> be great to have this working, too.
>
> > Osmo-sim-auth and pysim both same projects right?
>
> no.  osmo-sim-auth just performs a (GSM or UMTS) authentication against
> a SIM card.
>
> pySim is for programming certain cards where that is possible (like
> MagicSIM, sysmoSIM, sysmoUSIM, etc.)
>
> I think there are two distinct purposes and it makes sense to have two
> different tools.  But yes, it probably could make sense to merge the
> code in one repository and simply have multiple executables for that.
>
> Would you be interested in merging the two, i.e. provide an incremental
> patchset against pysim that adds the osmo-sim-auth binary?
>
> > Reason I asked since, I wrote all SIM API's in osmo-sim-auth and was
> > planning to push upstream and then realized there is a project pysim
> which
> > has all of that ?
>
> Sorry to hear that. pySim-prog actually existed for much longer time, it
> is what we always used to program SIM Cards ever since 2009.
>
> --
> --
> - 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/baseband-devel/attachments/20170328/5570ba0e/attachment.htm>

From domi at tomcsanyi.net  Tue Mar 28 07:27:54 2017
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Tue, 28 Mar 2017 09:27:54 +0200 (CEST)
Subject: OsmocomBB MNCC socket implementation without LCR
In-Reply-To: <CAMQrH54fTAdh9rTmMecpVPR11ni2R=t7tj1zyA7YrFvfSMf_FQ@mail.gmail.com>
References: <1489744038673-4026771.post@n3.nabble.com>
 <20170317154950.6w24x67abr7cfkjc@nataraja>
 <CAMQrH55oyTC5DuP_QWZxQUhKUgD0JuyFc7CCDtGn2k6X96NNkg@mail.gmail.com>
 <20170327092939.r253gwnh37pyg7e2@nataraja>
 <CAMQrH54fTAdh9rTmMecpVPR11ni2R=t7tj1zyA7YrFvfSMf_FQ@mail.gmail.com>
Message-ID: <D2D17EFD-CE95-4B06-B0BB-485DA85759FF@tomcsanyi.net>

Hi Gerard

2017. m?rc. 28. d?tummal, 9:10 id?pontban Gerard Pinto <gerardfly9 at gmail.com> ?rta:
> 2) I have been trying something different with OsmocomBB, osmo-sim-auth and Tor lately - I would like to hear your views on the same.
>  Attack Model: Geo-Location Anonymous calling in GSM.
> 
> Description:
> 1. The attacker uses OsmocomBB phone to make a call using a sim card service. (No sim card present in the phone).
> 2. For this, I have taken the SIM card outside OsmocomBB and re-written all SIM API's in osmo-sim-auth (which is the sim card service).
> 3. This sim card service is deployed over Tor network, so no one can actually know the location of the SIM card service.
> 4, The osmocombb connects to the network and uses this sim card service for authentication etc. 
> 5. The whole setup of calling etc is initiated by the sim card service, which is itself behind Tor.
> 
> 6. Now, This SIM card service can be used my multiple phones, so now you are not exactly going to track the phone since if I use the SIM card service to another phone (cell area) the DB entry in VLR has changed which says the location has changed. 
> 7. My experiments worked well on a LIVE network, understanding the delay in Tor the network, still, the BTS was accepting RES response challenge from the SIM card service behind Tor - I still have to calculate the exact max acceptable delay in sending RES back to BTS to confirm this!

This is a very interesting idea, I like it! I wanted to mention the SAP protocol that is available in OsmocomBB's mobile app via a Unix domain socket since some time now. It might be even easier to use it for your idea. I used it via an external card reader and softSIM to provide a SIM card for OsmocomBB.

Cheers,

Domi

From laforge at gnumonks.org  Tue Mar 28 09:45:04 2017
From: laforge at gnumonks.org (Harald Welte)
Date: Tue, 28 Mar 2017 11:45:04 +0200
Subject: OsmocomBB MNCC socket implementation without LCR
In-Reply-To: <CAMQrH54fTAdh9rTmMecpVPR11ni2R=t7tj1zyA7YrFvfSMf_FQ@mail.gmail.com>
References: <1489744038673-4026771.post@n3.nabble.com>
 <20170317154950.6w24x67abr7cfkjc@nataraja>
 <CAMQrH55oyTC5DuP_QWZxQUhKUgD0JuyFc7CCDtGn2k6X96NNkg@mail.gmail.com>
 <20170327092939.r253gwnh37pyg7e2@nataraja>
 <CAMQrH54fTAdh9rTmMecpVPR11ni2R=t7tj1zyA7YrFvfSMf_FQ@mail.gmail.com>
Message-ID: <20170328094504.ah6n54fvipstswio@nataraja>

Hi Gerard,

On Tue, Mar 28, 2017 at 12:08:49AM -0700, Gerard Pinto wrote:
> 1) Have you or your team tried to reverse engineer/hacking Over the Air OTA
> spec - firmware upgrade (understanding this type of communication) using
> OpenNITB and latest phones where bootloaders are locked?

I haven't looked at this personally, but several people have looked at
security of several different OTA updates for about a decade by now.
The main issue is that there is no standard protocol or system, and
everyone cooks up their own.

> - I was planning to try this! But now I will take up merging osmo-sim-auth
> and py-sim. (I'm not a great dev but I'm passionate about osmocom and
> willing to contribute my time to learning/contributing the same).

thanks!

> 2) I have been trying something different with OsmocomBB, osmo-sim-auth and
> Tor lately - I would like to hear your views on the same.
>  Attack Model: Geo-Location Anonymous calling in GSM.
> 
> Description:
> 1. The attacker uses OsmocomBB phone to make a call using a sim card
> service. (No sim card present in the phone).
> 2. For this, I have taken the SIM card outside OsmocomBB and re-written all
> SIM API's in osmo-sim-auth (which is the sim card service).
> 3. This sim card service is deployed over Tor network, so no one can
> actually know the location of the SIM card service.
> 4, The osmocombb connects to the network and uses this sim card service for
> authentication etc.
> 5. The whole setup of calling etc is initiated by the sim card service,
> which is itself behind Tor.

This is basically the sim card forwarding / remote SIM, which people
have been experimenting on SIMtrace for quite some time.  In this case
you can use any regular phone or modem, and don't need osmocombb.  There
is a complete 'remote sim / card emulation' proof of concept in the
simtrace2.git repository, but this requires a prototype of the simtrace
2.x hardware (with SAM3) and not the old/current simtrace 1.x hardware
(with SAM7).

Also, there are plenty of commercial suppliers of systems like you have
described.

a) in the area of automatic roaming testing (between operators)
b) in the area of automatic service quality testing (between operators)
c) in the grey area of so-called SIM-boxes, where you have hundreds to
   thousands of SIM cards in one data center, which you can remotely
   provision to any number of "GSM VoIP gateways" spread in different
   countries.  This is typically used for interconnection fraud by shady
   operators.

None of the above use Tor (as they have different use cases), but the
option 'c' at least also uses IMEI randomization to avoid tracking the
subscriber via his IMEI, which presumably you would want to do in your
OsmocomBB based system, t..

> 6. Now, This SIM card service can be used my multiple phones, so now you
> are not exactly going to track the phone since if I use the SIM card
> service to another phone (cell area) the DB entry in VLR has changed which
> says the location has changed.

Yes, but you have to be very quick.  Of course from the time of the LU
throughout the call, your position is known to the observer.  Not
because of your IMSI or IMEI (which you both keep changing) but because
of the phone numbers you call.

It depends on what you want to defend against.  Basically you can do
this already if you carry around a huge bag of sim cards which you
always only use for a single call, *and* you have a phone that can
change the IMEI every time you change the SIM.  This is apparently what
e.g. human rights activists in hostile countries are doing.

However, the biggest problem in such situations is not your own
identity, but the identities you contact.  So if you keep calling the
same destination number, all of the above is useless as the key to find
you is by the destination number.  So at the same time, you require a
potentially large number of phone numbers that are not in some way
associated to another (and at best in different countries), which then
provide call redirect to your real destination.

> 7. My experiments worked well on a LIVE network, understanding the delay in
> Tor the network, still, the BTS was accepting RES response challenge from
> the SIM card service behind Tor - I still have to calculate the exact max
> acceptable delay in sending RES back to BTS to confirm this!

I think I remember that at least 2 if not 4 seconds of delay are
acceptable for the complete authentication handshake.  People are even
doing this over satellite back-haul.

-- 
- 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 antgorka at gmail.com  Wed Mar 29 07:45:46 2017
From: antgorka at gmail.com (Anton Gorbachev)
Date: Wed, 29 Mar 2017 10:45:46 +0300
Subject: ARM Core and UI
Message-ID: <CAE8qTPO0Wr0o+ybo8xFaXRc2oVo6w=XDrNcJh=yP=5qHzRirmw@mail.gmail.com>

Dear Osmocom members,

I am new in OsmocomBB but trying to understand how all the stuff works.
And I have a question.
As I understood we have DigitalBB Calypso in our Motorola phones which
consist of DSP and ARM Cores.
If we are talking about "normal" phone firmware, In DSP L1 processing is
done, in ARM core L2 and L3 processing of GSM stack is done.
But we must also have some "regular" OS somewhere, am I right? So I mean
all the menus, applications like "Settings", "Phone book", etc.
In modern phones, I believe Adnroid or iOS communicate with some RTOS
running in ARM core of DigitalBB. But what is about Motorola phone? Does it
have separate ARM processor/RAM for a refular firmware?
Did you create some applications for ARM part of DigitalBB and some
applications for UI which run outside the RTOS?
It's possible that I am confusing with all the terms but I would appreciate
if you help me to understand.

Kind regards,
Anton
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170329/42fbf52c/attachment.htm>

From domi at tomcsanyi.net  Wed Mar 29 08:07:51 2017
From: domi at tomcsanyi.net (=?utf-8?B?VG9tY3PDoW55aSwgRG9tb25rb3M=?=)
Date: Wed, 29 Mar 2017 10:07:51 +0200 (CEST)
Subject: ARM Core and UI
In-Reply-To: <CAE8qTPO0Wr0o+ybo8xFaXRc2oVo6w=XDrNcJh=yP=5qHzRirmw@mail.gmail.com>
References: <CAE8qTPO0Wr0o+ybo8xFaXRc2oVo6w=XDrNcJh=yP=5qHzRirmw@mail.gmail.com>
Message-ID: <4552FED4-6097-420D-904F-3D58E606B51A@tomcsanyi.net>

Hi Anton,

The ARM core of the Calypso platform is responsible for both the UI/apps and other tasks as well, there is no separate application processor as found in most of current phones.

There are applications running on the phone presenting a UI as well as doing work on the ARM core for example the rssi application.

Cheers,

Domi


2017. m?rc. 29. d?tummal, 9:46 id?pontban Anton Gorbachev <antgorka at gmail.com> ?rta:

> Dear Osmocom members,
> 
> I am new in OsmocomBB but trying to understand how all the stuff works.
> And I have a question.
> As I understood we have DigitalBB Calypso in our Motorola phones which consist of DSP and ARM Cores.
> If we are talking about "normal" phone firmware, In DSP L1 processing is done, in ARM core L2 and L3 processing of GSM stack is done.
> But we must also have some "regular" OS somewhere, am I right? So I mean all the menus, applications like "Settings", "Phone book", etc.
> In modern phones, I believe Adnroid or iOS communicate with some RTOS running in ARM core of DigitalBB. But what is about Motorola phone? Does it have separate ARM processor/RAM for a refular firmware?
> Did you create some applications for ARM part of DigitalBB and some applications for UI which run outside the RTOS?
> It's possible that I am confusing with all the terms but I would appreciate if you help me to understand.
> 
> Kind regards,
> Anton

From gerardfly9 at gmail.com  Wed Mar 29 08:57:31 2017
From: gerardfly9 at gmail.com (Gerard Pinto)
Date: Wed, 29 Mar 2017 01:57:31 -0700
Subject: OsmocomBB MNCC socket implementation without LCR
In-Reply-To: <D2D17EFD-CE95-4B06-B0BB-485DA85759FF@tomcsanyi.net>
References: <1489744038673-4026771.post@n3.nabble.com>
 <20170317154950.6w24x67abr7cfkjc@nataraja>
 <CAMQrH55oyTC5DuP_QWZxQUhKUgD0JuyFc7CCDtGn2k6X96NNkg@mail.gmail.com>
 <20170327092939.r253gwnh37pyg7e2@nataraja>
 <CAMQrH54fTAdh9rTmMecpVPR11ni2R=t7tj1zyA7YrFvfSMf_FQ@mail.gmail.com>
 <D2D17EFD-CE95-4B06-B0BB-485DA85759FF@tomcsanyi.net>
Message-ID: <CAMQrH562B-mN1J5Vho62w3qnF3fzx8nAF2Vn509Q78Lth8R9eg@mail.gmail.com>

Hi Domi,

Thanks! While I building the same, I was wondering 'may be SAP protocol'
was built for it.
But thanks again for confirming it!
And Yes, I used an external card reader too. I did not check all osmocom
projects, just checked out softSIM it does mention SAP.
Sounds great! Thanks for the feedback again.

Thanks,
Gerard

On Tue, Mar 28, 2017 at 12:27 AM, Tomcs?nyi, Domonkos <domi at tomcsanyi.net>
wrote:

> Hi Gerard
>
> 2017. m?rc. 28. d?tummal, 9:10 id?pontban Gerard Pinto <
> gerardfly9 at gmail.com> ?rta:
> > 2) I have been trying something different with OsmocomBB, osmo-sim-auth
> and Tor lately - I would like to hear your views on the same.
> >  Attack Model: Geo-Location Anonymous calling in GSM.
> >
> > Description:
> > 1. The attacker uses OsmocomBB phone to make a call using a sim card
> service. (No sim card present in the phone).
> > 2. For this, I have taken the SIM card outside OsmocomBB and re-written
> all SIM API's in osmo-sim-auth (which is the sim card service).
> > 3. This sim card service is deployed over Tor network, so no one can
> actually know the location of the SIM card service.
> > 4, The osmocombb connects to the network and uses this sim card service
> for authentication etc.
> > 5. The whole setup of calling etc is initiated by the sim card service,
> which is itself behind Tor.
> >
> > 6. Now, This SIM card service can be used my multiple phones, so now you
> are not exactly going to track the phone since if I use the SIM card
> service to another phone (cell area) the DB entry in VLR has changed which
> says the location has changed.
> > 7. My experiments worked well on a LIVE network, understanding the delay
> in Tor the network, still, the BTS was accepting RES response challenge
> from the SIM card service behind Tor - I still have to calculate the exact
> max acceptable delay in sending RES back to BTS to confirm this!
>
> This is a very interesting idea, I like it! I wanted to mention the SAP
> protocol that is available in OsmocomBB's mobile app via a Unix domain
> socket since some time now. It might be even easier to use it for your
> idea. I used it via an external card reader and softSIM to provide a SIM
> card for OsmocomBB.
>
> Cheers,
>
> Domi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170329/045d7d3b/attachment.htm>

From gerardfly9 at gmail.com  Wed Mar 29 09:07:11 2017
From: gerardfly9 at gmail.com (Gerard Pinto)
Date: Wed, 29 Mar 2017 02:07:11 -0700
Subject: OsmocomBB MNCC socket implementation without LCR
In-Reply-To: <20170328094504.ah6n54fvipstswio@nataraja>
References: <1489744038673-4026771.post@n3.nabble.com>
 <20170317154950.6w24x67abr7cfkjc@nataraja>
 <CAMQrH55oyTC5DuP_QWZxQUhKUgD0JuyFc7CCDtGn2k6X96NNkg@mail.gmail.com>
 <20170327092939.r253gwnh37pyg7e2@nataraja>
 <CAMQrH54fTAdh9rTmMecpVPR11ni2R=t7tj1zyA7YrFvfSMf_FQ@mail.gmail.com>
 <20170328094504.ah6n54fvipstswio@nataraja>
Message-ID: <CAMQrH55NrpFW_hZmWu-OTqjVkvm1QRHeMyCeLLfZw9Ewh1ri=g@mail.gmail.com>

Hi Herald,

Thanks for the in-depth view.
Something that I missed out and you mentioned - IMEI randomization (I
haven't done this)
And also for introducing me to SIMtrace.
As soon as I am done with this one, I will look into pysim and SIMtrace.

Herald, I wish you good luck for OsmoCon2017 good success.
I wish to attend it someday, I look forward to hear about the session on
2.5G services and Fundamental GSM radio frequency planning.

Thanks for the help so far!
Gerard.




On Tue, Mar 28, 2017 at 2:45 AM, Harald Welte <laforge at gnumonks.org> wrote:

> Hi Gerard,
>
> On Tue, Mar 28, 2017 at 12:08:49AM -0700, Gerard Pinto wrote:
> > 1) Have you or your team tried to reverse engineer/hacking Over the Air
> OTA
> > spec - firmware upgrade (understanding this type of communication) using
> > OpenNITB and latest phones where bootloaders are locked?
>
> I haven't looked at this personally, but several people have looked at
> security of several different OTA updates for about a decade by now.
> The main issue is that there is no standard protocol or system, and
> everyone cooks up their own.
>
> > - I was planning to try this! But now I will take up merging
> osmo-sim-auth
> > and py-sim. (I'm not a great dev but I'm passionate about osmocom and
> > willing to contribute my time to learning/contributing the same).
>
> thanks!
>
> > 2) I have been trying something different with OsmocomBB, osmo-sim-auth
> and
> > Tor lately - I would like to hear your views on the same.
> >  Attack Model: Geo-Location Anonymous calling in GSM.
> >
> > Description:
> > 1. The attacker uses OsmocomBB phone to make a call using a sim card
> > service. (No sim card present in the phone).
> > 2. For this, I have taken the SIM card outside OsmocomBB and re-written
> all
> > SIM API's in osmo-sim-auth (which is the sim card service).
> > 3. This sim card service is deployed over Tor network, so no one can
> > actually know the location of the SIM card service.
> > 4, The osmocombb connects to the network and uses this sim card service
> for
> > authentication etc.
> > 5. The whole setup of calling etc is initiated by the sim card service,
> > which is itself behind Tor.
>
> This is basically the sim card forwarding / remote SIM, which people
> have been experimenting on SIMtrace for quite some time.  In this case
> you can use any regular phone or modem, and don't need osmocombb.  There
> is a complete 'remote sim / card emulation' proof of concept in the
> simtrace2.git repository, but this requires a prototype of the simtrace
> 2.x hardware (with SAM3) and not the old/current simtrace 1.x hardware
> (with SAM7).
>
> Also, there are plenty of commercial suppliers of systems like you have
> described.
>
> a) in the area of automatic roaming testing (between operators)
> b) in the area of automatic service quality testing (between operators)
> c) in the grey area of so-called SIM-boxes, where you have hundreds to
>    thousands of SIM cards in one data center, which you can remotely
>    provision to any number of "GSM VoIP gateways" spread in different
>    countries.  This is typically used for interconnection fraud by shady
>    operators.
>
> None of the above use Tor (as they have different use cases), but the
> option 'c' at least also uses IMEI randomization to avoid tracking the
> subscriber via his IMEI, which presumably you would want to do in your
> OsmocomBB based system, t..
>
> > 6. Now, This SIM card service can be used my multiple phones, so now you
> > are not exactly going to track the phone since if I use the SIM card
> > service to another phone (cell area) the DB entry in VLR has changed
> which
> > says the location has changed.
>
> Yes, but you have to be very quick.  Of course from the time of the LU
> throughout the call, your position is known to the observer.  Not
> because of your IMSI or IMEI (which you both keep changing) but because
> of the phone numbers you call.
>
> It depends on what you want to defend against.  Basically you can do
> this already if you carry around a huge bag of sim cards which you
> always only use for a single call, *and* you have a phone that can
> change the IMEI every time you change the SIM.  This is apparently what
> e.g. human rights activists in hostile countries are doing.
>
> However, the biggest problem in such situations is not your own
> identity, but the identities you contact.  So if you keep calling the
> same destination number, all of the above is useless as the key to find
> you is by the destination number.  So at the same time, you require a
> potentially large number of phone numbers that are not in some way
> associated to another (and at best in different countries), which then
> provide call redirect to your real destination.
>
> > 7. My experiments worked well on a LIVE network, understanding the delay
> in
> > Tor the network, still, the BTS was accepting RES response challenge from
> > the SIM card service behind Tor - I still have to calculate the exact max
> > acceptable delay in sending RES back to BTS to confirm this!
>
> I think I remember that at least 2 if not 4 seconds of delay are
> acceptable for the complete authentication handshake.  People are even
> doing this over satellite back-haul.
>
> --
> - 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/baseband-devel/attachments/20170329/c3d4c94b/attachment.htm>

From axilirator at gmail.com  Wed Mar 29 10:20:56 2017
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Wed, 29 Mar 2017 17:20:56 +0700
Subject: ARM Core and UI
Message-ID: <CAPEnp=YDh5r3afDKH=J31j-hT=3ZwZYMEO_soZGVQMDBOjP+Og@mail.gmail.com>

Hi Anton,

Feel free to watch OsmocomBB related talks, such as:
https://youtu.be/ihbRtTzc0NI
https://youtu.be/H7rNKZdASBE

You'll wind a lot of useful information.
Good luck!

With best regards,
Vadim Yanitskiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170329/c8ed5a1b/attachment.htm>

From axilirator at gmail.com  Fri Mar 31 14:58:36 2017
From: axilirator at gmail.com (Vadim Yanitskiy)
Date: Fri, 31 Mar 2017 21:58:36 +0700
Subject: Connecting OsmocomBB to OpenBTS
Message-ID: <CAPEnp=a+i9HX=89ipKaO1fe4GtxwB7r=e1=29DR94++Rp6TNiA@mail.gmail.com>

Hi,

> I'm guessing I would need to perform surgery on OSMOCOM-BB code in order
to
> connect it to another network? Is there any in built feature that would
> allow me to do so directly?

As I understand, you want to connect the network you running yourself on
OpenBTS.
There are two modes of network selection: manual and automatic (when MCC/MNC
from SIM card are used). Have a look at the 'network-selection-mode' in
your config
file (~/.osmocom/bb/mobile.cfg). Also, have a look at the 'network' command
in VTY.

You can also create a virtual SIM card in your ~/.osmocom/bb/mobile.cfg
(look at the
'test-sim' section) with desired IMSI and RPLMN (001 / 01 by default). Then
you will
be able to attach one using the 'sim testcard 1'.

With best regards,
Vadim Yanitskiy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170331/8127a126/attachment.htm>

From sebastian.stumpf87 at googlemail.com  Fri Mar  3 16:56:13 2017
From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf)
Date: Fri, 03 Mar 2017 16:56:13 -0000
Subject: Virtual layer 1 - Questions
In-Reply-To: <20170228213156.q72chdhhjxtyazy4@nataraja>
References: <CALFVOefg9TXn1bJ=WgNjdE+aNjotJFfzg3WkNg2yavyb94gTyA@mail.gmail.com>
 <20170212230920.epvdsj7jwxzta23w@nataraja>
 <CALFVOedfBVboU4Lk9D9QQNhr-dqybnH=0aNj=Zgucd3FjOJU4g@mail.gmail.com>
 <20170223144124.mdba7w7avdujy23g@nataraja>
 <CALFVOeeB=REeGK6=NaZr+adr7vNUJMzE6wHYMK=XdckFnzazbA@mail.gmail.com>
 <20170228213156.q72chdhhjxtyazy4@nataraja>
Message-ID: <CALFVOecU3fK6uPAB4=LDNE9OS9CY9vgUV+pwaAJCvC+qtPC+PQ@mail.gmail.com>

Hi Harald,

> This is likely a result of the MS somehow not receiving/processing the
> downlink signalling messages. [on TCH]

I found the reason for that. I thought I need to forward incoming messages
on TCH/H TCH/F as L1CTL_TRAFFIC_IND if the ACCH flag is not set in the
GSMTAP header channel type. But in case of a msg on FACCH this is wrong
and needs to be L1CTL_DATA_IND. As the CM Service Accept is sent on
FACCH it was not forwarded correctly to l23 and thus not processed.

Unfortunately I do not know, how to distinguish FACCH from TCH based on
the information available in the GSMTAP messages.
The stealing flag indicating a FACCH is set before and after the training
sequence in the burst I think, but this info is no longer available in the msg
as it is sent over the virtual um.

Or do I miss something here?

Do you have an idea how to check if the msg is TCH or FACCH?

> Also, what's noteworthy (but likely unrelated) is that the BTS is
> sending empty idle/padding frames on the TS7 all the time (those
> containing 0x2b2b2b2b) but the MS is not doing that in uplink.

That's because I just implemented some kind of one time scheduler.
If I do not get frames/data to schedule from the upper layer for a tdma slot,
I currently do not have any logic that fills these up with empty/idle frames.
Seems as if I need this, though.

Thanks a lot for your support, I am glad you are taking the time to help me
out :).

With kind regards,
Sebastian Stumpf


From sebastian.stumpf87 at googlemail.com  Fri Mar 10 13:36:13 2017
From: sebastian.stumpf87 at googlemail.com (Sebastian Stumpf)
Date: Fri, 10 Mar 2017 13:36:13 -0000
Subject: SMS not received in mobile - Virtual layer1 (osmo-nitb + osmo-bts +
 osmocom-bb/mobile)
Message-ID: <CALFVOecysW2gsyHN+r2bg-UXRz5ubRRk9eO2ahx=SwW5Wg=gEg@mail.gmail.com>

Hi,

Some of my sent SMS are not received by my mobile and I try to figure out
if this is a problem with my virtual layer 1, configuration or
something in the layers 2+.

I use:
osmo-nitb: 1 subscriber in hlr (id 1, ext 017519191919)
osmo-bts: virt-phy, arfcn 666, TS0=CCCH+SDCCH4, TS1=SDCCH8
MS layer23 app mobile: is the subscriber from osmo-nitb
MS layer1 virt-phy: virtual gsmtap layer between bts and mobile

I want:
Send a sms to subscriber 017519191919.
osmo-nitb VTY:
 OpenBSC# subscriber id 1 sms sender id 1 send Test

I have 2 outcomes, first one is the failure. See
https://www.dropbox.com/s/eunpfioq518t09a/mobile--ms-virt--bts-virt--bsc-nitb_170310%3Afailed_sms_rec_lapdm.pcapng?dl=0
for the pcap. Do not wonder about the duplicated gsmtap messages from mobile,
the ones to ip 225.0.0.1 are over virt-phy layer, the ones to localhost from
the gsmtap logging option from mobile. Filter them out via "gsmtap &&
(ip.dst != 127.0.0.1)".

602-613: RR channel establishment with RA and IA as reaction to paging in 590
627,631: SABM from BTS to establish async balanced mode on SAPI3 (SMS)
and the ACK from MS
656,684,699: I-Data frames on SAPI3 containing the sms
660,688,703: ReceiveReady's from MS (That ACK all I-frames before
N(R)-1 as far as I understood)

For me, that looks good and I really do not understand why the MS will
not answer with the CP-ACK/RP-ACK
after receiving the SMS Data in 699.
The LAPDM link will stay up for some more time and be used by the
network for retransmission of the sms (1149),
but MS will never react to it on the SMS layer (CP-ACK, RP-ACK).

Here is the console log for the mobile
(https://www.dropbox.com/s/6gug5cd4up5qv7y/mobile--ms-virt--bts-virt--bsc-nitb_170310%3Afailed_sms_rec_lapdm?dl=0).
The paging is answered in line 378:
 Fri Mar 10 10:42:06 2017 DLLAPD <0012> lapd_core.c:793 SABM(E)
received in state LAPD_STATE_IDLE

Second outcome is a successfully sent sms from network to ms. See
https://www.dropbox.com/s/ghdn7pc0j4vifbe/mobile--ms-virt--bts-virt--bsc-nitb_170310%3Asuc_sms_rec_lapdm.pcapng?dl=0
for the pcap. What is different here? There is no paging, but the sms
is sent within the dedicated
channel used for the location update initiated by the phone started
up. Why there is another outcome, I don't know.

169-181: RR channel establishment with RA and IA as part of mibiles
startup routine to make location update
188,416: Location udpdate procedure on SAPI0
230,234: SABM from BTS to establish async balanced mode on SAPI3 (SMS)
and the ACK from MS
396,444: I-Data frames on SAPI3 containing the sms
400,449: RR's from MS
450: CP-ACK for BTS
482,499: RP-ACK I-Frames for Network (osmo-nitb)

Again, the console log of the mobile
(https://www.dropbox.com/s/cujsn40d43g6wxk/mobile--ms-virt--bts-virt--bsc-nitb_170310%3Asuc_sms_rec_lapdm?dl=0).
The SABM on SAPI3 on downlink is received in line 206:
 Fri Mar 10 11:06:13 2017 DLLAPD <0012> lapd_core.c:793 SABM(E)
received in state LAPD_STATE_IDLE

The signaling looks quite similar in both cases, but one time the
mobiles sms handler responds to CP-DATA msg containing the SMS, the
other time not.
Can someone find an error in the signaling I did not see?
Is there a known Bug? To be honest, I last merged my branch with
master some time ago (~ Jan 18 2017) and thus did not update osmo-nitb
and
the libraries since then to avoid compatibility problems. Have there
been recent changes that could cause that behavior?

Thank you and Kind Regards,
Sebastian


From fisher.grubb at gmail.com  Fri Mar 10 16:55:22 2017
From: fisher.grubb at gmail.com (Fisher Grubb)
Date: Fri, 10 Mar 2017 16:55:22 -0000
Subject: Quectel modem documentation etc
Message-ID: <CAD4Xxq8YtU4V3XJgOHak_bSwcNXbDgV70uzde7xphmfqc=UndQ@mail.gmail.com>

Hi all,

I know of some publicly available documentation and tools.

I assume you have it, let me know if you don't and I'll post links.

I downloaded it last year for UC20 (124MB zip file),and EC21 (60MB zip
file).

Fisher
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20170310/ff4c07a7/attachment.htm>