From: gitosis@osmocom.org
Precedence: list
To: osmocom-commitlog@lists.osmocom.org
Date: Fri, 21 Mar 2014 11:35:03 GMT
Message-ID: <201403211135.s2LBZ3Ow073430@git.osmocom.org>
Subject: openggsn.git branch osmo-ggsn updated. 0.91-44-g51870ff
Message: 1

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 OpenGGSN project".

The branch, osmo-ggsn has been updated
  discards  d861a05cf0e7642aac7c156857185d3254b0c2e8 (commit)
  discards  6637a13dab3627e259c591287e9308a3d0677421 (commit)
  discards  1a1ba02292b17933c31b513979a4e8fb8b230247 (commit)
       via  51870ff24cc31a3fd2c8b924dc2e7c959007df20 (commit)
       via  6730fb9aed9a62e0b35d282eae66cf482e995594 (commit)

This update added new revisions after undoing existing revisions.  That is
to say, the old revision is not a strict subset of the new revision.  This
situation occurs when you --force push a change and generate a repository
containing something like this:

 * -- * -- B -- O -- O -- O (d861a05cf0e7642aac7c156857185d3254b0c2e8)
            \
             N -- N -- N (51870ff24cc31a3fd2c8b924dc2e7c959007df20)

When this happens we assume that you've already had alert emails for all
of the O revisions, and so we here report only the revisions in the N
branch from the common base, B.

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
http://cgit.osmocom.org/openggsn/commit/?id=51870ff24cc31a3fd2c8b924dc2e7c959007df20

commit 51870ff24cc31a3fd2c8b924dc2e7c959007df20
Author: Pablo Neira Ayuso <pablo@gnumonks.org>
Date:   Sat Feb 22 23:30:59 2014 +0100

    ggsn: add support for GTP kernel data encapsulation
    
    This patch adds the -g, --gtpnl=device option that allows you to
    enable the GTP kernel tunneling mode in openggsn. You have to specify
    the real downlink device that will be used to tunnel traffic, eg.
    
    	-g=eth0
    
    This means that the gtp0 device will be created and it will use eth0
    as the real device to encapsulate packet coming from the Internet that
    are addressed to the MS (so the tunnel devuce encapsulates these IP
    packets in GTP packets when traveling to the SGSN).
    
    Alternatively, you can also add this to the ggsn.conf configuration file:
    
    	gtpnl eth0
    
    The device has to be the real device that can route packets to the SGSN,
    if you select the wrong device, the kernel routing code may not find a
    way to reach the SSGN, you've been warned.
    
    Therefore, if this option is set, the operational becomes the following:
    
    1) A gtp0 device is created via rtnetlink and configure the socket
       encapsulation infrastructure in the kernel.
    2) Whenever a PDP context is created, this adds the necessary tunnel
       configuration via genetlink GTP interface.
    3) Whenever a PDP context is destroyed, this deletes the tunnel via
       genetlink GTP interface.
    4) Destroy the gtp0 device if ggsn is stopped, including all of the
       existing tunnels.
    
    You require the osmo-ggsn.git tree, which contains the kernel module
    gtp.ko and the libgtpnl library that you have to compile and install.
    Make sure you have loaded the gtp.ko kernel module before launching
    the ggsn daemon using the kernel driver mode, otherwise you will get
    a nice "operation not supported" error message ;-).
    
    This patch also adds supports for "ipup" configuration option to invoke
    an external script after the gtp0 device has been brought up. Typical
    command to add the route to reach the MS behind the GGSN is required,
    eg. ip route add 10.0.0.0/8 dev gtp0.
    
    The (horrible) ggsn parser has been manually extended to support the
    new configuration option. That code doesn't look nice, but it just
    mimics what we already have there for consistency, please don't blame
    me for that.
    
    If you want to run in debugging mode, I suggest you to use:
    
    	sudo ggsn -c ggsn.conf -f -d
    
    Note that you do have to run openggsn as root to bring up the gtp0
    device. You have to see this message that announce that the GTP kernel
    mode is enabled.
    
    openggsn[1106]: ggsn.c: 656: Using the GTP kernel mode (genl ID is 25)
    
    This patch also automagically sets up route to reach MS from Internet
    just like tun mode does. This is fundamental to get this working,
    better don't leave to the admin, he may forget to add this route.

http://cgit.osmocom.org/openggsn/commit/?id=6730fb9aed9a62e0b35d282eae66cf482e995594

commit 6730fb9aed9a62e0b35d282eae66cf482e995594
Author: Pablo Neira Ayuso <pablo@gnumonks.org>
Date:   Thu Mar 20 12:35:26 2014 +0100

    gtp: fix endianness in teid field of GTPv0 header
    
    This field needs to be in network byte order as well. This problem
    may manifest if you use ggsn and sgsn with different endianness.
    It also show up when using the gtp kernel mode since the downlink
    packets are using network byte order in the 64-bits teid field,
    which osmo-sgsn / libgtp doesn't expect.

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

Summary of changes:
 ggsn/ggsn.c |  9 +++------
 gtp/gtp.c   | 13 ++++---------
 gtp/pdp.c   |  6 ++++++
 gtp/pdp.h   |  2 ++
 4 files changed, 15 insertions(+), 15 deletions(-)


hooks/post-receive
-- 
The OpenGGSN project