osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

5 participants
507 discussions

Re: [PATCH net-next v2] ethtool: ice: Support for RSS settings to GTP from ethtool
by Jakub Kicinski 18 Oct '23

18 Oct '23

Thanks for the v2! Adding Willem, Pablo, and Harald to CC (please CC them on future versions). On Thu, 12 Oct 2023 06:01:15 +0000 Takeru Hayasaka wrote: > diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h > index f7fba0dc87e5..a2d4f2081cf3 100644 > --- a/include/uapi/linux/ethtool.h > +++ b/include/uapi/linux/ethtool.h > @@ -2011,6 +2011,18 @@ static inline int ethtool_validate_duplex(__u8 duplex) > #define IPV4_FLOW 0x10 /* hash only */ > #define IPV6_FLOW 0x11 /* hash only */ > #define ETHER_FLOW 0x12 /* spec only (ether_spec) */ > +#define GTPU_V4_FLOW 0x13 /* hash only */ > +#define GTPU_V6_FLOW 0x14 /* hash only */ > +#define GTPC_V4_FLOW 0x15 /* hash only */ > +#define GTPC_V6_FLOW 0x16 /* hash only */ > +#define GTPC_TEID_V4_FLOW 0x17 /* hash only */ > +#define GTPC_TEID_V6_FLOW 0x18 /* hash only */ > +#define GTPU_EH_V4_FLOW 0x19 /* hash only */ > +#define GTPU_EH_V6_FLOW 0x20 /* hash only */ nit: please note that these are hex numbers, next value after 0x19 is 0x1a, not 0x20. > +#define GTPU_UL_V4_FLOW 0x21 /* hash only */ > +#define GTPU_UL_V6_FLOW 0x22 /* hash only */ > +#define GTPU_DL_V4_FLOW 0x23 /* hash only */ > +#define GTPU_DL_V6_FLOW 0x24 /* hash only */ > /* Flag to enable additional fields in struct ethtool_rx_flow_spec */ > #define FLOW_EXT 0x80000000 > #define FLOW_MAC_EXT 0x40000000 What gives me pause here is the number of flow sub-types we define for GTP hashing. My understanding of GTP is limited to what I just read on Wikipedia. IIUC the GTPC vs GTPU distinction comes down to the UDP port on which the protocol runs? Are the frames also different? I'm guessing UL/DL are uplink/downlink but what's EH? How do GTPU_V4_FLOW, GTPU_EH_V4_FLOW, GTPU_UL_V4_FLOW, and GTPU_DL_V4_FLOW differ? Key question is - are there reasonable use cases that you can think of for enabling GTP hashing for each one of those bits individually or can we combine some of them? > @@ -2025,6 +2037,7 @@ static inline int ethtool_validate_duplex(__u8 duplex) > #define RXH_IP_DST (1 << 5) > #define RXH_L4_B_0_1 (1 << 6) /* src port in case of TCP/UDP/SCTP */ > #define RXH_L4_B_2_3 (1 << 7) /* dst port in case of TCP/UDP/SCTP */ > +#define RXH_GTP_TEID (1 << 8) /* teid in case of GTP */ > #define RXH_DISCARD (1 << 31)

3 13

September 2023 Osmocom CNI releases (202302)
by Pau Espin Pedrol 14 Sep '23

14 Sep '23

Hi all, I am happy to announce that a new version 202309 of the Osmocom CNI (Cellular Network Infrastructure) software has been released this week. For further information, please visit: https://osmocom.org/news/220 Regards, Pau -- - 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

1 0

Osmocom discourse as alternative to mailing lists
by Harald Welte 27 Jul '23

27 Jul '23

Dear Osmocom community, while many people with a long history in FOSS development have no issues at all with mailing lists as primary form of engaging with their community, they have undoubtedly fallen out of fashion in favor of various chat/messaging systems or web based forums. In Osmocom, we've just launched an installation of the discourse forum software available at https://discourse.osmocom.org/ providing an alternative to our traditional mailing lists at https://lists.osmocom.org/ We're looking forward to see whether this web-based approach will facilitate more and/or other people to engage with the Osmocom developer/contributor community. Feel free to join and get the discussions started. If there's a need for more categories or sub-categories, just let one of the moderators know and we can help with that. The old mailing lists will continue to remain available for those who prefer them. -- - Harald Welte <laforge(a)osmocom.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

[PATCH net-next 0/3] net: Remove more RTO_ONLINK users.
by Guillaume Nault 19 Jul '23

19 Jul '23

Code that initialise a flowi4 structure manually before doing a fib lookup can easily avoid overloading ->flowi4_tos with the RTO_ONLINK bit. They can just set ->flowi4_scope correctly instead. Properly separating the routing scope from ->flowi4_tos will allow to eventually convert this field to dscp_t (to ensure proper separation between DSCP and ECN). Guillaume Nault (3): gtp: Set TOS and routing scope independently for fib lookups. dccp: Set TOS and routing scope independently for fib lookups. sctp: Set TOS and routing scope independently for fib lookups. drivers/net/gtp.c | 3 ++- net/dccp/ipv4.c | 3 ++- net/sctp/protocol.c | 3 ++- 3 files changed, 6 insertions(+), 3 deletions(-) -- 2.39.2

2 2

Deprecating support for big endian in Osmocom
by Harald Welte 17 Jul '23

17 Jul '23

Hi all, during recent patch review (https://gerrit.osmocom.org/c/osmo-trx/+/33737) the topic of continuing to maintain support for big endian machines has come up. While traditionally I've always been a strong proponent of writing portable code that can run also on big endian systems, it is not the year 2003 or 2008 anymore, and PowerPC (the main big endian platform) is dead by now, as is SPARC. Not just in newly-built processors, but also in existing and still operating machines, at least of the class that would run our code. So unless somebody objects with strong arguments, I'd propose to officially and explicitly drop supporting big endian systems from osmocom CNI projects. From what I can tell, this would primarily mean * drop the struct_endianness check from the commit verification * removing all our struct_endianness-generated or other code that explicitly adds big endian support * adding some kind of #warning or even #error to a common libosmocore header file if anyone tries to build on big endian This obviously doesn't mean we can abandon using [osmo_]{htonl,ntohl}, as network byte order is still network byte order. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 3

[PATCH v1 net] gtp: Fix use-after-free in __gtp_encap_destroy().
by Kuniyuki Iwashima 25 Jun '23

25 Jun '23

syzkaller reported use-after-free in __gtp_encap_destroy(). [0] It shows the same process freed sk and touched it illegally. Commit e198987e7dd7 ("gtp: fix suspicious RCU usage") added lock_sock() and release_sock() in __gtp_encap_destroy() to protect sk->sk_user_data, but release_sock() is called after sock_put() releases the last refcnt. [0]: BUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:96 [inline] BUG: KASAN: slab-use-after-free in atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline] BUG: KASAN: slab-use-after-free in queued_spin_lock include/asm-generic/qspinlock.h:111 [inline] BUG: KASAN: slab-use-after-free in do_raw_spin_lock include/linux/spinlock.h:186 [inline] BUG: KASAN: slab-use-after-free in __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline] BUG: KASAN: slab-use-after-free in _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178 Write of size 4 at addr ffff88800dbef398 by task syz-executor.2/2401 CPU: 1 PID: 2401 Comm: syz-executor.2 Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:351 [inline] print_report+0xcc/0x620 mm/kasan/report.c:462 kasan_report+0xb2/0xe0 mm/kasan/report.c:572 check_region_inline mm/kasan/generic.c:181 [inline] kasan_check_range+0x39/0x1c0 mm/kasan/generic.c:187 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline] queued_spin_lock include/asm-generic/qspinlock.h:111 [inline] do_raw_spin_lock include/linux/spinlock.h:186 [inline] __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline] _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178 spin_lock_bh include/linux/spinlock.h:355 [inline] release_sock+0x1f/0x1a0 net/core/sock.c:3526 gtp_encap_disable_sock drivers/net/gtp.c:651 [inline] gtp_encap_disable+0xb9/0x220 drivers/net/gtp.c:664 gtp_dev_uninit+0x19/0x50 drivers/net/gtp.c:728 unregister_netdevice_many_notify+0x97e/0x1520 net/core/dev.c:10841 rtnl_delete_link net/core/rtnetlink.c:3216 [inline] rtnl_dellink+0x3c0/0xb30 net/core/rtnetlink.c:3268 rtnetlink_rcv_msg+0x450/0xb10 net/core/rtnetlink.c:6423 netlink_rcv_skb+0x15d/0x450 net/netlink/af_netlink.c:2548 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x700/0x930 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x91c/0xe30 net/netlink/af_netlink.c:1913 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg+0x1b7/0x200 net/socket.c:747 ____sys_sendmsg+0x75a/0x990 net/socket.c:2493 ___sys_sendmsg+0x11d/0x1c0 net/socket.c:2547 __sys_sendmsg+0xfe/0x1d0 net/socket.c:2576 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f1168b1fe5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007f1167edccc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f1168b1fe5d RDX: 0000000000000000 RSI: 00000000200002c0 RDI: 0000000000000003 RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f1168b80530 R15: 0000000000000000 </TASK> Allocated by task 1483: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 __kasan_slab_alloc+0x59/0x70 mm/kasan/common.c:328 kasan_slab_alloc include/linux/kasan.h:186 [inline] slab_post_alloc_hook mm/slab.h:711 [inline] slab_alloc_node mm/slub.c:3451 [inline] slab_alloc mm/slub.c:3459 [inline] __kmem_cache_alloc_lru mm/slub.c:3466 [inline] kmem_cache_alloc+0x16d/0x340 mm/slub.c:3475 sk_prot_alloc+0x5f/0x280 net/core/sock.c:2073 sk_alloc+0x34/0x6c0 net/core/sock.c:2132 inet6_create net/ipv6/af_inet6.c:192 [inline] inet6_create+0x2c7/0xf20 net/ipv6/af_inet6.c:119 __sock_create+0x2a1/0x530 net/socket.c:1535 sock_create net/socket.c:1586 [inline] __sys_socket_create net/socket.c:1623 [inline] __sys_socket_create net/socket.c:1608 [inline] __sys_socket+0x137/0x250 net/socket.c:1651 __do_sys_socket net/socket.c:1664 [inline] __se_sys_socket net/socket.c:1662 [inline] __x64_sys_socket+0x72/0xb0 net/socket.c:1662 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc Freed by task 2401: kasan_save_stack+0x22/0x50 mm/kasan/common.c:45 kasan_set_track+0x25/0x30 mm/kasan/common.c:52 kasan_save_free_info+0x2e/0x50 mm/kasan/generic.c:521 ____kasan_slab_free mm/kasan/common.c:236 [inline] ____kasan_slab_free mm/kasan/common.c:200 [inline] __kasan_slab_free+0x10c/0x1b0 mm/kasan/common.c:244 kasan_slab_free include/linux/kasan.h:162 [inline] slab_free_hook mm/slub.c:1781 [inline] slab_free_freelist_hook mm/slub.c:1807 [inline] slab_free mm/slub.c:3786 [inline] kmem_cache_free+0xb4/0x490 mm/slub.c:3808 sk_prot_free net/core/sock.c:2113 [inline] __sk_destruct+0x500/0x720 net/core/sock.c:2207 sk_destruct+0xc1/0xe0 net/core/sock.c:2222 __sk_free+0xed/0x3d0 net/core/sock.c:2233 sk_free+0x7c/0xa0 net/core/sock.c:2244 sock_put include/net/sock.h:1981 [inline] __gtp_encap_destroy+0x165/0x1b0 drivers/net/gtp.c:634 gtp_encap_disable_sock drivers/net/gtp.c:651 [inline] gtp_encap_disable+0xb9/0x220 drivers/net/gtp.c:664 gtp_dev_uninit+0x19/0x50 drivers/net/gtp.c:728 unregister_netdevice_many_notify+0x97e/0x1520 net/core/dev.c:10841 rtnl_delete_link net/core/rtnetlink.c:3216 [inline] rtnl_dellink+0x3c0/0xb30 net/core/rtnetlink.c:3268 rtnetlink_rcv_msg+0x450/0xb10 net/core/rtnetlink.c:6423 netlink_rcv_skb+0x15d/0x450 net/netlink/af_netlink.c:2548 netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline] netlink_unicast+0x700/0x930 net/netlink/af_netlink.c:1365 netlink_sendmsg+0x91c/0xe30 net/netlink/af_netlink.c:1913 sock_sendmsg_nosec net/socket.c:724 [inline] sock_sendmsg+0x1b7/0x200 net/socket.c:747 ____sys_sendmsg+0x75a/0x990 net/socket.c:2493 ___sys_sendmsg+0x11d/0x1c0 net/socket.c:2547 __sys_sendmsg+0xfe/0x1d0 net/socket.c:2576 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x72/0xdc The buggy address belongs to the object at ffff88800dbef300 which belongs to the cache UDPv6 of size 1344 The buggy address is located 152 bytes inside of freed 1344-byte region [ffff88800dbef300, ffff88800dbef840) The buggy address belongs to the physical page: page:00000000d31bfed5 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800dbeed40 pfn:0xdbe8 head:00000000d31bfed5 order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 memcg:ffff888008ee0801 flags: 0x100000000010200(slab|head|node=0|zone=1) page_type: 0xffffffff() raw: 0100000000010200 ffff88800c7a3000 dead000000000122 0000000000000000 raw: ffff88800dbeed40 0000000080160015 00000001ffffffff ffff888008ee0801 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff88800dbef280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff88800dbef300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb >ffff88800dbef380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff88800dbef400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff88800dbef480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb Fixes: e198987e7dd7 ("gtp: fix suspicious RCU usage") Reported-by: syzkaller <syzkaller(a)googlegroups.com> Signed-off-by: Kuniyuki Iwashima <kuniyu(a)amazon.com> --- drivers/net/gtp.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 15c7dc82107f..acb20ad4e37e 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -631,7 +631,9 @@ static void __gtp_encap_destroy(struct sock *sk) gtp->sk1u = NULL; udp_sk(sk)->encap_type = 0; rcu_assign_sk_user_data(sk, NULL); + release_sock(sk); sock_put(sk); + return; } release_sock(sk); } -- 2.30.2

4 3

Request for Assistance with GPRS Configuration
by Ahnaf Tahmid 29 May '23

29 May '23

Dear Osmocom Community, I have noticed that the wiki page for OpenBSC GPRS at https://osmocom.org/projects/cellular-infrastructure/wiki/OpenBSC_GPRS has not been updated for four years, and since then, there have been significant updates to the software. As a result, the information on the GPRS/EDGE Setup page may be outdated, and I am struggling to configure GPRS on my system. I have attached my configuration files below for your review. ip address 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether ec:8e:b5:41:cb:90 brd ff:ff:ff:ff:ff:ff 3: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether b8:8a:60:4f:59:02 brd ff:ff:ff:ff:ff:ff inet 192.168.1.109/24 brd 192.168.1.255 scope global dynamic noprefixroute wlp1s0 valid_lft 7152sec preferred_lft 7152sec inet6 fe80::649b:2ab5:6dd3:8779/64 scope link noprefixroute valid_lft forever preferred_lft forever

3 5

February 2023 Osmocom CNI releases (202302)
by Pau Espin Pedrol 09 Feb '23

09 Feb '23

Hi all, I am happy to announce that a new version 202302 of the Osmocom CNI (Cellular Network Infrastructure) software has been released this week. For further information, please visit: https://osmocom.org/news/207 Regards, Pau -- - 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

1 0

OsmoDevCall on Nov 16, 2022: MS/BS power control in OsmoBSC/OsmoBTS
by Harald Welte 14 Nov '22

14 Nov '22

Dear Osmocom community, we're happy to announce the next incarnation of OsmoDevCall]]. when: November 16, 2022 at 20:00 CET where: https://meeting5.franken.de/b/har-xbc-bsx-wvs This time, @fixeria will be presenting on MS/BS power control support in OsmoBSC/OsmoBTS For those not entirely 3gpp-acronym-savyy: That's how the uplink (phone -> network) and downlink (network -> phone) transmit RF power level is adjusted during an active call in GSM. This meeting will have the following schedule: 20:00 meet + greet 20:10 presentation as outlined above 21:00 unstructured supplementary social event [*] Attendance is free of charge and open to anyone with an interest in Osmocom or open source cellular technologies. More information about OsmoDevCall, including the schedule for further upcoming events can be found at https://osmocom.org/projects/osmo-dev-con/wiki/OsmoDevCall Looking forward to meeting you soon! Best regards, Harald [*] this is how we started to call the "unstructured" part of osmocom developer conferences in the past, basically where anyone can talk about anything, no formal schedule or structure. -- - Harald Welte <laforge(a)osmocom.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

1 0

Osmocom binary package repository URLs have changed
by Oliver Smith 25 Oct '22

25 Oct '22

Hello various Osmocom mailing lists, as previously announced (https://osmocom.org/news/191): * The binary packages are being built on Osmocom's own OBS server now. * We will stop pushing packages to the openSUSE OBS server at the end of October (in one week). If you are using Osmocom binary packages, please make sure that you have configured the new repository URLs. See the wiki for details: https://osmocom.org/projects/cellular-infrastructure/wiki/Binary_Packages Best, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://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

← Newer
1
...
4
5
6
7
8
9
10
...
51
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs