Feature #1621
closedtest + document OpenGGSN with osmo-gtp-kernel code
Added by laforge about 8 years ago. Updated about 7 years ago.
100%
Description
Recent versions of osmo-gtp-kernel have only been tested with the Erlang GGSN (ergw), but not with OpenGGSN. Change that.
Files
openbsc.log | openbsc.log | 18.1 KB | wirelesss, 12/14/2016 07:05 PM | ||
sgsn.log | sgsn.log | 29.2 KB | wirelesss, 12/14/2016 07:05 PM | ||
ggsn.log | ggsn.log | 755 Bytes | wirelesss, 12/14/2016 07:05 PM | ||
gtp0.pcapng | gtp0.pcapng | 788 Bytes | wirelesss, 12/15/2016 03:27 PM | ||
Gp_trace.pcapng | Gp_trace.pcapng | 2.42 MB | wirelesss, 12/15/2016 05:29 PM | ||
ggsn_log_22Dec.log | ggsn_log_22Dec.log | 1.11 KB | wirelesss, 12/22/2016 10:37 AM | ||
sgsn_log_22Dec.log | sgsn_log_22Dec.log | 24.3 KB | wirelesss, 12/22/2016 10:37 AM | ||
Lo_trace.pcapng | Lo_trace.pcapng | 491 KB | Gp | wirelesss, 12/22/2016 10:37 AM | |
gtp0_22dec.pcapng | gtp0_22dec.pcapng | 1.02 KB | wirelesss, 12/22/2016 10:40 AM | ||
gtp_tunnel_list.log | gtp_tunnel_list.log | 83 Bytes | wirelesss, 12/22/2016 10:40 AM | ||
osmso_sgsn_vty_22Dec.log | osmso_sgsn_vty_22Dec.log | 430 Bytes | wirelesss, 12/22/2016 10:40 AM |
Related issues
Updated by laforge over 7 years ago
- Assignee set to wirelesss
- Priority changed from Low to Normal
Updated by laforge over 7 years ago
- Subject changed from test OpenGGSN with new osmo-gtp-kernel code to test + document OpenGGSN with osmo-gtp-kernel code
please try to find a linux distribution/version that already has the kernel support for GTP-U included, i.e. let's avoid you having to re-build the linux kernel for this task. Once you have the required kernel, you will need to compile libgtpnl, and rebuild openggsn to link against the libgtpnl for supporting the GTP-u in the kernel plane.
Please also make sure that the process of building + using OpenGGSN with kernel-gtp is properly documented in the OpenGGSN project wiki here on osmocom.org.
Updated by wirelesss over 7 years ago
- % Done changed from 0 to 10
Looking for a linux distribution/version, which already has the kernel support for GTP-U included.
Installing of kernel 4.8.
Updated by laforge over 7 years ago
On Fri, Dec 02, 2016 at 06:42:01PM +0000, wirelesss [REDMINE] wrote:
Looking for a linux distribution/version, which already has the kernel support for GTP-U included.
Installing of kernel 4.8.
"debian unstable" has 4.8.0 kernel, but unfortunately doesn't seem to
activate the GTP kernel module during build :(
It would be great if somebody could request that from the debian
developer in charge of pcakaging the kernel, together with an
explanation.
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Updated by laforge over 7 years ago
I just requested Debian to enable CONFIG_GTP in Debian bug report
846913: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846913
This of couse doesn't anwer your question on which distribution right
now ships a 4.8.0 kernel or later. But at least it should make sure
that future users of the next stable debian release will have the
feature from day one.
Ubuntu 16.10 has kernel 4.8, and according to config.common.ubuntu in
https://launchpad.net/ubuntu/+archive/primary/+files/linux_4.8.0-27.29.diff.gz
they do enable CONFIG_GTP
OpenSUSE Tumbleweed (stable) also seems to have 4.8 (.12), and also
seems to have it enabled:
https://github.com/openSUSE/kernel-source/blob/stable/config/x86_64/default
Fedora 25 also seems to use 4.8, and according to
http://pkgs.fedoraproject.org/cgit/rpms/kernel.git/tree/config-generic?h=f25
CONFIG_GTP is enabled!
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Updated by wirelesss over 7 years ago
- % Done changed from 10 to 20
After installation of Ubuntu 16.10 (4.8.0-30-generic) on a virtual machine, libgtpnl libsomsocore
were compiled and OpenGGSN was rebuild.
Updated by wirelesss over 7 years ago
wiki page of building + using OpenGGSN with kernel-gtp is drafted and it is under construction.
Updated by wirelesss over 7 years ago
- % Done changed from 20 to 30
Starting OpenGGSN with option --gtp-linux leads to following:
from OpenGGSN the following messages are to be seen:
gtp.c:701 GTP: gtp_newgsn() started
gtp-kernel.c:156 GTP kernel configured
length: 12 content: 32 1a 00 04 00 00 00 00 00 00 00 00 : Unknown PDP context
from SGSN : length: 52 content: 38 ff 00 2c 00 00 00 00 45 00 00 2c 03 bb 00 00 6c 06 ad 69 0c 9b d0 61 c0 a8 00 03 52 08 04 05 f5 19 a2 62 04 40 61 02 60 12 20 00 87 f2 00 00 02 04 05 64 : Unknown PDP context.
Having that circumstance, it is not possible to run PS traffic and to load web site on the test mobile station.
Addinng to wiki site command for starting OpenGGSN
sudo ggsn --gtp-linux -c ggsn.conf -f
Updated by laforge over 7 years ago
Hi,
On Tue, Dec 13, 2016 at 06:02:20PM +0000, wirelesss [REDMINE] wrote:
Starting OpenGGSN with option --gtp-linux leads to following:
[...]
from SGSN : length: 52 content: 38 ff 00 2c 00 00 00 00 45 00 00 2c 03
bb 00 00 6c 06 ad 69 0c 9b d0 61 c0 a8 00 03 52 08 04 05 f5 19 a2 62
04 40 61 02 60 12 20 00 87 f2 00 00 02 04 05 64 : Unknown PDP context.Having that circumstance, it is not possible to run PS traffic and to
load web site on the test mobile station.
so you have discovered a problem. But where is the comprehensive bug
report? Where are the protocol traces (pcap files) of the Gb and
Gp interface while the above log lines of OpenGGSN where observed.
As somebody who receives bug reports from others, you should understand
how important it is to first collect all the relevant information and
then post it together. This is very important in terms of efifciency.
It might even make sense to raise all this ina separate bug ticket and
mark that related to this ticket on whcih you are working on.
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Updated by wirelesss over 7 years ago
laforge wrote:
Hi,
On Tue, Dec 13, 2016 at 06:02:20PM +0000, wirelesss [REDMINE] wrote:
Starting OpenGGSN with option --gtp-linux leads to following:
[...]
from SGSN : length: 52 content: 38 ff 00 2c 00 00 00 00 45 00 00 2c 03
bb 00 00 6c 06 ad 69 0c 9b d0 61 c0 a8 00 03 52 08 04 05 f5 19 a2 62
04 40 61 02 60 12 20 00 87 f2 00 00 02 04 05 64 : Unknown PDP context.Having that circumstance, it is not possible to run PS traffic and to
load web site on the test mobile station.so you have discovered a problem. But where is the comprehensive bug
report? Where are the protocol traces (pcap files) of the Gb and
Gp interface while the above log lines of OpenGGSN where observed.As somebody who receives bug reports from others, you should understand
how important it is to first collect all the relevant information and
then post it together. This is very important in terms of efifciency.It might even make sense to raise all this ina separate bug ticket and
mark that related to this ticket on whcih you are working on.--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/ ============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Hi,
Yes. I agree. I have sent this post / note a bit earlier without complete troubleshooting information.
I thought it would be valuable just as a progress of this Ticket. I do understand that in this case it was just useless.
Updated by wirelesss over 7 years ago
- File openbsc.log openbsc.log added
- File sgsn.log sgsn.log added
- File ggsn.log ggsn.log added
After building and compiling of openbsc, libgtpnl and OpenGGSN on a virtual machine running Ubuntu 16.10 with kernel 4.8.0-30-generic following was observed:
from SGSN console (time stamps:08:55:23 - 08:56:57) it is to be seen that GPRS attach is accepted and PDP CONTEXT activation is acknowledged. Please refer to sgsn.log file
at time stamp: 08:57:05 following message is present:
gtp.c:2619 Packet from 127.0.0.1:2152, length: 82 content: 38 ff 00 4a 00 00 00 00 45 00 00 4a 51 d5 00 00 2b 11 6d 14 08 08 08 08 c0 a8 00 02 00 35 40 01 00 36 74 a4 0d ce 81 80 00 01 00 01 00 00 00 00 03 77 77 77 04 7a 6f 63 6b 03 63 6f 6d 00 00 01 00 01 c0 0c 00 01 00 01 00 00 17 64 00 04 55 0d 93 d7 : Unknown PDP context Wed Dec 14 08:57:05 2016 <0025> gtp.c:213 Unknown packet flag: 56
Output from the GGSN console is:
gtp.c:2581 Packet from 127.0.0.2:2152, length: 12 content: 32 1a 00 04 00 00 00 00 00 00 00 00 : Unknown PDP context
The pcap file from Gb interface to be attached.
Updated by laforge over 7 years ago
On Wed, Dec 14, 2016 at 07:21:57PM +0000, wirelesss [REDMINE] wrote:
The pcap file from Gb interface to be attached.
As the problem is on the Gp interface, does it also include Gp?
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Updated by laforge over 7 years ago
... and, as raised severla times, what is the output of the "gtp-tunnel
list" after the pdp context is established?
Are you running openggsn with the "-d" flage to get debug lots?
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Updated by wirelesss over 7 years ago
- File Gp_trace.pcapng Gp_trace.pcapng added
It was found that communication between SGSN and GGSN is running, but at certain point GGSN switches Reserved bit to 1. This can be seen from the GGSN standard query response. In the attach Gp_trace.pcapng file we can see that in the frame no: 1082, 1889 etc.
Updated by laforge over 7 years ago
- Related to Bug #1879: reserved bit in GTPv1 header set wrong added
Updated by laforge over 7 years ago
- Related to Bug #1880: handling of reserved bit in flag octet broken added
Updated by wirelesss over 7 years ago
- % Done changed from 30 to 60
Test that relates to OpenGGSN with osmo-gtp-kernel code has been executed.
As conclusion: so-called "reserved" bit in the flags octet of the GTPv1 header is set to value '1'. This is done in the existing Linux Kernel GTP code. This operation is incorrect. As per 3GPP TS 129.060 (ETSI TS 129 060 V13.5.0), Chapter 6, bit 4 in octet 1, should be equal to value '0'.
Updated by laforge over 7 years ago
On Fri, Dec 16, 2016 at 05:20:07PM +0000, wirelesss [REDMINE] wrote:
Test that relates to OpenGGSN with osmo-gtp-kernel code has been
executed. As conclusion: so-called "reserved" bit in the flags octet
of the GTPv1 header is set to value '1'. This is done in the existing
Linux Kernel GTP code. This operation is incorrect. As per 3GPP TS
129.060 (ETSI TS 129 060 V13.5.0), Chapter 6, bit 4 in octet 1, should
be equal to value '0'.
please note that this is not the actual error cause. The invalid
reserved bit is just noted/complained about when constructing the GTP
error messge in response to the downlink message (icmp echo reply in
your tests).
The real cause seems to be some invalid / non-synchronized TEI/TID (tunnel
ID) for the GTP-U in downlink direction (GGSN->SGSN).
Please compare the TEI GTP-C negotiates/establishes for the user plane
in both directions at PDP CTX ACT time with those you see on the wire.
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
Updated by wirelesss over 7 years ago
- File ggsn_log_22Dec.log ggsn_log_22Dec.log added
- File sgsn_log_22Dec.log sgsn_log_22Dec.log added
- File Lo_trace.pcapng Lo_trace.pcapng added
- File gtp0_22dec.pcapng gtp0_22dec.pcapng added
- File gtp_tunnel_list.log gtp_tunnel_list.log added
- File osmso_sgsn_vty_22Dec.log osmso_sgsn_vty_22Dec.log added
TEID for GTP-C has been compared. SonyEricsson K790i mobile has been used.
In file lo_trace.pcapng next information can be seen.
In message "create PDP context request" (MS to Network direction - Uplinik), TEIDs have the following values:
Frame No.: 2569
TEID:0x00000000
TEID Data I: 0x00000001
TEID Control Plane: 0x00000001
In message "create PDP context response message" (Network to MS direction - Downlink) shows next TEIDs:
Frame No.: 2570
TEID:0x00000001
TEID Data I: 0x00000001
TEID Control Plane: 0x00000001
Message Standard query 0x0dce A wap.sonyericsson.com, includes TEIDs as presented below:
Frame No.: 2579
TEID:0x00000001
Frame No.: 2584 which is Standart query response message to frame no. 2579.
TEID:0x00000000
The output from gtp-tunnel list command is:
version 1 tei 1/0 ms_addr 192.168.0.2 sgsn_addr 127.0.0.2
OpenGGSN log shows: teid 1. Part of this log is presented in the next lines:
<000c> gtp.c:701 GTP: gtp_newgsn() started <0002> gtp-kernel.c:123 Using the GTP kernel mode (genl ID is 27) <0002> gtp-kernel.c:156 GTP kernel configured <000b> control_if.c:693 CTRL at 127.0.0.1 4257 version 1 teid 1 address (6) f1 21 c0 a8 0 2 sgsn-addr (4) 7f 0 0 2 <000c> gtp.c:2581 Packet from 127.0.0.2:2152, length: 12 content: 32 1a 00 04 00 00 00 00 00 00 00 00 : Unknown PDP context <000c> gtp.c:2581 Packet from 127.0.0.2:2152, length: 12 content: 32 1a 00 04 00 00 00 00 00 00 00 00 : Unknown PDP context <000c> gtp.c:2581 Packet from 127.0.0.2:2152, length: 12 content: 32 1a 00 04 00 00 00 00 00 00 00 00 : Unknown PDP context version 1 teid 1 address (6) f1 21 c0 a8 0 2 sgsn-addr (4) 7f 0 0 2
TEIDs are different or non-synchronized.
TEID in Frame No.: 2584 or Standard query response message shall be equal to 1.
Updated by laforge over 7 years ago
laforge wrote:
I just requested Debian to enable CONFIG_GTP in Debian bug report
846913: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=846913
FYI, Debian has just activated the kernel GTP module in their latest experimental build "linux 4.9.1-1~exp1"
From the change log:
* net: Enable GTP as module (Closes: #846913)
Would be good to collect all the information here about which distribution has kernel GTP and which not to a wiki page in the OpenGGSN project.
Updated by wirelesss over 7 years ago
Information about which distribution has GTP kernel is collected and added in wiki site.
Updated by laforge about 7 years ago
- Assignee changed from wirelesss to laforge
Updated by laforge about 7 years ago
- % Done changed from 60 to 80
with the recent patches merged ahead of the openggsn 0.93 release, the kernel-gtp integration with GTPv1 is finally working in OpenGGSN. I could establish PDP contexts between sgsnemu and openggsn and route bi-directional IP packets through them.
I've also been playing around with using different TEI values on both side of the tunnels, to make sure there are no mistakes in the local/remote TEI value handling.
I'll be documenting the test setup shortly and put it on an OpenGGSN wiki page.
Updated by laforge about 7 years ago
- Status changed from In Progress to Resolved
- % Done changed from 80 to 100
the setup is documented (and has been verified) in the wiki. see Basic_Testing and Kernel_GTP