Subject: openbsc.git branch ciaby/rhizomatica-next created. 0.13.0-403-gca90888
From: [email-masked]
To: [email-masked]
Date: Sat, 31 May 2014 19:31:47 GMT

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)".

The branch, ciaby/rhizomatica-next has been created
        at  ca90888cd18656c23b4b283cb1dee538ec8492f3 (commit)

- Log -----------------------------------------------------------------
http://cgit.osmocom.org/openbsc/commit/?id=ca90888cd18656c23b4b283cb1dee538ec8492f3

commit ca90888cd18656c23b4b283cb1dee538ec8492f3
Author: Ciaby <[email-masked]>
Date:   Sun May 4 20:04:11 2014 +0200

    Revert MNCC_SOCK_VERSION to 2 (from 4), otherwise there is no know LCR version which can work with it :)
    Also mentioned at:
    https://gitorious.org/sysmocom-openembedded/meta-telephony/commit/4da2963d82e7bee3045f73448d17395f78f1caf0

http://cgit.osmocom.org/openbsc/commit/?id=e332597196c5991fc3bce9c0ed7df9f6d4194881

commit e332597196c5991fc3bce9c0ed7df9f6d4194881
Author: Ciaby <[email-masked]>
Date:   Fri May 2 12:51:01 2014 +0200

    Merged hfreyther/fixes/channel-release-handling branch, bumped version number to -rhizo3

http://cgit.osmocom.org/openbsc/commit/?id=566ed809d174e07569f0dc2c6dfd05407630812b

commit 566ed809d174e07569f0dc2c6dfd05407630812b
Author: Ciaby <[email-masked]>
Date:   Sat Mar 8 20:25:48 2014 +0100

    Disable the gbproxy test (failing). Bump the debian version in the changelog.

http://cgit.osmocom.org/openbsc/commit/?id=c7501f9230b6ae0d172a4911f86f5c6433d57d1f

commit c7501f9230b6ae0d172a4911f86f5c6433d57d1f
Author: Ciaby <[email-masked]>
Date:   Fri Mar 7 15:50:51 2014 +0100

    DIRTY HACK: Force all SMSs to SMPP.

http://cgit.osmocom.org/openbsc/commit/?id=4379e6c35e8c559b1f813c2b55027b73c7e6232b

commit 4379e6c35e8c559b1f813c2b55027b73c7e6232b
Author: Ciaby <[email-masked]>
Date:   Fri Mar 7 15:36:22 2014 +0100

    Added SMPP support in the debian build, include libsmpp34-dev as a dependency.

http://cgit.osmocom.org/openbsc/commit/?id=6c7889f28b300d9798baf9c5719e634b5fb2a063

commit 6c7889f28b300d9798baf9c5719e634b5fb2a063
Author: Holger Hans Peter Freyther <[email-masked]>
Date:   Sat Apr 19 17:38:33 2014 +0200

    rsl: Check if the channel is active and then start the channel release
    
    In case we receive ERROR INDICATION and CONNECTION FAILURE we only
    want to RF Channel Release the lchan once. This code is more simple
    and should work as reliable as the previous commit.

http://cgit.osmocom.org/openbsc/commit/?id=ad61c3a23d0069dbf2c0c7dba518439e8930d8ad

commit ad61c3a23d0069dbf2c0c7dba518439e8930d8ad
Author: Holger Hans Peter Freyther <[email-masked]>
Date:   Sat Apr 19 16:45:36 2014 +0200

    rsl: Avoid double channel release procedure in error conditions
    
    When we receive an ERROR INDICATION and CONNECTION FAILURE we
    might call rsl_rf_chan_release multiple times. The channel release
    handling is still a bit messy and there too many paths that lead
    to the call.
    
    1.) In case we receive an ERROR INDICATION for SAPI=3. A RLL
    error signal will be emitted that leads to the release of the
    channel through the SMS code in case of the NITB.  The call to
    rsl_rf_chan_release might be a double release.
    
    2.) In case a CONNECTION FAILURE is received when the release
    process has already been started we would unconditionally
    call rsl_rf_chan_release as well.
    
    Because the lchan state is changed by the callers of the
    rsl_rf_chan_release we can not move the state checking into this
    code but need to do it in the caller. The issue was seen in a trace
    from Rhizomatica and I created the DoubleRelease.st to re-produce
    the issue and verified that we have no duplicate RF Channel Releses.
    
    The other option would be to introduce a new state to track
    the release process and see if we have already released SAPIs
    deactivated the SACCH or such. We can not simply look at these
    as for a channel that fails to activate they will be null already.

http://cgit.osmocom.org/openbsc/commit/?id=cb1976faf4b95e470a27754b5f2e180c7998c36f

commit cb1976faf4b95e470a27754b5f2e180c7998c36f
Author: Holger Hans Peter Freyther <[email-masked]>
Date:   Sun Apr 6 12:21:05 2014 +0200

    lchan: Speculative "fix" for error and late reply
    
    Looking at the code it seemed possible that a channel would
    transition from BROKEN to NONE. Or worse from NONE to BROKEN.
    Start the timer _after_ the channel has been released.

-----------------------------------------------------------------------

hooks/post-receive
-- 
The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)