- osmocom-net-gprs - lists.osmocom.org

[PATCH AUTOSEL 4.9 73/73] gtp: fix use-after-free in gtp_newlink()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit a2bed90704c68d3763bf24decb1b781a45395de8 ] Current gtp_newlink() could be called after unregister_pernet_subsys(). gtp_newlink() uses gtp_net but it can be destroyed by unregister_pernet_subsys(). So unregister_pernet_subsys() should be called after rtnl_link_unregister(). Test commands: #SHELL 1 while : do for i in {1..5} do ./gtp-link add gtp$i & done killall gtp-link done #SHELL 2 while : do modprobe -rv gtp done Splat looks like: [ 753.176631] BUG: KASAN: use-after-free in gtp_newlink+0x9b4/0xa5c [gtp] [ 753.177722] Read of size 8 at addr ffff8880d48f2458 by task gtp-link/7126 [ 753.179082] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G W 5.2.0-rc6+ #50 [ 753.185801] Call Trace: [ 753.186264] dump_stack+0x7c/0xbb [ 753.186863] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.187583] print_address_description+0xc7/0x240 [ 753.188382] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189097] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189846] __kasan_report+0x12a/0x16f [ 753.190542] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.191298] kasan_report+0xe/0x20 [ 753.191893] gtp_newlink+0x9b4/0xa5c [gtp] [ 753.192580] ? __netlink_ns_capable+0xc3/0xf0 [ 753.193370] __rtnl_newlink+0xb9f/0x11b0 [ ... ] [ 753.241201] Allocated by task 7186: [ 753.241844] save_stack+0x19/0x80 [ 753.242399] __kasan_kmalloc.constprop.3+0xa0/0xd0 [ 753.243192] __kmalloc+0x13e/0x300 [ 753.243764] ops_init+0xd6/0x350 [ 753.244314] register_pernet_operations+0x249/0x6f0 [ ... ] [ 753.251770] Freed by task 7178: [ 753.252288] save_stack+0x19/0x80 [ 753.252833] __kasan_slab_free+0x111/0x150 [ 753.253962] kfree+0xc7/0x280 [ 753.254509] ops_free_list.part.11+0x1c4/0x2d0 [ 753.255241] unregister_pernet_operations+0x262/0x390 [ ... ] [ 753.285883] list_add corruption. next->prev should be prev (ffff8880d48f2458), but was ffff8880d497d878. (next. [ 753.287241] ------------[ cut here ]------------ [ 753.287794] kernel BUG at lib/list_debug.c:25! [ 753.288364] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 753.289099] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G B W 5.2.0-rc6+ #50 [ 753.291036] RIP: 0010:__list_add_valid+0x74/0xd0 [ 753.291589] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 89 d9 48b [ 753.293779] RSP: 0018:ffff8880cae8f398 EFLAGS: 00010286 [ 753.294401] RAX: 0000000000000075 RBX: ffff8880d497d878 RCX: 0000000000000000 [ 753.296260] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed10195d1e69 [ 753.297070] RBP: ffff8880cd250ae0 R08: ffffed101b4bff21 R09: ffffed101b4bff21 [ 753.297899] R10: 0000000000000001 R11: ffffed101b4bff20 R12: ffff8880d497d878 [ 753.298703] R13: 0000000000000000 R14: ffff8880cd250ae0 R15: ffff8880d48f2458 [ 753.299564] FS: 00007f5f79805740(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000 [ 753.300533] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 753.301231] CR2: 00007fe8c7ef4f10 CR3: 00000000b71a6006 CR4: 00000000000606f0 [ 753.302183] Call Trace: [ 753.302530] gtp_newlink+0x5f6/0xa5c [gtp] [ 753.303037] ? __netlink_ns_capable+0xc3/0xf0 [ 753.303576] __rtnl_newlink+0xb9f/0x11b0 [ 753.304092] ? rtnl_link_unregister+0x230/0x230 Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 60df6e391ad2..7e1df403a37d 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1358,9 +1358,9 @@ late_initcall(gtp_init); static void __exit gtp_fini(void) { - unregister_pernet_subsys(&gtp_net_ops); genl_unregister_family(&gtp_genl_family); rtnl_link_unregister(&gtp_link_ops); + unregister_pernet_subsys(&gtp_net_ops); pr_info("GTP module unloaded\n"); } -- 2.20.1

1 0

[PATCH AUTOSEL 4.9 72/73] gtp: fix Illegal context switch in RCU read-side critical section.
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit 3f167e1921865b379a9becf03828e7202c7b4917 ] ipv4_pdp_add() is called in RCU read-side critical section. So GFP_KERNEL should not be used in the function. This patch make ipv4_pdp_add() to use GFP_ATOMIC instead of GFP_KERNEL. Test commands: gtp-link add gtp1 & gtp-tunnel add gtp1 v1 100 200 1.1.1.1 2.2.2.2 Splat looks like: [ 130.618881] ============================= [ 130.626382] WARNING: suspicious RCU usage [ 130.626994] 5.2.0-rc6+ #50 Not tainted [ 130.627622] ----------------------------- [ 130.628223] ./include/linux/rcupdate.h:266 Illegal context switch in RCU read-side critical section! [ 130.629684] [ 130.629684] other info that might help us debug this: [ 130.629684] [ 130.631022] [ 130.631022] rcu_scheduler_active = 2, debug_locks = 1 [ 130.632136] 4 locks held by gtp-tunnel/1025: [ 130.632925] #0: 000000002b93c8b7 (cb_lock){++++}, at: genl_rcv+0x15/0x40 [ 130.634159] #1: 00000000f17bc999 (genl_mutex){+.+.}, at: genl_rcv_msg+0xfb/0x130 [ 130.635487] #2: 00000000c644ed8e (rtnl_mutex){+.+.}, at: gtp_genl_new_pdp+0x18c/0x1150 [gtp] [ 130.636936] #3: 0000000007a1cde7 (rcu_read_lock){....}, at: gtp_genl_new_pdp+0x187/0x1150 [gtp] [ 130.638348] [ 130.638348] stack backtrace: [ 130.639062] CPU: 1 PID: 1025 Comm: gtp-tunnel Not tainted 5.2.0-rc6+ #50 [ 130.641318] Call Trace: [ 130.641707] dump_stack+0x7c/0xbb [ 130.642252] ___might_sleep+0x2c0/0x3b0 [ 130.642862] kmem_cache_alloc_trace+0x1cd/0x2b0 [ 130.643591] gtp_genl_new_pdp+0x6c5/0x1150 [gtp] [ 130.644371] genl_family_rcv_msg+0x63a/0x1030 [ 130.645074] ? mutex_lock_io_nested+0x1090/0x1090 [ 130.645845] ? genl_unregister_family+0x630/0x630 [ 130.646592] ? debug_show_all_locks+0x2d0/0x2d0 [ 130.647293] ? check_flags.part.40+0x440/0x440 [ 130.648099] genl_rcv_msg+0xa3/0x130 [ ... ] Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index cb206e5526c4..60df6e391ad2 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -952,7 +952,7 @@ static int ipv4_pdp_add(struct net_device *dev, struct genl_info *info) } - pctx = kmalloc(sizeof(struct pdp_ctx), GFP_KERNEL); + pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC); if (pctx == NULL) return -ENOMEM; -- 2.20.1

1 0

[PATCH AUTOSEL 4.14 104/105] gtp: fix use-after-free in gtp_newlink()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit a2bed90704c68d3763bf24decb1b781a45395de8 ] Current gtp_newlink() could be called after unregister_pernet_subsys(). gtp_newlink() uses gtp_net but it can be destroyed by unregister_pernet_subsys(). So unregister_pernet_subsys() should be called after rtnl_link_unregister(). Test commands: #SHELL 1 while : do for i in {1..5} do ./gtp-link add gtp$i & done killall gtp-link done #SHELL 2 while : do modprobe -rv gtp done Splat looks like: [ 753.176631] BUG: KASAN: use-after-free in gtp_newlink+0x9b4/0xa5c [gtp] [ 753.177722] Read of size 8 at addr ffff8880d48f2458 by task gtp-link/7126 [ 753.179082] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G W 5.2.0-rc6+ #50 [ 753.185801] Call Trace: [ 753.186264] dump_stack+0x7c/0xbb [ 753.186863] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.187583] print_address_description+0xc7/0x240 [ 753.188382] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189097] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189846] __kasan_report+0x12a/0x16f [ 753.190542] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.191298] kasan_report+0xe/0x20 [ 753.191893] gtp_newlink+0x9b4/0xa5c [gtp] [ 753.192580] ? __netlink_ns_capable+0xc3/0xf0 [ 753.193370] __rtnl_newlink+0xb9f/0x11b0 [ ... ] [ 753.241201] Allocated by task 7186: [ 753.241844] save_stack+0x19/0x80 [ 753.242399] __kasan_kmalloc.constprop.3+0xa0/0xd0 [ 753.243192] __kmalloc+0x13e/0x300 [ 753.243764] ops_init+0xd6/0x350 [ 753.244314] register_pernet_operations+0x249/0x6f0 [ ... ] [ 753.251770] Freed by task 7178: [ 753.252288] save_stack+0x19/0x80 [ 753.252833] __kasan_slab_free+0x111/0x150 [ 753.253962] kfree+0xc7/0x280 [ 753.254509] ops_free_list.part.11+0x1c4/0x2d0 [ 753.255241] unregister_pernet_operations+0x262/0x390 [ ... ] [ 753.285883] list_add corruption. next->prev should be prev (ffff8880d48f2458), but was ffff8880d497d878. (next. [ 753.287241] ------------[ cut here ]------------ [ 753.287794] kernel BUG at lib/list_debug.c:25! [ 753.288364] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 753.289099] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G B W 5.2.0-rc6+ #50 [ 753.291036] RIP: 0010:__list_add_valid+0x74/0xd0 [ 753.291589] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 89 d9 48b [ 753.293779] RSP: 0018:ffff8880cae8f398 EFLAGS: 00010286 [ 753.294401] RAX: 0000000000000075 RBX: ffff8880d497d878 RCX: 0000000000000000 [ 753.296260] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed10195d1e69 [ 753.297070] RBP: ffff8880cd250ae0 R08: ffffed101b4bff21 R09: ffffed101b4bff21 [ 753.297899] R10: 0000000000000001 R11: ffffed101b4bff20 R12: ffff8880d497d878 [ 753.298703] R13: 0000000000000000 R14: ffff8880cd250ae0 R15: ffff8880d48f2458 [ 753.299564] FS: 00007f5f79805740(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000 [ 753.300533] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 753.301231] CR2: 00007fe8c7ef4f10 CR3: 00000000b71a6006 CR4: 00000000000606f0 [ 753.302183] Call Trace: [ 753.302530] gtp_newlink+0x5f6/0xa5c [gtp] [ 753.303037] ? __netlink_ns_capable+0xc3/0xf0 [ 753.303576] __rtnl_newlink+0xb9f/0x11b0 [ 753.304092] ? rtnl_link_unregister+0x230/0x230 Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 53fd66534e3a..5de4053774b8 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1383,9 +1383,9 @@ late_initcall(gtp_init); static void __exit gtp_fini(void) { - unregister_pernet_subsys(&gtp_net_ops); genl_unregister_family(&gtp_genl_family); rtnl_link_unregister(&gtp_link_ops); + unregister_pernet_subsys(&gtp_net_ops); pr_info("GTP module unloaded\n"); } -- 2.20.1

1 0

[PATCH AUTOSEL 4.14 103/105] gtp: fix use-after-free in gtp_encap_destroy()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit 1788b8569f5de27da09087fa3f6580d2aa04cc75 ] gtp_encap_destroy() is called twice. 1. When interface is deleted. 2. When udp socket is destroyed. either gtp->sk0 or gtp->sk1u could be freed by sock_put() in gtp_encap_destroy(). so, when gtp_encap_destroy() is called again, it would uses freed sk pointer. patch makes gtp_encap_destroy() to set either gtp->sk0 or gtp->sk1u to null. in addition, both gtp->sk0 and gtp->sk1u pointer are protected by rtnl_lock. so, rtnl_lock() is added. Test command: gtp-link add gtp1 & killall gtp-link ip link del gtp1 Splat looks like: [ 83.182767] BUG: KASAN: use-after-free in __lock_acquire+0x3a20/0x46a0 [ 83.184128] Read of size 8 at addr ffff8880cc7d5360 by task ip/1008 [ 83.185567] CPU: 1 PID: 1008 Comm: ip Not tainted 5.2.0-rc6+ #50 [ 83.188469] Call Trace: [ ... ] [ 83.200126] lock_acquire+0x141/0x380 [ 83.200575] ? lock_sock_nested+0x3a/0xf0 [ 83.201069] _raw_spin_lock_bh+0x38/0x70 [ 83.201551] ? lock_sock_nested+0x3a/0xf0 [ 83.202044] lock_sock_nested+0x3a/0xf0 [ 83.202520] gtp_encap_destroy+0x18/0xe0 [gtp] [ 83.203065] gtp_encap_disable.isra.14+0x13/0x50 [gtp] [ 83.203687] gtp_dellink+0x56/0x170 [gtp] [ 83.204190] rtnl_delete_link+0xb4/0x100 [ ... ] [ 83.236513] Allocated by task 976: [ 83.236925] save_stack+0x19/0x80 [ 83.237332] __kasan_kmalloc.constprop.3+0xa0/0xd0 [ 83.237894] kmem_cache_alloc+0xd8/0x280 [ 83.238360] sk_prot_alloc.isra.42+0x50/0x200 [ 83.238874] sk_alloc+0x32/0x940 [ 83.239264] inet_create+0x283/0xc20 [ 83.239684] __sock_create+0x2dd/0x540 [ 83.240136] __sys_socket+0xca/0x1a0 [ 83.240550] __x64_sys_socket+0x6f/0xb0 [ 83.240998] do_syscall_64+0x9c/0x450 [ 83.241466] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 83.242061] [ 83.242249] Freed by task 0: [ 83.242616] save_stack+0x19/0x80 [ 83.243013] __kasan_slab_free+0x111/0x150 [ 83.243498] kmem_cache_free+0x89/0x250 [ 83.244444] __sk_destruct+0x38f/0x5a0 [ 83.245366] rcu_core+0x7e9/0x1c20 [ 83.245766] __do_softirq+0x213/0x8fa Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index c751f87c935e..53fd66534e3a 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -289,13 +289,17 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb) return gtp_rx(pctx, skb, hdrlen, gtp->role); } -static void gtp_encap_destroy(struct sock *sk) +static void __gtp_encap_destroy(struct sock *sk) { struct gtp_dev *gtp; lock_sock(sk); gtp = sk->sk_user_data; if (gtp) { + if (gtp->sk0 == sk) + gtp->sk0 = NULL; + else + gtp->sk1u = NULL; udp_sk(sk)->encap_type = 0; rcu_assign_sk_user_data(sk, NULL); sock_put(sk); @@ -303,12 +307,19 @@ static void gtp_encap_destroy(struct sock *sk) release_sock(sk); } +static void gtp_encap_destroy(struct sock *sk) +{ + rtnl_lock(); + __gtp_encap_destroy(sk); + rtnl_unlock(); +} + static void gtp_encap_disable_sock(struct sock *sk) { if (!sk) return; - gtp_encap_destroy(sk); + __gtp_encap_destroy(sk); } static void gtp_encap_disable(struct gtp_dev *gtp) @@ -1045,6 +1056,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) return -EINVAL; } + rtnl_lock(); rcu_read_lock(); gtp = gtp_find_dev(sock_net(skb->sk), info->attrs); @@ -1069,6 +1081,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) out_unlock: rcu_read_unlock(); + rtnl_unlock(); return err; } -- 2.20.1

1 0

[PATCH AUTOSEL 4.14 102/105] gtp: fix Illegal context switch in RCU read-side critical section.
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit 3f167e1921865b379a9becf03828e7202c7b4917 ] ipv4_pdp_add() is called in RCU read-side critical section. So GFP_KERNEL should not be used in the function. This patch make ipv4_pdp_add() to use GFP_ATOMIC instead of GFP_KERNEL. Test commands: gtp-link add gtp1 & gtp-tunnel add gtp1 v1 100 200 1.1.1.1 2.2.2.2 Splat looks like: [ 130.618881] ============================= [ 130.626382] WARNING: suspicious RCU usage [ 130.626994] 5.2.0-rc6+ #50 Not tainted [ 130.627622] ----------------------------- [ 130.628223] ./include/linux/rcupdate.h:266 Illegal context switch in RCU read-side critical section! [ 130.629684] [ 130.629684] other info that might help us debug this: [ 130.629684] [ 130.631022] [ 130.631022] rcu_scheduler_active = 2, debug_locks = 1 [ 130.632136] 4 locks held by gtp-tunnel/1025: [ 130.632925] #0: 000000002b93c8b7 (cb_lock){++++}, at: genl_rcv+0x15/0x40 [ 130.634159] #1: 00000000f17bc999 (genl_mutex){+.+.}, at: genl_rcv_msg+0xfb/0x130 [ 130.635487] #2: 00000000c644ed8e (rtnl_mutex){+.+.}, at: gtp_genl_new_pdp+0x18c/0x1150 [gtp] [ 130.636936] #3: 0000000007a1cde7 (rcu_read_lock){....}, at: gtp_genl_new_pdp+0x187/0x1150 [gtp] [ 130.638348] [ 130.638348] stack backtrace: [ 130.639062] CPU: 1 PID: 1025 Comm: gtp-tunnel Not tainted 5.2.0-rc6+ #50 [ 130.641318] Call Trace: [ 130.641707] dump_stack+0x7c/0xbb [ 130.642252] ___might_sleep+0x2c0/0x3b0 [ 130.642862] kmem_cache_alloc_trace+0x1cd/0x2b0 [ 130.643591] gtp_genl_new_pdp+0x6c5/0x1150 [gtp] [ 130.644371] genl_family_rcv_msg+0x63a/0x1030 [ 130.645074] ? mutex_lock_io_nested+0x1090/0x1090 [ 130.645845] ? genl_unregister_family+0x630/0x630 [ 130.646592] ? debug_show_all_locks+0x2d0/0x2d0 [ 130.647293] ? check_flags.part.40+0x440/0x440 [ 130.648099] genl_rcv_msg+0xa3/0x130 [ ... ] Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 2756edd84abc..c751f87c935e 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -956,7 +956,7 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct sock *sk, } - pctx = kmalloc(sizeof(struct pdp_ctx), GFP_KERNEL); + pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC); if (pctx == NULL) return -ENOMEM; -- 2.20.1

1 0

[PATCH AUTOSEL 4.14 101/105] gtp: fix suspicious RCU usage
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit e198987e7dd7d3645a53875151cd6f8fc425b706 ] gtp_encap_enable_socket() and gtp_encap_destroy() are not protected by rcu_read_lock(). and it's not safe to write sk->sk_user_data. This patch make these functions to use lock_sock() instead of rcu_dereference_sk_user_data(). Test commands: gtp-link add gtp1 Splat looks like: [ 83.238315] ============================= [ 83.239127] WARNING: suspicious RCU usage [ 83.239702] 5.2.0-rc6+ #49 Not tainted [ 83.240268] ----------------------------- [ 83.241205] drivers/net/gtp.c:799 suspicious rcu_dereference_check() usage! [ 83.243828] [ 83.243828] other info that might help us debug this: [ 83.243828] [ 83.246325] [ 83.246325] rcu_scheduler_active = 2, debug_locks = 1 [ 83.247314] 1 lock held by gtp-link/1008: [ 83.248523] #0: 0000000017772c7f (rtnl_mutex){+.+.}, at: __rtnl_newlink+0x5f5/0x11b0 [ 83.251503] [ 83.251503] stack backtrace: [ 83.252173] CPU: 0 PID: 1008 Comm: gtp-link Not tainted 5.2.0-rc6+ #49 [ 83.253271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 83.254562] Call Trace: [ 83.254995] dump_stack+0x7c/0xbb [ 83.255567] gtp_encap_enable_socket+0x2df/0x360 [gtp] [ 83.256415] ? gtp_find_dev+0x1a0/0x1a0 [gtp] [ 83.257161] ? memset+0x1f/0x40 [ 83.257843] gtp_newlink+0x90/0xa21 [gtp] [ 83.258497] ? __netlink_ns_capable+0xc3/0xf0 [ 83.259260] __rtnl_newlink+0xb9f/0x11b0 [ 83.260022] ? rtnl_link_unregister+0x230/0x230 [ ... ] Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index dba3869b61be..2756edd84abc 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -293,12 +293,14 @@ static void gtp_encap_destroy(struct sock *sk) { struct gtp_dev *gtp; - gtp = rcu_dereference_sk_user_data(sk); + lock_sock(sk); + gtp = sk->sk_user_data; if (gtp) { udp_sk(sk)->encap_type = 0; rcu_assign_sk_user_data(sk, NULL); sock_put(sk); } + release_sock(sk); } static void gtp_encap_disable_sock(struct sock *sk) @@ -798,7 +800,8 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, goto out_sock; } - if (rcu_dereference_sk_user_data(sock->sk)) { + lock_sock(sock->sk); + if (sock->sk->sk_user_data) { sk = ERR_PTR(-EBUSY); goto out_sock; } @@ -814,6 +817,7 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, setup_udp_tunnel_sock(sock_net(sock->sk), sock, &tuncfg); out_sock: + release_sock(sock->sk); sockfd_put(sock); return sk; } -- 2.20.1

1 0

[PATCH AUTOSEL 4.14 099/105] gtp: add missing gtp_encap_disable_sock() in gtp_encap_enable()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit e30155fd23c9c141cbe7d99b786e10a83a328837 ] If an invalid role is sent from user space, gtp_encap_enable() will fail. Then, it should call gtp_encap_disable_sock() but current code doesn't. It makes memory leak. Fixes: 91ed81f9abc7 ("gtp: support SGSN-side tunnels") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index f38e32a7ec9c..dba3869b61be 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -845,8 +845,13 @@ static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]) if (data[IFLA_GTP_ROLE]) { role = nla_get_u32(data[IFLA_GTP_ROLE]); - if (role > GTP_ROLE_SGSN) + if (role > GTP_ROLE_SGSN) { + if (sk0) + gtp_encap_disable_sock(sk0); + if (sk1u) + gtp_encap_disable_sock(sk1u); return -EINVAL; + } } gtp->sk0 = sk0; -- 2.20.1

1 0

[PATCH AUTOSEL 4.19 157/158] gtp: fix use-after-free in gtp_newlink()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit a2bed90704c68d3763bf24decb1b781a45395de8 ] Current gtp_newlink() could be called after unregister_pernet_subsys(). gtp_newlink() uses gtp_net but it can be destroyed by unregister_pernet_subsys(). So unregister_pernet_subsys() should be called after rtnl_link_unregister(). Test commands: #SHELL 1 while : do for i in {1..5} do ./gtp-link add gtp$i & done killall gtp-link done #SHELL 2 while : do modprobe -rv gtp done Splat looks like: [ 753.176631] BUG: KASAN: use-after-free in gtp_newlink+0x9b4/0xa5c [gtp] [ 753.177722] Read of size 8 at addr ffff8880d48f2458 by task gtp-link/7126 [ 753.179082] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G W 5.2.0-rc6+ #50 [ 753.185801] Call Trace: [ 753.186264] dump_stack+0x7c/0xbb [ 753.186863] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.187583] print_address_description+0xc7/0x240 [ 753.188382] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189097] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189846] __kasan_report+0x12a/0x16f [ 753.190542] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.191298] kasan_report+0xe/0x20 [ 753.191893] gtp_newlink+0x9b4/0xa5c [gtp] [ 753.192580] ? __netlink_ns_capable+0xc3/0xf0 [ 753.193370] __rtnl_newlink+0xb9f/0x11b0 [ ... ] [ 753.241201] Allocated by task 7186: [ 753.241844] save_stack+0x19/0x80 [ 753.242399] __kasan_kmalloc.constprop.3+0xa0/0xd0 [ 753.243192] __kmalloc+0x13e/0x300 [ 753.243764] ops_init+0xd6/0x350 [ 753.244314] register_pernet_operations+0x249/0x6f0 [ ... ] [ 753.251770] Freed by task 7178: [ 753.252288] save_stack+0x19/0x80 [ 753.252833] __kasan_slab_free+0x111/0x150 [ 753.253962] kfree+0xc7/0x280 [ 753.254509] ops_free_list.part.11+0x1c4/0x2d0 [ 753.255241] unregister_pernet_operations+0x262/0x390 [ ... ] [ 753.285883] list_add corruption. next->prev should be prev (ffff8880d48f2458), but was ffff8880d497d878. (next. [ 753.287241] ------------[ cut here ]------------ [ 753.287794] kernel BUG at lib/list_debug.c:25! [ 753.288364] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 753.289099] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G B W 5.2.0-rc6+ #50 [ 753.291036] RIP: 0010:__list_add_valid+0x74/0xd0 [ 753.291589] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 89 d9 48b [ 753.293779] RSP: 0018:ffff8880cae8f398 EFLAGS: 00010286 [ 753.294401] RAX: 0000000000000075 RBX: ffff8880d497d878 RCX: 0000000000000000 [ 753.296260] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed10195d1e69 [ 753.297070] RBP: ffff8880cd250ae0 R08: ffffed101b4bff21 R09: ffffed101b4bff21 [ 753.297899] R10: 0000000000000001 R11: ffffed101b4bff20 R12: ffff8880d497d878 [ 753.298703] R13: 0000000000000000 R14: ffff8880cd250ae0 R15: ffff8880d48f2458 [ 753.299564] FS: 00007f5f79805740(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000 [ 753.300533] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 753.301231] CR2: 00007fe8c7ef4f10 CR3: 00000000b71a6006 CR4: 00000000000606f0 [ 753.302183] Call Trace: [ 753.302530] gtp_newlink+0x5f6/0xa5c [gtp] [ 753.303037] ? __netlink_ns_capable+0xc3/0xf0 [ 753.303576] __rtnl_newlink+0xb9f/0x11b0 [ 753.304092] ? rtnl_link_unregister+0x230/0x230 Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 61e9b288d2dc..d178d5bad7e4 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1385,9 +1385,9 @@ late_initcall(gtp_init); static void __exit gtp_fini(void) { - unregister_pernet_subsys(&gtp_net_ops); genl_unregister_family(&gtp_genl_family); rtnl_link_unregister(&gtp_link_ops); + unregister_pernet_subsys(&gtp_net_ops); pr_info("GTP module unloaded\n"); } -- 2.20.1

1 0

[PATCH AUTOSEL 4.19 156/158] gtp: fix use-after-free in gtp_encap_destroy()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit 1788b8569f5de27da09087fa3f6580d2aa04cc75 ] gtp_encap_destroy() is called twice. 1. When interface is deleted. 2. When udp socket is destroyed. either gtp->sk0 or gtp->sk1u could be freed by sock_put() in gtp_encap_destroy(). so, when gtp_encap_destroy() is called again, it would uses freed sk pointer. patch makes gtp_encap_destroy() to set either gtp->sk0 or gtp->sk1u to null. in addition, both gtp->sk0 and gtp->sk1u pointer are protected by rtnl_lock. so, rtnl_lock() is added. Test command: gtp-link add gtp1 & killall gtp-link ip link del gtp1 Splat looks like: [ 83.182767] BUG: KASAN: use-after-free in __lock_acquire+0x3a20/0x46a0 [ 83.184128] Read of size 8 at addr ffff8880cc7d5360 by task ip/1008 [ 83.185567] CPU: 1 PID: 1008 Comm: ip Not tainted 5.2.0-rc6+ #50 [ 83.188469] Call Trace: [ ... ] [ 83.200126] lock_acquire+0x141/0x380 [ 83.200575] ? lock_sock_nested+0x3a/0xf0 [ 83.201069] _raw_spin_lock_bh+0x38/0x70 [ 83.201551] ? lock_sock_nested+0x3a/0xf0 [ 83.202044] lock_sock_nested+0x3a/0xf0 [ 83.202520] gtp_encap_destroy+0x18/0xe0 [gtp] [ 83.203065] gtp_encap_disable.isra.14+0x13/0x50 [gtp] [ 83.203687] gtp_dellink+0x56/0x170 [gtp] [ 83.204190] rtnl_delete_link+0xb4/0x100 [ ... ] [ 83.236513] Allocated by task 976: [ 83.236925] save_stack+0x19/0x80 [ 83.237332] __kasan_kmalloc.constprop.3+0xa0/0xd0 [ 83.237894] kmem_cache_alloc+0xd8/0x280 [ 83.238360] sk_prot_alloc.isra.42+0x50/0x200 [ 83.238874] sk_alloc+0x32/0x940 [ 83.239264] inet_create+0x283/0xc20 [ 83.239684] __sock_create+0x2dd/0x540 [ 83.240136] __sys_socket+0xca/0x1a0 [ 83.240550] __x64_sys_socket+0x6f/0xb0 [ 83.240998] do_syscall_64+0x9c/0x450 [ 83.241466] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 83.242061] [ 83.242249] Freed by task 0: [ 83.242616] save_stack+0x19/0x80 [ 83.243013] __kasan_slab_free+0x111/0x150 [ 83.243498] kmem_cache_free+0x89/0x250 [ 83.244444] __sk_destruct+0x38f/0x5a0 [ 83.245366] rcu_core+0x7e9/0x1c20 [ 83.245766] __do_softirq+0x213/0x8fa Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 6f1ad7ccaea6..61e9b288d2dc 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -289,13 +289,17 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb) return gtp_rx(pctx, skb, hdrlen, gtp->role); } -static void gtp_encap_destroy(struct sock *sk) +static void __gtp_encap_destroy(struct sock *sk) { struct gtp_dev *gtp; lock_sock(sk); gtp = sk->sk_user_data; if (gtp) { + if (gtp->sk0 == sk) + gtp->sk0 = NULL; + else + gtp->sk1u = NULL; udp_sk(sk)->encap_type = 0; rcu_assign_sk_user_data(sk, NULL); sock_put(sk); @@ -303,12 +307,19 @@ static void gtp_encap_destroy(struct sock *sk) release_sock(sk); } +static void gtp_encap_destroy(struct sock *sk) +{ + rtnl_lock(); + __gtp_encap_destroy(sk); + rtnl_unlock(); +} + static void gtp_encap_disable_sock(struct sock *sk) { if (!sk) return; - gtp_encap_destroy(sk); + __gtp_encap_destroy(sk); } static void gtp_encap_disable(struct gtp_dev *gtp) @@ -1047,6 +1058,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) return -EINVAL; } + rtnl_lock(); rcu_read_lock(); gtp = gtp_find_dev(sock_net(skb->sk), info->attrs); @@ -1071,6 +1083,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) out_unlock: rcu_read_unlock(); + rtnl_unlock(); return err; } -- 2.20.1

1 0

[PATCH AUTOSEL 4.19 155/158] gtp: fix Illegal context switch in RCU read-side critical section.
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit 3f167e1921865b379a9becf03828e7202c7b4917 ] ipv4_pdp_add() is called in RCU read-side critical section. So GFP_KERNEL should not be used in the function. This patch make ipv4_pdp_add() to use GFP_ATOMIC instead of GFP_KERNEL. Test commands: gtp-link add gtp1 & gtp-tunnel add gtp1 v1 100 200 1.1.1.1 2.2.2.2 Splat looks like: [ 130.618881] ============================= [ 130.626382] WARNING: suspicious RCU usage [ 130.626994] 5.2.0-rc6+ #50 Not tainted [ 130.627622] ----------------------------- [ 130.628223] ./include/linux/rcupdate.h:266 Illegal context switch in RCU read-side critical section! [ 130.629684] [ 130.629684] other info that might help us debug this: [ 130.629684] [ 130.631022] [ 130.631022] rcu_scheduler_active = 2, debug_locks = 1 [ 130.632136] 4 locks held by gtp-tunnel/1025: [ 130.632925] #0: 000000002b93c8b7 (cb_lock){++++}, at: genl_rcv+0x15/0x40 [ 130.634159] #1: 00000000f17bc999 (genl_mutex){+.+.}, at: genl_rcv_msg+0xfb/0x130 [ 130.635487] #2: 00000000c644ed8e (rtnl_mutex){+.+.}, at: gtp_genl_new_pdp+0x18c/0x1150 [gtp] [ 130.636936] #3: 0000000007a1cde7 (rcu_read_lock){....}, at: gtp_genl_new_pdp+0x187/0x1150 [gtp] [ 130.638348] [ 130.638348] stack backtrace: [ 130.639062] CPU: 1 PID: 1025 Comm: gtp-tunnel Not tainted 5.2.0-rc6+ #50 [ 130.641318] Call Trace: [ 130.641707] dump_stack+0x7c/0xbb [ 130.642252] ___might_sleep+0x2c0/0x3b0 [ 130.642862] kmem_cache_alloc_trace+0x1cd/0x2b0 [ 130.643591] gtp_genl_new_pdp+0x6c5/0x1150 [gtp] [ 130.644371] genl_family_rcv_msg+0x63a/0x1030 [ 130.645074] ? mutex_lock_io_nested+0x1090/0x1090 [ 130.645845] ? genl_unregister_family+0x630/0x630 [ 130.646592] ? debug_show_all_locks+0x2d0/0x2d0 [ 130.647293] ? check_flags.part.40+0x440/0x440 [ 130.648099] genl_rcv_msg+0xa3/0x130 [ ... ] Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index f45a806b6c06..6f1ad7ccaea6 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -958,7 +958,7 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct sock *sk, } - pctx = kmalloc(sizeof(struct pdp_ctx), GFP_KERNEL); + pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC); if (pctx == NULL) return -ENOMEM; -- 2.20.1

1 0

[PATCH AUTOSEL 4.19 154/158] gtp: fix suspicious RCU usage
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit e198987e7dd7d3645a53875151cd6f8fc425b706 ] gtp_encap_enable_socket() and gtp_encap_destroy() are not protected by rcu_read_lock(). and it's not safe to write sk->sk_user_data. This patch make these functions to use lock_sock() instead of rcu_dereference_sk_user_data(). Test commands: gtp-link add gtp1 Splat looks like: [ 83.238315] ============================= [ 83.239127] WARNING: suspicious RCU usage [ 83.239702] 5.2.0-rc6+ #49 Not tainted [ 83.240268] ----------------------------- [ 83.241205] drivers/net/gtp.c:799 suspicious rcu_dereference_check() usage! [ 83.243828] [ 83.243828] other info that might help us debug this: [ 83.243828] [ 83.246325] [ 83.246325] rcu_scheduler_active = 2, debug_locks = 1 [ 83.247314] 1 lock held by gtp-link/1008: [ 83.248523] #0: 0000000017772c7f (rtnl_mutex){+.+.}, at: __rtnl_newlink+0x5f5/0x11b0 [ 83.251503] [ 83.251503] stack backtrace: [ 83.252173] CPU: 0 PID: 1008 Comm: gtp-link Not tainted 5.2.0-rc6+ #49 [ 83.253271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 83.254562] Call Trace: [ 83.254995] dump_stack+0x7c/0xbb [ 83.255567] gtp_encap_enable_socket+0x2df/0x360 [gtp] [ 83.256415] ? gtp_find_dev+0x1a0/0x1a0 [gtp] [ 83.257161] ? memset+0x1f/0x40 [ 83.257843] gtp_newlink+0x90/0xa21 [gtp] [ 83.258497] ? __netlink_ns_capable+0xc3/0xf0 [ 83.259260] __rtnl_newlink+0xb9f/0x11b0 [ 83.260022] ? rtnl_link_unregister+0x230/0x230 [ ... ] Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 83488f2bf7a0..f45a806b6c06 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -293,12 +293,14 @@ static void gtp_encap_destroy(struct sock *sk) { struct gtp_dev *gtp; - gtp = rcu_dereference_sk_user_data(sk); + lock_sock(sk); + gtp = sk->sk_user_data; if (gtp) { udp_sk(sk)->encap_type = 0; rcu_assign_sk_user_data(sk, NULL); sock_put(sk); } + release_sock(sk); } static void gtp_encap_disable_sock(struct sock *sk) @@ -800,7 +802,8 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, goto out_sock; } - if (rcu_dereference_sk_user_data(sock->sk)) { + lock_sock(sock->sk); + if (sock->sk->sk_user_data) { sk = ERR_PTR(-EBUSY); goto out_sock; } @@ -816,6 +819,7 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, setup_udp_tunnel_sock(sock_net(sock->sk), sock, &tuncfg); out_sock: + release_sock(sock->sk); sockfd_put(sock); return sk; } -- 2.20.1

1 0

[PATCH AUTOSEL 4.19 152/158] gtp: add missing gtp_encap_disable_sock() in gtp_encap_enable()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit e30155fd23c9c141cbe7d99b786e10a83a328837 ] If an invalid role is sent from user space, gtp_encap_enable() will fail. Then, it should call gtp_encap_disable_sock() but current code doesn't. It makes memory leak. Fixes: 91ed81f9abc7 ("gtp: support SGSN-side tunnels") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 7a145172d503..83488f2bf7a0 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -847,8 +847,13 @@ static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]) if (data[IFLA_GTP_ROLE]) { role = nla_get_u32(data[IFLA_GTP_ROLE]); - if (role > GTP_ROLE_SGSN) + if (role > GTP_ROLE_SGSN) { + if (sk0) + gtp_encap_disable_sock(sk0); + if (sk1u) + gtp_encap_disable_sock(sk1u); return -EINVAL; + } } gtp->sk0 = sk0; -- 2.20.1

1 0

[PATCH AUTOSEL 5.1 217/219] gtp: fix use-after-free in gtp_newlink()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit a2bed90704c68d3763bf24decb1b781a45395de8 ] Current gtp_newlink() could be called after unregister_pernet_subsys(). gtp_newlink() uses gtp_net but it can be destroyed by unregister_pernet_subsys(). So unregister_pernet_subsys() should be called after rtnl_link_unregister(). Test commands: #SHELL 1 while : do for i in {1..5} do ./gtp-link add gtp$i & done killall gtp-link done #SHELL 2 while : do modprobe -rv gtp done Splat looks like: [ 753.176631] BUG: KASAN: use-after-free in gtp_newlink+0x9b4/0xa5c [gtp] [ 753.177722] Read of size 8 at addr ffff8880d48f2458 by task gtp-link/7126 [ 753.179082] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G W 5.2.0-rc6+ #50 [ 753.185801] Call Trace: [ 753.186264] dump_stack+0x7c/0xbb [ 753.186863] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.187583] print_address_description+0xc7/0x240 [ 753.188382] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189097] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189846] __kasan_report+0x12a/0x16f [ 753.190542] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.191298] kasan_report+0xe/0x20 [ 753.191893] gtp_newlink+0x9b4/0xa5c [gtp] [ 753.192580] ? __netlink_ns_capable+0xc3/0xf0 [ 753.193370] __rtnl_newlink+0xb9f/0x11b0 [ ... ] [ 753.241201] Allocated by task 7186: [ 753.241844] save_stack+0x19/0x80 [ 753.242399] __kasan_kmalloc.constprop.3+0xa0/0xd0 [ 753.243192] __kmalloc+0x13e/0x300 [ 753.243764] ops_init+0xd6/0x350 [ 753.244314] register_pernet_operations+0x249/0x6f0 [ ... ] [ 753.251770] Freed by task 7178: [ 753.252288] save_stack+0x19/0x80 [ 753.252833] __kasan_slab_free+0x111/0x150 [ 753.253962] kfree+0xc7/0x280 [ 753.254509] ops_free_list.part.11+0x1c4/0x2d0 [ 753.255241] unregister_pernet_operations+0x262/0x390 [ ... ] [ 753.285883] list_add corruption. next->prev should be prev (ffff8880d48f2458), but was ffff8880d497d878. (next. [ 753.287241] ------------[ cut here ]------------ [ 753.287794] kernel BUG at lib/list_debug.c:25! [ 753.288364] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 753.289099] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G B W 5.2.0-rc6+ #50 [ 753.291036] RIP: 0010:__list_add_valid+0x74/0xd0 [ 753.291589] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 89 d9 48b [ 753.293779] RSP: 0018:ffff8880cae8f398 EFLAGS: 00010286 [ 753.294401] RAX: 0000000000000075 RBX: ffff8880d497d878 RCX: 0000000000000000 [ 753.296260] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed10195d1e69 [ 753.297070] RBP: ffff8880cd250ae0 R08: ffffed101b4bff21 R09: ffffed101b4bff21 [ 753.297899] R10: 0000000000000001 R11: ffffed101b4bff20 R12: ffff8880d497d878 [ 753.298703] R13: 0000000000000000 R14: ffff8880cd250ae0 R15: ffff8880d48f2458 [ 753.299564] FS: 00007f5f79805740(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000 [ 753.300533] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 753.301231] CR2: 00007fe8c7ef4f10 CR3: 00000000b71a6006 CR4: 00000000000606f0 [ 753.302183] Call Trace: [ 753.302530] gtp_newlink+0x5f6/0xa5c [gtp] [ 753.303037] ? __netlink_ns_capable+0xc3/0xf0 [ 753.303576] __rtnl_newlink+0xb9f/0x11b0 [ 753.304092] ? rtnl_link_unregister+0x230/0x230 Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 61e9b288d2dc..d178d5bad7e4 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1385,9 +1385,9 @@ late_initcall(gtp_init); static void __exit gtp_fini(void) { - unregister_pernet_subsys(&gtp_net_ops); genl_unregister_family(&gtp_genl_family); rtnl_link_unregister(&gtp_link_ops); + unregister_pernet_subsys(&gtp_net_ops); pr_info("GTP module unloaded\n"); } -- 2.20.1

1 0

[PATCH AUTOSEL 5.1 216/219] gtp: fix use-after-free in gtp_encap_destroy()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit 1788b8569f5de27da09087fa3f6580d2aa04cc75 ] gtp_encap_destroy() is called twice. 1. When interface is deleted. 2. When udp socket is destroyed. either gtp->sk0 or gtp->sk1u could be freed by sock_put() in gtp_encap_destroy(). so, when gtp_encap_destroy() is called again, it would uses freed sk pointer. patch makes gtp_encap_destroy() to set either gtp->sk0 or gtp->sk1u to null. in addition, both gtp->sk0 and gtp->sk1u pointer are protected by rtnl_lock. so, rtnl_lock() is added. Test command: gtp-link add gtp1 & killall gtp-link ip link del gtp1 Splat looks like: [ 83.182767] BUG: KASAN: use-after-free in __lock_acquire+0x3a20/0x46a0 [ 83.184128] Read of size 8 at addr ffff8880cc7d5360 by task ip/1008 [ 83.185567] CPU: 1 PID: 1008 Comm: ip Not tainted 5.2.0-rc6+ #50 [ 83.188469] Call Trace: [ ... ] [ 83.200126] lock_acquire+0x141/0x380 [ 83.200575] ? lock_sock_nested+0x3a/0xf0 [ 83.201069] _raw_spin_lock_bh+0x38/0x70 [ 83.201551] ? lock_sock_nested+0x3a/0xf0 [ 83.202044] lock_sock_nested+0x3a/0xf0 [ 83.202520] gtp_encap_destroy+0x18/0xe0 [gtp] [ 83.203065] gtp_encap_disable.isra.14+0x13/0x50 [gtp] [ 83.203687] gtp_dellink+0x56/0x170 [gtp] [ 83.204190] rtnl_delete_link+0xb4/0x100 [ ... ] [ 83.236513] Allocated by task 976: [ 83.236925] save_stack+0x19/0x80 [ 83.237332] __kasan_kmalloc.constprop.3+0xa0/0xd0 [ 83.237894] kmem_cache_alloc+0xd8/0x280 [ 83.238360] sk_prot_alloc.isra.42+0x50/0x200 [ 83.238874] sk_alloc+0x32/0x940 [ 83.239264] inet_create+0x283/0xc20 [ 83.239684] __sock_create+0x2dd/0x540 [ 83.240136] __sys_socket+0xca/0x1a0 [ 83.240550] __x64_sys_socket+0x6f/0xb0 [ 83.240998] do_syscall_64+0x9c/0x450 [ 83.241466] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 83.242061] [ 83.242249] Freed by task 0: [ 83.242616] save_stack+0x19/0x80 [ 83.243013] __kasan_slab_free+0x111/0x150 [ 83.243498] kmem_cache_free+0x89/0x250 [ 83.244444] __sk_destruct+0x38f/0x5a0 [ 83.245366] rcu_core+0x7e9/0x1c20 [ 83.245766] __do_softirq+0x213/0x8fa Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 6f1ad7ccaea6..61e9b288d2dc 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -289,13 +289,17 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb) return gtp_rx(pctx, skb, hdrlen, gtp->role); } -static void gtp_encap_destroy(struct sock *sk) +static void __gtp_encap_destroy(struct sock *sk) { struct gtp_dev *gtp; lock_sock(sk); gtp = sk->sk_user_data; if (gtp) { + if (gtp->sk0 == sk) + gtp->sk0 = NULL; + else + gtp->sk1u = NULL; udp_sk(sk)->encap_type = 0; rcu_assign_sk_user_data(sk, NULL); sock_put(sk); @@ -303,12 +307,19 @@ static void gtp_encap_destroy(struct sock *sk) release_sock(sk); } +static void gtp_encap_destroy(struct sock *sk) +{ + rtnl_lock(); + __gtp_encap_destroy(sk); + rtnl_unlock(); +} + static void gtp_encap_disable_sock(struct sock *sk) { if (!sk) return; - gtp_encap_destroy(sk); + __gtp_encap_destroy(sk); } static void gtp_encap_disable(struct gtp_dev *gtp) @@ -1047,6 +1058,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) return -EINVAL; } + rtnl_lock(); rcu_read_lock(); gtp = gtp_find_dev(sock_net(skb->sk), info->attrs); @@ -1071,6 +1083,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) out_unlock: rcu_read_unlock(); + rtnl_unlock(); return err; } -- 2.20.1

1 0

[PATCH AUTOSEL 5.1 215/219] gtp: fix Illegal context switch in RCU read-side critical section.
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit 3f167e1921865b379a9becf03828e7202c7b4917 ] ipv4_pdp_add() is called in RCU read-side critical section. So GFP_KERNEL should not be used in the function. This patch make ipv4_pdp_add() to use GFP_ATOMIC instead of GFP_KERNEL. Test commands: gtp-link add gtp1 & gtp-tunnel add gtp1 v1 100 200 1.1.1.1 2.2.2.2 Splat looks like: [ 130.618881] ============================= [ 130.626382] WARNING: suspicious RCU usage [ 130.626994] 5.2.0-rc6+ #50 Not tainted [ 130.627622] ----------------------------- [ 130.628223] ./include/linux/rcupdate.h:266 Illegal context switch in RCU read-side critical section! [ 130.629684] [ 130.629684] other info that might help us debug this: [ 130.629684] [ 130.631022] [ 130.631022] rcu_scheduler_active = 2, debug_locks = 1 [ 130.632136] 4 locks held by gtp-tunnel/1025: [ 130.632925] #0: 000000002b93c8b7 (cb_lock){++++}, at: genl_rcv+0x15/0x40 [ 130.634159] #1: 00000000f17bc999 (genl_mutex){+.+.}, at: genl_rcv_msg+0xfb/0x130 [ 130.635487] #2: 00000000c644ed8e (rtnl_mutex){+.+.}, at: gtp_genl_new_pdp+0x18c/0x1150 [gtp] [ 130.636936] #3: 0000000007a1cde7 (rcu_read_lock){....}, at: gtp_genl_new_pdp+0x187/0x1150 [gtp] [ 130.638348] [ 130.638348] stack backtrace: [ 130.639062] CPU: 1 PID: 1025 Comm: gtp-tunnel Not tainted 5.2.0-rc6+ #50 [ 130.641318] Call Trace: [ 130.641707] dump_stack+0x7c/0xbb [ 130.642252] ___might_sleep+0x2c0/0x3b0 [ 130.642862] kmem_cache_alloc_trace+0x1cd/0x2b0 [ 130.643591] gtp_genl_new_pdp+0x6c5/0x1150 [gtp] [ 130.644371] genl_family_rcv_msg+0x63a/0x1030 [ 130.645074] ? mutex_lock_io_nested+0x1090/0x1090 [ 130.645845] ? genl_unregister_family+0x630/0x630 [ 130.646592] ? debug_show_all_locks+0x2d0/0x2d0 [ 130.647293] ? check_flags.part.40+0x440/0x440 [ 130.648099] genl_rcv_msg+0xa3/0x130 [ ... ] Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index f45a806b6c06..6f1ad7ccaea6 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -958,7 +958,7 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct sock *sk, } - pctx = kmalloc(sizeof(struct pdp_ctx), GFP_KERNEL); + pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC); if (pctx == NULL) return -ENOMEM; -- 2.20.1

1 0

[PATCH AUTOSEL 5.1 214/219] gtp: fix suspicious RCU usage
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit e198987e7dd7d3645a53875151cd6f8fc425b706 ] gtp_encap_enable_socket() and gtp_encap_destroy() are not protected by rcu_read_lock(). and it's not safe to write sk->sk_user_data. This patch make these functions to use lock_sock() instead of rcu_dereference_sk_user_data(). Test commands: gtp-link add gtp1 Splat looks like: [ 83.238315] ============================= [ 83.239127] WARNING: suspicious RCU usage [ 83.239702] 5.2.0-rc6+ #49 Not tainted [ 83.240268] ----------------------------- [ 83.241205] drivers/net/gtp.c:799 suspicious rcu_dereference_check() usage! [ 83.243828] [ 83.243828] other info that might help us debug this: [ 83.243828] [ 83.246325] [ 83.246325] rcu_scheduler_active = 2, debug_locks = 1 [ 83.247314] 1 lock held by gtp-link/1008: [ 83.248523] #0: 0000000017772c7f (rtnl_mutex){+.+.}, at: __rtnl_newlink+0x5f5/0x11b0 [ 83.251503] [ 83.251503] stack backtrace: [ 83.252173] CPU: 0 PID: 1008 Comm: gtp-link Not tainted 5.2.0-rc6+ #49 [ 83.253271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 83.254562] Call Trace: [ 83.254995] dump_stack+0x7c/0xbb [ 83.255567] gtp_encap_enable_socket+0x2df/0x360 [gtp] [ 83.256415] ? gtp_find_dev+0x1a0/0x1a0 [gtp] [ 83.257161] ? memset+0x1f/0x40 [ 83.257843] gtp_newlink+0x90/0xa21 [gtp] [ 83.258497] ? __netlink_ns_capable+0xc3/0xf0 [ 83.259260] __rtnl_newlink+0xb9f/0x11b0 [ 83.260022] ? rtnl_link_unregister+0x230/0x230 [ ... ] Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 83488f2bf7a0..f45a806b6c06 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -293,12 +293,14 @@ static void gtp_encap_destroy(struct sock *sk) { struct gtp_dev *gtp; - gtp = rcu_dereference_sk_user_data(sk); + lock_sock(sk); + gtp = sk->sk_user_data; if (gtp) { udp_sk(sk)->encap_type = 0; rcu_assign_sk_user_data(sk, NULL); sock_put(sk); } + release_sock(sk); } static void gtp_encap_disable_sock(struct sock *sk) @@ -800,7 +802,8 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, goto out_sock; } - if (rcu_dereference_sk_user_data(sock->sk)) { + lock_sock(sock->sk); + if (sock->sk->sk_user_data) { sk = ERR_PTR(-EBUSY); goto out_sock; } @@ -816,6 +819,7 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, setup_udp_tunnel_sock(sock_net(sock->sk), sock, &tuncfg); out_sock: + release_sock(sock->sk); sockfd_put(sock); return sk; } -- 2.20.1

1 0

[PATCH AUTOSEL 5.1 212/219] gtp: add missing gtp_encap_disable_sock() in gtp_encap_enable()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit e30155fd23c9c141cbe7d99b786e10a83a328837 ] If an invalid role is sent from user space, gtp_encap_enable() will fail. Then, it should call gtp_encap_disable_sock() but current code doesn't. It makes memory leak. Fixes: 91ed81f9abc7 ("gtp: support SGSN-side tunnels") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 7a145172d503..83488f2bf7a0 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -847,8 +847,13 @@ static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]) if (data[IFLA_GTP_ROLE]) { role = nla_get_u32(data[IFLA_GTP_ROLE]); - if (role > GTP_ROLE_SGSN) + if (role > GTP_ROLE_SGSN) { + if (sk0) + gtp_encap_disable_sock(sk0); + if (sk1u) + gtp_encap_disable_sock(sk1u); return -EINVAL; + } } gtp->sk0 = sk0; -- 2.20.1

1 0

[PATCH AUTOSEL 5.2 247/249] gtp: fix use-after-free in gtp_newlink()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit a2bed90704c68d3763bf24decb1b781a45395de8 ] Current gtp_newlink() could be called after unregister_pernet_subsys(). gtp_newlink() uses gtp_net but it can be destroyed by unregister_pernet_subsys(). So unregister_pernet_subsys() should be called after rtnl_link_unregister(). Test commands: #SHELL 1 while : do for i in {1..5} do ./gtp-link add gtp$i & done killall gtp-link done #SHELL 2 while : do modprobe -rv gtp done Splat looks like: [ 753.176631] BUG: KASAN: use-after-free in gtp_newlink+0x9b4/0xa5c [gtp] [ 753.177722] Read of size 8 at addr ffff8880d48f2458 by task gtp-link/7126 [ 753.179082] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G W 5.2.0-rc6+ #50 [ 753.185801] Call Trace: [ 753.186264] dump_stack+0x7c/0xbb [ 753.186863] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.187583] print_address_description+0xc7/0x240 [ 753.188382] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189097] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189846] __kasan_report+0x12a/0x16f [ 753.190542] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.191298] kasan_report+0xe/0x20 [ 753.191893] gtp_newlink+0x9b4/0xa5c [gtp] [ 753.192580] ? __netlink_ns_capable+0xc3/0xf0 [ 753.193370] __rtnl_newlink+0xb9f/0x11b0 [ ... ] [ 753.241201] Allocated by task 7186: [ 753.241844] save_stack+0x19/0x80 [ 753.242399] __kasan_kmalloc.constprop.3+0xa0/0xd0 [ 753.243192] __kmalloc+0x13e/0x300 [ 753.243764] ops_init+0xd6/0x350 [ 753.244314] register_pernet_operations+0x249/0x6f0 [ ... ] [ 753.251770] Freed by task 7178: [ 753.252288] save_stack+0x19/0x80 [ 753.252833] __kasan_slab_free+0x111/0x150 [ 753.253962] kfree+0xc7/0x280 [ 753.254509] ops_free_list.part.11+0x1c4/0x2d0 [ 753.255241] unregister_pernet_operations+0x262/0x390 [ ... ] [ 753.285883] list_add corruption. next->prev should be prev (ffff8880d48f2458), but was ffff8880d497d878. (next. [ 753.287241] ------------[ cut here ]------------ [ 753.287794] kernel BUG at lib/list_debug.c:25! [ 753.288364] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 753.289099] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G B W 5.2.0-rc6+ #50 [ 753.291036] RIP: 0010:__list_add_valid+0x74/0xd0 [ 753.291589] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 89 d9 48b [ 753.293779] RSP: 0018:ffff8880cae8f398 EFLAGS: 00010286 [ 753.294401] RAX: 0000000000000075 RBX: ffff8880d497d878 RCX: 0000000000000000 [ 753.296260] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed10195d1e69 [ 753.297070] RBP: ffff8880cd250ae0 R08: ffffed101b4bff21 R09: ffffed101b4bff21 [ 753.297899] R10: 0000000000000001 R11: ffffed101b4bff20 R12: ffff8880d497d878 [ 753.298703] R13: 0000000000000000 R14: ffff8880cd250ae0 R15: ffff8880d48f2458 [ 753.299564] FS: 00007f5f79805740(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000 [ 753.300533] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 753.301231] CR2: 00007fe8c7ef4f10 CR3: 00000000b71a6006 CR4: 00000000000606f0 [ 753.302183] Call Trace: [ 753.302530] gtp_newlink+0x5f6/0xa5c [gtp] [ 753.303037] ? __netlink_ns_capable+0xc3/0xf0 [ 753.303576] __rtnl_newlink+0xb9f/0x11b0 [ 753.304092] ? rtnl_link_unregister+0x230/0x230 Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 5615cdb7202c..607f38712b4e 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1382,9 +1382,9 @@ late_initcall(gtp_init); static void __exit gtp_fini(void) { - unregister_pernet_subsys(&gtp_net_ops); genl_unregister_family(&gtp_genl_family); rtnl_link_unregister(&gtp_link_ops); + unregister_pernet_subsys(&gtp_net_ops); pr_info("GTP module unloaded\n"); } -- 2.20.1

1 0

[PATCH AUTOSEL 5.2 246/249] gtp: fix use-after-free in gtp_encap_destroy()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit 1788b8569f5de27da09087fa3f6580d2aa04cc75 ] gtp_encap_destroy() is called twice. 1. When interface is deleted. 2. When udp socket is destroyed. either gtp->sk0 or gtp->sk1u could be freed by sock_put() in gtp_encap_destroy(). so, when gtp_encap_destroy() is called again, it would uses freed sk pointer. patch makes gtp_encap_destroy() to set either gtp->sk0 or gtp->sk1u to null. in addition, both gtp->sk0 and gtp->sk1u pointer are protected by rtnl_lock. so, rtnl_lock() is added. Test command: gtp-link add gtp1 & killall gtp-link ip link del gtp1 Splat looks like: [ 83.182767] BUG: KASAN: use-after-free in __lock_acquire+0x3a20/0x46a0 [ 83.184128] Read of size 8 at addr ffff8880cc7d5360 by task ip/1008 [ 83.185567] CPU: 1 PID: 1008 Comm: ip Not tainted 5.2.0-rc6+ #50 [ 83.188469] Call Trace: [ ... ] [ 83.200126] lock_acquire+0x141/0x380 [ 83.200575] ? lock_sock_nested+0x3a/0xf0 [ 83.201069] _raw_spin_lock_bh+0x38/0x70 [ 83.201551] ? lock_sock_nested+0x3a/0xf0 [ 83.202044] lock_sock_nested+0x3a/0xf0 [ 83.202520] gtp_encap_destroy+0x18/0xe0 [gtp] [ 83.203065] gtp_encap_disable.isra.14+0x13/0x50 [gtp] [ 83.203687] gtp_dellink+0x56/0x170 [gtp] [ 83.204190] rtnl_delete_link+0xb4/0x100 [ ... ] [ 83.236513] Allocated by task 976: [ 83.236925] save_stack+0x19/0x80 [ 83.237332] __kasan_kmalloc.constprop.3+0xa0/0xd0 [ 83.237894] kmem_cache_alloc+0xd8/0x280 [ 83.238360] sk_prot_alloc.isra.42+0x50/0x200 [ 83.238874] sk_alloc+0x32/0x940 [ 83.239264] inet_create+0x283/0xc20 [ 83.239684] __sock_create+0x2dd/0x540 [ 83.240136] __sys_socket+0xca/0x1a0 [ 83.240550] __x64_sys_socket+0x6f/0xb0 [ 83.240998] do_syscall_64+0x9c/0x450 [ 83.241466] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 83.242061] [ 83.242249] Freed by task 0: [ 83.242616] save_stack+0x19/0x80 [ 83.243013] __kasan_slab_free+0x111/0x150 [ 83.243498] kmem_cache_free+0x89/0x250 [ 83.244444] __sk_destruct+0x38f/0x5a0 [ 83.245366] rcu_core+0x7e9/0x1c20 [ 83.245766] __do_softirq+0x213/0x8fa Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index b770335c03c1..5615cdb7202c 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -285,13 +285,17 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb) return gtp_rx(pctx, skb, hdrlen, gtp->role); } -static void gtp_encap_destroy(struct sock *sk) +static void __gtp_encap_destroy(struct sock *sk) { struct gtp_dev *gtp; lock_sock(sk); gtp = sk->sk_user_data; if (gtp) { + if (gtp->sk0 == sk) + gtp->sk0 = NULL; + else + gtp->sk1u = NULL; udp_sk(sk)->encap_type = 0; rcu_assign_sk_user_data(sk, NULL); sock_put(sk); @@ -299,12 +303,19 @@ static void gtp_encap_destroy(struct sock *sk) release_sock(sk); } +static void gtp_encap_destroy(struct sock *sk) +{ + rtnl_lock(); + __gtp_encap_destroy(sk); + rtnl_unlock(); +} + static void gtp_encap_disable_sock(struct sock *sk) { if (!sk) return; - gtp_encap_destroy(sk); + __gtp_encap_destroy(sk); } static void gtp_encap_disable(struct gtp_dev *gtp) @@ -1043,6 +1054,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) return -EINVAL; } + rtnl_lock(); rcu_read_lock(); gtp = gtp_find_dev(sock_net(skb->sk), info->attrs); @@ -1067,6 +1079,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) out_unlock: rcu_read_unlock(); + rtnl_unlock(); return err; } -- 2.20.1

1 0

[PATCH AUTOSEL 5.2 245/249] gtp: fix Illegal context switch in RCU read-side critical section.
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit 3f167e1921865b379a9becf03828e7202c7b4917 ] ipv4_pdp_add() is called in RCU read-side critical section. So GFP_KERNEL should not be used in the function. This patch make ipv4_pdp_add() to use GFP_ATOMIC instead of GFP_KERNEL. Test commands: gtp-link add gtp1 & gtp-tunnel add gtp1 v1 100 200 1.1.1.1 2.2.2.2 Splat looks like: [ 130.618881] ============================= [ 130.626382] WARNING: suspicious RCU usage [ 130.626994] 5.2.0-rc6+ #50 Not tainted [ 130.627622] ----------------------------- [ 130.628223] ./include/linux/rcupdate.h:266 Illegal context switch in RCU read-side critical section! [ 130.629684] [ 130.629684] other info that might help us debug this: [ 130.629684] [ 130.631022] [ 130.631022] rcu_scheduler_active = 2, debug_locks = 1 [ 130.632136] 4 locks held by gtp-tunnel/1025: [ 130.632925] #0: 000000002b93c8b7 (cb_lock){++++}, at: genl_rcv+0x15/0x40 [ 130.634159] #1: 00000000f17bc999 (genl_mutex){+.+.}, at: genl_rcv_msg+0xfb/0x130 [ 130.635487] #2: 00000000c644ed8e (rtnl_mutex){+.+.}, at: gtp_genl_new_pdp+0x18c/0x1150 [gtp] [ 130.636936] #3: 0000000007a1cde7 (rcu_read_lock){....}, at: gtp_genl_new_pdp+0x187/0x1150 [gtp] [ 130.638348] [ 130.638348] stack backtrace: [ 130.639062] CPU: 1 PID: 1025 Comm: gtp-tunnel Not tainted 5.2.0-rc6+ #50 [ 130.641318] Call Trace: [ 130.641707] dump_stack+0x7c/0xbb [ 130.642252] ___might_sleep+0x2c0/0x3b0 [ 130.642862] kmem_cache_alloc_trace+0x1cd/0x2b0 [ 130.643591] gtp_genl_new_pdp+0x6c5/0x1150 [gtp] [ 130.644371] genl_family_rcv_msg+0x63a/0x1030 [ 130.645074] ? mutex_lock_io_nested+0x1090/0x1090 [ 130.645845] ? genl_unregister_family+0x630/0x630 [ 130.646592] ? debug_show_all_locks+0x2d0/0x2d0 [ 130.647293] ? check_flags.part.40+0x440/0x440 [ 130.648099] genl_rcv_msg+0xa3/0x130 [ ... ] Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 61f19e66be55..b770335c03c1 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -954,7 +954,7 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct sock *sk, } - pctx = kmalloc(sizeof(struct pdp_ctx), GFP_KERNEL); + pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC); if (pctx == NULL) return -ENOMEM; -- 2.20.1

1 0

[PATCH AUTOSEL 5.2 244/249] gtp: fix suspicious RCU usage
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit e198987e7dd7d3645a53875151cd6f8fc425b706 ] gtp_encap_enable_socket() and gtp_encap_destroy() are not protected by rcu_read_lock(). and it's not safe to write sk->sk_user_data. This patch make these functions to use lock_sock() instead of rcu_dereference_sk_user_data(). Test commands: gtp-link add gtp1 Splat looks like: [ 83.238315] ============================= [ 83.239127] WARNING: suspicious RCU usage [ 83.239702] 5.2.0-rc6+ #49 Not tainted [ 83.240268] ----------------------------- [ 83.241205] drivers/net/gtp.c:799 suspicious rcu_dereference_check() usage! [ 83.243828] [ 83.243828] other info that might help us debug this: [ 83.243828] [ 83.246325] [ 83.246325] rcu_scheduler_active = 2, debug_locks = 1 [ 83.247314] 1 lock held by gtp-link/1008: [ 83.248523] #0: 0000000017772c7f (rtnl_mutex){+.+.}, at: __rtnl_newlink+0x5f5/0x11b0 [ 83.251503] [ 83.251503] stack backtrace: [ 83.252173] CPU: 0 PID: 1008 Comm: gtp-link Not tainted 5.2.0-rc6+ #49 [ 83.253271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 83.254562] Call Trace: [ 83.254995] dump_stack+0x7c/0xbb [ 83.255567] gtp_encap_enable_socket+0x2df/0x360 [gtp] [ 83.256415] ? gtp_find_dev+0x1a0/0x1a0 [gtp] [ 83.257161] ? memset+0x1f/0x40 [ 83.257843] gtp_newlink+0x90/0xa21 [gtp] [ 83.258497] ? __netlink_ns_capable+0xc3/0xf0 [ 83.259260] __rtnl_newlink+0xb9f/0x11b0 [ 83.260022] ? rtnl_link_unregister+0x230/0x230 [ ... ] Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 01fc51892e48..61f19e66be55 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -289,12 +289,14 @@ static void gtp_encap_destroy(struct sock *sk) { struct gtp_dev *gtp; - gtp = rcu_dereference_sk_user_data(sk); + lock_sock(sk); + gtp = sk->sk_user_data; if (gtp) { udp_sk(sk)->encap_type = 0; rcu_assign_sk_user_data(sk, NULL); sock_put(sk); } + release_sock(sk); } static void gtp_encap_disable_sock(struct sock *sk) @@ -796,7 +798,8 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, goto out_sock; } - if (rcu_dereference_sk_user_data(sock->sk)) { + lock_sock(sock->sk); + if (sock->sk->sk_user_data) { sk = ERR_PTR(-EBUSY); goto out_sock; } @@ -812,6 +815,7 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, setup_udp_tunnel_sock(sock_net(sock->sk), sock, &tuncfg); out_sock: + release_sock(sock->sk); sockfd_put(sock); return sk; } -- 2.20.1

1 0

[PATCH AUTOSEL 5.2 242/249] gtp: add missing gtp_encap_disable_sock() in gtp_encap_enable()
by Sasha Levin 15 Jul '19

15 Jul '19

From: Taehee Yoo <ap420073(a)gmail.com> [ Upstream commit e30155fd23c9c141cbe7d99b786e10a83a328837 ] If an invalid role is sent from user space, gtp_encap_enable() will fail. Then, it should call gtp_encap_disable_sock() but current code doesn't. It makes memory leak. Fixes: 91ed81f9abc7 ("gtp: support SGSN-side tunnels") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> Signed-off-by: David S. Miller <davem(a)davemloft.net> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/net/gtp.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index fc45b749db46..01fc51892e48 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -843,8 +843,13 @@ static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]) if (data[IFLA_GTP_ROLE]) { role = nla_get_u32(data[IFLA_GTP_ROLE]); - if (role > GTP_ROLE_SGSN) + if (role > GTP_ROLE_SGSN) { + if (sk0) + gtp_encap_disable_sock(sk0); + if (sk1u) + gtp_encap_disable_sock(sk1u); return -EINVAL; + } } gtp->sk0 = sk0; -- 2.20.1

1 0

[PATCH net 0/6] gtp: fix several bugs
by Taehee Yoo 08 Jul '19

08 Jul '19

This patch series fixes several bugs in the gtp module. First patch fixes suspicious RCU usage. The problem is to use rcu_dereference_sk_user_data() outside of RCU read critical section. Second patch fixes use-after-free. gtp_encap_destroy() is called twice. gtp_encap_destroy() use both gtp->sk0 and gtp->sk1u. these pointers can be freed in gtp_encap_destroy(). So, gtp_encap_destroy() should avoid using freed sk pointer. Third patch removes duplicate code in gtp_dellink(). gtp_dellink() calls gtp_encap_disable() twice. So, remove one of them. Fourth patch fixes usage of GFP_KERNEL. GFP_KERNEL can not be used in RCU read critical section. This patch make ipv4_pdp_add() to use GFP_ATOMIC instead of GFP_KERNEL. Fifth patch fixes use-after-free in gtp_newlink(). gtp_newlink() uses gtp_net which would be destroyed by the __exit_net routine. So, gtp_newlink should not be called after the __exit_net routine. Sixth patch adds missing error handling routine in gtp_encap_enable(). gtp_encap_enable() will fail, if invalid role value is sent from user-space. if so, gtp_encap_enable() should execute error handling routine. Taehee Yoo (6): gtp: fix suspicious RCU usage gtp: fix use-after-free in gtp_encap_destroy() gtp: remove duplicate code in gtp_dellink() gtp: fix Illegal context switch in RCU read-side critical section. gtp: fix use-after-free in gtp_newlink() gtp: add missing gtp_encap_disable_sock() in gtp_encap_enable() drivers/net/gtp.c | 37 +++++++++++++++++++++++++++++-------- 1 file changed, 29 insertions(+), 8 deletions(-) -- 2.17.1

3 3

[PATCH net 6/6] gtp: add missing gtp_encap_disable_sock() in gtp_encap_enable()
by Taehee Yoo 02 Jul '19

02 Jul '19

If an invalid role is sent from user space, gtp_encap_enable() will fail. Then, it should call gtp_encap_disable_sock() but current code doesn't. It makes memory leak. Fixes: 91ed81f9abc7 ("gtp: support SGSN-side tunnels") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> --- drivers/net/gtp.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index b3ccac54e204..ecfe26215935 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -857,8 +857,13 @@ static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]) if (data[IFLA_GTP_ROLE]) { role = nla_get_u32(data[IFLA_GTP_ROLE]); - if (role > GTP_ROLE_SGSN) + if (role > GTP_ROLE_SGSN) { + if (sk0) + gtp_encap_disable_sock(sk0); + if (sk1u) + gtp_encap_disable_sock(sk1u); return -EINVAL; + } } gtp->sk0 = sk0; -- 2.17.1

1 0

[PATCH net 5/6] gtp: fix use-after-free in gtp_newlink()
by Taehee Yoo 02 Jul '19

02 Jul '19

Current gtp_newlink() could be called after unregister_pernet_subsys(). gtp_newlink() uses gtp_net but it can be destroyed by unregister_pernet_subsys(). So unregister_pernet_subsys() should be called after rtnl_link_unregister(). Test commands: #SHELL 1 while : do for i in {1..5} do ./gtp-link add gtp$i & done killall gtp-link done #SHELL 2 while : do modprobe -rv gtp done Splat looks like: [ 753.176631] BUG: KASAN: use-after-free in gtp_newlink+0x9b4/0xa5c [gtp] [ 753.177722] Read of size 8 at addr ffff8880d48f2458 by task gtp-link/7126 [ 753.179082] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G W 5.2.0-rc6+ #50 [ 753.185801] Call Trace: [ 753.186264] dump_stack+0x7c/0xbb [ 753.186863] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.187583] print_address_description+0xc7/0x240 [ 753.188382] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189097] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.189846] __kasan_report+0x12a/0x16f [ 753.190542] ? gtp_newlink+0x9b4/0xa5c [gtp] [ 753.191298] kasan_report+0xe/0x20 [ 753.191893] gtp_newlink+0x9b4/0xa5c [gtp] [ 753.192580] ? __netlink_ns_capable+0xc3/0xf0 [ 753.193370] __rtnl_newlink+0xb9f/0x11b0 [ ... ] [ 753.241201] Allocated by task 7186: [ 753.241844] save_stack+0x19/0x80 [ 753.242399] __kasan_kmalloc.constprop.3+0xa0/0xd0 [ 753.243192] __kmalloc+0x13e/0x300 [ 753.243764] ops_init+0xd6/0x350 [ 753.244314] register_pernet_operations+0x249/0x6f0 [ ... ] [ 753.251770] Freed by task 7178: [ 753.252288] save_stack+0x19/0x80 [ 753.252833] __kasan_slab_free+0x111/0x150 [ 753.253962] kfree+0xc7/0x280 [ 753.254509] ops_free_list.part.11+0x1c4/0x2d0 [ 753.255241] unregister_pernet_operations+0x262/0x390 [ ... ] [ 753.285883] list_add corruption. next->prev should be prev (ffff8880d48f2458), but was ffff8880d497d878. (next. [ 753.287241] ------------[ cut here ]------------ [ 753.287794] kernel BUG at lib/list_debug.c:25! [ 753.288364] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI [ 753.289099] CPU: 0 PID: 7126 Comm: gtp-link Tainted: G B W 5.2.0-rc6+ #50 [ 753.291036] RIP: 0010:__list_add_valid+0x74/0xd0 [ 753.291589] Code: 48 39 da 75 27 48 39 f5 74 36 48 39 dd 74 31 48 83 c4 08 b8 01 00 00 00 5b 5d c3 48 89 d9 48b [ 753.293779] RSP: 0018:ffff8880cae8f398 EFLAGS: 00010286 [ 753.294401] RAX: 0000000000000075 RBX: ffff8880d497d878 RCX: 0000000000000000 [ 753.296260] RDX: 0000000000000075 RSI: 0000000000000008 RDI: ffffed10195d1e69 [ 753.297070] RBP: ffff8880cd250ae0 R08: ffffed101b4bff21 R09: ffffed101b4bff21 [ 753.297899] R10: 0000000000000001 R11: ffffed101b4bff20 R12: ffff8880d497d878 [ 753.298703] R13: 0000000000000000 R14: ffff8880cd250ae0 R15: ffff8880d48f2458 [ 753.299564] FS: 00007f5f79805740(0000) GS:ffff8880da400000(0000) knlGS:0000000000000000 [ 753.300533] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 753.301231] CR2: 00007fe8c7ef4f10 CR3: 00000000b71a6006 CR4: 00000000000606f0 [ 753.302183] Call Trace: [ 753.302530] gtp_newlink+0x5f6/0xa5c [gtp] [ 753.303037] ? __netlink_ns_capable+0xc3/0xf0 [ 753.303576] __rtnl_newlink+0xb9f/0x11b0 [ 753.304092] ? rtnl_link_unregister+0x230/0x230 Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 52f35cbeb1dc..b3ccac54e204 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -1376,9 +1376,9 @@ late_initcall(gtp_init); static void __exit gtp_fini(void) { - unregister_pernet_subsys(&gtp_net_ops); genl_unregister_family(&gtp_genl_family); rtnl_link_unregister(&gtp_link_ops); + unregister_pernet_subsys(&gtp_net_ops); pr_info("GTP module unloaded\n"); } -- 2.17.1

1 0

[PATCH net 4/6] gtp: fix Illegal context switch in RCU read-side critical section.
by Taehee Yoo 02 Jul '19

02 Jul '19

ipv4_pdp_add() is called in RCU read-side critical section. So GFP_KERNEL should not be used in the function. This patch make ipv4_pdp_add() to use GFP_ATOMIC instead of GFP_KERNEL. Test commands: gtp-link add gtp1 & gtp-tunnel add gtp1 v1 100 200 1.1.1.1 2.2.2.2 Splat looks like: [ 130.618881] ============================= [ 130.626382] WARNING: suspicious RCU usage [ 130.626994] 5.2.0-rc6+ #50 Not tainted [ 130.627622] ----------------------------- [ 130.628223] ./include/linux/rcupdate.h:266 Illegal context switch in RCU read-side critical section! [ 130.629684] [ 130.629684] other info that might help us debug this: [ 130.629684] [ 130.631022] [ 130.631022] rcu_scheduler_active = 2, debug_locks = 1 [ 130.632136] 4 locks held by gtp-tunnel/1025: [ 130.632925] #0: 000000002b93c8b7 (cb_lock){++++}, at: genl_rcv+0x15/0x40 [ 130.634159] #1: 00000000f17bc999 (genl_mutex){+.+.}, at: genl_rcv_msg+0xfb/0x130 [ 130.635487] #2: 00000000c644ed8e (rtnl_mutex){+.+.}, at: gtp_genl_new_pdp+0x18c/0x1150 [gtp] [ 130.636936] #3: 0000000007a1cde7 (rcu_read_lock){....}, at: gtp_genl_new_pdp+0x187/0x1150 [gtp] [ 130.638348] [ 130.638348] stack backtrace: [ 130.639062] CPU: 1 PID: 1025 Comm: gtp-tunnel Not tainted 5.2.0-rc6+ #50 [ 130.641318] Call Trace: [ 130.641707] dump_stack+0x7c/0xbb [ 130.642252] ___might_sleep+0x2c0/0x3b0 [ 130.642862] kmem_cache_alloc_trace+0x1cd/0x2b0 [ 130.643591] gtp_genl_new_pdp+0x6c5/0x1150 [gtp] [ 130.644371] genl_family_rcv_msg+0x63a/0x1030 [ 130.645074] ? mutex_lock_io_nested+0x1090/0x1090 [ 130.645845] ? genl_unregister_family+0x630/0x630 [ 130.646592] ? debug_show_all_locks+0x2d0/0x2d0 [ 130.647293] ? check_flags.part.40+0x440/0x440 [ 130.648099] genl_rcv_msg+0xa3/0x130 [ ... ] Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 92ef777a757f..52f35cbeb1dc 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -959,7 +959,7 @@ static int ipv4_pdp_add(struct gtp_dev *gtp, struct sock *sk, } - pctx = kmalloc(sizeof(struct pdp_ctx), GFP_KERNEL); + pctx = kmalloc(sizeof(*pctx), GFP_ATOMIC); if (pctx == NULL) return -ENOMEM; -- 2.17.1

1 0

[PATCH net 3/6] gtp: remove duplicate code in gtp_dellink()
by Taehee Yoo 02 Jul '19

02 Jul '19

gtp_encap_disable() in gtp_dellink() is unnecessary because it will be called by unregister_netdevice(). unregister_netdevice() internally calls gtp_dev_uninit() by ->ndo_uninit(). And gtp_dev_uninit() calls gtp_encap_disable(). Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> --- drivers/net/gtp.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 5101f8c3c99c..92ef777a757f 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -694,7 +694,6 @@ static void gtp_dellink(struct net_device *dev, struct list_head *head) { struct gtp_dev *gtp = netdev_priv(dev); - gtp_encap_disable(gtp); gtp_hashtable_free(gtp); list_del_rcu(&gtp->list); unregister_netdevice_queue(dev, head); -- 2.17.1

1 0

[PATCH net 2/6] gtp: fix use-after-free in gtp_encap_destroy()
by Taehee Yoo 02 Jul '19

02 Jul '19

gtp_encap_destroy() is called twice. 1. When interface is deleted. 2. When udp socket is destroyed. either gtp->sk0 or gtp->sk1u could be freed by sock_put() in gtp_encap_destroy(). so, when gtp_encap_destroy() is called again, it would uses freed sk pointer. patch makes gtp_encap_destroy() to set either gtp->sk0 or gtp->sk1u to null. in addition, both gtp->sk0 and gtp->sk1u pointer are protected by rtnl_lock. so, rtnl_lock() is added. Test command: gtp-link add gtp1 & killall gtp-link ip link del gtp1 Splat looks like: [ 83.182767] BUG: KASAN: use-after-free in __lock_acquire+0x3a20/0x46a0 [ 83.184128] Read of size 8 at addr ffff8880cc7d5360 by task ip/1008 [ 83.185567] CPU: 1 PID: 1008 Comm: ip Not tainted 5.2.0-rc6+ #50 [ 83.188469] Call Trace: [ ... ] [ 83.200126] lock_acquire+0x141/0x380 [ 83.200575] ? lock_sock_nested+0x3a/0xf0 [ 83.201069] _raw_spin_lock_bh+0x38/0x70 [ 83.201551] ? lock_sock_nested+0x3a/0xf0 [ 83.202044] lock_sock_nested+0x3a/0xf0 [ 83.202520] gtp_encap_destroy+0x18/0xe0 [gtp] [ 83.203065] gtp_encap_disable.isra.14+0x13/0x50 [gtp] [ 83.203687] gtp_dellink+0x56/0x170 [gtp] [ 83.204190] rtnl_delete_link+0xb4/0x100 [ ... ] [ 83.236513] Allocated by task 976: [ 83.236925] save_stack+0x19/0x80 [ 83.237332] __kasan_kmalloc.constprop.3+0xa0/0xd0 [ 83.237894] kmem_cache_alloc+0xd8/0x280 [ 83.238360] sk_prot_alloc.isra.42+0x50/0x200 [ 83.238874] sk_alloc+0x32/0x940 [ 83.239264] inet_create+0x283/0xc20 [ 83.239684] __sock_create+0x2dd/0x540 [ 83.240136] __sys_socket+0xca/0x1a0 [ 83.240550] __x64_sys_socket+0x6f/0xb0 [ 83.240998] do_syscall_64+0x9c/0x450 [ 83.241466] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 83.242061] [ 83.242249] Freed by task 0: [ 83.242616] save_stack+0x19/0x80 [ 83.243013] __kasan_slab_free+0x111/0x150 [ 83.243498] kmem_cache_free+0x89/0x250 [ 83.244444] __sk_destruct+0x38f/0x5a0 [ 83.245366] rcu_core+0x7e9/0x1c20 [ 83.245766] __do_softirq+0x213/0x8fa Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> --- drivers/net/gtp.c | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 939da5442f65..5101f8c3c99c 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -285,13 +285,17 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb) return gtp_rx(pctx, skb, hdrlen, gtp->role); } -static void gtp_encap_destroy(struct sock *sk) +static void __gtp_encap_destroy(struct sock *sk) { struct gtp_dev *gtp; lock_sock(sk); gtp = sk->sk_user_data; if (gtp) { + if (gtp->sk0 == sk) + gtp->sk0 = NULL; + else + gtp->sk1u = NULL; udp_sk(sk)->encap_type = 0; rcu_assign_sk_user_data(sk, NULL); sock_put(sk); @@ -299,12 +303,19 @@ static void gtp_encap_destroy(struct sock *sk) release_sock(sk); } +static void gtp_encap_destroy(struct sock *sk) +{ + rtnl_lock(); + __gtp_encap_destroy(sk); + rtnl_unlock(); +} + static void gtp_encap_disable_sock(struct sock *sk) { if (!sk) return; - gtp_encap_destroy(sk); + __gtp_encap_destroy(sk); } static void gtp_encap_disable(struct gtp_dev *gtp) @@ -1038,6 +1049,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) return -EINVAL; } + rtnl_lock(); rcu_read_lock(); gtp = gtp_find_dev(sock_net(skb->sk), info->attrs); @@ -1062,6 +1074,7 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) out_unlock: rcu_read_unlock(); + rtnl_unlock(); return err; } -- 2.17.1

1 0

[PATCH net 1/6] gtp: fix suspicious RCU usage
by Taehee Yoo 02 Jul '19

02 Jul '19

gtp_encap_enable_socket() and gtp_encap_destroy() are not protected by rcu_read_lock(). and it's not safe to write sk->sk_user_data. This patch make these functions to use lock_sock() instead of rcu_dereference_sk_user_data(). Test commands: gtp-link add gtp1 Splat looks like: [ 83.238315] ============================= [ 83.239127] WARNING: suspicious RCU usage [ 83.239702] 5.2.0-rc6+ #49 Not tainted [ 83.240268] ----------------------------- [ 83.241205] drivers/net/gtp.c:799 suspicious rcu_dereference_check() usage! [ 83.243828] [ 83.243828] other info that might help us debug this: [ 83.243828] [ 83.246325] [ 83.246325] rcu_scheduler_active = 2, debug_locks = 1 [ 83.247314] 1 lock held by gtp-link/1008: [ 83.248523] #0: 0000000017772c7f (rtnl_mutex){+.+.}, at: __rtnl_newlink+0x5f5/0x11b0 [ 83.251503] [ 83.251503] stack backtrace: [ 83.252173] CPU: 0 PID: 1008 Comm: gtp-link Not tainted 5.2.0-rc6+ #49 [ 83.253271] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 83.254562] Call Trace: [ 83.254995] dump_stack+0x7c/0xbb [ 83.255567] gtp_encap_enable_socket+0x2df/0x360 [gtp] [ 83.256415] ? gtp_find_dev+0x1a0/0x1a0 [gtp] [ 83.257161] ? memset+0x1f/0x40 [ 83.257843] gtp_newlink+0x90/0xa21 [gtp] [ 83.258497] ? __netlink_ns_capable+0xc3/0xf0 [ 83.259260] __rtnl_newlink+0xb9f/0x11b0 [ 83.260022] ? rtnl_link_unregister+0x230/0x230 [ ... ] Fixes: 1e3a3abd8b28 ("gtp: make GTP sockets in gtp_newlink optional") Signed-off-by: Taehee Yoo <ap420073(a)gmail.com> --- drivers/net/gtp.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index fc45b749db46..939da5442f65 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -289,12 +289,14 @@ static void gtp_encap_destroy(struct sock *sk) { struct gtp_dev *gtp; - gtp = rcu_dereference_sk_user_data(sk); + lock_sock(sk); + gtp = sk->sk_user_data; if (gtp) { udp_sk(sk)->encap_type = 0; rcu_assign_sk_user_data(sk, NULL); sock_put(sk); } + release_sock(sk); } static void gtp_encap_disable_sock(struct sock *sk) @@ -796,7 +798,8 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, goto out_sock; } - if (rcu_dereference_sk_user_data(sock->sk)) { + lock_sock(sock->sk); + if (sock->sk->sk_user_data) { sk = ERR_PTR(-EBUSY); goto out_sock; } @@ -812,6 +815,7 @@ static struct sock *gtp_encap_enable_socket(int fd, int type, setup_udp_tunnel_sock(sock_net(sock->sk), sock, &tuncfg); out_sock: + release_sock(sock->sk); sockfd_put(sock); return sk; } -- 2.17.1

1 0

high ksoftirqd while using module gtp?
by Tony Clark 19 Jun '19

19 Jun '19

Dear All, I've been using the GTP-U kernel module to communicate with a P-GW. Running Fedora 29, kernel 4.18.16-300.fc29.x86_64. At high traffic levels through the GTP-U tunnel I see the performance degrade as 100% CPU is consumed by a single ksoftirqd process. It is running on a multi-cpu machine and as far as I can tell the load is evenly spread across the cpus (ie either manually via smp_affinity, or even irqbalance, checking /proc/interrupts so forth.). Has anyone else experienced this? Is there any particular area you could recommend I investigate to find the root cause of this bottleneck, as i'm starting to scratch my head where to look next... Thanks in advance Tony ---- FYI modinfo gtp filename: /lib/modules/4.18.16-300.fc29.x86_64/kernel/drivers/net/gtp.ko.xz alias: net-pf-16-proto-16-family-gtp alias: rtnl-link-gtp description: Interface driver for GTP encapsulated traffic author: Harald Welte <hwelte(a)sysmocom.de> license: GPL depends: udp_tunnel retpoline: Y intree: Y name: gtp vermagic: 4.18.16-300.fc29.x86_64 SMP mod_unload modinfo udp_tunnel filename: /lib/modules/4.18.16-300.fc29.x86_64/kernel/net/ipv4/udp_tunnel.ko.xz license: GPL depends: retpoline: Y intree: Y name: udp_tunnel vermagic: 4.18.16-300.fc29.x86_64 SMP mod_unload

1 0

[OSMO_PCU] EGPRS
by Andrey Lavrukhin 01 Apr '19

01 Apr '19

Hi Now I'm trying osmo-pcu on octasic-phy. GPRS worked, but I want to get EGPRS. I set 'gprs mode none' in openbsc.cfg and 'egprs only' in osmo-pcu.cfg. And got next error: "Not accepting non-EGPRS phone in EGPRS-only mode". As I found, it is like bug #3499. What does this error depend on and how can it be fixed? How can I test EGPRS? Thanks, Andrey Lavrukhin

3 4

Problem with the sgsnemu of OsmoGGSN
by ArthurLRJ＠outlook.com 28 Mar '19

28 Mar '19

Dear all I am facting the following problems and hope you can help me: - At present, I have two GGSN nodes(such as A and B), I also hava a sgsnemu node which is connected to GGSN-A and hold a PDP context, now I want to connect this PDP context to GGSN-B to simulate the handover of mobile devices between different base stations. How can I do it? - And I I wonder if sgsnemu can generate “Update PDP Context Request” message. Thanks and regards Arthur

3 2

New osmocom CNI versions released
by Harald Welte 25 Jan '19

25 Jan '19

Hi! Just in case not every subscriber here is following the osmocom.org RSS feed: At http://osmocom.org/news/104 we have just announced a bunch of new tagged versions of the Osmocom CNI (cellular network infrastructure) software stack. See the link above for all related details, and links to changelogs. The "network:osmocom:latest" feed already contains builds for Debian 8 and 9, as well as Ubuntu 16.04, 16.10, 17.04, 17.10 and 18.04. Raspbian 9 + Ubuntu 18.10 are currently building, see https://build.opensuse.org/project/monitor/network:osmocom:latest I'd like to thank everyone who has contributed in some way to those new versions. That's primarily the great team of developers, but also everyone helping with testing, bug reports, bug squashing, documentation, etc. Happy hacking, Harald -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

Security Issue
by Dhiraj Mishra 12 Jan '19

12 Jan '19

Hi List, I found a security issue in libgtpnl osmocom project, could some one please let me know where to submit such bugs ? Thank you

2 1

OsmoDevCon 2019 registration
by Harald Welte 31 Dec '18

31 Dec '18

Dear fellow Osmocom developers, I'm a bit surprised to notice that not more people have signed up for OsmoDevCon 2019. I guess it was mostly an oversight when the date was originally announced, and not a lack of interest? ;) All details about the event are available at the related wiki page at: https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019 Please enter your name at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCon2019#Requested in case you would like to attend. Registering early allows proper planning. Thanks! Looking forward to meeting old and new Osmocom developers in April 2019. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Question about basic usage of GTP kernel module
by Michał Siuda 07 Dec '18

07 Dec '18

Hi, I'm trying to build a simple node that would encap/decap between IP and GTP in the user plane. For this I have been using gtp-link and gtp-tunnel tools of the libgtpnl, but with no luck so far. Could anyone please review my setup and let me know what I'm doing wrong? Topology: node1 - DUT, I would like to be able to send a ping from this node such that it is encapsulated into GTP tunnel towards node2. 2 interfaces: - ens6 - represents interface towards MS, has address 20.1.1.1/24 - ens7 - represents interface towards GGSN, has address 10.1.1.1/24 node2 Just a single interface towards node1, address 10.1.1.2/24 Test: On node2, I'm following these steps: - creating a GTP device: # ./gtp-link add gtp-u - adding a GTP tunnel: # ./gtp-tunnel add gtp-u v1 20 10 20.1.1.1 10.1.1.2 # ./gtp-tunnel list version 1 tei 20/10 ms_addr 20.1.1.1 sgsn_addr 10.1.1.2 - adding a route to an address representing APN to use the GTP device: # ip route add 8.8.8.8 src 20.1.1.1 dev gtp-u - Trying to ping 8.8.8.8 Result: I was expecting to see ECMP packets to 8.8.8.8 to be sent out via ens7 towards node2 and encapsulated in GTP. However, I can only see that these packets appear on the gtp-u interface, but are not forwarded. Looking at interface stats on gtp-u, I can see that the ping hits "tx_error" counter. Is there anything I'm missing here? Are any parameters wrong? Or am I misunderstanding the function of the GTP-U kernel support entirely? Any help would be appreciated. Thanks, Michael

1 0

Can you tell me how to compile and install libgtpnl?
by luo 06 Dec '18

06 Dec '18

hello,Please forgive my childishness,Can you tell me how to compile and install libgtpnl?thanks I saw that you wrote the libgtpnl project on github, but there is no readme above.

2 1

[BUG][OSMO-PCU][OSMO-SGSN] GPRS and EGPRS attach procedure is not working with Kirin Modem phones
by Bipin Jaiswal 06 Dec '18

06 Dec '18

Hi, We are using Honor 7X mobile phone with Huawei Kirin modem and observed that GPRS and EGPRS attach is not working with Huawei Kirin Modem phones. There is no issue observed from OSMO-PCU. it seems either Huawei Kirin modem issue or OSMO-SGSN issue. Please check below analysis for this issue. 1- UE send attach request with IMSI and invalid MCC and MNC to SGSN. 2- SGSN send Identity Request with IMEI to UE. 3- UE responded Identity Response with IMEI to SGSN. 4- SGSN sends ATTACH ACCEPT message to SGSN with new PMTSI but UE is not responding ATTACH COMPLETE message to SGSN and resend ATTACH REQUEST message to SGSN. 5- SO SGSN re transmit ATTACH ACCEPT message to UE and after max number of re transmission , SGSN is release UE MM context. It seems that UE is not accepting ATTACH ACCEPT message. We also observed that Huawei Kirin UE is sending wrong LLC data to SGSN. UE had set more bit in RLC LME header and send invalid LLC data with 0x2B. So OSMO-PCU had forward this data to SGSN because more bit is set and SGSN is complaining LLC error for this LLC data. Please look into this issue or let us know if we have fix for this issue. Thanks, Bipin Jaiswal

2 1

[ASK version support GPRS for USRP ]
by Dzakwan Falih 31 Oct '18

31 Oct '18

Hi semua, saya memiliki pertanyaan: 1. Versi berapa yang cocok untuk membangun layanan GPRS.? 2. bagaimana jika saya ingin menginstall GPRS pada satu host bagaimana contoh konfigurasinya, saya sudah membaca manualnya kurang paham. . Hormat Saya, [photo] Muhammad Dzakwan Falih dzakwanfalih.wordpress.com<http://dzakwanfalih.wordpress.com> [https://s3.amazonaws.com/images.wisestamp.com/social_icons/square/facebook.…]<http://www.facebook.com/dzakwan.pilot> [https://s3.amazonaws.com/images.wisestamp.com/social_icons/square/linkedin.…] <http://www.linkedin.com/in/muhammad-dzakwan-falih-2ab30612a/> [https://s3.amazonaws.com/images.wisestamp.com/social_icons/square/twitter.p…] <http://twitter.com/Dz4kwan> [https://s3.amazonaws.com/images.wisestamp.com/social_icons/square/instagram…] <http://www.instagram.com/supernode/>

2 1

[ASK : Version for build GPRS ]
by Dzakwan Falih 29 Oct '18

29 Oct '18

Sorry, I made a mistake in posting. to be honest I am first time using the mailing list Hi all, I have a question: 1. how many Versions suitable for constructing GPRS service.? 2. What if I want to install GPRS on a single host configuration, examples of how I've been reading the manual is less familiar. Hormat Saya, [photo] Muhammad Dzakwan Falih dzakwanfalih.wordpress.com<http://dzakwanfalih.wordpress.com> [https://s3.amazonaws.com/images.wisestamp.com/social_icons/square/facebook.…]<http://www.facebook.com/dzakwan.pilot> [https://s3.amazonaws.com/images.wisestamp.com/social_icons/square/linkedin.…] <http://www.linkedin.com/in/muhammad-dzakwan-falih-2ab30612a/> [https://s3.amazonaws.com/images.wisestamp.com/social_icons/square/twitter.p…] <http://twitter.com/Dz4kwan> [https://s3.amazonaws.com/images.wisestamp.com/social_icons/square/instagram…] <http://www.instagram.com/supernode/>

1 0

OsmoDevCon 2019 date poll
by Harald Welte 24 Oct '18

24 Oct '18

Dear all, I would like to get your input as to when we should schedule OsmoDevCon 2019. NOTE: OsmoDevCon is our "for developers by developers" event, not to be confused with OsmoCon, our public conference. If we want to stay with the usual "Friday through Monday in April" arrangement, we have the following options: April 05-08, 2019 April 12-15, 2019 April 26-29, 2019 The one missing weekend in the list above is the easter weekend, which is probably a good idea to exclude as flights and hotels are more expensive during that time, and people might have other plans during holidays. I would like to invite anyone planning to attend the Osmocom Developer Conference 2019 to participate in the poll at https://dudle.inf.tu-dresden.de/OsmoDevCon2019/ to state their availability/preference. The Dudle only shows the first day of the four days of OsmoDevCon. Looking forward to your feedback so we can settle on a date soon. Thanks! Kind regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

OsmoGGSN - Centos 7 Support
by Duleep Thilakarathne 16 Oct '18

16 Oct '18

Hi i am old user of openGGSN and planned to test OsmoGGSN. is it possible to compile osmoGGSN in Centos 7. is there any limitation. regards DT

2 1

Problem with SGSN Location Update Reject during UE attach
by Lam Ngoc Tuan 16 Oct '18

16 Oct '18

Dear all We are facing the following problem and hope you can help us: - We use OSMO as UMTS core emulation, working with our real NodeB - During UE attach procedure we see from SGSN "Location Update Reject" and afterthat UE is released. - We do the comparison test with real UMTS core and our real NodeB, here it works properly, UE can attach successful. We assume there is some Osmo configuration problem but we have not found the root cause, we very appreciate if you can take a look and give us some advice. Here is the current message flow of UE attach 10.2.9.200 10.2.9.139 RANAP 170 (RUA) InitialUE-Message (DTAP) (MM) Location Updating Request 10.2.9.139 10.2.9.200 RANAP 158 SACK (RUA) DirectTransfer (DTAP) (MM) Authentication Request 10.2.9.200 10.2.9.139 RANAP 222 SACK (RUA) InitialUE-Message (DTAP) (GMM) Attach Request 10.2.9.139 10.2.9.200 RANAP 122 SACK (RUA) DirectTransfer (DTAP) (GMM) Identity Request 10.2.9.200 10.2.9.139 RANAP 118 (RUA) DirectTransfer (DTAP) (MM) Authentication Failure 10.2.9.139 10.2.9.200 RANAP 158 SACK (RUA) DirectTransfer (DTAP) (MM) Authentication Request 10.2.9.200 10.2.9.139 RANAP 154 SACK (RUA) DirectTransfer (DTAP) (GMM) Identity Response 10.2.9.139 10.2.9.200 RANAP 162 SACK (RUA) DirectTransfer (DTAP) (GMM) Authentication and Ciphering Req 10.2.9.200 10.2.9.139 RANAP 110 (RUA) DirectTransfer (DTAP) (MM) Authentication Response 10.2.9.139 10.2.9.200 RANAP 138 SACK (RUA) SecurityModeCommand 10.2.9.200 10.2.9.139 RANAP 98 (RUA) SecurityModeComplete 10.2.9.139 10.2.9.200 RANAP 122 SACK (RUA) CommonID 10.2.9.200 10.2.9.139 RANAP 166 SACK (RUA) DirectTransfer (DTAP) (GMM) Authentication and Ciphering Resp 10.2.9.139 10.2.9.200 RANAP 134 SACK (RUA) DirectTransfer (DTAP) (MM) Location Updating Accept 10.2.9.139 10.2.9.200 RANAP 122 (RUA) SecurityModeCommand --> 10.2.9.139 10.2.9.200 RANAP 106 (RUA) DirectTransfer (DTAP) (MM) Location Updating Reject 10.2.9.139 10.2.9.200 RANAP 102 (RUA) Iu-ReleaseCommand 10.2.9.200 10.2.9.139 RANAP 114 SACK (RUA) Iu-ReleaseComplete 10.2.9.200 10.2.9.139 RANAP 102 (RUA) SecurityModeReject 10.2.9.200 10.2.9.139 RANAP 102 (RUA) Iu-ReleaseRequest 10.2.9.139 10.2.9.200 RANAP 118 SACK (RUA) Iu-ReleaseCommand 10.2.9.200 10.2.9.139 RANAP 114 SACK (RUA) Iu-ReleaseComplete Thanks and regards Tuan Lam

2 4

Build failed in Jenkins: master-osmo-sgsn
by Harald Welte 24 Sep '18

24 Sep '18

Dear fellow Osmocom developers, During the past hours, we've been experiencing master-osmo-sgsn build failures. It coincides with some libosmocore.git vty change merge, it would be great if people working on this and/or osmo-sgsn can have a look. Thanks! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

UE Unable to Obtain IP Address | Flooding error logs in OSMO-PCU
by Ron 24 Aug '18

24 Aug '18

Hi Community, We tried to used the GPRS capability of OSMOCOM. Installation and configuration were based in the URL provided below: https://osmocom.org/projects/cellular-infrastructure/wiki/Osmocom_Network_I… We successfully installed the needed elements to run GPRS and we were able to run the following: osmo-msc osmo-stp osmo-hnbgw (optional) osmo-ggsn osmo-sgsn osmo-mgw osmo-bsc osmo-trx-uhd osmo-hlr osmo-pcu UE were able to camp but IP Address is unavailable (checked it under Settings > About Phone > Status) No session / request coming in the OSMO-SGSN. We are also flooded with this log in OSMO-PCU: <000c> gprs_bssgp_pcu.cpp:848 Sending unblock on BVCI 1800 <000c> gprs_bssgp_bss.c:274 BSSGP (BVCI=1800) Tx BVC-BLOCK <000c> gprs_bssgp.c:288 Cell 001-01-23-0 CI 0 on BVCI 1800 <000c> gprs_bssgp_bss.c:294 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <000c> gprs_bssgp.c:550 BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:354 Rx BSSGP BVCI=0 (SIGN) PDU type BVC-UNBLOCK unknown <000c> gprs_bssgp_util.c:238 BSSGP BVCI=0 Tx STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:304 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <000c> gprs_bssgp_pcu.cpp:848 Sending unblock on BVCI 1800 <000c> gprs_bssgp_bss.c:274 BSSGP (BVCI=1800) Tx BVC-BLOCK <000c> gprs_bssgp.c:288 Cell 001-01-23-0 CI 0 on BVCI 1800 <000c> gprs_bssgp_bss.c:294 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <000c> gprs_bssgp.c:550 BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:354 Rx BSSGP BVCI=0 (SIGN) PDU type BVC-UNBLOCK unknown <000c> gprs_bssgp_util.c:238 BSSGP BVCI=0 Tx STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:304 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <000c> gprs_bssgp_pcu.cpp:848 Sending unblock on BVCI 1800 <000c> gprs_bssgp_bss.c:274 BSSGP (BVCI=1800) Tx BVC-BLOCK <000c> gprs_bssgp.c:288 Cell 001-01-23-0 CI 0 on BVCI 1800 <000c> gprs_bssgp_bss.c:294 BSSGP (BVCI=1800) Tx BVC-RESET CAUSE=O&M intervention <000c> gprs_bssgp.c:550 BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:354 Rx BSSGP BVCI=0 (SIGN) PDU type BVC-UNBLOCK unknown <000c> gprs_bssgp_util.c:238 BSSGP BVCI=0 Tx STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:304 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK Any suggestion / comments what seems to be the problem with our setup? TIA. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

2 2

OsmoCon 2018 draft schedule announced
by Harald Welte 16 Aug '18

16 Aug '18

Dear Osmocom community, the first schedule of the 2018 incarnation of OsmoCon 2018 has been announced, see http://osmocom.org/news/99 for the announcment and https://pretalx.sysmocom.de/osmocon2018/schedule/ for the actual schedule. At OsmoCon, we are not targetting developers, but more the wider community and Osmocom users. It would be great to meet many of you and hear more about your relation to Osmocom. Tickets are available from https://pretix.sysmocom.de/sysmocom/osmocon2018/, and until August 31st the early bird discount still applies. For those with a community / "just for fun" background and no employer that would cover the ticket, we have a number of subsidized community discount vouchers available. See the OsmoCon 2018 wiki page at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 for more information. Looking forward to meeting as many of you as possible in roughly two months from now, Harald Welte -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

SGSN TTCN3 update
by Alexander Couzens 07 Aug '18

07 Aug '18

Hi, I've pushed my SGSN Branch "attach fsm" where I reworked the Attach Request into an FSM together with a TTCN branch (replacing unit tests) to gerrit. When both branches applied upstream, we're up to 42 tests. However these 4 test cases are still open: pass->FAIL SGSN_Tests.TC_attach_pdp_act_deact_mt_t3395_expire => TEID wrong. Cleaning up the internal SGSN seems to fail. xfail SGSN_Tests.TC_attach_gsup_lu_timeout => HLR interaction xfail SGSN_Tests.TC_attach_gsup_lu_reject => HLR interaction xfail SGSN_Tests.TC_attach_second_attempt => HLR interaction Best, lynxis -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu mobile: +4915123277221 gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

1 0

[PATCH net-next 0/2] constify nla_policy
by Stephen Hemminger 18 Jul '18

18 Jul '18

Almost all places that use nla_policy declare it const. A couple of drivers didn't but that is fixable. Stephen Hemminger (2): nbd: constify nla_policy gtp: constify nla_policy drivers/block/nbd.c | 6 +++--- drivers/net/gtp.c | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) -- 2.18.0

1 2

Data Rate of EGPRS is Too Low
by XINKE ZHANG 28 Jun '18

28 Jun '18

Hi all, I have set up the EGPRS network using software bundles (osmo-nitb + osmo-bts-trx + osmo-trx + osmo-pcu + osmo-sgsn + openggsn) based on the USRP B210 platform. Now the cell phone can connect to the EGPRS network, but the network is not stable and the data rate is too low (only about 8kbs). Is this data rate correct? If not, could you pls send me some working config files? Thank you. Best Regards, Xinke

3 8

GPRS doesn't work
by weng alexa 25 Jun '18

25 Jun '18

Hi all, I set up the EGPRS network using software bundles (osmo-bts-trx + osmo-trx + osmo-pcu + osmo-sgsn + osmo-ggsn + osmo-bsc + osmo-msc + osmo-hlr) based on the USRP B210 platform. Now the cell phone can connect to the EGPRS network, but the phone has no IP address. All the config files are in the attachments, could you help we find what's wrong? Thanks sincerely All of the osmo-pcu's log is like the below: 20180625043250233 DRLCMACMEAS <0007> gprs_rlcmac_meas.cpp:183 DL Bandwitdh of IMSI=xxxxxxxxxxxxxxxx/ TLLI=0xb6ccf813: 190 KBits/s 20180625043250233 DTBFDL <0009> tbf_dl.cpp:863 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Scheduled Ack/Nack polling on FN=2035509, TS=4 20180625043250334 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250334 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250353 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250353 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250353 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250353 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250371 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250371 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250371 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250371 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250389 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250389 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250389 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250389 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250408 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250408 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250408 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250408 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250431 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250431 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250431 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250431 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250449 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250449 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250449 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250449 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250468 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250468 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250468 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250468 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250472 DTBF <0008> tbf_dl.cpp:648 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) changes poll state from GPRS_RLCMAC_POLL_SCHED to GPRS_RLCMAC_POLL_NONE 20180625043250472 DTBF <0008> pdch.cpp:407 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) RX: [PCU <- BTS] Packet Downlink Ack/Nack 20180625043250491 DTBFDL <0009> tbf_dl.cpp:863 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Scheduled Ack/Nack polling on FN=2035566, TS=4 20180625043250588 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250588 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250611 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250611 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250611 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250611 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250629 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250629 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250629 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250630 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250648 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250648 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250648 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250648 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250671 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250671 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250671 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250671 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250690 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250690 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250690 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250690 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250708 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250708 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250708 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250708 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250731 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250731 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250731 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250731 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250737 DTBF <0008> tbf_dl.cpp:648 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) changes poll state from GPRS_RLCMAC_POLL_SCHED to GPRS_RLCMAC_POLL_NONE 20180625043250737 DTBF <0008> pdch.cpp:407 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) RX: [PCU <- BTS] Packet Downlink Ack/Nack 20180625043250750 DTBFDL <0009> tbf_dl.cpp:863 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Scheduled Ack/Nack polling on FN=2035622, TS=4 20180625043250851 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250851 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250880 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250880 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250880 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250880 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250888 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250888 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250888 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250888 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250911 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250911 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250911 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250911 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250930 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250930 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250930 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250930 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250948 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250948 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250948 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250948 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043250971 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043250971 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043250971 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043250971 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043251009 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043251010 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043251010 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043251010 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043251010 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043251010 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043251010 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043251010 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043251011 DTBF <0008> tbf_dl.cpp:648 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) changes poll state from GPRS_RLCMAC_POLL_SCHED to GPRS_RLCMAC_POLL_NONE 20180625043251011 DTBF <0008> pdch.cpp:407 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) RX: [PCU <- BTS] Packet Downlink Ack/Nack 20180625043251031 DTBFDL <0009> tbf_dl.cpp:863 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Scheduled Ack/Nack polling on FN=2035683, TS=4 20180625043251128 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043251128 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043251151 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043251151 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043251151 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043251151 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043251170 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043251170 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043251170 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043251170 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043251188 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043251188 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043251188 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043251188 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043251211 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043251211 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043251211 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043251211 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043251230 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043251230 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043251230 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043251230 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043251248 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043251248 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043251248 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043251248 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043251271 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 2 (first control TS 4) 20180625043251271 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 3 (first control TS 4) 20180625043251271 DTBF <0008> tbf.cpp:718 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling is already scheduled 20180625043251271 DTBF <0008> tbf.cpp:714 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) Polling cannot be scheduled in this TS 5 (first control TS 4) 20180625043251272 DTBF <0008> tbf_dl.cpp:648 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) changes poll state from GPRS_RLCMAC_POLL_SCHED to GPRS_RLCMAC_POLL_NONE 20180625043251272 DTBF <0008> pdch.cpp:407 TBF(TFI=0 TLLI=0xb6ccf813 DIR=DL STATE=FLOW) RX: [PCU <- BTS] Packet Downlink Ack/Nack 20180625043251290 DRLCMACMEAS <0007> gprs_rlcmac_meas.cpp:183 DL Bandwitdh of IMSI=xxxxxxxxxxxxxxxxxx/ TLLI=0xb6ccf813: 186 KBits/s Part of the osmo-sgsn's log is shown below: 20180625042017231 DMM <0002> gprs_gmm.c:1272 MM(---/ffffffff) -> GMM ATTACH REQUEST MI(4140627987) type="GPRS attach" 20180625042017231 DMM <0002> gprs_sgsn.c:237 MM(/00000000) Allocated with GEA0 cipher. 20180625042017231 DLGLOBAL <001d> rate_ctr.c:88 validating counter group 0x558216d5ee00(sgsn:mmctx) with 11 counters 20180625042017233 DMM <0002> gprs_gmm.c:556 MM(/e35372d8) <- GPRS IDENTITY REQUEST: mi_type=IMEI 20180625042018409 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042018409 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x8b6c20 CMD=UI DATA 20180625042018410 DMM <0002> gprs_gmm.c:1195 MM(/e35372d8) -> GMM IDENTITY RESPONSE: MI(IMEI)=866049037683470 20180625042018410 DMM <0002> gprs_gmm.c:556 MM(/e35372d8) <- GPRS IDENTITY REQUEST: mi_type=IMSI 20180625042019133 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042019133 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0xa77256 CMD=UI DATA 20180625042019133 DMM <0002> gprs_gmm.c:1195 MM(/e35372d8) -> GMM IDENTITY RESPONSE: MI(IMSI)=xxxxxxxxxxxxxxx 20180625042019133 DMM <0002> sgsn_auth.c:161 MM(xxxxxxxxxxxxxxx/e35372d8) Requesting authorization 20180625042019133 DMM <0002> sgsn_auth.c:220 MM(xxxxxxxxxxxxxxx/e35372d8) Updating authorization (unknown -> accepted) 20180625042019133 DMM <0002> sgsn_auth.c:249 MM(xxxxxxxxxxxxxxx/e35372d8) Got authorization update: state unknown -> accepted 20180625042019133 DMM <0002> gprs_gmm.c:1119 MM(xxxxxxxxxxxxxxx/e35372d8) Authorized, continuing procedure, IMSI=xxxxxxxxxxxxxxx 20180625042019133 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042024027 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042024483 DGPRS <000f> gprs_sgsn.c:912 Checking for inactive LLMEs, time = 341 20180625042024615 DLGSUP <0027> gsup_client.c:244 GSUP ping callback (connected, got PONG) 20180625042024615 DLGSUP <0027> gsup_client.c:264 GSUP sending PING 20180625042024615 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042024615 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042024615 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042024615 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042024615 DLINP <001f> input/ipa.c:138 127.0.0.1:4222 connected read 20180625042024615 DLINP <001f> input/ipa.c:56 127.0.0.1:4222 message received 20180625042024615 DLGSUP <0027> gsup_client.c:201 GSUP receiving PONG 20180625042025134 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042031136 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042034027 DNS <0010> gprs_ns.c:638 NSEI=1800 Timer expired in mode tns-test (30 seconds) 20180625042034027 DNS <0010> gprs_ns.c:571 NSEI=1800 Tx NS ALIVE (NSVCI=1800) 20180625042034027 DNS <0010> gprs_ns.c:610 NSEI=1800 Starting timer in mode tns-alive (3 seconds) 20180625042034027 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042034028 DNS <0010> gprs_ns.c:584 NSEI=1800 Tx NS ALIVE_ACK (NSVCI=1800) 20180625042034028 DNS <0010> gprs_ns.c:610 NSEI=1800 Starting timer in mode tns-test (30 seconds) 20180625042037138 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042037889 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042037889 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x5b3c8d CMD=UI DATA 20180625042037889 DMM <0002> gprs_gmm.c:1272 MM(xxxxxxxxxxxxxxx/e35372d8) -> GMM ATTACH REQUEST MI(4140627987) type="GPRS attach" 20180625042037889 DMM <0002> gprs_gmm.c:228 MM(xxxxxxxxxxxxxxx/e35372d8) Starting MM timer 3350 while old timer 3350 pending 20180625042037889 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042043889 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042044027 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042044616 DLGSUP <0027> gsup_client.c:244 GSUP ping callback (connected, got PONG) 20180625042044616 DLGSUP <0027> gsup_client.c:264 GSUP sending PING 20180625042044616 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042044616 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042044616 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042044616 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042044616 DLINP <001f> input/ipa.c:138 127.0.0.1:4222 connected read 20180625042044616 DLINP <001f> input/ipa.c:56 127.0.0.1:4222 message received 20180625042044616 DLGSUP <0027> gsup_client.c:201 GSUP receiving PONG 20180625042047034 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042047034 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x75dfce CMD=UI DATA 20180625042047034 DMM <0002> gprs_gmm.c:1272 MM(xxxxxxxxxxxxxxx/e35372d8) -> GMM ATTACH REQUEST MI(4140627987) type="GPRS attach" 20180625042047034 DMM <0002> gprs_gmm.c:228 MM(xxxxxxxxxxxxxxx/e35372d8) Starting MM timer 3350 while old timer 3350 pending 20180625042047034 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042053036 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042054028 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042054484 DGPRS <000f> gprs_sgsn.c:912 Checking for inactive LLMEs, time = 371 20180625042059038 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042102113 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042102113 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x06fa0b CMD=UI DATA 20180625042102113 DMM <0002> gprs_gmm.c:1272 MM(xxxxxxxxxxxxxxx/e35372d8) -> GMM ATTACH REQUEST MI(4140627987) type="GPRS attach" 20180625042102113 DMM <0002> gprs_gmm.c:228 MM(xxxxxxxxxxxxxxx/e35372d8) Starting MM timer 3350 while old timer 3350 pending 20180625042102113 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042104028 DNS <0010> gprs_ns.c:638 NSEI=1800 Timer expired in mode tns-test (30 seconds) 20180625042104028 DNS <0010> gprs_ns.c:571 NSEI=1800 Tx NS ALIVE (NSVCI=1800) 20180625042104028 DNS <0010> gprs_ns.c:610 NSEI=1800 Starting timer in mode tns-alive (3 seconds) 20180625042104028 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042104028 DNS <0010> gprs_ns.c:584 NSEI=1800 Tx NS ALIVE_ACK (NSVCI=1800) 20180625042104028 DNS <0010> gprs_ns.c:610 NSEI=1800 Starting timer in mode tns-test (30 seconds) 20180625042104617 DLGSUP <0027> gsup_client.c:244 GSUP ping callback (connected, got PONG) 20180625042104617 DLGSUP <0027> gsup_client.c:264 GSUP sending PING 20180625042104617 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042104617 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042104617 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042104617 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042104617 DLINP <001f> input/ipa.c:138 127.0.0.1:4222 connected read 20180625042104617 DLINP <001f> input/ipa.c:56 127.0.0.1:4222 message received 20180625042104617 DLGSUP <0027> gsup_client.c:201 GSUP receiving PONG 20180625042108114 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042114030 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042114116 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042120117 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042124030 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042124484 DGPRS <000f> gprs_sgsn.c:912 Checking for inactive LLMEs, time = 401 20180625042124617 DLGSUP <0027> gsup_client.c:244 GSUP ping callback (connected, got PONG) 20180625042124617 DLGSUP <0027> gsup_client.c:264 GSUP sending PING 20180625042124617 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042124617 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042124617 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042124617 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042124617 DLINP <001f> input/ipa.c:138 127.0.0.1:4222 connected read 20180625042124617 DLINP <001f> input/ipa.c:56 127.0.0.1:4222 message received 20180625042124617 DLGSUP <0027> gsup_client.c:201 GSUP receiving PONG 20180625042126121 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/e35372d8) <- GPRS ATTACH ACCEPT (new P-TMSI=0xe35372d8) 20180625042132125 DMM <0002> gprs_gmm.c:2108 MM(xxxxxxxxxxxxxxx/e35372d8) T3350 expired >= 5 times 20180625042132125 DMM <0002> gprs_gmm.c:313 MM(xxxxxxxxxxxxxxx/e35372d8) Cleaning MM context due to T3350 20180625042132791 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042132791 DLLC <0012> gprs_llc.c:526 LLC RX: unknown TLLI 0xb6ccf813, creating LLME on the fly 20180625042132791 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0xe0b181 CMD=UI DATA 20180625042132791 DMM <0002> gprs_gmm.c:1272 MM(---/ffffffff) -> GMM ATTACH REQUEST MI(4140627987) type="GPRS attach" 20180625042132791 DMM <0002> gprs_sgsn.c:237 MM(/00000000) Allocated with GEA0 cipher. 20180625042132791 DLGLOBAL <001d> rate_ctr.c:88 validating counter group 0x558216d5ee00(sgsn:mmctx) with 11 counters 20180625042132791 DMM <0002> gprs_gmm.c:556 MM(/f2d9d8dd) <- GPRS IDENTITY REQUEST: mi_type=IMEI 20180625042133968 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042133968 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x607d37 CMD=UI DATA 20180625042133968 DMM <0002> gprs_gmm.c:1195 MM(/f2d9d8dd) -> GMM IDENTITY RESPONSE: MI(IMEI)=866049037683470 20180625042133968 DMM <0002> gprs_gmm.c:556 MM(/f2d9d8dd) <- GPRS IDENTITY REQUEST: mi_type=IMSI 20180625042134028 DNS <0010> gprs_ns.c:638 NSEI=1800 Timer expired in mode tns-test (30 seconds) 20180625042134028 DNS <0010> gprs_ns.c:571 NSEI=1800 Tx NS ALIVE (NSVCI=1800) 20180625042134028 DNS <0010> gprs_ns.c:610 NSEI=1800 Starting timer in mode tns-alive (3 seconds) 20180625042134028 DNS <0010> gprs_ns.c:584 NSEI=1800 Tx NS ALIVE_ACK (NSVCI=1800) 20180625042134028 DNS <0010> gprs_ns.c:610 NSEI=1800 Starting timer in mode tns-test (30 seconds) 20180625042134030 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042134685 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042134685 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0xfe7d5b CMD=UI DATA 20180625042134685 DMM <0002> gprs_gmm.c:1195 MM(/f2d9d8dd) -> GMM IDENTITY RESPONSE: MI(IMSI)=xxxxxxxxxxxxxxx 20180625042134685 DMM <0002> sgsn_auth.c:161 MM(xxxxxxxxxxxxxxx/f2d9d8dd) Requesting authorization 20180625042134685 DMM <0002> sgsn_auth.c:220 MM(xxxxxxxxxxxxxxx/f2d9d8dd) Updating authorization (unknown -> accepted) 20180625042134685 DMM <0002> sgsn_auth.c:249 MM(xxxxxxxxxxxxxxx/f2d9d8dd) Got authorization update: state unknown -> accepted 20180625042134685 DMM <0002> gprs_gmm.c:1119 MM(xxxxxxxxxxxxxxx/f2d9d8dd) Authorized, continuing procedure, IMSI=xxxxxxxxxxxxxxx 20180625042134685 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042140686 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042144031 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042144618 DLGSUP <0027> gsup_client.c:244 GSUP ping callback (connected, got PONG) 20180625042144618 DLGSUP <0027> gsup_client.c:264 GSUP sending PING 20180625042144618 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042144618 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042144618 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042144618 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042144618 DLINP <001f> input/ipa.c:138 127.0.0.1:4222 connected read 20180625042144618 DLINP <001f> input/ipa.c:56 127.0.0.1:4222 message received 20180625042144618 DLGSUP <0027> gsup_client.c:201 GSUP receiving PONG 20180625042146689 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042147289 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042147289 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x939444 CMD=UI DATA 20180625042147289 DMM <0002> gprs_gmm.c:1272 MM(xxxxxxxxxxxxxxx/f2d9d8dd) -> GMM ATTACH REQUEST MI(4140627987) type="GPRS attach" 20180625042147289 DMM <0002> gprs_gmm.c:228 MM(xxxxxxxxxxxxxxx/f2d9d8dd) Starting MM timer 3350 while old timer 3350 pending 20180625042147289 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042153290 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042154031 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042154485 DGPRS <000f> gprs_sgsn.c:912 Checking for inactive LLMEs, time = 431 20180625042159292 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042202149 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042202149 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x5b3c8d CMD=UI DATA 20180625042202149 DMM <0002> gprs_gmm.c:1272 MM(xxxxxxxxxxxxxxx/f2d9d8dd) -> GMM ATTACH REQUEST MI(4140627987) type="GPRS attach" 20180625042202149 DMM <0002> gprs_gmm.c:228 MM(xxxxxxxxxxxxxxx/f2d9d8dd) Starting MM timer 3350 while old timer 3350 pending 20180625042202149 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042204029 DNS <0010> gprs_ns.c:638 NSEI=1800 Timer expired in mode tns-test (30 seconds) 20180625042204029 DNS <0010> gprs_ns.c:571 NSEI=1800 Tx NS ALIVE (NSVCI=1800) 20180625042204029 DNS <0010> gprs_ns.c:610 NSEI=1800 Starting timer in mode tns-alive (3 seconds) 20180625042204029 DNS <0010> gprs_ns.c:584 NSEI=1800 Tx NS ALIVE_ACK (NSVCI=1800) 20180625042204029 DNS <0010> gprs_ns.c:610 NSEI=1800 Starting timer in mode tns-test (30 seconds) 20180625042204031 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042204619 DLGSUP <0027> gsup_client.c:244 GSUP ping callback (connected, got PONG) 20180625042204619 DLGSUP <0027> gsup_client.c:264 GSUP sending PING 20180625042204619 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042204619 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042204619 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042204619 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042204619 DLINP <001f> input/ipa.c:138 127.0.0.1:4222 connected read 20180625042204619 DLINP <001f> input/ipa.c:56 127.0.0.1:4222 message received 20180625042204619 DLGSUP <0027> gsup_client.c:201 GSUP receiving PONG 20180625042208149 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042214031 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042214150 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042216947 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042216947 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x75dfce CMD=UI DATA 20180625042216947 DMM <0002> gprs_gmm.c:1272 MM(xxxxxxxxxxxxxxx/f2d9d8dd) -> GMM ATTACH REQUEST MI(4140627987) type="GPRS attach" 20180625042216947 DMM <0002> gprs_gmm.c:228 MM(xxxxxxxxxxxxxxx/f2d9d8dd) Starting MM timer 3350 while old timer 3350 pending 20180625042216947 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042222948 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042224031 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042224486 DGPRS <000f> gprs_sgsn.c:912 Checking for inactive LLMEs, time = 461 20180625042224619 DLGSUP <0027> gsup_client.c:244 GSUP ping callback (connected, got PONG) 20180625042224619 DLGSUP <0027> gsup_client.c:264 GSUP sending PING 20180625042224619 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042224619 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042224619 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042224619 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042224619 DLINP <001f> input/ipa.c:138 127.0.0.1:4222 connected read 20180625042224619 DLINP <001f> input/ipa.c:56 127.0.0.1:4222 message received 20180625042224619 DLGSUP <0027> gsup_client.c:201 GSUP receiving PONG 20180625042228950 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042232086 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042232086 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0x06fa0b CMD=UI DATA 20180625042232086 DMM <0002> gprs_gmm.c:1272 MM(xxxxxxxxxxxxxxx/f2d9d8dd) -> GMM ATTACH REQUEST MI(4140627987) type="GPRS attach" 20180625042232086 DMM <0002> gprs_gmm.c:228 MM(xxxxxxxxxxxxxxx/f2d9d8dd) Starting MM timer 3350 while old timer 3350 pending 20180625042232086 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042234029 DNS <0010> gprs_ns.c:638 NSEI=1800 Timer expired in mode tns-test (30 seconds) 20180625042234029 DNS <0010> gprs_ns.c:571 NSEI=1800 Tx NS ALIVE (NSVCI=1800) 20180625042234029 DNS <0010> gprs_ns.c:610 NSEI=1800 Starting timer in mode tns-alive (3 seconds) 20180625042234029 DNS <0010> gprs_ns.c:584 NSEI=1800 Tx NS ALIVE_ACK (NSVCI=1800) 20180625042234030 DNS <0010> gprs_ns.c:610 NSEI=1800 Starting timer in mode tns-test (30 seconds) 20180625042234032 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042238087 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042244032 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042244090 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042244619 DLGSUP <0027> gsup_client.c:244 GSUP ping callback (connected, got PONG) 20180625042244619 DLGSUP <0027> gsup_client.c:264 GSUP sending PING 20180625042244619 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042244619 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042244619 DLINP <001f> input/ipa.c:142 127.0.0.1:4222 connected write 20180625042244619 DLINP <001f> input/ipa.c:92 127.0.0.1:4222 sending data 20180625042244620 DLINP <001f> input/ipa.c:138 127.0.0.1:4222 connected read 20180625042244620 DLINP <001f> input/ipa.c:56 127.0.0.1:4222 message received 20180625042244620 DLGSUP <0027> gsup_client.c:201 GSUP receiving PONG 20180625042250092 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042254032 DBSSGP <0011> gprs_bssgp.c:806 BSSGP BVCI=1800 Rx Flow Control BVC 20180625042254487 DGPRS <000f> gprs_sgsn.c:912 Checking for inactive LLMEs, time = 491 20180625042256094 DMM <0002> gprs_gmm.c:437 MM(xxxxxxxxxxxxxxx/f2d9d8dd) <- GPRS ATTACH ACCEPT (new P-TMSI=0xf2d9d8dd) 20180625042302097 DMM <0002> gprs_gmm.c:2108 MM(xxxxxxxxxxxxxxx/f2d9d8dd) T3350 expired >= 5 times 20180625042302097 DMM <0002> gprs_gmm.c:313 MM(xxxxxxxxxxxxxxx/f2d9d8dd) Cleaning MM context due to T3350 20180625042302304 DBSSGP <0011> gprs_bssgp.c:392 BSSGP TLLI=0xb6ccf813 Rx UPLINK-UNITDATA 20180625042302304 DLLC <0012> gprs_llc.c:526 LLC RX: unknown TLLI 0xb6ccf813, creating LLME on the fly 20180625042302304 DLLC <0012> gprs_llc_parse.c:81 LLC SAPI=1 C U GEA0 IOV-UI=0x000000 FCS=0xe0b181 CMD=UI DATA Thanks, Alexa

1 0

osmo-pcu build failures on Debian 8.0
by Harald Welte 06 Jun '18

06 Jun '18

For quite some time, osmo-pcu has been causing build failures on Debian 8. You can find a build log e.g. at https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/o… The visible sign is that for some reasson there are additional log lines present in the output of our unit tests, like: [ 127s] TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) downlink acknowledge [ 127s] TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) Final ACK received. [ 127s] +DL packet loss of IMSI= / TLLI=0xffeeddcc: 0% [ 127s] TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=FLOW EGPRS) changes state from FLOW to WAIT RELEASE [ 127s] TBF(TFI=0 TLLI=0xffeeddcc DIR=DL STATE=WAIT RELEASE EGPRS) starting timer T3193 [release (DL-TBF)] with 0 sec. 0 microsec, cur_fn=0 where the "+" is the unexpected additional line. Does anyone have any information about why that is? I don't see any related changes recently. -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 1

GTP-U support for a UE with multiple bearers (LTE)
by Shashank Prasad 18 Apr '18

18 Apr '18

Hi, I just started exploring the GTP-U module (maintained in the kernel) for LTE. In LTE, a UE can be associated with multiple bearers. This implies that an MS IP address can be associated with multiple TEIDs (one for each bearer). Based on browsing the kernel GTP implementation[1], it looks like the GTP-U (maintained in the kernel) can only support 1 TEID per MS IP address. In which case, the GTP implementation, as is, may NOT be usable by LTE modules. Is this a correct interpretation? - Shashank [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/dr…

2 1

GTP-U support for a UE with multiple bearers
by Shashank Prasad 17 Apr '18

17 Apr '18

Hi, I just started exploring the GTP-U module (maintained in the kernel) for LTE scenarios. In LTE, a UE can be associated with multiple bearers. This implies that an MS IP address can be associated with multiple TEIDs (one for each bearer). Based on browsing the kernel GTP implementation[1], it looks like the GTP-U (maintained in the kernel) can only support 1 TEID per MS IP address. In which case, the GTP implementation, as is, may NOT be usable by LTE modules. Is it an correct interpretation? - Shashank [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/dr…

1 0

Save the Date: OsmoCon 2018 on October 18-19, 2018
by Harald Welte 11 Apr '18

11 Apr '18

== OsmoCon 2018 == OsmoCon (Osmocom Conference) 2018 is the technical conference for Osmocom users, operators and developers! We are happy to announce the date of OsmoCon 2018. It has been scheduled on October 18 + 19, 2018 and will happen in Berlin, Germany. For the second time, the Osmocom Conference brings together users, operators and developers of the Osmocom Open Source cellular infrastructure projects, such as OsmoBTS, OsmoBSC, OsmoSGSN, OpenGGSN and others. Join us for two days of presentations and discussions with the main developers behind Open Source Mobile Communications, as well as commercial and non-profit users of the Osmocom cellular infrastructure software. You can find some initial information in our wiki at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2018 which will be updated as more information becomes available. == Call for Participation == We're also at the same time announcing the Call for Participation and call on everyone with experiences to share around the Osmocom member projects to submit talks, workshops, discussions or other proposals. You can find the CfP at https://pretalx.sysmocom.de/osmocon2018/cfp We are particularly looking for contributions about: * updates on features/functionality/status of individual Osmocom projects * success stories on how Osmocom projects are deployed in practice * migration from OsmoNITB to the post-NITB architecture * tutorials / workshops on how to setup / analyze Osmocom projects * statistics, reporting, operations aspects of Osmocom projects * third-party open source utilities to be used with Osmocom projects Looking forward to meeting many existing and new Osmocom users at OsmCon this October! Regards, Harald Welte -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Data throughput issues. Increasing throughput.
by Dave Ellis 05 Apr '18

05 Apr '18

Hi, I need to increase the throughput through the GTP tunnels to around 9Gb/s. I have two servers and they are connected using two GTP tunnels over a Mellanox 25Gb/s link. Via the tunnels I am seeing a total of 4.2 Gb/s to 4.5 Gb/s using iPerf. If data is sent without the tunnels I see a throughput of around 24.5Gb/s. I have tried various tweaks to improve the throughput over the GTP tunnels and have only made marginal gains. I have tried iPerf 2.0.9 and iPerf3 and see the same results. Wireshark shows the iPerf MTU is reflected in the pcap logs. I have tried changing the txqueuelen on the tunnels, changing osmo-ggsn niceness, network buffer sizes etc. The restriction seems to be osmo-ggsn as that is taking up to 92% CPU on one of the cores when the throughput tests are running. I'm hoping I have made a mistake in the configuration of OsmoGGSN and sgsnemu. -- The servers are running Ubuntu 16.04 desktop. 16GB RAM - 12.6GB free when running throughput tests. Intel E52620v3. Mellanox MCX516A-CCAT network adapter. 25Gb direct attach copper connecting the two servers OsmoGGSN version 1.1.0.75-3e44-dirty. For one of the servers: - Mellanox interface details ens3f0 Link encap:Ethernet HWaddr ec:0d:9a:a0:1d:7c inet addr:172.16.8.1 Bcast:172.16.255.255 Mask:255.255.0.0 inet6 addr: fe80::8f38:33e3:bd46:dd65/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:9000 Metric:1 RX packets:142373677 errors:0 dropped:0 overruns:0 frame:0 TX packets:157500406 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10000 RX bytes:793825609487 (793.8 GB) TX bytes:879898325287 (879.8 GB) Tunnel interface details S1Utun Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.1.1.2 P-t-P:10.1.1.2 Mask:255.255.255.0 inet6 addr: fe80::b3fc:3d43:b751:bcbf/64 Scope:Link UP POINTOPOINT RUNNING MTU:9000 Metric:1 RX packets:4640412 errors:0 dropped:0 overruns:0 frame:0 TX packets:2272797 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:37729672063 (37.7 GB) TX bytes:118866016 (118.8 MB) X2Utun Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.1.2.2 P-t-P:10.1.2.2 Mask:255.255.255.0 inet6 addr: fe80::6ed8:8a79:b3e9:a51d/64 Scope:Link UP POINTOPOINT RUNNING MTU:9000 Metric:1 RX packets:1824011 errors:0 dropped:0 overruns:0 frame:0 TX packets:3856238 errors:0 dropped:4229 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:95648485 (95.6 MB) TX bytes:31367266755 (31.3 GB) client side iperf server1 iperf3 -c 10.1.2.1 -i1 -t 30 -M8100 -w 2048K -P8 server2 iperf3 -c 10.1.2.1 -i1 -t 30 -M8100 -w 2048K -P8 server1 and 2 iperf server iperf3 -s -i1 osmo-ggsn -c /home/osmo-ggsn.cfg -g 172.16.1.1 contents of osmo-ggsn.cfg ! ! OpenGGSN (0.94.1-adac) configuration saved from vty !! ! log stderr logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging level ip info logging level tun info logging level ggsn info logging level sgsn notice logging level icmp6 notice logging level lglobal notice logging level llapd notice logging level linp notice logging level lmux notice logging level lmi notice logging level lmib notice logging level lsms notice logging level lctrl notice logging level lgtp info logging level lstats notice logging level lgsup notice logging level loap notice logging level lss7 notice logging level lsccp notice logging level lsua notice logging level lm3ua notice logging level lmgcp notice ! stats interval 5 ! line vty no login ! ggsn X2Uggsn gtp state-dir /tmp gtp bind-ip 172.16.8.1 gtp gtp0-port 3386 gtp gtp1c-port 2123 gtp gtp1u-port 2153 gtp gtp1uremot-port 2153 apn X2U gtpu-mode tun tun-device X2Utun type-support v4 ip prefix dynamic 10.1.2.0/24 ip dns 0 192.168.100.1 ip dns 1 8.8.8.8 ip ifconfig 10.1.2.2/24 no shutdown default-apn X2U no shutdown ggsn ggsn S1Uggsn gtp state-dir /tmp gtp bind-ip 172.16.8.1 gtp gtp0-port 3387 gtp gtp1c-port 2124 gtp gtp1u-port 2152 gtp gtp1uremot-port 2152 apn S1U gtpu-mode tun tun-device S1Utun type-support v4 ip prefix dynamic 10.1.1.0/24 ip dns 0 192.168.100.1 ip dns 1 8.8.8.8 ip ifconfig 10.1.1.2/24 no shutdown default-apn S1U no shutdown ggsn sgsnemu -l 127.0.0.2 -r 172.16.8.1 --contexts 1 -a S1U -m 4412345678 -q 0x00000000000b921f --defaultroute --pingcount 0 --gtpteid=8 --gtpversion=1 --gsnuip 172.16.1.1 --enduserip 10.1.1.1 --gtp0port 3387 --gtp1cport 2124 --nsapi 1 sgsnemu -l 127.0.0.3 -r 172.16.8.1 --contexts 1 -a X2U -m 4412345678 -q 0x00000000000b921f --defaultroute --pingcount 0 --gtpteid=3 --gtpversion=1 --gsnuip 172.16.1.1 --enduserip 10.1.2.1 --gtp0port 3386 --gtp1cport 2123 --nsapi 2 Hopefully I have provided enough information. Any ideas on how to increase tunnel throughput? Thanks Dave

3 3

Interfering with the GTP-u Kernel module
by Thomas Boros 16 Feb '18

16 Feb '18

Hello, I would like to implement a command line tool, which will be able to open / close , read / write to gtp tunnels. I was able to install the libgtpnl library, but due to lack of documentation I have no idea where to start. Is there some sort of documentation available for this library? I need to be able to create and delete tunnels without the GTP-C communication, so just basic command line tool like create-gtp-tunnel + arguments like IPs, version and teid. The GTP-U tunnels must be kernel based. I have the latest kernel with the gtp kernel module loaded. Any help is appreciated. Thank you, Tomas

2 4

Problem when building OsmoSGSN
by XINKE ZHANG 16 Feb '18

16 Feb '18

Hi all, I built OsmoSGSN with the these following instructions. <build instructions> git clone git://git.osmocom.org/osmo-sgsn cd osmo-sgsn autoreconf -fi ./configure --enable-iu make -j5 make check make install sudo ldconfig <build instructions> And no error came out during building process, but no “osmo-sgsn” executable was found. Pls help me. Thank you in advance. Best Regards, Xinke

4 11

sgsnemu: no outgoing GTP-U in "createif" mode
by Viktor Tsymbalyuk 09 Feb '18

09 Feb '18

Hello, I tried to run sgsnemu in "createif" mode - transfer traffic via tun interface. tun interface created and routing too. But there are no outgoing GTP-U from test machine. (in my scenario sgsnemu on separated server). From gdb it looks, that in cb_tun_ind function ipm->pdp is 0x0, as result gtp_data_req(gsn, ipm->pdp, pack, len); not running. After changes like below, it's start working. Does I correctly understood internal logic? diff --git a/sgsnemu/sgsnemu.c b/sgsnemu/sgsnemu.c index 630733b..cf4aa44 100644 --- a/sgsnemu/sgsnemu.c +++ b/sgsnemu/sgsnemu.c @@ -1462,7 +1462,7 @@ static int create_pdp_conf(struct pdp_t *pdp, void *cbp, int cause) free(forwarding); } - ipset((struct iphash_t *)pdp->peer, &addr); + ipset(iph, &addr); state = 2; /* Connected */ If need more test details, please let me know. -- Viktor

2 1

GPRS trafic in PCU - type BVC-UNBLOCK unknown // Protocol error - unspecified
by Osmocom Mailing List 05 Feb '18

05 Feb '18

Hi, I'm trying to run GPRS in my network. So far I get flooded with the bellow trafic in the PCU and the GGNS doesn't appear to receive any traffic. <000c> gprs_bssgp_bss.c:294 BSSGP (BVCI=2) Tx BVC-RESET CAUSE=O&M intervention <000c> gprs_bssgp.c:551 BSSGP BVCI=0 Rx BVC STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:348 Rx BSSGP BVCI=0 (SIGN) PDU type BVC-UNBLOCK unknown <000c> gprs_bssgp_util.c:238 BSSGP BVCI=0 Tx STATUS, cause=Protocol error - unspecified <000c> gprs_bssgp_pcu.cpp:298 Rx BSSGP BVCI=0 (SIGN) BVC_RESET_ACK <000c> gprs_bssgp_pcu.cpp:835 Sending unblock on BVCI 2 <000c> gprs_bssgp_bss.c:274 BSSGP (BVCI=2) Tx BVC-BLOCK <000c> gprs_bssgp.c:289 Cell 1-1-1-0 CI 0 on BVCI 2 Thanks, Filipe Laíns <https://github.com/FFY00> Sent via Migadu.com, world's easiest email hosting

2 1

Fwd: icmp encapsulation
by fırat sönmez 01 Feb '18

01 Feb '18

---------- Forwarded message ---------- From: fırat sönmez <firatssonmez(a)gmail.com> Date: 2018-02-01 15:51 GMT+03:00 Subject: Re: icmp encapsulation To: Pau Espin Pedrol <pespin(a)sysmocom.de> Hi Pau, Thank you for your response. You are right, I should have told the configuration in more detail. However, you came to the point already. I am talking about the second case where there is NAT. There is a slight difference though. After the NAT two IP (IP1 and IP2) will be IPnat, but the NAT maps the IP1 and IP2 to the port range. Since, there is no port in ICMP, both IP1 and IP2 will be go to uplink as IPg and but on the return there must be problem for NAT machine to traverse the two different paths from IPnat to IP1 and IPnat to IP2. I looked into the ICMP header and observed the packets have different identifiers. So, NAT machine must be using the identifies to reverse the packets. Anyways, in my case the *IP1=IP2* (In my experimental architecture, the GGSN will not be assigning distinct IP for each host. Instead, GGSN will assign 1 IP address for 32 hosts (seems like NAT). My configuration is probably out of standard architectures, but I need to understand how would gtp handle matching these two pdp contexts. I have tried this configuration, pinging from two different host with same IP and it was successful! Two packets coming from the server to the GGSN will be *[src:IPs | dst:IP1]* and *[src:IPs | dst:IP2]* IP1=IP2, but two packets have different icmp identifier. And pdp contexts are still resolved successfully. so a big HOW in my mind? Fırat 2018-02-01 13:46 GMT+03:00 Pau Espin Pedrol <pespin(a)sysmocom.de>: > Hi firat, > > I didn't understand fully the configuration you are describing. Something > like this? > > Host1 --SGSN1--\GGSN--Server > Host2 --SGSN2--/ > > Where Host1 has been assigned IP1 and Host2 has been assigned IP2, both > assigned by GGSN where IP1 != IP2. Let's assume the server IP is IPs and > the GGSN public uplink (non-GTP) IP is IPg. > > As far as I understand, it works as follow: > > - Case without NAT between GGSN and Server: > Host1 sends ICMP packet with saddr=IP1 daddr=IPs, which gets encapsulated > through GTP and GGSN decapsulates it. Same for Host2 but in this case the > packet will have saddr=IP2. As there's no NAT (eg. host clients are > assigned a public IP), the server receives 2 ICMP packets with different > saddr, and when answering back using the original saddr now as daddr. As > GGSN keeps track of the saddr assigned to each pdp context, when it > receives a packet from the uplink (non-GTP side), it matches the daddr of > the packet against the saddr of the active pdp ctx to find to which pdp ctx > should forward the packet. > > - Case with NAT between GGSN and Server: > Almost the same but with extra steps done by the NAT. When the GGSN sends > the packet saddr=IP1 daddr=IPs to the server, the NAT changes > saddr=IP1->IPg. It does the same for saddr=IP2, but the NAT keeps track of > the binding. When the response is received from the server, the NAT > converts back IPg->IP1 and GGSN can again track the pdp ctx as described in > the previous case. > > -- > - Pau Espin Pedrol <pespin(a)sysmocom.de> http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Geschaeftsfuehrer / Managing Director: Harald Welte >

2 1

icmp encapsulation
by fırat sönmez 01 Feb '18

01 Feb '18

Hi, I would like to ask&know how the GGSN holds and finds pdp contexts for icmp packets that have same source and destination address on the downlink? For example, if there are two hosts having same IP address behind two different network pinging same destination address and they are encapsulated at SGSN and then one GGSN receives both and saves the packet, decapsulates and sends to the destination. On the downlink destination responds to the two ping packets (they are different because they have different identifier in icmp packet), but then how does GGSN finds the pdp contexts again to encapsulate these packets and send back to the two SGSNs? The pdp context doesnt include thse icmp identifiers. There is no sockets either since icmp doesnt have sockets. On the downlink, when there are two icmp packets recieved by GGSN, there is only icmp identfier that distinguish each other, but this identifier is not in the pdp context. Would someone help me figure out this? Thank you all

2 1

sgsnemu ignoring Request accepted
by Viktor Tsymbalyuk 26 Jan '18

26 Jan '18

Hello, I continue to play with sgsnemu, and found that it stopped for some reason after "Request accepted". Does sgsnemu working? At my mind problem inside `create_pdp_conf` function . After small changes, I start to see icmp inside gtp tunnel in trace. Please check attachments with console output, patch and pcap. May be I has wrong understanding. -- Viktor

2 4

sgsnemu: why --listen and --remote in one network?
by Viktor Tsymbalyuk 19 Jan '18

19 Jan '18

Hello, I'm querying why sgsnemu shoul work in a same network with ggsn? What the reason for such limitation? -- Viktor

2 3

Osmocom Year 2017 Review
by Harald Welte 01 Jan '18

01 Jan '18

Dear all, I've written up a "short" review of what I perceive as the most important events in the Osmocom Cellular Infrastructure projects in 2017. See http://osmocom.org/news/84 for all details, or below for a raw copy+paste: h1. Osmocom Review 2017 This is a review of the most significant changes and events in the Osmocom Cellular Infrastructure projects in 2017 h2. January 2017 * announce of first ever public [[OsmoCon:]] conference in April * osmo-bts ** Add Abis OML failure event reporting ** fix memory leaks in osmo-bts-{sysmo,lc15} at every channel activation * openbsc/osmo-bsc ** support multiple UARFCNs in SI2quater * osmo-hlr ** add test suite for 2G and 3G authentication ** fix UMTS AKA re-sync h2. February 2017 * weekly manual testing with related weekly test reports to mailing list * "heads-up about the (lack of a )future of osmo-nitb":http://lists.osmocom.org/pipermail/openbsc/2017-February/010300.html * "heads-up about libosmo-sccp SIGTRAN work":http://lists.osmocom.org/pipermail/openbsc/2017-February/010274.html * "sysmo-usim-tool":http://lists.osmocom.org/pipermail/openbsc/2017-February/010317.html * libosmo-abis ** unix domain socket support (for Ericsson L2TP) * osmo-bts ** fix AMR HR DTX FSM logic ** fix SACCH sending fo system information with enum value > 7 ** osmo-bts-trx: fix RXGAIN and POWER parameters on second TRX ** fix TCH/H interleaving table bit position ** sysmoBTS 1020/1100: slow power ramp-up on TRX enable * osmo-sgsn ** fix PDP context activation memory allocation bug ** integrate support for UMTS AKA * openggsn ** fix kernel-gtp tunnel creation/removal for GTPv1 ** release 0.93 h3. March 2017 * "cgit improvements":http://lists.osmocom.org/pipermail/openbsc/2017-March/010448.html (about page, change-ID hyperlinks, issue hyperlinks) * Add README.md files to all our repositories * libosmocore ** migrate gsm 05.03 coding from OsmoBTS to libosmocore ** fix SQN / SEQ handling in UMTS AKA ** 3GPP AoIP message encoding/decoding * libosmo-abis ** fix ever-increasing jitter buffer * libosmo-netif ** handle SCTP in in stream server ** doxygen documentation on stream an datagram modules * osmo-bts ** octphy: CBCH support ** include MS timing offset in RSL measurements * osmo-sgsn ** handle IMSIs with leading zeroes * osmo-bsc ** fix T3186 encoding in SI13 ** Improved Ericsson OM2000/RBS2000 support ** new ctrl2soap proxy in python * osmo-hlr ** add CTRL interface ** fix SQN/SEQ handling in UMTS AKA h3. April 2017 * "update of coding style for longer line lengths":http://lists.osmocom.org/pipermail/openbsc/2017-April/010502.html * [[osmo-dev-con:OsmoCon2017]] and [[osmo-dev-con:OsmoDevCon2017]] * libosmocore ** "control interface for osmo_fsm":http://lists.osmocom.org/pipermail/openbsc/2017-April/010542.html * libosmo-netif ** fix file descriptor leak in error paths ** work around linux kenrel SCTP bug with sender_dry_events ** RTP marker bit support * libosmo-sccp ** Add new [[libosmo-sigtran:]] library with SS7 AS/ASP Link/Linkset handling, M3UA support, new FSM based SCCP implementation ** Add [[osmo-stp:]] program * osmo-bts ** inform BSC of PCU disconnect ** fix measurement reporting period ** exclude idle channels from uplink measurement processing ** octphy: measurement reports h3. May 2017 * libosmocore ** fix embedded builds ** import and generalise 'sercomm' from osmocom-bb into libosmocore ** SSE optimized convolutional coder ** fix wrong GSM FR codec SID frame generation ** doxygen docs for libosmocoding * osmo-bsc ** TS 04.14 mobile station side loop control * osmo-bts ** consistently check all RSL and OML TLVs for minimum length value ** fix bit-order in every HR codec parameter (spec compliance) ** OML get/set attribute handling ** SI2quater support ** bypass radio link timeout for lab testing * osmo-bsc ** PCU socket support for BSC-colocated PCU for Ericsson RBS2000 ** reelase 1.0.1 * "M3UA and SUA testing as part of jenkins":http://lists.osmocom.org/pipermail/openbsc/2017-May/010698.html * "osmo-gsm-tester produces successful runs with NITB as well as new AoIP":http://lists.osmocom.org/pipermail/openbsc/2017-May/010760.html h3. June 2017 * libosmocore ** doxygen autobrief ** doxygen documentation for libosmogb * osmo-bts ** use CLOCK_MONOTONIC timer for GSM frame timer ** PDTCH loopback support h3. July 2017 * "Plan for openbsc.git split and code review":http://lists.osmocom.org/pipermail/openbsc/2017-July/010914.html * libosmocore ** PDP charging characteristics in GSUP ** PRBS sequence generators ** multicast IP related helper functions ** 'make release' target * libosmo-sccp ** SCCP address book * osmo-bts ** new virtual BTS @osmo-bts-virtual@ for testing without radio hardware ** don't send dummy UI frames on unused BCCH slots on TC=5 ** GSMTAP: don't log/send fill frames consisting of only padding * osmo-hlr ** change to default GSUP port 4222 h3. August 2017 * "Support for SMPP Delivery Receipt / GSM03.40 Status Report":http://lists.osmocom.org/pipermail/openbsc/2017-August/011023.html * "Jenkins now executing M3UA, SUA and GGSN testsuite":http://lists.osmocom.org/pipermail/openbsc/2017-August/011043.html * libosmocore ** fix crash in lapd_est_req() * libosmo-abis ** release 0.4.0 * osmo-bts ** osmo-bts-trx: fix MS power control loop ** release 0.6.0 ** support sending/removing SI13 to/from PCU * osmo-bsc ** indicate R99+ MSC in SI3 to enable UMTS AKA over GERAN * osmo-sgsn ** properly report GERAN/UTRAN mode in PDP CTX ACT REQ to GGSN * osmo-msc ** implement IuCS support ** split openbsc.git into osmo-bsc.git, osmo-msc.git and osmo-sgsn.git * openggsn ** Add IPv6 address pool and IPV6 user (inner) plane support ** release 0.94 h3. September 2017 * libosmocore.git ** "'show talloc-context' VTY introspection":http://lists.osmocom.org/pipermail/openbsc/2017-June/010771.html ** CTRL parsing unit tests ** unification of vty exit/end commands * osmo-hlr ** CTRL interface tests -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

OsmoDevCon 2018 schedule planning
by Harald Welte 06 Dec '17

06 Dec '17

Dear Osmocom Community, [please respect the Reply-To and post all follow-up discussion to this to openbsc(a)lists.osmocom.org, so we avoid having long threads cross-posted to several mailing lists.] Like every year in early December, it is time to discuss as schedule for OsmoDevCon in the upcoming year. Note: Ths is about OsmoDevCon, the more private meeting of developers, *NOT* about OsmoCon, the public conference. == When, Who, Where == I propose the following date for OsmoDevCon 2018: April 20 - April 23rd, 2018 * Who: Active developers/contributors of Osmocom projects (as usual) * Where: IN-Berlin, Berlin (as usual) Please let me know ASAP if that proposed date works for everyone who'd want to attend. We can still change it now, but I would want to nail down the date pretty soon. == Format == After the experiment of reducing from 4 to 3 days last year (due to OsmoCon), we will again go for *four days* in 2018. However, we should clearly divide the days in a way that e.g. "GSM/3G" topics are on two days, while SDR+Other topics are on the other days, so people not interested in some topics can skip one or two days, as needed. We could even divide it further like: * 1 day 3GPP RAN (osmo-bts, osmo-bsc, osmo-pcu, virt_phy, fake_trx, ...) * 1 day 3GPP CN (osmo-msc, osmo-hlr, osmo-sip-connector, nextepc, etc.) * 2 days misc Regards, and looking forward to meeting you [again] in 2018, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 1

Packets are not arrived at tunnel setup by libgtpnl
by congnt 24 Nov '17

24 Nov '17

Hi guys, I'm using libgtpnl tools (gtp-link, gtp-tunnel) to setup a tunnel in my local machines. I was able to setup gtp link to 2152 port as well as gtp tunnel. I have pre-recorded GTP packets with correct teid and IP address as well as chksum and port to send to 2152. However I can not see any packets in gtp link device when using tcpdump. By add some messages in gtp module, I notice that the function gtp1u_udp_encap_recv in gtp.c kernel file was never been called if I send packet with GTP headers. However, that function is called if I send normal UDP packet without GTP header. Note that I'm using Ubuntu 14.04 with kernel 4.8.0 lowlatency, the tunnel is on a VM created by Virtualbox using virtio network driver. Any suggestions on how to debug/solve this problem? Many thanks in advances. Best regards Cong.

2 2

libgtpnl migrated to gerrit
by Harald Welte 12 Nov '17

12 Nov '17

Hi all, FYI: I migrated libgtpnl (the kernel-GTP netlink interface helper library used by OpenGGSN and OsmoGGSN) to gerrit earlier today. This means direct pushes to git.osmocom.org no longer work and you will have to submit modifications via gerrit, as we do for all our other major repositories. I've also set up a gerrit build verification job via jenkins-job-builder and added a corresponding contrib/jenkins.sh script to it. The buildhosts now need libmnl-dev as build dependency installed. I added this to our current debian8 + debian9 build slaves and the wiki documentation about them. In other news: libgtpnl is already part of the network:osmocom:nightly and network:osmocom:latest feeds for some weeks. I intend to test kernel GTP support in osmo-ggsn soon and then change the package builds to include kernel-gtp support via libgtpnl by default. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Re: GPRS EXperiments
by Neels Hofmeyr 03 Nov '17

03 Nov '17

(BTW, for GPRS we use osmocom-net-gprs(a)lists.osmocom.org but admittedly, almost all osmocom communication is taking place on openbsc@) On Mon, Oct 30, 2017 at 12:12:03PM -0600, Keith wrote: > I've installed up to date versions of osmo-bts and osmo-pcu > on sysmobts 2050 hardware and it's working great! > Dynamic channels are really nice, with half rate TCH and AMR > working perfectly. Thanks for all that work! Good to hear that! > I configured pcodns1 in the ggsn to point to this DNS > server, AND I setup a port 53 redirect to catch quite a lot > of traffic from android that likes to just talk directly to > 8.8.8.8 anyway. Interesting, this sounds like it would make for a good wiki page on osmocom.org. > games. Such is the sad state of affairs on today's internet. > Fortunately, we have iptables and ip sets and we have AS > blocks assigned to certain bandwidth hungry corporations :-) So instead of compromising net neutrality by giving the rich more bandwidth, you do it by cutting the big ones out instead ;) > I have observed that if I initiate any data transfer from > the network side then the uplink is established. By the same > token, If I transfer a file from the network (http download > or some such), the same applies. The link stays active and > the IM chat session is very responsive alongside the file > transfer. Shortly after the file transfer completes, the > uplink is quiet again and the latency in the IM session > becomes a problem. It might be related to a basic problem we still have with data services: we don't cache anything. If a PDP context is still being established, we drop data transfers to the floor, instead of storing them and sending them through when the context is established. I'm personally not familiar with the details there, but that's my current understanding. So a first ping would get lost, a second one within a timeframe that still has the PDP context open will go through. I think the idea there is that generally, higher level data communication should attempt to resend, but in practice that often doesn't seem to work that well. Not sure how to configure the PDP context timeout, or whether we even can. Theoretically, if you had on your phone a regular ping running in the background ... it's ugly, but yea. Caching those first packets is quite complex, especially for SGSNs sitting on a small device like a sysmoBTS with limited memory. I guess something could be tried there, by limiting resources used for caching in intelligent ways... Someone would need to fund that, or go ahead and try. ~N

1 0

Want to do paid work on Osmocom? sysmocom is hiring
by Harald Welte 31 Oct '17

31 Oct '17

Dear Osmocom community, I would like to point out that at sysmocom, we're currently (again) hiring [1]. If you happen to have an interest in open source cellular communications and are fluent in C language development, we would love to hear from you. sysmocom probably doesn't need any introduction here, but just in case: The company was founded by Holger Freyther and Harald Welte, two of the leading OpenBSC and Osmocom developers from the very early days of the project. Today we are responsible for by far the largest number of commits to the Osmocom GSM/3G infrastructure related git repositories. Among our current priorities are automatic testing for the GPRS PCU, generalization of the OsmoMGW media gateway, support for load-based hand-over, inter-BSC hand-over as well as various improvements on the lower layers of the GPRS protocol stack. We're very dedicated to the cause in furthering the capabilities of open source cellular infrastructure from 2G to 4G. We believe in working upstream, no open core or dual licensing. If you have an interest working with an enthusiastic, strong technical and dedicated team of Osmocom hackers, please don't hesitate to let me know, best by e-mail to jobs(a)sysmocom.de Thanks, Harald p.s.: I hope this kind of message is not disturbing to anyone. I think it is important to the Osmocom project to have more paid people working on the stack, so it is justified. The positions we are seeking to fill will work [almost exclusively] on Osmocom, so it's not a random job ad but in the very interest of Osmocom, and hence on-topic for this list. [1] https://www.sysmocom.de/jobs/ -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

New "osmocom:latest" package feed
by Harald Welte 28 Oct '17

28 Oct '17

Dear Osmocom community, since the NITB-split has completed, and we have integrated 3G fully into master, and also merged nitb-split and nitb packages in one feed, the next step on the agenda was to create packages/feeds that are more stable than "nightly". After a long day of "release engineering" work and related fixes, starting from today, Osmocom not only has the "osmocom:nightly" feed tracking the "master of the day" of all repositories. We now also have a "osmocom:latest" feed for various Debian and Ubuntu GNU/Linux distributions which contains packages for the last tagged version of each source code repository. The setup is fairly similar to that of the "osmocom:nightly" packages and is described at https://osmocom.org/projects/cellular-infrastructure/wiki/Latest_Builds I've also removed all known references to Nightly_Builds on the wiki and replaced it with a reference to the new Binary_Packages page explaining the differences between Nightly_Builds and Latest_Builds: https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages As you can see at https://build.opensuse.org/project/monitor/network:osmocom:latest almost all the packages are building already. I intend to fix the remaining three (osmo-bsc, osmo-msc and osmo-pcu) shortly. -- - Harald Welte <hwelte(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

1 0

libgtp: Users of gtpie_encaps() and gtpie_encaps2() ?
by Harald Welte 14 Oct '17

14 Oct '17

Dear all, during manual review, I found some pretty obvious bugs and inconsistencies in the gtpie_encaps() and gtpie_encaps2() functions of libgtp. Interestingly, it seems those functions have been around since the very fist commit in 2002. However, no code in openggsn, osmo-ggsn, osmo-sgsn or even gtphub seems to be using them. Does anyone know of any users of those functions? Rather than keeping them updated manually without any test cases and users, I would say there's a strong argument to remove them from the code base. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Planning for OsmoCon + OsmoDevCon
by Harald Welte 14 Oct '17

14 Oct '17

[cross-post to many lists, please follow-up-to openbsc(a)lists.osmocom.org] Dear all, time is flying, and I would like to start early with discussions and planning about OsmoCon and OsmoDevCon in 2018. It helps to start early. Side note: We have some pending issues about the events from last year at http://osmocom.org/projects/osmo-dev-con/issues - I've incorporated them in the text below. == OsmoDevCon == For OsmoDevCon, I think it's easy: We keep it as-is. Same procedure as every year, which means: * same venue, same catering options * same concept of 'anyone contributing to Osmocom can apply for registration until all seats are taken' * same idea of inviting some few speaker[s] doing other FOSS mobile communications work to join us The parts that we need to change, IMHO: * don't reduce from 4 to 3 days like last year. Have full 4 days again * sort topics per day / half-day, i.e. have "GSM/UMTS Cellular Infrastructure" days for BTS/BSC/NITB/MSC/HLR/SGSN/GGSN & Co, but then have other days for other projects. This would enable people not interested in the [continued evolvement] of the cellular projects be able to skip those days, or to simply meet in an adjacent room for parallel hacking sessions/discussions * try to be a bit more structured with the schedule in general. The existing approach works for people who attend all the event all day long, but not so well for people with other plans / limited time Any further change requests or topics to discuss? Please note that Pablo Neira has offered to kindly host an OsmoDevCon in Seville (Spain). I've attended a number of netfilter workshops he organized there, and he's doing a great job! However, given the large number of attendees from Berlin (and Germany in general), I think this would make things more complicated, and more expensive for most attendees. If you disagree with that assessment: I'm open for having the discussion, I just thought it's more practical/economic to do it in Berlin. === 10 year Anniversary Party === Given that 2018 marks the 10 year anniversary of Dieter and me hacking with the Siemens BS-11 in 2008, I think the 2018 incarnation deserves some special celebration of some form. I have no concrete idea yet, but for sure we should so something, and it should be at/around OsmoDevCon. And for sure we should have a BS-11 around :) == OsmoCon == The public OsmoCon was welcomed and was a success. However, let's start this discussion with a review of last years event. === Registration === * Registrations came in way too late. Two weeks ahead of the event, we were considering to cancel it. And then within the last few days, we had to turn people down due to limited seating capacity * To make planning more reliable, we see on other option but to significantly raise the registration fee combined with an equally significant discount for early booking === Duration === * Many people requested multiple days rather than just one, in order to make more out of (long distance) travels. This is obvious, but as we had no idea how many people would attend at all (or if we have to cancel due to lack of attendance), planning multiple days in the first incarnation would have been high risk and a multitude of work * I would suggest to expand to two or even three days this week, possibly one days with tutorials and the other day with tech talks * Slightly less crammed schedule due to multiple days === Venue === We recognize this yearso venue was not the best option, due to * Bad ventilation in the basemenet * Difficult to find * No space next to the conference room where people can meet / hang out in parallel to talks (not everyone attends every talk) I still like the "understatement" of the venue. I'd prefer any hostel / non-profit / hackerspace / university over luxurious hotels any time. Going to an expensive venue means more or less automatically more expensive ticket fees, which again is more likely to exclude pure community members without a commercial activity related to Osmocom. So any future venue would ideally: * be able to hold slightly more people than this year * have a second room or large lobby in which people can meet for extended coffee breaks in parallel to some talks, as needed * be slightly easier to find (and we have to put up some signs outside and in the lobby) * have better WiFi and/or wired connectivity === Programme / Format === * less crammed over multiple days * some more "interactive" formats were requested, for users to provide feedback to developers * there was some discussion about topics / speakers in redmine last year, but not too much participation [until it was too late]. * I'd suggest a more formal CfP process with a submission deadline that allows us to publish a preliminary schedule long ahead of the event === Video Recordings === I think they were a big success, and it was a very big surprise that the CCC Video Operations Center was volunteering to help such a small and niche-interest event like OsmoCon. We should make sure that we can repeat this for 2018. == Dates / Frequency == Having OsmoCon and OsmoDevCon back to back becomes somewhat long, if OsmoCon is 2-3 days and OsmoDevCon is 4 days. Basically we're looking at a full week for those of you who would like to attend both events. But then, I think the number of people attending both events is actually not all that big. Without checking the details, I think not more than half of the OsmoDevCon attendees were attending OsmoCon. I would expect that tendency to remain or even increase. I still think it's good to keep them back-to-back. In terms of frequency, I would actually suggest we move to a 6-month cycle rather than a 12-month cycle. There's a lot of development going on at all time. I understand that not everyone is able to attend two events just on Osmocom, especially if it's a spare time / hobby type activity. That's ok, I think there's no problem with attending either of the two only, and catching up by video recordings and/or mail on the other. The qeustion is: Should that second event be developer-oriented or user-oriented? Or again both? Any comments here? Ok, that was a somewhat lengthy e-mail. Please make sure to provide any feedback you may have as early as possible, to increase the chances of your feedback being reflected in the planning. Happy hacking, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Current osmo-pcu patch set
by Holger Freyther 05 Oct '17

05 Oct '17

Hi, I am a bit lost with the review of the current osmo-pcu patchset. Going through the patches I have difficulties to see the red thread and what is better after we integrate the changes. I guess the goal is to add the allocation of multiple uplink timeslots but from my point of view this is buried in a lot of subjective sideway development. My wish would be: For multiple slot UL allocation: Make the most direct patchset to implement this feature. I understand that to avoid code duplication some methods can be re-used but instead of having 10 patches that change int->bool, change signatures of functions, maybe make it minimal to see how it works first? After it works send a cover mail that explains what and why you took the approach, what the _speed_ improvement for browsing is or when it is being used. What you see the danger in terms of common ts and allocation. For the clean-ups: I don't say we shouldn't do them but we should do them in a way they don't take much time to review and still provide a net gain to the contributor. A "cosmetic" patch that breaks the build is very suspicious and forces a reviewer to look extra carefully into these "clean-ups". int->bool: I think int->bool and 1->true adds little value for an application but if it is important then please do it by semantic patching so they can be easily reviewed. bts->trx: I think there is little value to change a function signature from getting a BTS to a TRX when the implementation starts to do: - bts->list + trx->bts->list "API" documentation: Comments can be helpful and it is good to explain on a high level what a function will do and what the side-effects will be. But in an application I think writing: \param[in,out] bts Pointer to BTS struct adds not enough value. First it is wrong as the type is not "BTS" but it is the "C" gprs_rlcmac_bts. And second doxygen will perfectly tell you the type of of the parameter anyway. Documenting that -1 of a parameter has a specific semantic can have some advantage but the risk of code/doc not agreeing is there as well. libosmocore: We do have a desire for reuse but everytime you make osmo-pcu depend on a unreleased version of libosmocore rebuilding osmo-pcu get's more difficult and the compile error is not obvious. It is not clear where the macro is coming from. So please keep this in mind and try to find a balance. thank you for your consideration holger

4 5

HEADS UP: stricter VTY, possible config fallout
by Neels Hofmeyr 21 Sep '17

21 Sep '17

Hi all, we have recently merged a profound change to the inner workings of the VTY configuration. We've hit some fallout due to that, hence I would like to let you know that you might hit the same. The VTY parsing of config files is now strict about indenting. A child node *must* be indented below the parent node, and indenting must be consistent. For more details on the reason why and a definition of 'consistent', see the commit log of https://git.osmocom.org/libosmocore/commit/?id=4a31ffa2f0097d96201f80305a04… So, if you are in the near future faced with config files being rejected that worked perfectly before, it is most probably because your indenting was wrong all the time, and only now did we start checking it. If the cause is hard to figure out, a good aid is the telnet VTY, where you may either 'show running-config' or traverse the nodes manually to query which command exists on which level. If your current config is broken, you may be able to start the program with an empty or stripped down config file to make its telnet available. The above is about reading config files, but we have also dropped the implicit 'exit' to parent level on the telnet VTY console. This caused fallout where nodes by plain omission lack the 'exit' command: one is unable to leave such a node once it is entered. That is a fault in the program's VTY setup that was not found before, because the VTY would often just find the parent node's exit command instead. I have a patch to avoid all of these everywhere, by installing the exit and end commands automatically for every VTY node that gets created; it is not merged yet: https://gerrit.osmocom.org/3998 ------ Config Fallout Example ------ For example, we hit a breakage with this osmo-bts-trx.cfg: phy 0 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 Before, this worked perfectly. Now it says the command 'osmotrx rx-gain' does not exist. The reason is that 'osmotrx rx-gain' is a child node of 'instance 0'. The first fix looked like this: phy 0 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 But alas, this time it said the command 'osmotrx ip local' does not exist. I suspected bugs in the new parsing, but indeed, 'osmotrx ip' is actually a direct child of the 'phy 0' level. Before, the VTY would implicitly step out of a child level if it found a matching command one parent above. That is confusing in other situations (see above commit log), hence we now require indenting to clarify the structure. This is the correct one: phy 0 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 Or rephrased: phy 0 osmotrx ip local 10.23.42.1 osmotrx ip remote 10.23.42.2 instance 0 osmotrx rx-gain 25 osmotrx tx-attenuation oml To query the structure via telnet, I did: $ ./osmo-bts/src/osmo-bts-trx/osmo-bts-trx -c osmo-bts/doc/examples/trx/osmo-bts.cfg $ telnet localhost 4241 OsmoBTS> enable OsmoBTS# configure terminal OsmoBTS(config)# phy 0 OsmoBTS(phy)# list [...] osmotrx ip HOST osmotrx ip (local|remote) A.B.C.D [...] OsmoBTS(phy)# inst OsmoBTS(phy)# instance 0 OsmoBTS(phy-inst)# list [...] osmotrx rx-gain <0-50> osmotrx tx-attenuation <0-50> osmotrx tx-attenuation oml [...] ------ No Exit Example ------ The same osmo-trx VTY nodes also show the exit failure: $ telnet localhost 4241 OsmoBTS> enable OsmoBTS# configure terminal OsmoBTS(config)# phy 0 OsmoBTS(phy)# exit % Unknown command. OsmoBTS(phy)# instance 0 OsmoBTS(phy-inst)# exit % Unknown command. On the phy level, we would previously find the parent's 'exit' command, but in the 'instance' level, 'exit' has never been available. Above patch should fix all of these. ~N -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

3 3

Kernel patchset for IPv6 support on netdev mailinglist
by Harald Welte 19 Sep '17

19 Sep '17

Hi all! Just in case anyone here is intrerested, I'd like to point out that a recent patch series for IPv6 (and other feature) support of the Linux kernel GTP-U code has been posted to the linux-netdev list and is under review/discussion there: https://www.spinics.net/lists/netdev/msg455286.html Please follow-up with any review comments there. Thanks! -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

回复：Re: Unable to access git repository
by lokira 19 Sep '17

19 Sep '17

Hi Holger, It's working now!Thanks for the quick fix! Regards, WangSS

1 0

Unable to access git repository
by lokira 19 Sep '17

19 Sep '17

Hello, I was trying to clone git repository from http://git.osmocom.org/libgtpnl/but got an error : remote: An error occurred while reading CGI reply (no response received)fatal: unable to access 'http://git.osmocom.org/libgtpnl/': The requested URL returned error: 502 I can't open http://git.osmocom.org/libgtpnl/ in browser either. It said 'An error occurred while reading CGI reply (no response received)'. Is my url to git repository wrong ? Thanks, WangSS

2 1

Update and Question
by fırat sönmez 18 Sep '17

18 Sep '17

Hi, I want to ask two questions. I dont know if you remember, but I have been trying to backport GTP to 3.18 kernel. I fixed all the errors, it works. However there is one issue that I'm not sure how to implement it correctly. --->There is one private flag called IFF_NO_QUEUE and it has no implemetation in 3.18 kernel, I just set it to an unused bit in the private flag field. I would like to get your opinion on this. *include/linux/netdevice.h ->(*@IFF_NO_QUEUE: device can run without qdisc attached*) The other thing I would like to ask is that I cannot reach the git repository for libgtpnl. Could you please check it? Thanks, Fırat

1 0

Unable to start osmo-ggsn with -g or --gtp-linux options
by Ravi Tandon 14 Sep '17

14 Sep '17

Hello, I compiled osmo-ggsn and was trying to run it as per the instructions present on https://osmocom.org/projects/openggsn/wiki/Kernel_GTP But when I try to start osmo-ggsn *using -g or --gtp-linux*, it says invalid option. Please let me know how to start it using gtp kernel. I have modprobed gtp.ko successfully. [root@localhost osmo-ggsn]# lsmod |grep gtp gtp 28672 0 ip6_udp_tunnel 16384 1 gtp udp_tunnel 16384 1 gtp [root@localhost examples]# osmo-ggsn --gtp-linux -c osmo-ggsn.cfg -d *osmo-ggsn: unrecognized option '--gtp-linux'* <0002> ggsn.c:159 APN(internet): Starting <0002> ggsn.c:162 APN(internet): Opening TUN device tun4 <0002> ggsn.c:167 APN(internet): Opened TUN device tun4 <0002> ggsn.c:178 APN(internet): Setting tun IP address 176.16.222.0/24 <0002> ggsn.c:224 APN(internet): Creating IPv4 pool 176.16.222.0/24 <0002> ggsn.c:245 APN(internet): Successfully started <0002> ggsn.c:159 APN(inet6): Starting <0002> ggsn.c:162 APN(inet6): Opening TUN device tun6 <0002> ggsn.c:167 APN(inet6): Opened TUN device tun6 <0002> ggsn.c:190 APN(inet6): Setting tun IPv6 address 2001:780:44:2000::/56 <0002> ggsn.c:236 APN(inet6): Creating IPv6 pool 2001:780:44:2000::/56 <0002> ggsn.c:245 APN(inet6): Successfully started <0002> ggsn.c:159 APN(inet46): Starting <0002> ggsn.c:162 APN(inet46): Opening TUN device tun46 <0002> ggsn.c:167 APN(inet46): Opened TUN device tun46 <0002> ggsn.c:178 APN(inet46): Setting tun IP address 176.16.46.0/24 <0002> ggsn.c:190 APN(inet46): Setting tun IPv6 address 2001:780:44:2100::/56 <0002> ggsn.c:224 APN(inet46): Creating IPv4 pool 176.16.46.0/24 <0002> ggsn.c:236 APN(inet46): Creating IPv6 pool 2001:780:44:2100::/56 <0002> ggsn.c:245 APN(inet46): Successfully started <0002> ggsn.c:687 GGSN(ggsn0): Starting GGSN <000d> gtp.c:705 GTP: gtp_newgsn() started at 192.168.11.128 <0002> ggsn.c:724 GGSN(ggsn0): Successfully started <0005> telnet_interface.c:102 telnet at 127.0.0.1 4260 <000c> control_if.c:788 CTRL at 127.0.0.1 4257 Also, I tried executing gtp-tunnel list but it gives empty output. [root@localhost tools]# ./gtp-tunnel list [root@localhost tools]# Please help. Thanks, Ravi <https://osmocom.org/projects/openggsn/wiki/Kernel_GTP>

2 1

OsmoGGSN succeeds OpenGGSN!
by Harald Welte 06 Sep '17

06 Sep '17

Hi all, 12 years after OpenGGSN was seemingly abandoned by its original creators, and 7 years after Osmocom adopted it, it is time for a significant change: OpenGGSN is becoming a first-class Osmocom citizen called OsmoGGSN. We had already taken some baby-steps in the past by introduction of a CTRL interface as well as the use of libosmocore logging. However, my recent patches introducing a VTY interface and changing the configuration file format from the 'gengetopt' style to libosmovty based change the look+feel of the program significantly that it is a good point to rename. After all, if command-line arguments and config file syntax are changing, documentation will also need to change and it becomes confusing to users to understand that depending on the version the documentation is correct or incorrect. So from today on, * osmo-ggsn is available from http://git.osmocom.org/osmo-ggsn/ * osmocom:nightly packages will build both openggsn + osmo-ggsn * osmocom:nitb-split:nightly packages will only build osmo-ggsn * redmine still at http://osmocom.org/projects/openggsn due to permanent redmine project naming... The introduction of the VTY interface comes with many new possibilities, such as * multiple GGSN instances bound to different GTP IP addresses * multiple APNs within each GGSN, each with different Address Pools and tun-devices * sophisticated logging configuration (syslog, file, stdout, telnet) What's still missing: * re-integrate kernel GTP-U support * create OsmoGGSN user manual in osmo-gsm-manuals.git * migrate TTCN-3 test execution on jenkins to osmo-ggsn * perl/python script to convert old config file to new config file format (any volunteers?) Roadmap: * IPv6 transport plane support (outer IP layer surrounding GTP/UDP) * improved logging (ensure context is always included) * libgtp: migration of kernel GTP-U support into libgtp (not just ggsn) * libgtp: make PDP context hash table part of the 'gsn' structure * once all expected ABI/API changes are done, rename libgtp to libosmo-gtp In terms of maintenance, I don't want to continue to maintain OpenGGSN for much longer. We'll keep it around for some time and merge important security and/or bug fixes, but I won't accept new feature patches into OpenGGSN. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

2 2

GTP-C v2 in open grps
by Tom Herbert 04 Sep '17

04 Sep '17

Hello, I am a newbie in this area so please pardon me if these are dumb or covered questions! I am looking for a GTP stack that implements GTP-C version 2. Is this supported in open grps or is there a plan for that? If not, what stack (preferably open source) is recommended? Thanks, Tom

3 6

RFC: OpenGGSN split/rename
by Max 02 Sep '17

02 Sep '17

Hi. With the ongoing split of OpenBSC into per-project repository, I wonder if we could do the same to OpenGGSN and split libgtp into separate repository? Rationale: * would simplify docs for newcomers (it's not obvious that openggsn have to be built ahead of OsmoSGSN because of libgtp) * simplify release process (we can release libgtp independently of OpenGGSN, makes it easier to automate too) While at it and considering recent IPv6 support (and related config changes) it might be also good idea to rename it to OsmoGGSN (and libosmo-gtp?) to clearly mark the breaking point. What do you think? -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

3 5

redmine e-mails broken from 08/26 through 08/31
by Harald Welte 31 Aug '17

31 Aug '17

Dear Osmocom community, from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org redmine could not send any e-mails. This was due to a configuration file syntax error introduced by me, my apologies. If you rely on redmine e-mail notifications to the issues you have subscribed to, please double-check as related notifications during that interval were unfortunately lost. Best regards, Harald p.s.: The reason for the config change was to enable e-mail notifications from jenkins.osmocom.org (which it now has, if you want to configure e.g. post-build notification actions). -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

OpenGGSN IPv6 PDP context support
by Harald Welte 03 Aug '17

03 Aug '17

Dear all, I've been busy all day (and night) implementing IPv6 PDP context support in OpenGGSN. The related code is currently in gerrit for review, you can also use the 'laforge/ipv6' branch of openggsn.git In terms of configuration, all you need to do is to specify IPv6 address + prefix as the 'net'. If you don't specify a 'dynip' config option, it will automatically use the network/prefix specified in 'net'. My minimalistic example config file for testing looks like this: debug fg listen 127.0.0.6 net 2001:780:44:2000:0:0:0:0/120 Which means it is listening for GTP on IPv4 (no IPv6 on the GTP side supported), and will create a tun device with the stated IPv6 address and a /120 netmask. Your GGSN is 2001:780:44:2000::1, and UEs will get addresses allocated from 2001:780:44:2000::2 onwards. It's important to configure your UE to actually request and IPv6 PDP context. If no v4/v6 is specified in the request, it will default to IPv4. If IPv4 is requested while having a v6 pool configured, OpenGGSN will reject the PDP Context Creation due to not being able to serve a v4 PDP context. I don't have immediate plans for supporting IPv6 on the outer (transport) layer for now. I also have no plans to support v4 and v6 from a single OpenGGSN at this time. It's quite easy to run two different OpenGGSN instances in parallel, on two different IPv4 addresses for the GTP side, and then use OsmoSGSN's PDP context routing to those different GGSNs. This way it is possible to have a v4 APN and a v6 APN without having to do any additional development right now. Architecturally, having multiple IP pools (and some for v4 and some for v6) is definitely possible, and should actually be easy. We just need to switch to a configuration mechanism that supports something like this, such as libosmovty. Once we have a VTY based configuration, it should be simple to operate multiple IP pools or multiple virtual APNs on one OpenGGSN. WARNING: The Linux Kernel GTP code does *not* support IPv6 user payload at this point. So if you want IPv6, you will need to use regular, old-fashioned userspace GTP-U in OpenGGSN for now. Controbutions are always welcome, of course! Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

[PATCH net-next v1 0/3] Flow Based GTP Tunneling
by Jiannan Ouyang 02 Aug '17

02 Aug '17

This patch series augmented the existing GTP module to support flow based GTP tunneling and modified the openvswitch datapath to support the GTP vport type. A flow based GTP net device enables that, 1) on the RX path, the outer (IP/UDP/GTP) header information could to be stored in the metadata_dst struct, and embedded into the skb. 2) on the TX path, packets are encapsulated following instructions in the metadata_dst field of the skb. A flow based GTP net device can be integrated with Open vSwitch, which allows SDN controllers to program GTP tunnels via Open vSwitch. Open vSwitch changes are based on patch set [PATCH] Add GTP vport based on upstream datapath Example usage with OVS: ovs-vsctl add-port br0 gtp-vport -- set interface gtp-vport \ ofport_request=2 type=gtp option:remote_ip=flow options:key=flow ovs-ofctl add-flow br0 "in_port=2,tun_src=192.168.60.141,tun_id=123, \ actions=set_field:02:00:00:00:00:00->eth_src, \ set_field:ff:ff:ff:ff:ff:ff->eth_dst,LOCAL" ovs-ofctl add-flow br0 \ "in_port=LOCAL,actions=set_tunnel:888, \ set_field:192.168.60.141->tun_dst,2" arp -s 10.1.1.122 02:00:00:00:00:00 Jiannan Ouyang (3): gtp: refactor to support flow-based gtp encap and decap gtp: Support creating flow-based gtp net_device openvswitch: Add GPRS Tunnel Protocol (GTP) vport support drivers/net/gtp.c | 375 ++++++++++++++++++++++++++++++++------- include/net/gtp.h | 8 + include/uapi/linux/openvswitch.h | 1 + net/openvswitch/Kconfig | 10 ++ net/openvswitch/Makefile | 1 + net/openvswitch/vport-gtp.c | 144 +++++++++++++++ 6 files changed, 475 insertions(+), 64 deletions(-) create mode 100644 net/openvswitch/vport-gtp.c -- 2.9.3

6 16

[PATCH net 5/7] gtp: Initialize 64-bit per-cpu stats correctly
by Florian Fainelli 02 Aug '17

02 Aug '17

On 32-bit hosts and with CONFIG_DEBUG_LOCK_ALLOC we should be seeing a lockdep splat indicating this seqcount is not correctly initialized, fix that by using netdev_alloc_pcpu_stats() instead of an open coded allocation. Fixes: 459aa660eb1d ("gtp: add initial driver for datapath of GPRS Tunneling Protocol (GTP-U)") Signed-off-by: Florian Fainelli <f.fainelli(a)gmail.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 1542e837fdfa..f38e32a7ec9c 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -364,7 +364,7 @@ static int gtp_dev_init(struct net_device *dev) gtp->dev = dev; - dev->tstats = alloc_percpu(struct pcpu_sw_netstats); + dev->tstats = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats); if (!dev->tstats) return -ENOMEM; -- 2.9.3

2 1

GTP in previous kernels
by fırat sönmez 10 Jul '17

10 Jul '17

Hi, I am currently working on building a GTP tunnel between two hosts. I used two virtual machines to implement GTP tunnel. The machines have the kernel 4.8 since GTP is in mainline. (I just did 'modprobe gtp') I setup the tunnel with libgtpnl tools. What I would like to do is that I want to have GTP module in a kernel 3.18. I did some google search and then I added the headers, libraries and the source code to the source code of 3.18 to compile all the kernel, but it didnt work. I am not experienced in kernel module programming or about the consequences compiling GTP in previous kernels which have different structural mechanisms than the 4.* versions. Is there any way to achieve this? If so, how could it be possible to get help from this community? Thanks all, Fırat

2 1

[PATCH net-next] net: add netlink_ext_ack support to rtnl_link_ops
by Matthias Schiffer 25 Jun '17

25 Jun '17

The following functions are extended with a netlink_ext_ack argument to allow extended error reporting: * validate * newlink * changelink * slave_validate * slave_changelink Signed-off-by: Matthias Schiffer <mschiffer(a)universe-factory.net> --- Checkpatch is unhappy about the long lines in include/net/rtnetlink.h, but I guess it's as readable as it gets... Most work was done by the following Coccinelle snippet, the original version of which was provided by Johannes Berg: @ops1@ identifier newfn, ops; @@ struct rtnl_link_ops ops = { .newlink = newfn, ... }; @@ identifier ops1.newfn; identifier src_net, dev, tb, data; @@ -int newfn(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) +int newfn(struct net *src_net, struct net_device *dev, + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) {...} @ops2@ identifier chfn, ops; @@ struct rtnl_link_ops ops = { .changelink = chfn, ... }; @@ identifier ops2.chfn; identifier dev, tb, data; @@ -int chfn(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) +int chfn(struct net_device *dev, + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) {...} @ops3@ identifier valfn, ops; @@ struct rtnl_link_ops ops = { .validate = valfn, ... }; @@ identifier ops3.valfn; identifier tb, data; @@ -int valfn(struct nlattr *tb[], struct nlattr *data[]) +int valfn(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) {...} @ops4@ identifier chfn, ops; @@ struct rtnl_link_ops ops = { .slave_changelink = chfn, ... }; @@ identifier ops4.chfn; identifier dev, slave_dev, tb, data; @@ -int chfn(struct net_device *dev, struct net_device *slave_dev, - struct nlattr *tb[], struct nlattr *data[]) +int chfn(struct net_device *dev, struct net_device *slave_dev, + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) {...} @ops5@ identifier valfn, ops; @@ struct rtnl_link_ops ops = { .slave_validate = valfn, ... }; @@ identifier ops5.valfn; identifier tb, data; @@ -int valfn(struct nlattr *tb[], struct nlattr *data[]) +int valfn(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) {...} drivers/infiniband/ulp/ipoib/ipoib_netlink.c | 10 ++++++---- drivers/net/bonding/bond_netlink.c | 16 ++++++++++------ drivers/net/caif/caif_hsi.c | 6 ++++-- drivers/net/can/dev.c | 11 +++++++---- drivers/net/can/vxcan.c | 3 ++- drivers/net/dummy.c | 3 ++- drivers/net/geneve.c | 6 ++++-- drivers/net/gtp.c | 6 ++++-- drivers/net/ifb.c | 3 ++- drivers/net/ipvlan/ipvlan.h | 3 ++- drivers/net/ipvlan/ipvlan_main.c | 9 ++++++--- drivers/net/ipvlan/ipvtap.c | 9 ++++----- drivers/net/macsec.c | 9 ++++++--- drivers/net/macvlan.c | 9 ++++++--- drivers/net/macvtap.c | 7 +++---- drivers/net/nlmon.c | 3 ++- drivers/net/ppp/ppp_generic.c | 6 ++++-- drivers/net/team/team.c | 6 ++++-- drivers/net/tun.c | 3 ++- drivers/net/veth.c | 8 +++++--- drivers/net/vrf.c | 6 ++++-- drivers/net/vxlan.c | 9 ++++++--- include/net/rtnetlink.h | 15 ++++++++++----- net/8021q/vlan_netlink.c | 13 ++++++++----- net/bridge/br_netlink.c | 15 ++++++++++----- net/caif/chnl_net.c | 6 ++++-- net/core/rtnetlink.c | 13 ++++++++----- net/hsr/hsr_netlink.c | 3 ++- net/ieee802154/6lowpan/core.c | 6 ++++-- net/ipv4/ip_gre.c | 16 ++++++++++------ net/ipv4/ip_vti.c | 9 ++++++--- net/ipv4/ipip.c | 9 ++++++--- net/ipv6/ip6_gre.c | 14 +++++++++----- net/ipv6/ip6_tunnel.c | 9 ++++++--- net/ipv6/ip6_vti.c | 9 ++++++--- net/ipv6/sit.c | 9 ++++++--- 36 files changed, 190 insertions(+), 107 deletions(-) diff --git a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c index 28884781311b..3e44087935ae 100644 --- a/drivers/infiniband/ulp/ipoib/ipoib_netlink.c +++ b/drivers/infiniband/ulp/ipoib/ipoib_netlink.c @@ -64,8 +64,9 @@ static int ipoib_fill_info(struct sk_buff *skb, const struct net_device *dev) return -EMSGSIZE; } -static int ipoib_changelink(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) +static int ipoib_changelink(struct net_device *dev, struct nlattr *tb[], + struct nlattr *data[], + struct netlink_ext_ack *extack) { u16 mode, umcast; int ret = 0; @@ -93,7 +94,8 @@ static int ipoib_changelink(struct net_device *dev, } static int ipoib_new_child_link(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_device *pdev; struct ipoib_dev_priv *ppriv; @@ -133,7 +135,7 @@ static int ipoib_new_child_link(struct net *src_net, struct net_device *dev, child_pkey, IPOIB_RTNL_CHILD); if (!err && data) - err = ipoib_changelink(dev, tb, data); + err = ipoib_changelink(dev, tb, data, extack); return err; } diff --git a/drivers/net/bonding/bond_netlink.c b/drivers/net/bonding/bond_netlink.c index 47a8103610bc..a1b33aa6054a 100644 --- a/drivers/net/bonding/bond_netlink.c +++ b/drivers/net/bonding/bond_netlink.c @@ -118,7 +118,8 @@ static const struct nla_policy bond_slave_policy[IFLA_BOND_SLAVE_MAX + 1] = { [IFLA_BOND_SLAVE_QUEUE_ID] = { .type = NLA_U16 }, }; -static int bond_validate(struct nlattr *tb[], struct nlattr *data[]) +static int bond_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -131,7 +132,8 @@ static int bond_validate(struct nlattr *tb[], struct nlattr *data[]) static int bond_slave_changelink(struct net_device *bond_dev, struct net_device *slave_dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct bonding *bond = netdev_priv(bond_dev); struct bond_opt_value newval; @@ -156,8 +158,9 @@ static int bond_slave_changelink(struct net_device *bond_dev, return 0; } -static int bond_changelink(struct net_device *bond_dev, - struct nlattr *tb[], struct nlattr *data[]) +static int bond_changelink(struct net_device *bond_dev, struct nlattr *tb[], + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct bonding *bond = netdev_priv(bond_dev); struct bond_opt_value newval; @@ -438,11 +441,12 @@ static int bond_changelink(struct net_device *bond_dev, } static int bond_newlink(struct net *src_net, struct net_device *bond_dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { int err; - err = bond_changelink(bond_dev, tb, data); + err = bond_changelink(bond_dev, tb, data, extack); if (err < 0) return err; diff --git a/drivers/net/caif/caif_hsi.c b/drivers/net/caif/caif_hsi.c index 11ba6e3eea22..438966bf51c2 100644 --- a/drivers/net/caif/caif_hsi.c +++ b/drivers/net/caif/caif_hsi.c @@ -1352,7 +1352,8 @@ static void cfhsi_netlink_parms(struct nlattr *data[], struct cfhsi *cfhsi) } static int caif_hsi_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { cfhsi_netlink_parms(data, netdev_priv(dev)); netdev_state_change(dev); @@ -1399,7 +1400,8 @@ static int caif_hsi_fill_info(struct sk_buff *skb, const struct net_device *dev) } static int caif_hsi_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct cfhsi *cfhsi = NULL; struct cfhsi_ops *(*get_ops)(void); diff --git a/drivers/net/can/dev.c b/drivers/net/can/dev.c index a3011c001080..365a8cc62405 100644 --- a/drivers/net/can/dev.c +++ b/drivers/net/can/dev.c @@ -848,7 +848,8 @@ static const struct nla_policy can_policy[IFLA_CAN_MAX + 1] = { = { .len = sizeof(struct can_bittiming_const) }, }; -static int can_validate(struct nlattr *tb[], struct nlattr *data[]) +static int can_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { bool is_can_fd = false; @@ -880,8 +881,9 @@ static int can_validate(struct nlattr *tb[], struct nlattr *data[]) return 0; } -static int can_changelink(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) +static int can_changelink(struct net_device *dev, struct nlattr *tb[], + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct can_priv *priv = netdev_priv(dev); int err; @@ -1146,7 +1148,8 @@ static int can_fill_xstats(struct sk_buff *skb, const struct net_device *dev) } static int can_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { return -EOPNOTSUPP; } diff --git a/drivers/net/can/vxcan.c b/drivers/net/can/vxcan.c index cfe889e8f172..8404e8852a0f 100644 --- a/drivers/net/can/vxcan.c +++ b/drivers/net/can/vxcan.c @@ -163,7 +163,8 @@ static void vxcan_setup(struct net_device *dev) static struct rtnl_link_ops vxcan_link_ops; static int vxcan_newlink(struct net *net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct vxcan_priv *priv; struct net_device *peer; diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c index 9905b52fe293..d0c165d2086e 100644 --- a/drivers/net/dummy.c +++ b/drivers/net/dummy.c @@ -356,7 +356,8 @@ static void dummy_setup(struct net_device *dev) dev->max_mtu = ETH_MAX_MTU; } -static int dummy_validate(struct nlattr *tb[], struct nlattr *data[]) +static int dummy_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) diff --git a/drivers/net/geneve.c b/drivers/net/geneve.c index d586ad93aaff..eb77201cb718 100644 --- a/drivers/net/geneve.c +++ b/drivers/net/geneve.c @@ -1058,7 +1058,8 @@ static const struct nla_policy geneve_policy[IFLA_GENEVE_MAX + 1] = { [IFLA_GENEVE_UDP_ZERO_CSUM6_RX] = { .type = NLA_U8 }, }; -static int geneve_validate(struct nlattr *tb[], struct nlattr *data[]) +static int geneve_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -1181,7 +1182,8 @@ static void init_tnl_info(struct ip_tunnel_info *info, __u16 dst_port) } static int geneve_newlink(struct net *net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { bool use_udp6_rx_checksums = false; struct ip_tunnel_info info; diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 8e333a8a2295..1542e837fdfa 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -636,7 +636,8 @@ static void gtp_hashtable_free(struct gtp_dev *gtp); static int gtp_encap_enable(struct gtp_dev *gtp, struct nlattr *data[]); static int gtp_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct gtp_dev *gtp; struct gtp_net *gn; @@ -697,7 +698,8 @@ static const struct nla_policy gtp_policy[IFLA_GTP_MAX + 1] = { [IFLA_GTP_ROLE] = { .type = NLA_U32 }, }; -static int gtp_validate(struct nlattr *tb[], struct nlattr *data[]) +static int gtp_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (!data) return -EINVAL; diff --git a/drivers/net/ifb.c b/drivers/net/ifb.c index 144ea5ae8ab4..8870bd2a2e8a 100644 --- a/drivers/net/ifb.c +++ b/drivers/net/ifb.c @@ -273,7 +273,8 @@ static int ifb_open(struct net_device *dev) return 0; } -static int ifb_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ifb_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) diff --git a/drivers/net/ipvlan/ipvlan.h b/drivers/net/ipvlan/ipvlan.h index 7919369c0a72..ba8173a0b62e 100644 --- a/drivers/net/ipvlan/ipvlan.h +++ b/drivers/net/ipvlan/ipvlan.h @@ -140,7 +140,8 @@ unsigned int ipvlan_nf_input(void *priv, struct sk_buff *skb, void ipvlan_count_rx(const struct ipvl_dev *ipvlan, unsigned int len, bool success, bool mcast); int ipvlan_link_new(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]); + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack); void ipvlan_link_delete(struct net_device *dev, struct list_head *head); void ipvlan_link_setup(struct net_device *dev); int ipvlan_link_register(struct rtnl_link_ops *ops); diff --git a/drivers/net/ipvlan/ipvlan_main.c b/drivers/net/ipvlan/ipvlan_main.c index dc888dd344eb..f37e3c1fd4e7 100644 --- a/drivers/net/ipvlan/ipvlan_main.c +++ b/drivers/net/ipvlan/ipvlan_main.c @@ -455,7 +455,8 @@ static const struct ethtool_ops ipvlan_ethtool_ops = { }; static int ipvlan_nl_changelink(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ipvl_dev *ipvlan = netdev_priv(dev); struct ipvl_port *port = ipvlan_port_get_rtnl(ipvlan->phy_dev); @@ -476,7 +477,8 @@ static size_t ipvlan_nl_getsize(const struct net_device *dev) ); } -static int ipvlan_nl_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ipvlan_nl_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (data && data[IFLA_IPVLAN_MODE]) { u16 mode = nla_get_u16(data[IFLA_IPVLAN_MODE]); @@ -508,7 +510,8 @@ static int ipvlan_nl_fillinfo(struct sk_buff *skb, } int ipvlan_link_new(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ipvl_dev *ipvlan = netdev_priv(dev); struct ipvl_port *port; diff --git a/drivers/net/ipvlan/ipvtap.c b/drivers/net/ipvlan/ipvtap.c index 2b713b63b62c..22f133ea8d7b 100644 --- a/drivers/net/ipvlan/ipvtap.c +++ b/drivers/net/ipvlan/ipvtap.c @@ -73,10 +73,9 @@ static void ipvtap_update_features(struct tap_dev *tap, netdev_update_features(vlan->dev); } -static int ipvtap_newlink(struct net *src_net, - struct net_device *dev, - struct nlattr *tb[], - struct nlattr *data[]) +static int ipvtap_newlink(struct net *src_net, struct net_device *dev, + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ipvtap_dev *vlantap = netdev_priv(dev); int err; @@ -98,7 +97,7 @@ static int ipvtap_newlink(struct net *src_net, /* Don't put anything that may fail after macvlan_common_newlink * because we can't undo what it does. */ - err = ipvlan_link_new(src_net, dev, tb, data); + err = ipvlan_link_new(src_net, dev, tb, data, extack); if (err) { netdev_rx_handler_unregister(dev); return err; diff --git a/drivers/net/macsec.c b/drivers/net/macsec.c index e370d7c894cb..5e1ab1160856 100644 --- a/drivers/net/macsec.c +++ b/drivers/net/macsec.c @@ -3056,7 +3056,8 @@ static void macsec_changelink_common(struct net_device *dev, } static int macsec_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { if (!data) return 0; @@ -3203,7 +3204,8 @@ static int macsec_add_dev(struct net_device *dev, sci_t sci, u8 icv_len) } static int macsec_newlink(struct net *net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct macsec_dev *macsec = macsec_priv(dev); struct net_device *real_dev; @@ -3285,7 +3287,8 @@ static int macsec_newlink(struct net *net, struct net_device *dev, return err; } -static int macsec_validate_attr(struct nlattr *tb[], struct nlattr *data[]) +static int macsec_validate_attr(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { u64 csid = MACSEC_DEFAULT_CIPHER_ID; u8 icv_len = DEFAULT_ICV_LEN; diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c index 8ca274c6df3d..9ffff0362a11 100644 --- a/drivers/net/macvlan.c +++ b/drivers/net/macvlan.c @@ -1162,7 +1162,8 @@ static void macvlan_port_destroy(struct net_device *dev) kfree(port); } -static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[]) +static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -1390,7 +1391,8 @@ int macvlan_common_newlink(struct net *src_net, struct net_device *dev, EXPORT_SYMBOL_GPL(macvlan_common_newlink); static int macvlan_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { return macvlan_common_newlink(src_net, dev, tb, data); } @@ -1408,7 +1410,8 @@ void macvlan_dellink(struct net_device *dev, struct list_head *head) EXPORT_SYMBOL_GPL(macvlan_dellink); static int macvlan_changelink(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct macvlan_dev *vlan = netdev_priv(dev); enum macvlan_mode mode; diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c index da85057680d6..91e7b19bbf86 100644 --- a/drivers/net/macvtap.c +++ b/drivers/net/macvtap.c @@ -77,10 +77,9 @@ static void macvtap_update_features(struct tap_dev *tap, netdev_update_features(vlan->dev); } -static int macvtap_newlink(struct net *src_net, - struct net_device *dev, - struct nlattr *tb[], - struct nlattr *data[]) +static int macvtap_newlink(struct net *src_net, struct net_device *dev, + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct macvtap_dev *vlantap = netdev_priv(dev); int err; diff --git a/drivers/net/nlmon.c b/drivers/net/nlmon.c index c4b3362da4a2..4b22955de191 100644 --- a/drivers/net/nlmon.c +++ b/drivers/net/nlmon.c @@ -127,7 +127,8 @@ static void nlmon_setup(struct net_device *dev) dev->min_mtu = sizeof(struct nlmsghdr); } -static int nlmon_validate(struct nlattr *tb[], struct nlattr *data[]) +static int nlmon_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) return -EINVAL; diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c index d42091f11eb8..13028833bee3 100644 --- a/drivers/net/ppp/ppp_generic.c +++ b/drivers/net/ppp/ppp_generic.c @@ -1061,7 +1061,8 @@ static const struct nla_policy ppp_nl_policy[IFLA_PPP_MAX + 1] = { [IFLA_PPP_DEV_FD] = { .type = NLA_S32 }, }; -static int ppp_nl_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ppp_nl_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (!data) return -EINVAL; @@ -1075,7 +1076,8 @@ static int ppp_nl_validate(struct nlattr *tb[], struct nlattr *data[]) } static int ppp_nl_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ppp_config conf = { .unit = -1, diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c index 629a412dc690..464570409796 100644 --- a/drivers/net/team/team.c +++ b/drivers/net/team/team.c @@ -2101,7 +2101,8 @@ static void team_setup(struct net_device *dev) } static int team_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS] == NULL) eth_hw_addr_random(dev); @@ -2109,7 +2110,8 @@ static int team_newlink(struct net *src_net, struct net_device *dev, return register_netdevice(dev); } -static int team_validate(struct nlattr *tb[], struct nlattr *data[]) +static int team_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index ae49f4b99b67..3d4c24572ecd 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1580,7 +1580,8 @@ static void tun_setup(struct net_device *dev) /* Trivial set of netlink ops to allow deleting tun or tap * device with netlink. */ -static int tun_validate(struct nlattr *tb[], struct nlattr *data[]) +static int tun_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { return -EINVAL; } diff --git a/drivers/net/veth.c b/drivers/net/veth.c index 0156fe8cac17..b33553b1e19c 100644 --- a/drivers/net/veth.c +++ b/drivers/net/veth.c @@ -329,7 +329,8 @@ static void veth_setup(struct net_device *dev) * netlink interface */ -static int veth_validate(struct nlattr *tb[], struct nlattr *data[]) +static int veth_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -347,7 +348,8 @@ static int veth_validate(struct nlattr *tb[], struct nlattr *data[]) static struct rtnl_link_ops veth_link_ops; static int veth_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { int err; struct net_device *peer; @@ -373,7 +375,7 @@ static int veth_newlink(struct net *src_net, struct net_device *dev, if (err < 0) return err; - err = veth_validate(peer_tb, NULL); + err = veth_validate(peer_tb, NULL, extack); if (err < 0) return err; diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c index 997ef25189fd..f4d0054981c6 100644 --- a/drivers/net/vrf.c +++ b/drivers/net/vrf.c @@ -1372,7 +1372,8 @@ static void vrf_setup(struct net_device *dev) dev->priv_flags |= IFF_NO_QUEUE; } -static int vrf_validate(struct nlattr *tb[], struct nlattr *data[]) +static int vrf_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -1389,7 +1390,8 @@ static void vrf_dellink(struct net_device *dev, struct list_head *head) } static int vrf_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_vrf *vrf = netdev_priv(dev); bool *add_fib_rules; diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index 653b2bb32be1..0dafd8e6c665 100644 --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -2711,7 +2711,8 @@ static const struct nla_policy vxlan_policy[IFLA_VXLAN_MAX + 1] = { [IFLA_VXLAN_REMCSUM_NOPARTIAL] = { .type = NLA_FLAG }, }; -static int vxlan_validate(struct nlattr *tb[], struct nlattr *data[]) +static int vxlan_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) { @@ -3333,7 +3334,8 @@ static int vxlan_nl2conf(struct nlattr *tb[], struct nlattr *data[], } static int vxlan_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct vxlan_config conf; int err; @@ -3346,7 +3348,8 @@ static int vxlan_newlink(struct net *src_net, struct net_device *dev, } static int vxlan_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct vxlan_dev *vxlan = netdev_priv(dev); struct vxlan_rdst *dst = &vxlan->default_dst; diff --git a/include/net/rtnetlink.h b/include/net/rtnetlink.h index 78fa5fe32947..abe6b733d473 100644 --- a/include/net/rtnetlink.h +++ b/include/net/rtnetlink.h @@ -63,15 +63,18 @@ struct rtnl_link_ops { int maxtype; const struct nla_policy *policy; int (*validate)(struct nlattr *tb[], - struct nlattr *data[]); + struct nlattr *data[], + struct netlink_ext_ack *extack); int (*newlink)(struct net *src_net, struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]); + struct nlattr *data[], + struct netlink_ext_ack *extack); int (*changelink)(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]); + struct nlattr *data[], + struct netlink_ext_ack *extack); void (*dellink)(struct net_device *dev, struct list_head *head); @@ -88,11 +91,13 @@ struct rtnl_link_ops { int slave_maxtype; const struct nla_policy *slave_policy; int (*slave_validate)(struct nlattr *tb[], - struct nlattr *data[]); + struct nlattr *data[], + struct netlink_ext_ack *extack); int (*slave_changelink)(struct net_device *dev, struct net_device *slave_dev, struct nlattr *tb[], - struct nlattr *data[]); + struct nlattr *data[], + struct netlink_ext_ack *extack); size_t (*get_slave_size)(const struct net_device *dev, const struct net_device *slave_dev); int (*fill_slave_info)(struct sk_buff *skb, diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c index 9c94aad153b3..5e831de3103e 100644 --- a/net/8021q/vlan_netlink.c +++ b/net/8021q/vlan_netlink.c @@ -39,7 +39,8 @@ static inline int vlan_validate_qos_map(struct nlattr *attr) NULL); } -static int vlan_validate(struct nlattr *tb[], struct nlattr *data[]) +static int vlan_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ifla_vlan_flags *flags; u16 id; @@ -87,8 +88,9 @@ static int vlan_validate(struct nlattr *tb[], struct nlattr *data[]) return 0; } -static int vlan_changelink(struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) +static int vlan_changelink(struct net_device *dev, struct nlattr *tb[], + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ifla_vlan_flags *flags; struct ifla_vlan_qos_mapping *m; @@ -115,7 +117,8 @@ static int vlan_changelink(struct net_device *dev, } static int vlan_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct vlan_dev_priv *vlan = vlan_dev_priv(dev); struct net_device *real_dev; @@ -153,7 +156,7 @@ static int vlan_newlink(struct net *src_net, struct net_device *dev, else if (dev->mtu > max_mtu) return -EINVAL; - err = vlan_changelink(dev, tb, data); + err = vlan_changelink(dev, tb, data, extack); if (err < 0) return err; diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c index 63dca347b73b..3bc890716c89 100644 --- a/net/bridge/br_netlink.c +++ b/net/bridge/br_netlink.c @@ -858,7 +858,9 @@ int br_dellink(struct net_device *dev, struct nlmsghdr *nlh, u16 flags) return err; } -static int br_validate(struct nlattr *tb[], struct nlattr *data[]) + +static int br_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != ETH_ALEN) @@ -895,7 +897,8 @@ static int br_validate(struct nlattr *tb[], struct nlattr *data[]) static int br_port_slave_changelink(struct net_device *brdev, struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_bridge *br = netdev_priv(brdev); int ret; @@ -960,7 +963,8 @@ static const struct nla_policy br_policy[IFLA_BR_MAX + 1] = { }; static int br_changelink(struct net_device *brdev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_bridge *br = netdev_priv(brdev); int err; @@ -1213,7 +1217,8 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[], } static int br_dev_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_bridge *br = netdev_priv(dev); int err; @@ -1228,7 +1233,7 @@ static int br_dev_newlink(struct net *src_net, struct net_device *dev, if (err) return err; - err = br_changelink(dev, tb, data); + err = br_changelink(dev, tb, data, extack); if (err) unregister_netdevice(dev); return err; diff --git a/net/caif/chnl_net.c b/net/caif/chnl_net.c index fe3c53efb949..922ac1d605b3 100644 --- a/net/caif/chnl_net.c +++ b/net/caif/chnl_net.c @@ -461,7 +461,8 @@ static void caif_netlink_parms(struct nlattr *data[], } static int ipcaif_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { int ret; struct chnl_net *caifdev; @@ -484,7 +485,8 @@ static int ipcaif_newlink(struct net *src_net, struct net_device *dev, } static int ipcaif_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct chnl_net *caifdev; ASSERT_RTNL(); diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c index 9a1bd510c812..ed51de525a88 100644 --- a/net/core/rtnetlink.c +++ b/net/core/rtnetlink.c @@ -2582,7 +2582,7 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, data = attr; } if (ops->validate) { - err = ops->validate(tb, data); + err = ops->validate(tb, data, extack); if (err < 0) return err; } @@ -2601,7 +2601,8 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, slave_data = slave_attr; } if (m_ops->slave_validate) { - err = m_ops->slave_validate(tb, slave_data); + err = m_ops->slave_validate(tb, slave_data, + extack); if (err < 0) return err; } @@ -2620,7 +2621,7 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, !ops->changelink) return -EOPNOTSUPP; - err = ops->changelink(dev, tb, data); + err = ops->changelink(dev, tb, data, extack); if (err < 0) return err; status |= DO_SETLINK_NOTIFY; @@ -2631,7 +2632,8 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, return -EOPNOTSUPP; err = m_ops->slave_changelink(master_dev, dev, - tb, slave_data); + tb, slave_data, + extack); if (err < 0) return err; status |= DO_SETLINK_NOTIFY; @@ -2705,7 +2707,8 @@ static int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh, dev->ifindex = ifm->ifi_index; if (ops->newlink) { - err = ops->newlink(link_net ? : net, dev, tb, data); + err = ops->newlink(link_net ? : net, dev, tb, data, + extack); /* Drivers should call free_netdev() in ->destructor * and unregister it on failure after registration * so that device could be finally freed in rtnl_unlock. diff --git a/net/hsr/hsr_netlink.c b/net/hsr/hsr_netlink.c index 81dac16933fc..b9cce0fd5696 100644 --- a/net/hsr/hsr_netlink.c +++ b/net/hsr/hsr_netlink.c @@ -33,7 +33,8 @@ static const struct nla_policy hsr_policy[IFLA_HSR_MAX + 1] = { * hsr_dev_setup routine has been executed. Nice! */ static int hsr_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_device *link[2]; unsigned char multicast_spec, hsr_version; diff --git a/net/ieee802154/6lowpan/core.c b/net/ieee802154/6lowpan/core.c index 0a866f332290..de2661cd0328 100644 --- a/net/ieee802154/6lowpan/core.c +++ b/net/ieee802154/6lowpan/core.c @@ -111,7 +111,8 @@ static void lowpan_setup(struct net_device *ldev) ldev->features |= NETIF_F_NETNS_LOCAL; } -static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[]) +static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { if (tb[IFLA_ADDRESS]) { if (nla_len(tb[IFLA_ADDRESS]) != IEEE802154_ADDR_LEN) @@ -121,7 +122,8 @@ static int lowpan_validate(struct nlattr *tb[], struct nlattr *data[]) } static int lowpan_newlink(struct net *src_net, struct net_device *ldev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net_device *wdev; int ret; diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c index 41394a4b9af9..7a7829e839c2 100644 --- a/net/ipv4/ip_gre.c +++ b/net/ipv4/ip_gre.c @@ -779,7 +779,8 @@ static struct pernet_operations ipgre_net_ops = { .size = sizeof(struct ip_tunnel_net), }; -static int ipgre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ipgre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { __be16 flags; @@ -802,7 +803,8 @@ static int ipgre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) return 0; } -static int ipgre_tap_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ipgre_tap_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { __be32 daddr; @@ -823,7 +825,7 @@ static int ipgre_tap_validate(struct nlattr *tb[], struct nlattr *data[]) } out: - return ipgre_tunnel_validate(tb, data); + return ipgre_tunnel_validate(tb, data, extack); } static int ipgre_netlink_parms(struct net_device *dev, @@ -957,7 +959,8 @@ static void ipgre_tap_setup(struct net_device *dev) } static int ipgre_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel_parm p; struct ip_tunnel_encap ipencap; @@ -979,7 +982,8 @@ static int ipgre_newlink(struct net *src_net, struct net_device *dev, } static int ipgre_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel *t = netdev_priv(dev); struct ip_tunnel_parm p; @@ -1155,7 +1159,7 @@ struct net_device *gretap_fb_dev_create(struct net *net, const char *name, t = netdev_priv(dev); t->collect_md = true; - err = ipgre_newlink(net, dev, tb, NULL); + err = ipgre_newlink(net, dev, tb, NULL, NULL); if (err < 0) { free_netdev(dev); return ERR_PTR(err); diff --git a/net/ipv4/ip_vti.c b/net/ipv4/ip_vti.c index 4ec9affb2252..0192c255e508 100644 --- a/net/ipv4/ip_vti.c +++ b/net/ipv4/ip_vti.c @@ -465,7 +465,8 @@ static struct pernet_operations vti_net_ops = { .size = sizeof(struct ip_tunnel_net), }; -static int vti_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) +static int vti_tunnel_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { return 0; } @@ -503,7 +504,8 @@ static void vti_netlink_parms(struct nlattr *data[], } static int vti_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel_parm parms; __u32 fwmark = 0; @@ -513,7 +515,8 @@ static int vti_newlink(struct net *src_net, struct net_device *dev, } static int vti_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel *t = netdev_priv(dev); __u32 fwmark = t->fwmark; diff --git a/net/ipv4/ipip.c b/net/ipv4/ipip.c index 1e441c6f2160..fb1ad22b5e29 100644 --- a/net/ipv4/ipip.c +++ b/net/ipv4/ipip.c @@ -375,7 +375,8 @@ static int ipip_tunnel_init(struct net_device *dev) return ip_tunnel_init(dev); } -static int ipip_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ipip_tunnel_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { u8 proto; @@ -469,7 +470,8 @@ static bool ipip_netlink_encap_parms(struct nlattr *data[], } static int ipip_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel *t = netdev_priv(dev); struct ip_tunnel_parm p; @@ -488,7 +490,8 @@ static int ipip_newlink(struct net *src_net, struct net_device *dev, } static int ipip_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel *t = netdev_priv(dev); struct ip_tunnel_parm p; diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c index e0e726c338a7..67ff2aaf5dcb 100644 --- a/net/ipv6/ip6_gre.c +++ b/net/ipv6/ip6_gre.c @@ -1170,7 +1170,8 @@ static struct pernet_operations ip6gre_net_ops = { .size = sizeof(struct ip6gre_net), }; -static int ip6gre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ip6gre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { __be16 flags; @@ -1188,7 +1189,8 @@ static int ip6gre_tunnel_validate(struct nlattr *tb[], struct nlattr *data[]) return 0; } -static int ip6gre_tap_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ip6gre_tap_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct in6_addr daddr; @@ -1209,7 +1211,7 @@ static int ip6gre_tap_validate(struct nlattr *tb[], struct nlattr *data[]) } out: - return ip6gre_tunnel_validate(tb, data); + return ip6gre_tunnel_validate(tb, data, extack); } @@ -1342,7 +1344,8 @@ static bool ip6gre_netlink_encap_parms(struct nlattr *data[], } static int ip6gre_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip6_tnl *nt; struct net *net = dev_net(dev); @@ -1403,7 +1406,8 @@ static int ip6gre_newlink(struct net *src_net, struct net_device *dev, } static int ip6gre_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip6_tnl *t, *nt = netdev_priv(dev); struct net *net = nt->net; diff --git a/net/ipv6/ip6_tunnel.c b/net/ipv6/ip6_tunnel.c index 8c6c3c8e7eef..3a0ba2ae4b0f 100644 --- a/net/ipv6/ip6_tunnel.c +++ b/net/ipv6/ip6_tunnel.c @@ -1885,7 +1885,8 @@ static int __net_init ip6_fb_tnl_dev_init(struct net_device *dev) return 0; } -static int ip6_tnl_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ip6_tnl_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { u8 proto; @@ -1974,7 +1975,8 @@ static bool ip6_tnl_netlink_encap_parms(struct nlattr *data[], } static int ip6_tnl_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net *net = dev_net(dev); struct ip6_tnl_net *ip6n = net_generic(net, ip6_tnl_net_id); @@ -2005,7 +2007,8 @@ static int ip6_tnl_newlink(struct net *src_net, struct net_device *dev, } static int ip6_tnl_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip6_tnl *t = netdev_priv(dev); struct __ip6_tnl_parm p; diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c index 837ea1eefe7f..486c2305f53c 100644 --- a/net/ipv6/ip6_vti.c +++ b/net/ipv6/ip6_vti.c @@ -907,7 +907,8 @@ static int __net_init vti6_fb_tnl_dev_init(struct net_device *dev) return 0; } -static int vti6_validate(struct nlattr *tb[], struct nlattr *data[]) +static int vti6_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { return 0; } @@ -940,7 +941,8 @@ static void vti6_netlink_parms(struct nlattr *data[], } static int vti6_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net *net = dev_net(dev); struct ip6_tnl *nt; @@ -966,7 +968,8 @@ static void vti6_dellink(struct net_device *dev, struct list_head *head) } static int vti6_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip6_tnl *t; struct __ip6_tnl_parm p; diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c index 2378503577b0..e9958b1398cb 100644 --- a/net/ipv6/sit.c +++ b/net/ipv6/sit.c @@ -1406,7 +1406,8 @@ static void __net_init ipip6_fb_tunnel_init(struct net_device *dev) rcu_assign_pointer(sitn->tunnels_wc[0], tunnel); } -static int ipip6_validate(struct nlattr *tb[], struct nlattr *data[]) +static int ipip6_validate(struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { u8 proto; @@ -1537,7 +1538,8 @@ static bool ipip6_netlink_6rd_parms(struct nlattr *data[], #endif static int ipip6_newlink(struct net *src_net, struct net_device *dev, - struct nlattr *tb[], struct nlattr *data[]) + struct nlattr *tb[], struct nlattr *data[], + struct netlink_ext_ack *extack) { struct net *net = dev_net(dev); struct ip_tunnel *nt; @@ -1573,7 +1575,8 @@ static int ipip6_newlink(struct net *src_net, struct net_device *dev, } static int ipip6_changelink(struct net_device *dev, struct nlattr *tb[], - struct nlattr *data[]) + struct nlattr *data[], + struct netlink_ext_ack *extack) { struct ip_tunnel *t = netdev_priv(dev); struct ip_tunnel_parm p; -- 2.13.1

3 2

[PATCH] net: fix potential null pointer dereference
by Gustavo A. R. Silva 25 May '17

25 May '17

Add null check to avoid a potential null pointer dereference. Addresses-Coverity-ID: 1408831 Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> --- drivers/net/gtp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 4fea1b3..7b652bb 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -873,7 +873,7 @@ static struct gtp_dev *gtp_find_dev(struct net *src_net, struct nlattr *nla[]) /* Check if there's an existing gtpX device to configure */ dev = dev_get_by_index_rcu(net, nla_get_u32(nla[GTPA_LINK])); - if (dev->netdev_ops == &gtp_netdev_ops) + if (dev && dev->netdev_ops == &gtp_netdev_ops) gtp = netdev_priv(dev); put_net(net); -- 2.5.0

3 2

Removing FCS from SNDCP packages
by Holger Freyther 16 May '17

16 May '17

Hi, I see that while adding decompression support dexter has fixed a bug in the sndcp code. Before the GTP-U frame would include the LLC FCS and now we do this: npdu_len = (msg->data + msg->len) - npdu - 3; What I wonder (and the commit message didn't say is) was the fragment part handled as well. The calculation is: /* make sure to subtract length of SNDCP header from 'len' */ rc = defrag_enqueue(sne, suh->seg_nr, data, len - (data - hdr)); and len is passed in from the TLV struct in gprs_llc_rcvmsg. I think the fragmented case is working okay. Shall we try to unify the length calculation to rely on the local "len" variable instead of checking msg->data+msg->len? cheers holger

3 3

kernel-to-kernel gtp implementation
by fırat sönmez 05 May '17

05 May '17

Hi, I am currently working in a project where I was asked to implement a GTP tunnel from client to company servers. I have read through osmocom pages and tried to implement the simple network structure. I have seen from Basic testing of openGGSN page: " test GTP-U interoperability of the kernel with at least one other implementation, not just kernel-to-kernel (which currently is not supported in the kernel, as it only implements the GGSN/P-GW role) " I would not like to implement openGGSN but just linux-kernel-gtp-u implementation between two kernels. To achieve kernel-to-kernel implementation, I found sgsn patch on the internet: https://patchwork.ozlabs.org/patch/739408/ and there is already a kernel-gtp-U in osmocom. So, my basic network structure is below. [image: Satır içi resim 2] I would like make a tunnel between sgsn and ggsn. I have used libgtpnl tools to create link and then tunnel. I have added a default gateway GTP interface to route table on sgsn side, but the packets cannot reach ggsn side. Is there any detailed explanation for a simple bidirectional tunnel setup. If so, it would be so nice to know about. Thank you for all your efforts, Fırat

2 1

Video Recordings of OsmoCon 2017
by Harald Welte 25 Apr '17

25 Apr '17

Hi all, the Osmocom Conference 2017 last week was an overwhelming success. We received lots of positive feedback from all sides. Thanks to all the speakers, to the attendees as well as to the anonymous sponsor of the travel grant funds. It is my great pleasure that due to the great support by C3VOC (The CCC Video Operation Center), we have full recordings of all talks given at OsmoCon 2017. You can find the videos on the C3VOC site at https://media.ccc.de/search/?q=osmocon They are also linked individually from the OsmoCon 2017 homepage at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017 I hope the video recordings will be of help for everyone who could not make it to the event in person. We will also be collecting the slides and put them up on the wiki during the next few days. Please don't hesitate to raise any feedback and/or questions. Technical feedback/questions regarding Osmocom software / projects should be addressed to the appropriate mailing lists, such as openbsc(a)lists.osmocom.org. Feedback to the organizers should be sent to osmocon2017(a)sysmocom.de. Looking forward to the next OsmoCon, which we'll expect to be spanning ore than just a single day. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

kernel GTP-U support dev roadmap
by Jiannan Ouyang 24 Apr '17

24 Apr '17

Hi Harald and Andreas, I’m writing to inquiry about the development roadmap of the kernel gtp module. For example, is there any plan to support the following features soon - lightweight tunnel - ipv6 The openair-cn project I’m working on is a user of the kernel gtp module. I’m happy to help improve the kernel gtp support, so it’s good to first ask about the roadmap. Regards, -Jiannan

3 4

GTP echo response
by Alandre de Carvalho 05 Apr '17

05 Apr '17

Hi everyone, We're using kernel GTP developed by Osmocom on openair-cn. Turns out that we are not able to connect an UE for longer than 20 seconds using an ZTE eNB apparently because the GTP-U is not answering to the echo requests. As far I know this response is supposed to be implemented but it is not answering. Do you guys have any tips on this issue? Thanks in advance, Alandre

3 2

allow gtp tunnel updating in libgtpnl: gtp_add_tunnel()
by Jiannan Ouyang 28 Mar '17

28 Mar '17

Hi All, In current OAI implementation, we found that there are cases SPGW is out-of-sync with MME, because of the delete_session_request is not received by the SPGW because of some errors, however MME has cleared the state of that session. Then when the UE re-attaches, a new create_session_request is sent to SPGW; and because we try to allocate the same IP for the same IMSI (local change), the SPGW will result out in trying to update an existing GTP tunnel. According to http://lxr.free-electrons.com/source/drivers/net/gtp.c#L937 and https://github.com/RoadRunnr/osmo-ggsn/blob/master/libgtnl/src/gtp-genl.c#L…, the NLM_F_EXCL flag is used to prevent updating an existing tunnel. I’m is wondering what is the reason of preventing updating? While we are actively investigating sending delete_session_request properly, as temporary workaround, I’m thinking to recovery from the out-of-sync problem, we can allow the new GTP tunnel to overwrite the old one in libgtpnl. Your suggestions are welcomed. Thanks. Regards, -Jiannan

3 4

Updates on Osmocom Conference 2017
by Harald Welte 27 Mar '17

27 Mar '17

OsmoCon 2017 updates There are some updates related to OsmoCon2017, the first Osmocom Conference, held on April 21st, 2017 in Berlin, Germany. See http://osmocom.org/news/68 for the web version of this announcement. == Summary == Summary (for those too busy to read the full post): * Schedule of talks has been released http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017#Schedule * Travel Grants available for participants who are otherwise unable to travel to Berlin: http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_TravelGrants * Social Event details available, including menu: http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_SocialEvent * April 21st is approaching fast, make sure you get your Ticket in time. Limited number of seats available http://shop.sysmocom.de/products/ticket-for-osmocon-2017 == Details == === Schedule has been released === The list of talks with their abstracts has been on the website for quite some time, but now we actually have put together a schedule based on those talks. Please see http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017#Schedule for the schedule. As you can see, the day is fully packed with talks about Osmocom cellular infrastructure projects. We had to cut some talk slots short (30min instead of 45min), but I'm confident that it is good to cover a wider range of topics, while at the same time avoiding fragmenting the audience with multiple tracks. === Travel Grants === We are happy to announce that we have received donations to permit for providing travel grants! This means that any attendee who is otherwise not able to cover their travel to OsmoCon 2017 (e.g. because their interest in Osmocom is not related to their work, or because their employer doesn't pay the travel expenses) can now apply for such a travel grant. For more details see http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_TravelGrants and/or constact osmocon2017(a)sysmocom.de. === Social Event === Tech Talks are nice and fine, but what many people enjoy even more at conferences is the informal networking combined with good food. For this, we have the social event at night, which is open to all attendees. See more details about it at http://osmocom.org/projects/osmo-dev-con/wiki/OsmoCon2017_SocialEvent -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

[osmo-pcu 0.2.896-0a8f] testsuite: 4 failed
by Arnaud ZANETTI 26 Mar '17

26 Mar '17

Hi, building osmo-pcu on a raspberry Pi 3, I noticed a failure in make check: ## --------------------------------- ## ## osmo-pcu 0.2.896-0a8f test suite. ## ## --------------------------------- ## Regression tests 1: rlcmac ok 2: ts_alloc ok 3: tbf ok 4: bitcomp FAILED (testsuite.at:30) 5: edge ok 6: types ok 7: ms ok 8: llc ok 9: llist ok 10: codel ok 11: fn ok ## ------------- ## ## Test results. ## ## ------------- ## ERROR: All 11 tests were run, 1 failed unexpectedly. ## -------------------------- ## ## testsuite.log was created. ## ## -------------------------- ## The exact same test also fails on a raspberry Pi 2, with the same osmo-pcu and gcc versions but succeeds on an old Pentium4 Feel free to contact me if you need further informations. ----- Arnaud ZANETTI

2 1

[PATCH 0/2] libgtpnl patches
by Jonas Bonn 24 Mar '17

24 Mar '17

Here are two small patches for libgtpnl. They both apply to the laforge/sgsn-role branch (although patch 2/2 could be taken separately into the main branch, too). Patch 1/2 is a small fixup for a netlink parameter rename in a kernel patch. Patch 2/2 is a trivial include file addition to prevent some warnings. Jonas Bonn (2): Rename netlink attribute Provide declaration for struct in_addr include/libgtpnl/gtp.h | 1 + include/linux/gtp.h | 2 +- src/gtp-genl.c | 8 ++++---- 3 files changed, 6 insertions(+), 5 deletions(-) -- 2.9.3

2 3

git.osmocom.org cgit improvements
by Harald Welte 20 Mar '17

20 Mar '17

Hi all, today I've deployed some cgit improvements on https://git.osmocom.org/, in the hope that it makes this tool even more useful: 1) syntax highlighting of source code (requested by Hoernchen) The source code is now highlighted by pygments. I don't really understand why somebody would want to look at source code a lot in a browser, but well, it was as easy as to enable the existing pygments based filter plugin. 2) rendering of "about" page from README.md As you might have noticed, I've introduced a README.md in a number of repositoires, and cgit is now rendering an about page for every repository, e.g. at http://git.osmocom.org/libosmo-abis/about/ 3) gerrit change-ID hyperlink generation All gerrit Change-IDs in commit messages are now automatically converted to hyperlinks to the respective gerrit change, see e.g. the below example: http://git.osmocom.org/openbsc/commit/?id=6dd0fc685b7149f67a5fe17a5bce55c44… Please note that this works for the "Change-Id" line of the actual change, but also for change-ids in the free text (e.g. "this depends on change-id ... in libosmocore") 4) Osmocom ticket/issue hyperlink generation Any Line that matches the "^((Relate|Close|Fixe)[ds]):" prefix is scanned for occurrences of "OS#(\d+)" which are then amended with hyperlinks to the respective issue on osmocom.org Please note the OS# prefix is mandatory, so things like "OS#1614, 1615" will not work, as can be seen at http://git.osmocom.org/osmo-pcu/commit/?id=0a8fae8d141c2cfa4387ffe9b35402d5… Please format your commit messages accordingly. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 3

Re: [PATCH 1/1] gtp: support SGSN-side tunnels
by Harald Welte 15 Mar '17

15 Mar '17

Hi Pablo, On Wed, Mar 15, 2017 at 06:23:48PM +0100, Pablo Neira Ayuso wrote: > On Wed, Mar 15, 2017 at 05:39:16PM +0100, Harald Welte wrote: > > > > I would definitely like to see this move forward, particularly in order > > to test the GGSN-side code. > > Agreed. I've modified the patch slightly, see below (compile-tested, but not otherwise tested yet). Basically rename the flags attribute to 'role', expand the commit log and removed unrelated cosmetic changes. I've also prepared a corresponding change to libgtpnl into the laforge/sgsn-rol branch, see http://git.osmocom.org/libgtpnl/commit/?h=laforge/sgsn-role This is not yet tested in any way, but I'm planning to add some associated support to the command line tools and then give it some testing (both against the kernel GTP in GGSN mode, as well as an independent userspace GTP implementation). > It would be good if we provide a way to configure GTP via iproute2 for > testing purposes. I don't really care about which tool is used, as long as it is easily available [and FOSS, of course]. > We would need to create some dummy socket from > kernel too though so we don't need any userspace daemon for this > testing mode. I don't really like that latter idea. It sounds too much like a hack to me. But then, I don't have enough phantasy right now ti imagine how an actual implementation would look like. To me, it is perfectly fine to run a simple, small utility in userspace even for testing. Regards, Harald >From 63920950f9498069993def78e178bde85c174e0c Mon Sep 17 00:00:00 2001 From: Jonas Bonn <jonas(a)southpole.se> Date: Wed, 15 Mar 2017 17:52:28 +0100 Subject: [PATCH] gtp: support SGSN-side tunnels The GTP-tunnel driver is explicitly GGSN-side as it searches for PDP contexts based on the incoming packets _destination_ address. For real-world use cases, this is sufficient, as the other side of a GTP tunnel is not in fact implemented by GTP, but by the protocol stacking of a mobile station / user equipment on the radio interface (like PDCP, SNDCP). However, if we want to simulate the mobile station, radio access network and SGSN (for example to test the GGSN side implementation), then we want to be identifying PDP contexts based on _source_ address. This patch adds a "role" attribute at GTP-link creation time to specify whether we behave like the GGSN or SGSN role of the tunnel; this attribute is then used to determine which part of the IP packet to use in determining the PDP context. Signed-off-by: Jonas Bonn <jonas(a)southpole.se> Signed-off-by: Harald Welte <laforge(a)gnumonks.org> diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 99d3df788ce8..9aef4217f6e1 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -71,6 +71,7 @@ struct gtp_dev { struct net_device *dev; + enum ifla_gtp_role role; unsigned int hash_size; struct hlist_head *tid_hash; struct hlist_head *addr_hash; @@ -149,8 +150,8 @@ static struct pdp_ctx *ipv4_pdp_find(struct gtp_dev *gtp, __be32 ms_addr) return NULL; } -static bool gtp_check_src_ms_ipv4(struct sk_buff *skb, struct pdp_ctx *pctx, - unsigned int hdrlen) +static bool gtp_check_ms_ipv4(struct sk_buff *skb, struct pdp_ctx *pctx, + unsigned int hdrlen, enum ifla_gtp_role role) { struct iphdr *iph; @@ -159,18 +160,21 @@ static bool gtp_check_src_ms_ipv4(struct sk_buff *skb, struct pdp_ctx *pctx, iph = (struct iphdr *)(skb->data + hdrlen); - return iph->saddr == pctx->ms_addr_ip4.s_addr; + if (role == GTP_ROLE_SGSN) + return iph->daddr == pctx->ms_addr_ip4.s_addr; + else + return iph->saddr == pctx->ms_addr_ip4.s_addr; } /* Check if the inner IP source address in this packet is assigned to any * existing mobile subscriber. */ -static bool gtp_check_src_ms(struct sk_buff *skb, struct pdp_ctx *pctx, - unsigned int hdrlen) +static bool gtp_check_ms(struct sk_buff *skb, struct pdp_ctx *pctx, + unsigned int hdrlen, enum ifla_gtp_role role) { switch (ntohs(skb->protocol)) { case ETH_P_IP: - return gtp_check_src_ms_ipv4(skb, pctx, hdrlen); + return gtp_check_ms_ipv4(skb, pctx, hdrlen, role); } return false; } @@ -204,7 +208,7 @@ static int gtp0_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb, goto out_rcu; } - if (!gtp_check_src_ms(skb, pctx, hdrlen)) { + if (!gtp_check_ms(skb, pctx, hdrlen, gtp->role)) { netdev_dbg(gtp->dev, "No PDP ctx for this MS\n"); ret = -1; goto out_rcu; @@ -261,7 +265,7 @@ static int gtp1u_udp_encap_recv(struct gtp_dev *gtp, struct sk_buff *skb, goto out_rcu; } - if (!gtp_check_src_ms(skb, pctx, hdrlen)) { + if (!gtp_check_ms(skb, pctx, hdrlen, gtp->role)) { netdev_dbg(gtp->dev, "No PDP ctx for this MS\n"); ret = -1; goto out_rcu; @@ -490,7 +494,11 @@ static int gtp_build_skb_ip4(struct sk_buff *skb, struct net_device *dev, * Prepend PDP header with TEI/TID from PDP ctx. */ iph = ip_hdr(skb); - pctx = ipv4_pdp_find(gtp, iph->daddr); + if (gtp->role == GTP_ROLE_SGSN) + pctx = ipv4_pdp_find(gtp, iph->saddr); + else + pctx = ipv4_pdp_find(gtp, iph->daddr); + if (!pctx) { netdev_dbg(dev, "no PDP ctx found for %pI4, skip\n", &iph->daddr); @@ -665,12 +673,26 @@ static int gtp_newlink(struct net *src_net, struct net_device *dev, int hashsize, err, fd0, fd1; struct gtp_dev *gtp; struct gtp_net *gn; + unsigned int role; + + /* The default role is GGSN, and for backwards compatibility + * reasons, the lack of a IFLA_GTP_ROLE IE means that we're + * operating in GGSN role. */ + if (data[IFLA_GTP_ROLE]) { + role = nla_get_u32(data[IFLA_GTP_ROLE]); + if (role != GTP_ROLE_GGSN && + role != GTP_ROLE_SGSN) + return -EINVAL; + } else + role = GTP_ROLE_GGSN; if (!data[IFLA_GTP_FD0] || !data[IFLA_GTP_FD1]) return -EINVAL; gtp = netdev_priv(dev); + gtp->role = role; + fd0 = nla_get_u32(data[IFLA_GTP_FD0]); fd1 = nla_get_u32(data[IFLA_GTP_FD1]); @@ -722,6 +744,7 @@ static const struct nla_policy gtp_policy[IFLA_GTP_MAX + 1] = { [IFLA_GTP_FD0] = { .type = NLA_U32 }, [IFLA_GTP_FD1] = { .type = NLA_U32 }, [IFLA_GTP_PDP_HASHSIZE] = { .type = NLA_U32 }, + [IFLA_GTP_ROLE] = { .type = NLA_U32 }, }; static int gtp_validate(struct nlattr *tb[], struct nlattr *data[]) diff --git a/include/uapi/linux/gtp.h b/include/uapi/linux/gtp.h index 72a04a0e8cce..79037cca6b51 100644 --- a/include/uapi/linux/gtp.h +++ b/include/uapi/linux/gtp.h @@ -19,7 +19,7 @@ enum gtp_attrs { GTPA_LINK, GTPA_VERSION, GTPA_TID, /* for GTPv0 only */ - GTPA_SGSN_ADDRESS, + GTPA_SGSN_ADDRESS, /* Remote GSN, either SGSN or GGSN */ GTPA_MS_ADDRESS, GTPA_FLOW, GTPA_NET_NS_FD, diff --git a/include/uapi/linux/if_link.h b/include/uapi/linux/if_link.h index 6b13e591abc9..de7bea223749 100644 --- a/include/uapi/linux/if_link.h +++ b/include/uapi/linux/if_link.h @@ -536,11 +536,18 @@ enum { #define IFLA_PPP_MAX (__IFLA_PPP_MAX - 1) /* GTP section */ + +enum ifla_gtp_role { + GTP_ROLE_GGSN = 0, + GTP_ROLE_SGSN, +}; + enum { IFLA_GTP_UNSPEC, IFLA_GTP_FD0, IFLA_GTP_FD1, IFLA_GTP_PDP_HASHSIZE, + IFLA_GTP_ROLE, __IFLA_GTP_MAX, }; #define IFLA_GTP_MAX (__IFLA_GTP_MAX - 1) -- 2.11.0 -- - Harald Welte <laforge(a)netfilter.org> http://netfilter.org/ ============================================================================ "Fragmentation is like classful addressing -- an interesting early architectural error that shows how much experimentation was going on while IP was being designed." -- Paul Vixie

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs