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.orgThis 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, laforge/ipv6 has been updated discards 86f42e4d9d17f4134018a556070d801adf64d974 (commit) discards 8b74b473e235cc409a4a443ba82ffd20df452b13 (commit) discards 95340e164e12a89a8e15750cd17503a89baaca9a (commit) discards 4f2c0e3e7627ffe0762d96f3289f71632ea9b32f (commit) via 8f5d38cc134a21151e6ab0e0c29b9106614df8b9 (commit) via 72a38b55e38407aa6c6b1cd32f848198ceee1287 (commit) via 1ae98777d9b1ee62e6900caf4bb580d1a42bb416 (commit) via d46bcd236e93432c894a939f4e5810dc5e9b4974 (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 (86f42e4d9d17f4134018a556070d801adf64d974) \ N -- N -- N (8f5d38cc134a21151e6ab0e0c29b9106614df8b9) 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=8f5d38cc134a21151e6ab0e0c29b9106614df8b9 commit 8f5d38cc134a21151e6ab0e0c29b9106614df8b9 Author: Harald Welte <laforge at gnumonks.org> Date: Thu Aug 3 00:47:03 2017 +0200 Support setting TUN device IPv6 address + prefix As we can now have PDP contexts with IPv6 user IP payload, it is useful to extend the TUN related code to be able to configure the tun device IPv6 address + prefix length Change-Id: I899d21e52d02e0b8384af29ddd489ff19c8f2cf6 http://cgit.osmocom.org/openggsn/commit/?id=72a38b55e38407aa6c6b1cd32f848198ceee1287 commit 72a38b55e38407aa6c6b1cd32f848198ceee1287 Author: Harald Welte <laforge at gnumonks.org> Date: Wed Aug 9 21:58:12 2017 +0200 IPv6: in46_addr: OSMO_ASSERT() in case of unsupported calls There's a bit of trickery with the ip_pool and it's "lengty=8" IPv6 prefix handling, let's make sure we don't accidentially call any support functions with addresses of wrong length. Change-Id: I444c190bdcd18780344e1f0dad4faf3bcf9da5a5 http://cgit.osmocom.org/openggsn/commit/?id=1ae98777d9b1ee62e6900caf4bb580d1a42bb416 commit 1ae98777d9b1ee62e6900caf4bb580d1a42bb416 Author: Harald Welte <laforge at gnumonks.org> Date: Wed Aug 9 20:28:52 2017 +0200 IPv6: Support PCO for IPv6 DNS addresses In IPv6, DNS server information is not passed along as IPCP6 like in IPv5 with IPCP. The reason is that IPCP6 (for PPP) doesn't support passing DNS server information. Rather, the relevant RFCs indicate DHCPv6 should be used even over point-to-point links. 3GPP decided to avoid DHCPv6 dependency for stateless autoconfiguration (the only mandatory IPv6 configuration mechanism) and added some new non-PPP-style PCO information elements ("containers") which can among other things inform a MS about IPV6 DNS servers. That same mechanism can also be used to inform the MS about IPv4 DNS servers, so for IPv4 there are now two competing mechanisms: IPCP and the new "native" PCO container. With this patch, we support both for IPv4. Change-Id: I21499afd61def8c925f7838bde76f34d28214b56 http://cgit.osmocom.org/openggsn/commit/?id=d46bcd236e93432c894a939f4e5810dc5e9b4974 commit d46bcd236e93432c894a939f4e5810dc5e9b4974 Author: Harald Welte <laforge at gnumonks.org> Date: Tue Aug 8 23:27:22 2017 +0200 IPv6: Implement IPv6 prefix assignment via ICMPv6 router advertisement The 3GPP specs are quite strange when it comes to how an IPv6 address or rather prefix is assigned to an IPv6 PDP context. The designated method for allocating the IPv6 address via the PDP EUA (End User Address) Information Element in the GTP signalling plane is *not* used to allocate the address/prefix. Instead, the EUA is used to allocate an "interface identifier" to the MS, which it the uses to derive its link-local source address to send a router solicitation. The GGSN subsequently answers witha router advertisement, advertising a single/64 prefix, whihcthe MS then uses to generate it's real IPv6 source address for subsequent communication. Change-Id: Icddf7d30e01d76a4784bcef5787b36f52f703a9f ----------------------------------------------------------------------- Summary of changes: ggsn/checksum.c | 12 +++++++++--- ggsn/icmpv6.c | 12 ++++++++---- 2 files changed, 17 insertions(+), 7 deletions(-) hooks/post-receive -- The OpenGGSN project