in "createif" mode uplink traffic not forwarding
from tun interface into Gn, inside GTP-U.
create_pdp_conf get iphash (ipm) with pdp == 0x0
Fix - in create_pdp_conf - instead of casting using already
definned iphash in ipset function.
Change-Id: Icd58450548b3a47cb933d70a2e3166c067552b2c
No warnings when used options from "pinghost" and "createif" groups
in a same time. sgsnemu created tun0 interface and send pings inside
G-PDU, but didn't calculate replys. Added options modes to avoid
mutual exclusion options.
Change-Id: I196df7838212dcddecd64a64a6cba613b6cfced0
Improvements include:
- Use Identifier received from request instead of using hardcoded id=0.
- Don't add DNS to response if they were not included in request.
Change-Id: Ic8aa5d634e526683b2ad8ed5d14088e171c41c98
Check (before forwarding received GTP packets into the tun) if the pdp ctx
associated with the packet requested was assigned an EUA of the given IP version.
This way we avoid for instance forwarding an IPv6 packet (or sending
back a response to a Router Solicitation packet) in case the APN was
configured without IPv6 support or if the MS/SGSN didn't ask for an IPv6
while requesting an EUA.
As a side effect, this commit fixes an OSMO_ASSERT hit introduced in handle_router_mcast
in 2d6a69e69a due to a deffective MS
sending an icmpv6 Router Solicitation over IPv6 after having been
requesting and assigned an IPv4 EUA (so no IPv6 packets expected).
Before that commit, there was no crash but the message was being wrongly
answered and used an uninitialized .v6 addr field from the peer struct.
Fixes: OS#2843
Change-Id: Ib6d18a64c2b71f3bcf6cb7e3a978d2d3f9c7a79b
Functions not exported in gtp.h should be static.
There's no need to mark functions as extern in the .c file.
Change-Id: Ie61d5c6e0ae45ef3885911cedf71c826ed1705d0
"sgsnemu" stopped with the message "Received create PDP context response. Cause value: 128",
but normaly at that poit it should continue working and create "user plane".
Reason: Funtion "create_pdp_conf" checking result of "in46a_from_eua" and mistakenly
returned EOF when more than 1 IP address provided by GGSN.
Now function "create_pdp_conf" stopped with error when 0 IP provided or error code comes from "in46a_from_eua".
Fixes: 2d6a69e69a ("Add support for IPv4v6 End User Addresses")
Change-Id: I7881b8e1f27c432007cb6e5ff665a2ce55f103b5
If the version received is not known, pdp is then uninitalized so we
should not be using it. Let's return an error to inform the caller.
Change-Id: Ib3e23b61a3521bd3c9002d3165ca8eff4361a35e
As reported by Viktor Tsymbalyuk, "Use the same LAN switch as the one
your SGSN is connected to." is of course completely bogus. As long as
you have IP routing in place, it doesn't matter at all which switch you
are using.
Change-Id: I748752337b863b317d2899017b1dc255ced2515d
The error is:
CC gtp-kernel.o
gtp-kernel.c:19:26: fatal error: libgtpnl/gtp.h: No such file or directory
#include <libgtpnl/gtp.h>
^
compilation terminated.
Fix it by using proper CFLAGS/LIBS for libgtpnl.
Change-Id: I5a24076778ea3ce263ac27211a6f45f935155b33
Previous commit added the ipv6 link-local vty cmd but forgot to add code
to print its value in config_write_apn.
Fixes: 37c45e3998
Change-Id: I08aeaa98d6dc318b7e9740d837ba4ac48cd7051c
This vty cmd let's you set up a new link-local IP for a specific APN to
be used during ICMPv6 Router Advertisement procedure.
osmo-ggsn hence requires a link-local IPv6 address to be added to the
tun interface, otherwise the apn will not be configured correctly and it
won't be able to allocate addresses from the ipv6 pool later on.
This feature is useful in case your OS doesn't support autoconfiguring
link-local IPs when the interface is brought up (some linux versions are
known to fail at this) or in case you configured your OS specifically to
avoid automatic set up (sysctl net.ipv6.conf.*.autoconf).
If "no ipv6 link-local" is provided (default), osmo-ggsn will rely on the
OS or the ipup-script setting up the link-local IP for the tun
interface at creation time, then fetching it after ipup-script time and
using the first link-local ip found. On the other hand, if the "ipv6
link-local" cmd is provided, osmo-ggsn will add the link-local IP to the
interface manually and use that one for later Router Advertisement
procedures.
Change-Id: I09ef27f54940d4c47150e5f9016d1cd4298c16b5
sgsnemu (the only user of this API so far) has been modified to use the
new API with in46_addr.
FreeBSD code for IPv6 has not been tested.
Change-Id: Ie36afe6eaf393855a4a708000ef4ad0192bf4767
First of all, dstaddr can be NULL, avoid copying it in that case.
Second, we want to copy the addr data, not the pointer. I tested it and
the IP was not added (not shown in ip addr) until I copied the content
instead of the address.
Change-Id: I8da637b155f0e913cab6c5b0dde355c9f33375b5
Before this commit, when an MS requested an ipv4v6 context osmo-ggsn
returned an error stating the type was unknown, and this text was
printed in the log:
Processing create PDP context request for APN 'ims'
Cannot decode EUA from MS/SGSN: f1 8d
This patch has been tested with an MS running the 3 types of addresses:
- IPv4 and IPv6: no regressions observed, the context is activated and
packets are sent to the ggsn.
- IPv4v6: Wireshark correctly parses request and reponse, and then
ICMPv6 traffic from both sides. Finally I see the MS using the IPv4 and
IPv6 DNS addresses advertised and TCP traffic over IPv4 (because
probably my IPv6 network setup is not correct). I also checked I can
disable/enable data (pdp ctx delete and activate) several times without
any issue.
Change-Id: Ic820759167fd3bdf329cb11d4b942e903fe50af5
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
... 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
In any case, if we add support for ipv6 in tun_addaddr we will need
tun_setaddr (and also change the API of tun_addaddr to use in46_addr).
Change-Id: Iadf51379455174a642b477040ec96f28022c24c7
Changes made as requested by the deprecation text.
Fixes warning below:
warning: ‘vty_install_default’ is deprecated: Now happens implicitly with install_node() [-Wdeprecat
ed-declarations]
vty_install_default(GGSN_NODE);
^~~~~~~~~~~~~~~~~~~
Change-Id: I5c6197129e0c251a4e8dd174027b011c8f6476c6
Viktor Tsymbalyuk
Pau Espin
Harald Welte