This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/baseband-devel@lists.osmocom.org/.
Вадим Яницкий axilirator at gmail.comHi all! Moving all projects to a Redmine is a good way, I think. In connection with the event I would like to offer my help with post-processing some old pages (mostly OsmocomBB) and with improving the new wiki structure. So, my suggestions: - Create the main page that will describe all all of the child projects of Osmocom umbrella including recent news and plans. - Separate the libosmocore related pages from OsmocomBB into a new section named "Libraries", for example. - Separate both SIMTrace and softSIM into a new sections. It it would be nice to enable Strict-Transport-Security to avoid some traffic interception attempts. Also what about enabling SPF and DKIM for mailing lists? With best regards, Vadim Yanitskiy. 2016-02-19 4:46 GMT+06:00 <openbsc-request at lists.osmocom.org>: > Send OpenBSC mailing list submissions to > openbsc at 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 at lists.osmocom.org > > You can reach the person managing the list at > openbsc-owner at 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 at sysmocom.de> > To: Eric Blake <eblake at redhat.com> > Cc: bug-autoconf at gnu.org, openbsc at lists.osmocom.org > Subject: Re: autoreconf v2.69 with subdir-objects: ./configure creates > directory 'src/tests/\$(top_srcdir)' > Message-ID: <20160217144435.GD2106 at 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 at sysmocom.de> > To: Harald Welte <hwelte at sysmocom.de> > Cc: openbsc at lists.osmocom.org > Subject: Re: hnb_cs_lu.msc > Message-ID: <20160217144710.GE2106 at 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 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: Holger Freyther, Harald Welte > > > > -- > - 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: 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 at sysmocom.de> > To: Neels Hofmeyr <nhofmeyr at sysmocom.de> > Cc: openbsc at lists.osmocom.org > Subject: Re: hnb_cs_lu.msc > Message-ID: <20160217162652.GU5868 at 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 at sysmocom.de> http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte > > > ------------------------------ > > Message: 4 > Date: Thu, 18 Feb 2016 12:56:20 +0100 > From: Neels Hofmeyr <nhofmeyr at sysmocom.de> > To: openbsc at lists.osmocom.org > Subject: branches: daniel/gprs-iu + sysmocom/cscn = sysmocom/iu; > merging to master > Message-ID: <20160218115512.GA2630 at 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 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: 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 at gnumonks.org> > To: Holger Freyther <holger at freyther.de> > Cc: baseband-devel at lists.osmocom.org, OpenBSC Mailing List > <openbsc at lists.osmocom.org>, osmocom-sdr at lists.osmocom.org, > gmr at lists.osmocom.org > Subject: Re: Moving from trac to a single redmine > Message-ID: <20160218184318.GW4570 at 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 at 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 at freyther.de> > To: baseband-devel at lists.osmocom.org, OpenBSC Mailing List > <openbsc at lists.osmocom.org>, osmocom-sdr at lists.osmocom.org, > gmr at lists.osmocom.org > Subject: Re: Moving from trac to a single redmine > Message-ID: <753DCDAF-0723-4EC5-8E3C-870B7D5959C5 at freyther.de> > Content-Type: text/plain; charset=us-ascii > > > > On 18 Feb 2016, at 19:43, Harald Welte <laforge at 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 at freyther.de> > To: Neels Hofmeyr <nhofmeyr at sysmocom.de> > Cc: openbsc at lists.osmocom.org > Subject: Re: branches: daniel/gprs-iu + sysmocom/cscn = sysmocom/iu; > merging to master > Message-ID: <D8449C8C-5FD0-4A03-88FA-F0EBBA3ADD41 at freyther.de> > Content-Type: text/plain; charset=iso-8859-1 > > > > On 18 Feb 2016, at 12:56, Neels Hofmeyr <nhofmeyr at 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 at sysmocom.de> > To: Daniel Willmann <dwillmann at sysmocom.de> > Cc: openbsc at lists.osmocom.org > Subject: sysmocom/iu: your commits from today > Message-ID: <20160218224544.GA18542 at 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 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: 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 at lists.osmocom.org > https://lists.osmocom.org/mailman/listinfo/openbsc > > > ------------------------------ > > End of OpenBSC Digest, Vol 16, Issue 19 > *************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.osmocom.org/pipermail/baseband-devel/attachments/20160219/07484ae4/attachment.htm>