prinzowo / gtp5g Goto Github PK
View Code? Open in Web Editor NEWLinux kernel module 5G GTP-U
License: GNU General Public License v2.0
gtp5g's People
Contributors
Stargazers
Watchers
Forkers
ziseputi bjoern-r acoderhz brchiu frankurcrazy dirkcgrunwald coolshou edingroot calee0219 giangnvbk1989 zplusless cn0xroot lapd-telco helloboy2018 jefferycwc j13tw sumichaaan chch1970 aricwang88 unakatsuo caicunren free5gc-plus shugo-h ravens gavz mazhuoran-cn sutanuk tug-hour niyingdong 85117921 briansp8210 qiqingh jeepperscreeppers weiyd jimmy19891989 syujy 5l1v3r1 397315955 honysyang telcosecgtp5g's Issues
Does not compile on kernel 5.8
The kernel headers (proc_fs.h) has been changed from 5.4 to 5.8 (do not know when exactly) so that gtp5g does not compile any more.
Segmentation fault when terminating upf
Currently, I've built gtp5g kernel module v0.2.0 in Fedora CoreOS 32 and Kernel 5.8.x.
In my environment, I've checked that gtp5g kernel module is read correctly and free5gc upf is up.
But a segmentation fault occur when terminating upf.
The log at that time is as follows.
<...snip…>
2020-11-25T16:24:57Z [INFO][UPF][Util] Removing DNN routes
2020-11-25T16:24:57Z [DEBU][UPF][Util] Pool Free successful, total capacity[1024], available[1023]
[ 1109.305515] stack segment: 0000 [#1] SMP PTI
[ 1109.306562] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G OE 5.8.17-200.fc32.x86_64 #1
[ 1109.308537] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 1109.310568] RIP: 0010:pdr_context_free+0x90/0x120 [gtp5g]
[ 1109.311819] Code: 48 8b 7d 08 e8 21 4e 9a f7 48 8b bb 58 ff ff ff e8 15 4e 9a f7 48 8b bb 60 ff ff ff e8 09 4e 9a f7 48 8b 6d 10 48 85 ed 74 4c <48> 8b 45 00 48 85 c0 74 1f 48 8b 78 18 e8 ee 4d 9a f7 48 8b 45 00
[ 1109.315911] RSP: 0018:ffffb518800a8ef0 EFLAGS: 00010286
[ 1109.317118] RAX: ffff9ec6f87a2b01 RBX: ffff9ec6f95970f8 RCX: 0000000000003674
[ 1109.318729] RDX: 0000000000003673 RSI: e8df0a46b05900e6 RDI: 000000000002f040
[ 1109.320345] RBP: 90b4338f06190d33 R08: ffff9ec6f3683b00 R09: 0000000000000000
[ 1109.321959] R10: ffff9ec6f87a2e30 R11: 000000000000b801 R12: ffff9ec6f9597000
[ 1109.323571] R13: 0000000000000000 R14: ffff9ec6fd63a6c0 R15: ffff9ec6fdd2b090
[ 1109.325199] FS: 0000000000000000(0000) GS:ffff9ec6fdd00000(0000) knlGS:0000000000000000
[ 1109.327029] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1109.328352] CR2: 000000c0003f4000 CR3: 00000000307f8005 CR4: 00000000003606e0
[ 1109.329970] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1109.331583] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 1109.333218] Call Trace:
[ 1109.333840] <IRQ>
[ 1109.334381] rcu_do_batch+0x197/0x3e0
[ 1109.335272] rcu_core+0x189/0x2e0
[ 1109.336089] __do_softirq+0xd9/0x2c4
[ 1109.336960] asm_call_irq_on_stack+0x12/0x20
[ 1109.337975] </IRQ>
[ 1109.338524] do_softirq_own_stack+0x37/0x40
[ 1109.339518] irq_exit_rcu+0xc2/0x100
[ 1109.340391] sysvec_apic_timer_interrupt+0x34/0x80
[ 1109.341520] asm_sysvec_apic_timer_interrupt+0x12/0x20
[ 1109.342718] RIP: 0010:native_safe_halt+0xe/0x10
[ 1109.343793] Code: 02 20 48 8b 00 a8 08 75 c4 e9 7b ff ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc cc e9 07 00 00 00 0f 00 2d 06 5a 49 00 fb f4 <c3> 90 e9 07 00 00 00 0f 00 2d f6 59 49 00 f4 c3 cc cc 0f 1f 44 00
[ 1109.347925] RSP: 0018:ffffb51880073ed0 EFLAGS: 00000246
[ 1109.349139] RAX: ffffffffb8b73450 RBX: 0000000000000001 RCX: 0000000000000000
[ 1109.350763] RDX: 0000000000000001 RSI: ffffb51880073ea0 RDI: 000001025d329955
[ 1109.352398] RBP: 0000000000000001 R08: 0000000000000001 R09: ffff9ec6f89af200
[ 1109.354021] R10: 00000000000003ec R11: 0000000000000000 R12: 0000000000000000
[ 1109.355646] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[ 1109.357274] ? __sched_text_end+0x3/0x3
[ 1109.358194] default_idle+0x1a/0x140
[ 1109.359057] do_idle+0x1f3/0x2a0
[ 1109.359851] ? arch_cpu_idle_exit+0x40/0x40
[ 1109.360846] cpu_startup_entry+0x19/0x20
Maybe I suspect a timing of kfree(pdr->pdi) in pdr_context_free() (line 1097, gtp5g.c) is a mistake.
So, I think this code should be written after run the lines related to freeing SDF fields (line 1100 to 1110.)
How do you think about this?
Best Regards.
insmod: ERROR: could not insert module gtp5g.ko: Operation not permitted
I can't solve this problem.
I'm using ubuntu 18.04 and kernel version 5.3.0-53-generic changing to 5.0.0-23-generic.
:~/workspace/gtp5g$ make install
modprobe udp_tunnel
insmod gtp5g.ko
insmod: ERROR: could not insert module gtp5g.ko: Operation not permitted
Makefile:16: recipe for target 'install' failed
make: *** [install] Error 1
Error when compiling in RHEL7
Hi,
I tried to compile the module in RHEL7 (kernel version 5.12.10) and I have the following error (I also attached the log file):
/root/gtp5g/gtp5g.c:1461:27: error: ‘ip_tunnel_get_stats64’ undeclared here (not in a function); did you mean ‘ip_tunnel_get_ttl’?
.ndo_get_stats64 = ip_tunnel_get_stats64,
Does this module support RHEL7?
log.txt
update to support latest linux kernels
Linux is currently at 5.8.3, with ubuntu 18.04 now at version 5.3 and ubuntu 20.04 at version 5.4. I was wondering what it would take to make this compatible with these kernel versions. It would be nice not to have to downgrade to 5.0.0.23 when using this in free5GC
support Sequence Number
3.2 GTP-U Header Format
Figure 3 shows general and mandatory GTP-U header and Figure 4 shows
extension GTP-U header.
[GTP-U-6]: GTP-U supports sequence number option in the header, but
it is not recommended to be used by almost GTP-U
entities.
GTP-U header has Sequence Number field to reorder incoming packets
based on the sequence number. If Sequence Number Flag is set to '1'
it indicates that Sequence Number Filed exists in GTP-U header and
examined at receiving tunnel endpoint node to reorder incoming
packets. However, the sequence number flag is set to '1' only for
RAT HO procedure and sequence number flag should be set to '0' in
normal case. Therefore, in normal case receiver tunnel endpoint node
doesn't examine sequence number and can't reorder GTP-U packets based
on the sequence number. This specification is described in section
5.1 of [TS.29.281-3GPP].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver |P|R|E|S|N| Message Type| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Endpoint Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | N-PDU Number | Next-Ext-Hdr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: GTP-U Header
get this merged mainline by extending the existing GTP-U kernel support?
I'm the maintainer of libgtpnl and the existing GTP-U mainline linux kernel module. It would have been great to see your project discussed one one of our mailing lists.
What are your plans to get this merged mainline?
Insert to boot module
I'm not sure is it a good idea to insert gtp5g module on booting for user in the script.
Or maybe considering about writing it on README or writing another trigger rules to insert module to boot module.
Newest Version gtp5g is not Respone the UPF GTP Reply
Hello, PrinzOwO
I am testing the gtp5g in my free5gc v3.0.4 env
and I try to use the newest version to build gtp5g to my environment
the newest is the v1.0.0-f
and I test in free5gc v3.0.4 to ping UPF IP,
It can unpack the GTP<ICMP_Request> from UE/RAN request
and get the <ICMP_Request> => <ICMP_Reply>
but not reply the GTP<ICMP_Reply> Packet on UPF requst to UE/RAN
and I try the old version in my forked gtp5g repo
It can reply GTP<ICMP_Reply> to UE
Old version
Newest version
Maybe you can tell me, gtp5g version v1.0.0-f
It can mapping to free5gc which version when I testing.
thx!
'Invalid extension header length or else' when running end to end test with QER
Hi,
I have properly installed gtp5g and libgtp5gnl on my Ubuntu 20.04 server and successfully invoked the test script script/ns_ran_upf.sh.
I then went ahead and added QER usage to the script, invoked ./cleanup.sh and run the script again. Ping failed.
I then noticed
gtp5gtest:[gtp5g] gtp1u_udp_encap_recv: Invalid extension header length or else
being reported in /var/log/syslog. I would like to ask whether I did something wrong or perhaps QER support is not fully implemented yet?
Please find below more details:
under "RAN part":
sudo ./gtp5g-tunnel add qer gtp5gtest 1 --qfi 9
sudo ./gtp5g-tunnel add qer gtp5gtest 2 --qfi 9
...
sudo ./gtp5g-tunnel add pdr gtp5gtest 1 --pcd 1 --hdr-rm 0 --ue-ipv4 ${UE_IP} --f-teid 87 ${RAN_IP} --far-id 1 --qer-id 1
sudo ./gtp5g-tunnel add pdr gtp5gtest 2 --pcd 2 --ue-ipv4 ${UE_IP} --far-id 2 --qer-id 2
under "UPF part":
${EXEC_NS2} ./gtp5g-tunnel add qer gtp5gtest 1 --qfi 9
${EXEC_NS2} ./gtp5g-tunnel add qer gtp5gtest 2 --qfi 9
...
${EXEC_NS2} ./gtp5g-tunnel add pdr gtp5gtest 1 --pcd 1 --hdr-rm 0 --ue-ipv4 ${UE_IP} --f-teid 78 ${UPF_IP} --far-id 1 --qer-id 1
${EXEC_NS2} ./gtp5g-tunnel add pdr gtp5gtest 2 --pcd 2 --ue-ipv4 ${UE_IP} --far-id 2 --qer-id 2
I am using master version for both.
Thanks.
The kernel crash in tunnel creation
We use the gtp5g revison 508c558.
When we send the large number of GTP-U packets (more than 10,000,000 pps), the GTP-U tunnel is create by the command `gtp5g-tunnel'. The kernel is crashed by the zero-divide.
The crash occurs at this point.
static struct gtp5g_pdr *pdr_find_by_gtp1u(struct gtp5g_dev *gtp, struct sk_buff *skb,
unsigned int hdrlen, u32 teid) {
struct iphdr *iph;
__be32 *target_addr;
struct hlist_head *head;
struct gtp5g_pdr *pdr;
struct gtp5g_pdi *pdi;
switch(ntohs(skb->protocol)) {
case ETH_P_IP:
break;
default:
return NULL;
}
if (!pskb_may_pull(skb, hdrlen + sizeof(struct iphdr)))
return NULL;
iph = (struct iphdr *)(skb->data + hdrlen);
target_addr = (gtp->role == GTP5G_ROLE_UPF ? &iph->saddr : &iph->daddr);
head = >p->i_teid_hash[u32_hashfn(teid) % gtp->hash_size]; <= crash here
hlist_for_each_entry_rcu(pdr, head, hlist_i_teid) {
pdi = pdr->pdi;
// GTP-U packet must check teid
if (!(pdi->f_teid && pdi->f_teid->teid == teid))
continue;
And the crash log and the backtrace are these.
KERNEL: /usr/lib/debug/boot/vmlinux-5.0.0-23-generic
DUMPFILE: /var/crash/202006251024/dump.202006251024 [PARTIAL DUMP]
CPUS: 4
DATE: Thu Jun 25 10:22:59 2020
UPTIME: 00:04:20
LOAD AVERAGE: 0.51, 0.42, 0.18
TASKS: 250
NODENAME: GTP-U
RELEASE: 5.0.0-23-generic
VERSION: #24~18.04.1-Ubuntu SMP Mon Jul 29 16:12:28 UTC 2019
MACHINE: x86_64 (2261 Mhz)
MEMORY: 4 GB
PANIC: "divide error: 0000 [#1] SMP PTI"
PID: 9
COMMAND: "ksoftirqd/0"
TASK: ffff9faebaff0000 [THREAD_INFO: ffff9faebaff0000]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash> bt -l
PID: 9 TASK: ffff9faebaff0000 CPU: 0 COMMAND: "ksoftirqd/0"
#0 [ffffbe9080687680] machine_kexec at ffffffff82e6b583
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/arch/x86/kernel/machine_kexec_64.c: 346
#1 [ffffbe90806876e0] __crash_kexec at ffffffff82f43742
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/kernel/kexec_core.c: 957
#2 [ffffbe90806877b0] crash_kexec at ffffffff82f445e1
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/include/linux/compiler.h: 219
#3 [ffffbe90806877d0] oops_end at ffffffff82e3379d
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/arch/x86/kernel/dumpstack.c: 334
#4 [ffffbe90806877f8] die at ffffffff82e33f82
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/arch/x86/kernel/dumpstack.c: 406
#5 [ffffbe9080687828] do_trap at ffffffff82e2fb8e
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/arch/x86/kernel/traps.c: 212
#6 [ffffbe9080687870] do_error_trap at ffffffff82e2fffc
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/arch/x86/kernel/traps.c: 278
#7 [ffffbe90806878b8] do_divide_error at ffffffff82e303f8
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/arch/x86/kernel/traps.c: 289
#8 [ffffbe90806878e0] divide_error at ffffffff83a00ba4
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/arch/x86/entry/entry_64.S: 970
[exception RIP: gtp5g_encap_recv+431]
RIP: ffffffffc065841f RSP: ffffbe9080687990 RFLAGS: 00010246
RAX: 0000000054f51ee2 RBX: ffff9fadeec80200 RCX: 00000000ef536f6a
RDX: 0000000000000000 RSI: 000000007c163994 RDI: 0000000000000000
RBP: ffffbe9080687a28 R8: 0000000000000000 R9: 0000000000000010
R10: ffff9fade135e940 R11: 0000000000000024 R12: ffff9fade2ce7940
R13: 0000000000000008 R14: ffff9fade135e924 R15: 00000000ea030000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
/home/*****/gtp5g/gtp5g.c: 1370
#9 [ffffbe9080687a30] udp_queue_rcv_one_skb at ffffffff83755c84
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/ipv4/udp.c: 2012
#10 [ffffbe9080687a68] udp_queue_rcv_skb at ffffffff83755f3f
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/ipv4/udp.c: 2098
#11 [ffffbe9080687a90] udp_unicast_rcv_skb at ffffffff83756117
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/ipv4/udp.c: 2251
#12 [ffffbe9080687aa0] __udp4_lib_rcv at ffffffff83756d8a
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/ipv4/udp.c: 2312
#13 [ffffbe9080687b28] udp_rcv at ffffffff8375789a
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/ipv4/udp.c: 2483
#14 [ffffbe9080687b38] ip_protocol_deliver_rcu at ffffffff8371e415
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/ipv4/ip_input.c: 209
#15 [ffffbe9080687b60] ip_local_deliver_finish at ffffffff8371e5e5
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/ipv4/ip_input.c: 238
#16 [ffffbe9080687b70] ip_local_deliver at ffffffff8371e65f
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/ipv4/ip_input.c: 258
#17 [ffffbe9080687bc8] ip_rcv_finish at ffffffff8371dd94
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/ipv4/ip_input.c: 415
#18 [ffffbe9080687bf0] ip_rcv at ffffffff8371e736
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/ipv4/ip_input.c: 526
#19 [ffffbe9080687c50] __netif_receive_skb_one_core at ffffffff836bf197
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/core/dev.c: 4989
#20 [ffffbe9080687c80] __netif_receive_skb at ffffffff836bf1f8
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/core/dev.c: 5102
#21 [ffffbe9080687ca0] netif_receive_skb_internal at ffffffff836be3c5
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/core/dev.c: 5202
#22 [ffffbe9080687cd0] napi_gro_receive at ffffffff836c03b0
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/core/dev.c: 5681
#23 [ffffbe9080687cf8] bnx2x_rx_int at ffffffffc037889a [bnx2x]
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c: 1088
#24 [ffffbe9080687db0] bnx2x_poll at ffffffffc037a978 [bnx2x]
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c: 3228
#25 [ffffbe9080687de0] net_rx_action at ffffffff836bf9c0
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/net/core/dev.c: 6362
#26 [ffffbe9080687e60] __softirqentry_text_start at ffffffff83c000e4
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/kernel/softirq.c: 292
#27 [ffffbe9080687ec8] run_ksoftirqd at ffffffff82e9d4fb
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/arch/x86/include/asm/paravirt.h: 776
#28 [ffffbe9080687ed8] smpboot_thread_fn at ffffffff82ec05cc
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/kernel/smpboot.c: 164
#29 [ffffbe9080687f08] kthread at ffffffff82ebc521
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/kernel/kthread.c: 246
#30 [ffffbe9080687f50] ret_from_fork at ffffffff83a00215
/build/linux-hwe-zHO4ZF/linux-hwe-5.0.0/arch/x86/entry/entry_64.S: 358
crash>
[ 143.046091] divide error: 0000 [#1] SMP PTI
[ 143.046242] CPU: 0 PID: 9 Comm: ksoftirqd/0 Kdump: loaded Tainted: G OE 5.0.0-23-generic #24~18.04.1-Ubuntu
[ 143.046497] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/21/2015
[ 143.046754] RIP: 0010:gtp5g_encap_recv+0x1af/0x7e0 [gtp5g]
[ 143.046880] Code: ce 31 ca c1 ce 07 29 f2 89 d6 31 d0 c1 c6 10 29 f0 89 c6 31 c1 c1 c6 04 29 f1 31 ca c1 c1 0e 29 ca 31 d0 c1 ca 08 29 d0 31 d2 <41> f7 74 24 24 89 d0 49 8b 54 24 38 48 8d 04 c2 4c 8b 28 4d 85 ed
[ 143.047265] RSP: 0018:ffffbe9080687990 EFLAGS: 00010246
[ 143.047311] RAX: 0000000054f51ee2 RBX: ffff9fadeec80200 RCX: 00000000ef536f6a
[ 143.047346] RDX: 0000000000000000 RSI: 000000007c163994 RDI: 0000000000000000
[ 143.047381] RBP: ffffbe9080687a28 R08: 0000000000000000 R09: 0000000000000010
[ 143.047415] R10: ffff9fade135e940 R11: 0000000000000024 R12: ffff9fade2ce7940
[ 143.047450] R13: 0000000000000008 R14: ffff9fade135e924 R15: 00000000ea030000
[ 143.047485] FS: 0000000000000000(0000) GS:ffff9faebba00000(0000) knlGS:0000000000000000
[ 143.047524] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 143.047553] CR2: 000055a55fdfb110 CR3: 000000006b044000 CR4: 00000000000006f0
[ 143.047650] Call Trace:
[ 143.047672] ? gtp5g_genl_add_far+0x2a0/0x2a0 [gtp5g]
[ 143.047700] udp_queue_rcv_one_skb+0x1d4/0x450
[ 143.047724] udp_queue_rcv_skb+0x3f/0x1a0
[ 143.047746] udp_unicast_rcv_skb+0x77/0x90
[ 143.047767] __udp4_lib_rcv+0x4fa/0xba0
[ 143.047790] ? get_page_from_freelist+0xc7f/0x1560
[ 143.047815] udp_rcv+0x1a/0x20
[ 143.047835] ip_protocol_deliver_rcu+0x25/0x1b0
[ 143.047859] ip_local_deliver_finish+0x45/0x50
[ 143.047884] ip_local_deliver+0x6f/0xf0
[ 143.047906] ? ip_rcv_finish_core.isra.19+0x72/0x390
[ 143.047932] ip_rcv_finish+0x84/0xa0
[ 143.047952] ip_rcv+0x56/0xd0
[ 143.047972] __netif_receive_skb_one_core+0x57/0x80
[ 143.047998] __netif_receive_skb+0x18/0x60
[ 143.049060] netif_receive_skb_internal+0x45/0xe0
[ 143.049817] napi_gro_receive+0x120/0x150
[ 143.050589] bnx2x_rx_int+0x89a/0x1820 [bnx2x]
[ 143.051338] ? try_to_wake_up+0x59/0x4c0
[ 143.052078] ? entry_SYSCALL_64+0x36/0x38
[ 143.052786] ? inc_ucount+0x3e/0x210
[ 143.053478] bnx2x_poll+0x1c8/0x260 [bnx2x]
[ 143.054138] net_rx_action+0x140/0x3a0
[ 143.054800] __do_softirq+0xe4/0x2f3
[ 143.055429] run_ksoftirqd+0x2b/0x40
[ 143.056028] smpboot_thread_fn+0xfc/0x170
[ 143.056610] kthread+0x121/0x140
[ 143.057178] ? sort_range+0x30/0x30
[ 143.057747] ? kthread_park+0x90/0x90
[ 143.058297] ret_from_fork+0x35/0x40
[ 143.058843] Modules linked in: gtp5g(OE) udp_tunnel vmw_vsock_vmci_transport vsock vmwgfx joydev input_leds serio_raw ttm vmw_balloon drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt vmw_vmci mac_hid binfmt_misc sch_fq_codel ip_tables x_tables autofs4 bnx2x mdio ahci psmouse libcrc32c vmxnet3 libahci vmw_pvscsi i2c_piix4 pata_acpi hid_generic usbhid hid
The get_gtpu_header_len lacks packet length check
We read the "gtp5g.c".
The funtction "get_gtpu_header_len" traverse extension headers.
/* ext_hdr will always point to "Next ext hdr type" */
while (*(ext_hdr = gtp1 + rt_len - 1)) {
rt_len += (*(++ext_hdr)) * 4;
}
But, it seems that this code lacks checking the packet length.
We think that it must call the function "pskb_may_pull" to check the packet length every time the "rt_len" is updated.
Amazon Linux2 Installation
Hi,
I am currently trying to install this module on Amazon Linux 2 but am getting the following error:
make -C /usr/src/kernels/4.14.203-156.332.amzn2.x86_64/ M=/home/ec2-user/gtp5g clean
make[1]: Entering directory `/usr/src/kernels/4.14.203-156.332.amzn2.x86_64'
make[1]: Leaving directory `/usr/src/kernels/4.14.203-156.332.amzn2.x86_64'
make -C /usr/src/kernels/4.14.203-156.332.amzn2.x86_64/ M=/home/ec2-user/gtp5g modules
make[1]: Entering directory `/usr/src/kernels/4.14.203-156.332.amzn2.x86_64'
scripts/Makefile.build:50: *** CFLAGS was changed in "/home/ec2-user/gtp5g/Makefile". Fix it to use ccflags-y. Stop.
make[1]: *** [_module_/home/ec2-user/gtp5g] Error 2
make[1]: Leaving directory `/usr/src/kernels/4.14.203-156.332.amzn2.x86_64'
make: *** [all] Error 2
Any idea how to resolve this?
Get Linux kernel module 5G GTP-U Problem
after this commands
git clone https://github.com/PrinzOwO/gtp5g.git
cd gtp5g
make
sudo make install
I take this result :
make -C /usr/src/linux-headers-5.3.0-53-generic/ M=/root/go/src/free5gc/gtp5g modules
make[1]: Entering directory '/usr/src/linux-headers-5.3.0-53-generic'
CC [M] /root/go/src/free5gc/gtp5g/gtp5g.o
/root/go/src/free5gc/gtp5g/gtp5g.c: In function ‘ip4_find_route’:
/root/go/src/free5gc/gtp5g/gtp5g.c:766:2: error: too few arguments to function ‘rt->dst.ops->update_pmtu’
rt->dst.ops->update_pmtu(&rt->dst, NULL, skb, mtu);
^~
scripts/Makefile.build:288: recipe for target '/root/go/src/free5gc/gtp5g/gtp5g.o' failed
make[2]: *** [/root/go/src/free5gc/gtp5g/gtp5g.o] Error 1
Makefile:1656: recipe for target 'module/root/go/src/free5gc/gtp5g' failed
make[1]: *** [module/root/go/src/free5gc/gtp5g] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-5.3.0-53-generic'
Makefile:10: recipe for target 'all' failed
make: *** [all] Error 2
Can you please help me for this problem ?
Help:gtp5g Makefile error
**~/gtp5g$ make
make -C /usr/src/linux-headers-5.11.0-31-generic/ M=/home/gzzx/gtp5g modules
make[1]: “/usr/src/linux-headers-5.11.0-31-generic”
CC [M] /home/gzzx/gtp5g/gtp5g.o
/home/gzzx/gtp5g/gtp5g.c:1499:27: error: ‘ip_tunnel_get_stats64’ undeclared here (not in a function); did you mean ‘ip_tunnel_get_ttl’?
1499 | .ndo_get_stats64 = ip_tunnel_get_stats64,
| ^~~~~~~~~~~~~~~~~~~~~
| ip_tunnel_get_ttl
make[2]: *** [scripts/Makefile.build:287：/home/gzzx/gtp5g/gtp5g.o] error 1
make[1]: *** [Makefile:1848：/home/gzzx/gtp5g] error 2
make[1]: “/usr/src/linux-headers-5.11.0-31-generic”
make: *** [Makefile:15：all] error 2
**
Failed at make install due to udp_tunnel
Currently, I'm try to install modules after already building. When running make install as root, I get the following error:
modprobe udp_tunnel
modprobe: FATAL: Module udp_tunnel not found in directory
/lib/modules/5.4.0-77-generic
make: *** [Makefile:20: install] Error 1
Could you share with me how to fix this error? (install udp_tunnel module)
Update docs with instructions for compiling `gtp5g` in RHEL8/CentOS8
To compilegtp5g in RHEL8.2 or CentOS8.x
-
Install the Kernel RPMs and elfutils dependencies:
yum -y install kernel-devel kernel-headers elfutils-libelf elfutils-libelf-devel -
Update
INCLUDE_DIRwith the CentOS/RHEL 8x Kernel path:
INCLUDE_DIR = /usr/src/kernels/$(KVERSION)/
cannot create 5G GTP device : Operation not supported
Hi Team, thanks for the initiative. I tried gtp-link and gtp-tunnel which doesn't have any problem but while tying gtp5g I see the following, could you let me know the mistake I did?
[root@b0e32fc33a30 gnb]# gtp5g-link add test
cannot create 5G GTP device
: Operation not supported
Linux b0e32fc33a30 4.15.0-142-generic #146-Ubuntu SMP Tue Apr 13 01:11:19 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Regression tests?
Hi - are there any regression tests to determine if this module is functioning or not?
For example, I'm able to compile & insmod it on Ubuntu 18.04 which runs 4.15 and dmesg shows the following output. This is largely what I get when compiling on a 5.x kernel as well.
[ 67.315781] gtp5g: loading out-of-tree module taints kernel.
[ 67.315821] gtp5g: module verification failed: signature and/or required key missing - tainting kernel
[ 67.316747] gtp5g: 5G GTP module loaded (pdr ctx size 264 bytes)
I'd like to figure out if it's working and if not, work on the patches to make it work on U18.04
With kernel 5.4.0-73-generic, gtp5g failed to decap gtp pkts larger than 144 bytes
As title, I have tested it with free5gc, and device "upfgtp" always failed to decap gtp pkts larger than 144 bytes. But it's OK with Linux kernel 5.4.0-42.
I have printed out "sk_buff->data" to kernel message, and I found "sk_buff->data" was corrupted since the byte of "next extention header type". Is there any workaround to solve this issue, instead of replacing the kernel?
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.