Send OpenBSC mailing list submissions to
openbsc@lists.osmocom.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osmocom.org/mailman/listinfo/openbsc
or, via email, send a message with subject or body 'help' to
openbsc-request@lists.osmocom.org
You can reach the person managing the list at
openbsc-owner@lists.osmocom.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of OpenBSC digest..."
Today's Topics:
1. Re: autoreconf v2.69 with subdir-objects: ./configure creates
directory 'src/tests/\$(top_srcdir)' (Neels Hofmeyr)
2. Re: hnb_cs_lu.msc (Neels Hofmeyr)
3. Re: hnb_cs_lu.msc (Harald Welte)
4. branches: daniel/gprs-iu + sysmocom/cscn = sysmocom/iu;
merging to master (Neels Hofmeyr)
5. Re: Moving from trac to a single redmine (Harald Welte)
6. Re: Moving from trac to a single redmine (Holger Freyther)
7. Re: branches: daniel/gprs-iu + sysmocom/cscn = sysmocom/iu;
merging to master (Holger Freyther)
8. sysmocom/iu: your commits from today (Neels Hofmeyr)
----------------------------------------------------------------------
Message: 1
Date: Wed, 17 Feb 2016 15:44:35 +0100
From: Neels Hofmeyr <nhofmeyr@sysmocom.de>
To: Eric Blake <eblake@redhat.com>
Cc: bug-autoconf@gnu.org, openbsc@lists.osmocom.org
Subject: Re: autoreconf v2.69 with subdir-objects: ./configure creates
directory 'src/tests/\$(top_srcdir)'
Message-ID: <20160217144435.GD2106@dub6>
Content-Type: text/plain; charset="us-ascii"
Eric,
you've clarified just about all of my questions.
Many thanks for your reply!
~Neels
> https://lists.gnu.org/archive/html/automake/2015-12/msg00001.html
-------------- 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/openbsc/attachments/20160217/8d3fdbf8/attachment-0001.bin>
------------------------------
Message: 2
Date: Wed, 17 Feb 2016 15:47:10 +0100
From: Neels Hofmeyr <nhofmeyr@sysmocom.de>
To: Harald Welte <hwelte@sysmocom.de>
Cc: openbsc@lists.osmocom.org
Subject: Re: hnb_cs_lu.msc
Message-ID: <20160217144710.GE2106@dub6>
Content-Type: text/plain; charset="iso-8859-1"
Update: it seems that for IuPS/SGSN, a quite identical Identity Request
message is indeed answered upon by the UE, so the reason why I'm not
receiving one for IuCS/CSCN is unclear.
~Neels
On Wed, Feb 17, 2016 at 02:18:54PM +0100, Neels Hofmeyr wrote:
> Hi Harald,
>
> in osmo-iuh/doc/hnb_cs_lu.msc I find that after the location update
> request from the UE, an identity request "should" follow from the CN.
>
> Yesterday I made my first pcap using our hNodeB and that weighty black UE
> we use for testing, and saw that the MSC indeed sends out an identity
> request at that time [1], however, the UE simply never responds to it.
>
> My question: is the hnb_cs_lu.msc declarative and definitely correct, or
> could it be that in 3G, UEs in general expect authentication first, as
> the "osmo-iuh/pcap/UPP RANAP.pcap" suggests (starting at packet #335).
>
> Since my sources tell me (i.e. Daniel) that an identity request at that
> time is indeed kinda special practise by openbsc to collect all IMEIs we
> possibly can, I'm going for authentication first.
>
> Just wanted to make sure you agree that the hnb_cs_lu.msc may be erratic
> in that case. Thanks!
>
> ~Neels
>
> [1] near openbsc/src/libmsc/gsm_04_08.c:589 (thanks Daniel!)
>
> --
> - Neels Hofmeyr <nhofmeyr@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: Holger Freyther, Harald Welte
--
- Neels Hofmeyr <nhofmeyr@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: Holger Freyther, 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/openbsc/attachments/20160217/7dbd36fd/attachment-0001.bin>
------------------------------
Message: 3
Date: Wed, 17 Feb 2016 17:26:52 +0100
From: Harald Welte <hwelte@sysmocom.de>
To: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Cc: openbsc@lists.osmocom.org
Subject: Re: hnb_cs_lu.msc
Message-ID: <20160217162652.GU5868@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Neels,
On Wed, Feb 17, 2016 at 02:18:54PM +0100, Neels Hofmeyr wrote:
> in osmo-iuh/doc/hnb_cs_lu.msc I find that after the location update
> request from the UE, an identity request "should" follow from the CN.
it is no 'should at all'. There are some "Common MM Procedures" that
can be invoked by MM (on the network side) at any time. This includes,
AFAIR:
* IDENTITY REQ / RESP
* AUTHENTICATION REQ / RESP
* MM INFO
So the network can at any point in time ask the MS/UE about any of its
identities.
> Yesterday I made my first pcap using our hNodeB and that weighty black UE
> we use for testing, and saw that the MSC indeed sends out an identity
> request at that time [1], however, the UE simply never responds to it.
OsmoNITB was originally developed as part of security research, and thus
we wanted to demonstrate the fact that we can query the IMSI and IMEI of
every phone at a very early stage. This is why we always ask for the
IMEI, and we ask for the IMSI if we don't already know it (because it
was contained in the LU / CM SERV REQ, or because we know the TMSI and
can use it to map to the IMSI).
If there's no response from the phone, then it's likely something is
going wrong somehwere in between. Do you see the request on the RUA
interface towards the HNB? What does the HNB logging/tracing tell you
about that message? What does a protocol trace on a UE with xgoldmon
tell you?
> My question: is the hnb_cs_lu.msc declarative and definitely correct, or
> could it be that in 3G, UEs in general expect authentication first, as
> the "osmo-iuh/pcap/UPP RANAP.pcap" suggests (starting at packet #335).
No. There might still be situtaions where the IMSI is not known to the
network at LU time, and the network must be able to obtain it via
IDENTITY REQUEST before being able to obtain the auth quintuples and
perform authentication.
What else would you do if you'd get a LU with an unknown TMSI?
--
- Harald Welte <hwelte@sysmocom.de> http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte
------------------------------
Message: 4
Date: Thu, 18 Feb 2016 12:56:20 +0100
From: Neels Hofmeyr <nhofmeyr@sysmocom.de>
To: openbsc@lists.osmocom.org
Subject: branches: daniel/gprs-iu + sysmocom/cscn = sysmocom/iu;
merging to master
Message-ID: <20160218115512.GA2630@dub6>
Content-Type: text/plain; charset="iso-8859-1"
The openbsc branches to use for testing IuPS and IuCS have changed,
because Daniel and I have merged the branches.
They used to be daniel/gprs-iu (IIRC) and sysmocom/cscn.
Both are now merged as:
sysmocom/iu
Holger, this is relevant to our coverity configuration.
We are still using other branches that may or may not be merged to their
respective masters. I'd like to publicly record here why or why not we
should merge them now. Please add any reasons you know.
We're using master for Iu[h|CS|PS] in:
libasn1c: * master
libosmo-abis: * master
libosmocore: * master
openggsn: * master
osmo-python-tests: * master
osmo-iuh: * master
Reasons NOT to merge to master in:
openbsc: * sysmocom/iu
- hardcoded kc and sres for testing
- NITB and most probably osmo-bsc are not operational
- A-interface not implemented in CSCN
asn1c: * aper-prefix
- ?
libosmo-netif: * sysmocom/sctp
- ?
libosmo-sccp: * laforge/wip
- ?
Thanks for any additions...
~Neels
--
- Neels Hofmeyr <nhofmeyr@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: Holger Freyther, 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/openbsc/attachments/20160218/3f7a1c48/attachment-0001.bin>
------------------------------
Message: 5
Date: Thu, 18 Feb 2016 19:43:18 +0100
From: Harald Welte <laforge@gnumonks.org>
To: Holger Freyther <holger@freyther.de>
Cc: baseband-devel@lists.osmocom.org, OpenBSC Mailing List
<openbsc@lists.osmocom.org>, osmocom-sdr@lists.osmocom.org,
gmr@lists.osmocom.org
Subject: Re: Moving from trac to a single redmine
Message-ID: <20160218184318.GW4570@nataraja>
Content-Type: text/plain; charset=us-ascii
Hi Holger,
let's move ahead and start with the migration, I can't wait to put all
the various tickets into a public redmine.
Thanks!
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
------------------------------
Message: 6
Date: Thu, 18 Feb 2016 19:52:55 +0100
From: Holger Freyther <holger@freyther.de>
To: baseband-devel@lists.osmocom.org, OpenBSC Mailing List
<openbsc@lists.osmocom.org>, osmocom-sdr@lists.osmocom.org,
gmr@lists.osmocom.org
Subject: Re: Moving from trac to a single redmine
Message-ID: <753DCDAF-0723-4EC5-8E3C-870B7D5959C5@freyther.de>
Content-Type: text/plain; charset=us-ascii
> On 18 Feb 2016, at 19:43, Harald Welte <laforge@gnumonks.org> wrote:
>
> Hi Holger,
Hi all!
>
> let's move ahead and start with the migration, I can't wait to put all
> the various tickets into a public redmine.
last weekend I used the "stock" redmine trac->redmine converter and the result is on projects.osmocom.org. It is not perfect but I think good enough to start moving. We see that certain formating needs a post-import correction but that should be doable by all of us quickly.
My plan/timeline (on short notice but I don't expect a major resistence so I hope it is fine):
* Patch the redmine importer to not import tickets. This hopefully allows me to import other tracs at the same time (and re-add the security tickets by hand)
* Friday evening set the tracs to read-only (I probably move the account file away)
* Saturday/Sunday do the migration of the trac.
* Make it available on osmocom.org (currently it is projects.osmocom.org)
* Keep the trac as read-only version for now
In the mid-term:
* We need to post-process some pages and move them around to have a better structure
* Add permanent redirects from the trac to osmocom.org for "approved" content. This way normal traffic will automatically move to the new page and then we can look at the access.log for which pages still need a re-direct.
any objections?
holger
------------------------------
Message: 7
Date: Thu, 18 Feb 2016 21:02:42 +0100
From: Holger Freyther <holger@freyther.de>
To: Neels Hofmeyr <nhofmeyr@sysmocom.de>
Cc: openbsc@lists.osmocom.org
Subject: Re: branches: daniel/gprs-iu + sysmocom/cscn = sysmocom/iu;
merging to master
Message-ID: <D8449C8C-5FD0-4A03-88FA-F0EBBA3ADD41@freyther.de>
Content-Type: text/plain; charset=iso-8859-1
> On 18 Feb 2016, at 12:56, Neels Hofmeyr <nhofmeyr@sysmocom.de> wrote:
>
> The openbsc branches to use for testing IuPS and IuCS have changed,
> because Daniel and I have merged the branches.
>
> They used to be daniel/gprs-iu (IIRC) and sysmocom/cscn.
> Both are now merged as:
>
> sysmocom/iu
>
> Holger, this is relevant to our coverity configuration.
and the build is broken.
/home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:126:1: warning: "ENHANCEDRELOCATIONCOMPLETEREQUESTIES_RANAP_EXTENDEDRNC_ID_PRESENT" redefined
/home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:125:1: warning: this is the location of the previous definition
/home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:436:1: warning: "RANAP_ENHANCEDRELOCATIONINFORMATIONREQUESTIES_RANAP_IUSIGNALLINGCONNECTIONIDENTIFIER_PRESENT" redefined
/home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:434:1: warning: this is the location of the previous definition
/home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:437:1: warning: "RANAP_ENHANCEDRELOCATIONINFORMATIONREQUESTIES_RANAP_GLOBALCN_ID_PRESENT" redefined
/home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:435:1: warning: this is the location of the previous definition
In file included from /home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_common.h:592,
from /home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:7,
from iu.c:26:
/home/builder/coverity/install-iuh/include/osmocom/ranap/ranap_ies_defs.h:856: error: redefinition of typedef 'RANAP_RAB_SetupOrModifiedItemIEs_t'
../../include/openbsc/iu.h:8: note: previous declaration of 'RANAP_RAB_SetupOrModifiedItemIEs_t' was here
In file included from iu.c:31:
/home/builder/coverity/install-iuh/include/asn1c/asn1helpers.h: In function 'OCTET_STRING_noalloc':
/home/builder/coverity/install-iuh/include/asn1c/asn1helpers.h:26: warning: assignment discards qualifiers from pointer target type
iu.c: In function 'ranap_handle_co_rab_ass_resp':
iu.c:273: warning: implicit declaration of function 'ranap_free_rab_setupormodifieditemies'
make[3]: *** [iu.o] Error 1
make[3]: Leaving directory `/home/builder/coverity/source-iuh/openbsc/openbsc/src/libiu'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/builder/coverity/source-iuh/openbsc/openbsc/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/builder/coverity/source-iuh/openbsc/openbsc'
make: *** [all] Error 2
branches used:
asn1c
* aper-prefix
layer1-api
* master
libasn1c
* master
libosmo-abis
* master
libosmo-dsp
* master
libosmo-netif
* sysmocom/sctp
libosmo-sccp
* laforge/wip
libosmocore
* master
libsmpp34
* master
openbsc
* sysmocom/iu
openggsn
* master
osmo-bts
* master
osmo-gmr
* master
osmo-iuh
* master
osmo-pcu
* master
------------------------------
Message: 8
Date: Thu, 18 Feb 2016 23:45:44 +0100
From: Neels Hofmeyr <nhofmeyr@sysmocom.de>
To: Daniel Willmann <dwillmann@sysmocom.de>
Cc: openbsc@lists.osmocom.org
Subject: sysmocom/iu: your commits from today
Message-ID: <20160218224544.GA18542@dub6>
Content-Type: text/plain; charset="iso-8859-1"
Moin Daniel :)
(1)
About ebd4d820b3b0d7ba5db3b25a14f407d0c7276044
"libiu: Use custom setupormodifieditemies function"
It seems you forgot to commit the actual function definition of
ranap_decode_rab_setupormodifieditemies_fromlist()
I got the caller of it only and thus can't compile as-is.
(2)
About 38e2f1bca4e43414ed39a938d7c5d8bafe5e8533
"
Revert "iu.c: avoid warning by declaring ranap_free_rab_setupormodifieditemies()"
There should be no need to silence this warning, the ranap_free_*
functions are declared in libranap headers. In any case this will only
obscure any real issue. Maybe osmo-iuh was not rebuilt completely
(including generation of the c files from the python script).
This reverts commit 05ae5b1245f95bf765b42e49af7b2596e013f0a0.
"
I declared ranap_free_rab_setupormodifieditemies() like that because it is
indeed not declared in a header that is installed. Also a grep tells me
that no ranap_free_* is found in any osmo-iuh header file at all.
I also did a 'make regen' in osmo-iuh/src/ to no avail.
By 'libranap headers' I assume you mean libosmo-ranap, or is there a
libranap I'm not aware of yet?
If the ranap_free_* aren't in headers yet, I agree that they should be. I
wanted to silence the warning without being sucked down the rabbit hole of
autogenerated asn1 stuff. Any suggestions: more than welcome.
(3)
In general, I would welcome to see more of your WIP work in publicly
visible private branches, maturing as you go and merged to sysmocom/iu
once ready. For one, having a backup of your work-in-progress in the git
repos makes it harder to lose it due to hardware failure. More important
for me though is that I can see what you're up to, e.g. I could possibly
find the ranap_..._fromlist() function defintion now. It's of course
opening up your "most private" code developments to the outside world,
possibly some stupid commits will be seen by one or two hacker peers, but
I think it's a healthy premise that we all commit mostly bollocks and all
needs refinement anyway... once again: push it! :)
Ah, push it
Push it good
Ah, push it
Pu-Push it real good
-- Salt N Pepa (1987)
As always I'm open to opinions and suggestions...
~Neels
--
- Neels Hofmeyr <nhofmeyr@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: Holger Freyther, 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/openbsc/attachments/20160218/e2656577/attachment.bin>
------------------------------
Subject: Digest Footer
_______________________________________________
OpenBSC mailing list
OpenBSC@lists.osmocom.org
https://lists.osmocom.org/mailman/listinfo/openbsc
------------------------------
End of OpenBSC Digest, Vol 16, Issue 19
***************************************