osmo-ggsn.git branch master updated. 1.1.0-38-g4f03432

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/osmocom-commitlog@lists.osmocom.org/.

gitosis at osmocom.org gitosis at osmocom.org
Tue Dec 5 17:29:26 UTC 2017


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, master has been updated
       via  4f0343233b83337afa1e1dfb4bcf9d076ecd4be2 (commit)
       via  bcab7fb4afcd5c9015f05ce1cce02f9a76928217 (commit)
       via  427699e6ebcf2f9e3f05198fb1f5afbd408d389e (commit)
      from  9c0f4f49e9b15b55cd9baa42c1ba191903664397 (commit)

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/osmo-ggsn/commit/?id=4f0343233b83337afa1e1dfb4bcf9d076ecd4be2

commit 4f0343233b83337afa1e1dfb4bcf9d076ecd4be2
Author: Harald Welte <laforge at gnumonks.org>
Date:   Mon Dec 4 17:33:07 2017 +0100

    ggsn: Ignore PCO with length 0, don't abort processing
    
    The existing code would abort iterating over the list of PCO TLVs
    if a TLV of length zero was encountered.  However, there's nothing
    in the spec that would make a zero-length PCO invalid, so we should
    continue to iterate over any PCO TLVs after the zero-length one.
    
    This issue was discovered while writing test cases in
    osmo-ttcn3-hacks.git
    
    Change-Id: I36660566a8ee2ca80ae6ee99c86e167e7c208df2

http://cgit.osmocom.org/osmo-ggsn/commit/?id=bcab7fb4afcd5c9015f05ce1cce02f9a76928217

commit bcab7fb4afcd5c9015f05ce1cce02f9a76928217
Author: Harald Welte <laforge at gnumonks.org>
Date:   Sun Dec 3 21:43:50 2017 +0100

    ggsn.c: Fix byte order of IPCP IPv4 DNS servers
    
    ... this probably didn't show up as 8.8.8.8 is dual-endian. doh!
    
    The address was already in network byte order, but msgb_put_u32 "of
    course" expects host byte order, ending up the wrong way in the actual
    packets :/
    
    Change-Id: Ia4bcac5fcebfc24760432eb66be258a01d78f65f
    Closes: OS#2685

http://cgit.osmocom.org/osmo-ggsn/commit/?id=427699e6ebcf2f9e3f05198fb1f5afbd408d389e

commit 427699e6ebcf2f9e3f05198fb1f5afbd408d389e
Author: Max <msuraev at sysmocom.de>
Date:   Tue Dec 5 16:30:37 2017 +0100

    Log APN and tun names for packets
    
    Change-Id: I6f7ce33f6585b2b78e2b8a5c0f7111f0316d6ddd

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

Summary of changes:
 ggsn/ggsn.c | 13 ++++++-------
 1 file changed, 6 insertions(+), 7 deletions(-)


hooks/post-receive
-- 
The OpenGGSN project



More information about the osmocom-commitlog mailing list