Also make linter happy:
sgsnemu/cmdline.c:4: WARNING:LEADING_SPACE: please, no spaces at the start of a line
Change-Id: Ie89a9f9de64cd59d21341b6f381b32f56693840f
To handle both incoming and outgoing SGSN Context via GTPv1.
Introduce a FSM which handles the state of SGSN Context to simplify
the API for the SGSN which uses libgtp as well as the external SGSN
which communicates via GTP.
Change-Id: Idb8ed0bb87200a68bb8caedd734fc070df9179c0
Using a pointer is more universal for the macro.
Further the upcoming SGSN Context Req/Response/Ack code will use
a peer pointer instead of the direct object.
Change-Id: Iab11a8b07eb177c479e1920cd7fa8be2099a4b7b
This callback was drepecated and is not ever called since
libosmocore.git 70ce871532ab21955e0955d7e230eae65438f047 (release 1.3.0).
See also libosmocore.git d31de237582f6fe3315d61bb9a488d4cda92654e.
Change-Id: Ief57c4ce98055e5063aafc53cb8330d3bd95d323
Split the preparing the data from the socket and queue handling into two functions:
gtp_req(): preparing the data
gtp_req_transmit(): selecting socket, port and adding it to the transmit queue.
In a following commit gtp_req_transmit() can be used by gtpv1 function
as well.
Change-Id: Icda0ef7b0ce3631e23da88827dd54cf019878b5d
No idea why the previous ones started at the second IE.
Further add more length arguments to the encapsulation method.
Change-Id: I8bb086c568e07052c52d880df06049490346e91e
gtp_resp() requires a PDP context. To support more generic messages
without a PDP context, rename gtp_resp() into gtp_resp_pdp() and
create a more generic function to transmit a GTP response.
Will be used by the SGSN Context Req/Resp/Ack code.
Change-Id: Id9ff95e0e2a10a22e65ecf42b2a2b06a0f2d1a45
Required for SGSN Context Req fsm which is using talloc.
Adds a new api to set the libgtp talloc context via gtp_set_talloc_ctx()
Change-Id: I7c4a29c4bb1ef3c7bf506e59e99b3a804cabe34b
The previous state of code made allocation code more complex for no good
reason; use usual alloc() type function instead, splitting between the 2
types of tun_t implementations available to make it easier to
understand.
Move the several tun-iface specific mode fields to a substruct to make
it clear those are only really containing useful information when the
tun_t is created in tun-iface mode.
Change-Id: Ic71f91c62cd5bd48c6d35534eaac2091e4c69735
The terminology of "encapsulating" used in tun_encaps is confusing,
since in this case we are not really encapsulating anything, but
actually delivering ("injecting") the packet to the system network
stack.
Using the "encapsulating" term is also confusing because readers may
think it may be doing the GTP-U encapsulation, which is not.
Change-Id: Ibb17c792b81668571e69d79918f3adf0e9e0f6c8
It's really confusing having a function operating on a rx path called
"encaps" since it's not really encapsulating anything.
This confuses the reader by thinking this is the function encapsulating
packets into GTP-U.
Change-Id: I7ff54f5e57ccc2c436becd1be1b0f728cbcdb12c
There's no need to forward those. Morevoer, they cannot be forwarded
when using gtpu kernel mode since it doesn't support reinjecting packets
we got from it, so avoid erroring out when trying to inject them later
on.
Related: OS#6600
Related: OS#6382
Change-Id: Iac8f14083620d86f3872aa951930fbe8f680ff24
When using gtp kernel module, the kernel sends GTP-U packets to
userspace (osmo-ggsn) when it is unable to find a related pdp ctx for
the packet.
This is so far processes through the code path:
ggsn_gtp_fd_cb => gtp_decaps1u => gtp_gpdu_ind => encaps_tun = > tun_encaps
In usual circumstances, if the gtp module sends a packet to userspace
because it is unable to find a pdp ctx, userspace shouldn't be able
anyway, so it should go through a different code path and answer over
GTP-U with a "Error Indication".
Other specific packets (such as ICMPv6 with link local address) are also
being forwarded to userspace. Some of them are being handled in
encaps_tun() in a special way (eg. Router Soliciation), but others, such
as Neighbor Solicitation, are not being handled there and follow the
generic path where they try to be forwarded over the tun towards the
Internet.
When using the kernel gtp mode, there's no way to re-inject into the
network stack a packet we received from the gtp mode, like done when
using the tun device mode.
Prior to 38b607ece3, a bug existed in
tun_encaps() which would still try to use tun->fd (-1) when in gtp
kernel module, which ended up in an error being printed.
After the mentioned commit was applied, when in gtp kernel module it
started accessing tun->tundev which is is NULL under that setup, hence
making the bug consequences worse.
Add a pointer guard with a log line to inform about the problem, while
still discussing the originating problem in OS#6600.
Related: OS#6600
Change-Id: I508758696a0bcbb7c780a0ed33b28ba640602488
Move general/generic osmocom chapters (logging, vty) further to the end,
so that the osmo-ggsn specific chapters stay together and don't get lost
in tons of generic content.
Change-Id: I6441944cc365bae40ab0f3cc4f1ecd1ac790c5c5
This allows dropping a lot of duplicated code.
While at it, drop references to non-linux systems, which are not
maintained anymore.
Param "dstaddr" was not used anywhere in the old APIs, so it can also be
dropped.
Param "tun->routes" was also used in BSD code, so it can also be
dropped.
Change-Id: I1fccfd658542481cd61536fbd3c7a3a32a1c253b
This way we can start dropping old osmo-ggsn specific API, avoiding
duplication of code.
Moreover, the osmo-ggsn code is using older ioctl APIs, which are
discouraged nowadays in favour of netlink, which osmo_tundev/osmo_netdev
from libosmocore is used.
Even better, we win for free non-blocking write behavior in the tundev
when switching to the new API, since it already has its own internal
wqueue.
While doing this, BSD code is dropped since anyway it's not been
maintained for a long time.
If needed, the BSD support can be added to libosmocore
osmo_tundev/osmo_netdev API.
This is a first step (already working). Follow-up commits will replace
the APIs to set up routes and addresses, and later on osmo-ggsn will win
support to set MTU on the interface.
Furthermore, this will allow easily adding netns support to osmo-ggsn
later on if ever needed.
Depends: libosmocore.git Change-Id Ia8a7e7ec6d96c7aebc80528236a0e0d035e7f38d
Change-Id: I4d99ba147ac0f3b414d2efef0068b6b8d6cf0014
This is only useful for IPv4 (or IPv4v6) APNs.
IPv6 APNs obtain this information from SLAAC RA.
Related: OS#6298
Related: SYS#7122
Change-Id: I8532acfffadda9e83962b30e4f6b17eb8b3362ac
The details of creation of data structures don't belong on the vty file.
While at it, split allocation code into its own function to quickly find
out where the allocation of the object happens.
Change-Id: Iaa4cd86c44957321c238d268ea62daafa1b79c69
The details of creation of data structures don't belong on the vty file.
While at it, split allocation code into its own function to quickly find
out where the allocation of the object happens.
Change-Id: If15a4158dd6599341017efd24dbf67ca565a7c34
Whenever the SGSN sends the GGSN a UpdatePDPCtxReq, it may offer a new
remote IP address or/and remote TEID, eg. because it wants to establish
a Direct Tunnel and point the GTPU towards the RNC, or to point it back
to itself.
If the gtpu kernel is used, osmo-ggsn lacked updating the kernel with
the new remote data.
The gtp kernel module doesn't provide an efficient/explicit way to
update a pdp context keeping the4 same local IP+TEID and changing only
the remote remote IP+TEID, hence first destroy the pdp ctx in the gtp
kernel module and then recreate it.
This fixes test GGSN_Tests_v4_only.TC_pdp4_act_update_teid in
ttcn3-ggsn-test-kernel-net-next.
Related: OS#6523
Change-Id: I1fc48be5c0f177ccf6fbe97c003b4df44809c0fe
This will be used by:
* SGSN: Get to know that RNC has gonne down according to GGSN (re-attempt
Direct Tunnel or go back to tun SGSN<->GGSN).
* GGSN: Maybe find out that Direct Flags are used (should be handled
internally directly in the rx path probably)
Related: OS#6512
Change-Id: Ic80a9a928c55b6ff85be96014920bb42793cb943
The Update PDP Context procedure can be initiated GGSN -> SGSN, as
described in TS 29.060 7.3.3.
Related: OS#6512
Change-Id: I1c3441c71b90c5bbf6f4545484586222e6180fe1
In Update PDP Ctx Response, only SGSN is expected to transmit Direct
Tunnel Flags in the message.
Related: SYS#5435
Change-Id: Ia3e360a35d30858eab1e438dc2508fd756c2e22e
