Moving from trac to a single redmine

Вадим Яницкий axilirator at gmail.com
Fri Feb 19 08:08:12 UTC 2016


Hi 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-0001.html>


More information about the baseband-devel mailing list