osmocom-net-gprs

osmocom-net-gprs@lists.osmocom.org

6 participants
480 discussions

[RFC PATCH 2/3] gtp: Add LSM hooks to GPRS Tunneling Protocol (GTP)

by Richard Haines

Add security hooks to allow security modules to exercise access control over GTP. Signed-off-by: Richard Haines <richard_c_haines(a)btinternet.com> --- drivers/net/gtp.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 48 insertions(+), 1 deletion(-) diff --git a/drivers/net/gtp.c b/drivers/net/gtp.c index 21640a035..ee00b12ab 100644 --- a/drivers/net/gtp.c +++ b/drivers/net/gtp.c @@ -73,6 +73,8 @@ struct gtp_dev { unsigned int hash_size; struct hlist_head *tid_hash; struct hlist_head *addr_hash; + + void *security; }; static unsigned int gtp_net_id __read_mostly; @@ -663,6 +665,12 @@ static int gtp_newlink(struct net *src_net, struct net_device *dev, gtp = netdev_priv(dev); + err = security_gtp_dev_add(&gtp->security); + pr_debug("security_gtp_dev_add() ptr: %p err: %d\n", + gtp->security, err); + if (err < 0) + return err; + err = gtp_encap_enable(gtp, data); if (err < 0) return err; @@ -705,7 +713,15 @@ static void gtp_dellink(struct net_device *dev, struct list_head *head) { struct gtp_dev *gtp = netdev_priv(dev); struct pdp_ctx *pctx; - int i; + int i, err; + + err = security_gtp_dev_del(gtp->security); + pr_debug("security_gtp_dev_del() ptr: %p err: %d\n", + gtp->security, err); + if (err < 0) { + pr_err("Failed security_gtp_dev_del_link() err: %d\n", err); + return; + } for (i = 0; i < gtp->hash_size; i++) hlist_for_each_entry_rcu(pctx, &gtp->tid_hash[i], hlist_tid) @@ -1076,6 +1092,12 @@ static int gtp_genl_new_pdp(struct sk_buff *skb, struct genl_info *info) goto out_unlock; } + err = security_gtp_dev_cmd(gtp->security, GTP_CMD_NEWPDP); + pr_debug("security_gtp_dev_cmd(GTP_CMD_NEWPDP) ptr: %p err: %d\n", + gtp->security, err); + if (err < 0) + goto out_unlock; + if (version == GTP_V0) sk = gtp->sk0; else if (version == GTP_V1) @@ -1139,6 +1161,7 @@ static struct pdp_ctx *gtp_find_pdp(struct net *net, struct nlattr *nla[]) static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) { struct pdp_ctx *pctx; + struct gtp_dev *gtp; int err = 0; if (!info->attrs[GTPA_VERSION]) @@ -1152,6 +1175,13 @@ static int gtp_genl_del_pdp(struct sk_buff *skb, struct genl_info *info) goto out_unlock; } + gtp = netdev_priv(pctx->dev); + err = security_gtp_dev_cmd(gtp->security, GTP_CMD_DELPDP); + pr_debug("security_gtp_dev_cmd(GTP_CMD_DELPDP) ptr: %p err: %d\n", + gtp->security, err); + if (err < 0) + goto out_unlock; + if (pctx->gtp_version == GTP_V0) netdev_dbg(pctx->dev, "GTPv0-U: deleting tunnel id = %llx (pdp %p)\n", pctx->u.v0.tid, pctx); @@ -1208,6 +1238,7 @@ static int gtp_genl_get_pdp(struct sk_buff *skb, struct genl_info *info) { struct pdp_ctx *pctx = NULL; struct sk_buff *skb2; + struct gtp_dev *gtp; int err; if (!info->attrs[GTPA_VERSION]) @@ -1221,6 +1252,13 @@ static int gtp_genl_get_pdp(struct sk_buff *skb, struct genl_info *info) goto err_unlock; } + gtp = netdev_priv(pctx->dev); + err = security_gtp_dev_cmd(gtp->security, GTP_CMD_GETPDP); + pr_debug("security_gtp_dev_cmd(GTP_CMD_GETPDP) ptr: %p err: %d\n", + gtp->security, err); + if (err < 0) + goto err_unlock; + skb2 = genlmsg_new(NLMSG_GOODSIZE, GFP_ATOMIC); if (skb2 == NULL) { err = -ENOMEM; @@ -1250,6 +1288,7 @@ static int gtp_genl_dump_pdp(struct sk_buff *skb, struct net *net = sock_net(skb->sk); struct pdp_ctx *pctx; struct gtp_net *gn; + int err; gn = net_generic(net, gtp_net_id); @@ -1263,6 +1302,14 @@ static int gtp_genl_dump_pdp(struct sk_buff *skb, else last_gtp = NULL; + err = security_gtp_dev_cmd(gtp->security, GTP_CMD_GETPDP); + pr_debug("security_gtp_dev_cmd(GTP_CMD_GETPDP) ptr: %p err: %d\n", + gtp->security, err); + if (err < 0) { + rcu_read_unlock(); + return err; + } + for (i = bucket; i < gtp->hash_size; i++) { j = 0; hlist_for_each_entry_rcu(pctx, &gtp->tid_hash[i], -- 2.26.2

4 years, 8 months

[RFC PATCH 1/3] security: Add GPRS Tunneling Protocol (GTP) security hooks

by Richard Haines

The GTP security hooks are explained in: Documentation/security/GTP.rst Signed-off-by: Richard Haines <richard_c_haines(a)btinternet.com> --- Documentation/security/GTP.rst | 39 ++++++++++++++++++++++++++++++++ Documentation/security/index.rst | 1 + include/linux/lsm_hook_defs.h | 3 +++ include/linux/lsm_hooks.h | 16 +++++++++++++ include/linux/security.h | 19 ++++++++++++++++ security/security.c | 18 +++++++++++++++ 6 files changed, 96 insertions(+) create mode 100644 Documentation/security/GTP.rst diff --git a/Documentation/security/GTP.rst b/Documentation/security/GTP.rst new file mode 100644 index 000000000..e307d0b59 --- /dev/null +++ b/Documentation/security/GTP.rst @@ -0,0 +1,39 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================= +GPRS Tunneling Protocol (GTP) +============================= + +GTP LSM Support +=============== + +Security Hooks +-------------- +For security module support, three GTP specific hooks have been implemented:: + + security_gtp_dev_add() + security_gtp_dev_del() + security_gtp_dev_cmd() + + +security_gtp_dev_add() +~~~~~~~~~~~~~~~~~~~~~~ +Allows a module to allocate a security structure for a GTP device. Returns a +zero on success, negative values on failure. +If successful the GTP device ``struct gtp_dev`` will hold the allocated +pointer in ``void *security;``. + + +security_gtp_dev_del() +~~~~~~~~~~~~~~~~~~~~~~ +Allows a module to free the security structure for a GTP device. Returns a +zero on success, negative values on failure. + + +security_gtp_dev_cmd() +~~~~~~~~~~~~~~~~~~~~~~ +Allows a module to validate a command for the selected GTP device. Returns a +zero on success, negative values on failure. The commands are based on values +from ``include/uapi/linux/gtp.h`` as follows:: + +``enum gtp_genl_cmds { GTP_CMD_NEWPDP, GTP_CMD_DELPDP, GTP_CMD_GETPDP };`` diff --git a/Documentation/security/index.rst b/Documentation/security/index.rst index 8129405eb..cdbdaa83b 100644 --- a/Documentation/security/index.rst +++ b/Documentation/security/index.rst @@ -16,3 +16,4 @@ Security Documentation siphash tpm/index digsig + GTP diff --git a/include/linux/lsm_hook_defs.h b/include/linux/lsm_hook_defs.h index 2a8c74d99..a994417fb 100644 --- a/include/linux/lsm_hook_defs.h +++ b/include/linux/lsm_hook_defs.h @@ -322,6 +322,9 @@ LSM_HOOK(int, 0, sctp_bind_connect, struct sock *sk, int optname, struct sockaddr *address, int addrlen) LSM_HOOK(void, LSM_RET_VOID, sctp_sk_clone, struct sctp_endpoint *ep, struct sock *sk, struct sock *newsk) +LSM_HOOK(int, 0, gtp_dev_add, void **security) +LSM_HOOK(int, 0, gtp_dev_del, void *security) +LSM_HOOK(int, 0, gtp_dev_cmd, void *security, enum gtp_genl_cmds cmd) #endif /* CONFIG_SECURITY_NETWORK */ #ifdef CONFIG_SECURITY_INFINIBAND diff --git a/include/linux/lsm_hooks.h b/include/linux/lsm_hooks.h index 9e2e3e637..3d6888d51 100644 --- a/include/linux/lsm_hooks.h +++ b/include/linux/lsm_hooks.h @@ -982,6 +982,22 @@ * This hook can be used by the module to update any security state * associated with the TUN device's security structure. * @security pointer to the TUN devices's security structure. + * @gtp_dev_add: + * This hook allows a module to allocate a security structure for a GTP + * device. + * @security pointer to a security structure pointer. + * Returns a zero on success, negative values on failure. + * @gtp_dev_del: + * This hook allows a module to free the security structure for a GTP + * device. + * @security pointer to the GTP device's security structure. + * Returns a zero on success, negative values on failure. + * @gtp_dev_cmd: + * This hook allows a module to free the security structure for a GTP + * device. + * @security pointer to the GTP device's security structure. + * @cmd contains the GTP command. + * Returns a zero on success, negative values on failure. * * Security hooks for SCTP * diff --git a/include/linux/security.h b/include/linux/security.h index 0a0a03b36..67ff43afa 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -30,6 +30,7 @@ #include <linux/err.h> #include <linux/string.h> #include <linux/mm.h> +#include <linux/gtp.h> struct linux_binprm; struct cred; @@ -1365,6 +1366,9 @@ int security_sctp_bind_connect(struct sock *sk, int optname, struct sockaddr *address, int addrlen); void security_sctp_sk_clone(struct sctp_endpoint *ep, struct sock *sk, struct sock *newsk); +int security_gtp_dev_add(void **security); +int security_gtp_dev_del(void *security); +int security_gtp_dev_cmd(void *security, enum gtp_genl_cmds cmd); #else /* CONFIG_SECURITY_NETWORK */ static inline int security_unix_stream_connect(struct sock *sock, @@ -1582,6 +1586,21 @@ static inline void security_sctp_sk_clone(struct sctp_endpoint *ep, struct sock *newsk) { } + +static inline int security_gtp_dev_add(void **security) +{ + return 0; +} + +static inline int security_gtp_dev_del(void *security) +{ + return 0; +} + +static inline int security_gtp_dev_cmd(void *security, enum gtp_genl_cmds cmd) +{ + return 0; +} #endif /* CONFIG_SECURITY_NETWORK */ #ifdef CONFIG_SECURITY_INFINIBAND diff --git a/security/security.c b/security/security.c index 70a7ad357..63b656848 100644 --- a/security/security.c +++ b/security/security.c @@ -2304,6 +2304,24 @@ void security_sctp_sk_clone(struct sctp_endpoint *ep, struct sock *sk, } EXPORT_SYMBOL(security_sctp_sk_clone); +int security_gtp_dev_add(void **security) +{ + return call_int_hook(gtp_dev_add, 0, security); +} +EXPORT_SYMBOL(security_gtp_dev_add); + +int security_gtp_dev_del(void *security) +{ + return call_int_hook(gtp_dev_del, 0, security); +} +EXPORT_SYMBOL(security_gtp_dev_del); + +int security_gtp_dev_cmd(void *security, enum gtp_genl_cmds cmd) +{ + return call_int_hook(gtp_dev_cmd, 0, security, cmd); +} +EXPORT_SYMBOL(security_gtp_dev_cmd); + #endif /* CONFIG_SECURITY_NETWORK */ #ifdef CONFIG_SECURITY_INFINIBAND -- 2.26.2

4 years, 8 months

[PATCH 0/3] Add LSM/SELinux support for GPRS Tunneling Protocol (GTP)

by Richard Haines

These patches came about after looking at 5G open source in particular the updated 5G GTP driver at [1]. As this driver is still under development, added the LSM/SELinux hooks to the current stable GTP version in kernel selinux-next [2]. Similar hooks have also been implemented in [1] as it uses the same base code as the current 3G version (except that it handles different packet types). To test the 3G GTP driver there is an RFC patch for the selinux-testsuite at [3]. To enable the selinux-testsuite GTP tests, the libgtpnl [4] library and tools needed to be modified to: Return ERRNO on error to detect EACCES, Add gtp_match_tunnel function, Allow gtp-link to specify port numbers for multiple instances to run in the same namespace. A patch for libgtpnl is supplied in the selinux-testsuite patch as well as setup/test instructions (libgtpnl is not packaged by Fedora) These patches were tested on Fedora 32 with kernel [2] using the 'targeted' policy. Also ran the Linux Kernel GTP-U basic tests [5]. [1] https://github.com/PrinzOwO/gtp5g [2] https://github.com/SELinuxProject/selinux-kernel [3] https://lore.kernel.org/selinux/20200924085314.6120-1-richard_c_haines@btin… [4] git://git.osmocom.org/libgtpnl.git [5] https://osmocom.org/projects/linux-kernel-gtp-u/wiki/Basic_Testing Changes from RFC patches: 1) Rework the LSM hook names and contents as suggested by Casey Schaufler. This resulted in moving the gtp_dev struct from gtp.c to include/net/gtp.h so that it is visible to the LSM modules for storing the security blob. 2) Remove pr_debug's from gtp.c security_* calls. 3) Minor GTP.rst updates. 4) Added netdev to distribution list. Richard Haines (3): security: Add GPRS Tunneling Protocol (GTP) security hooks gtp: Add LSM hooks to GPRS Tunneling Protocol (GTP) selinux: Add SELinux GTP support Documentation/security/GTP.rst | 100 ++++++++++++++++++++++++++++ Documentation/security/index.rst | 1 + drivers/net/gtp.c | 50 +++++++++----- include/linux/lsm_hook_defs.h | 3 + include/linux/lsm_hooks.h | 13 ++++ include/linux/security.h | 22 ++++++ include/net/gtp.h | 21 ++++++ security/security.c | 18 +++++ security/selinux/hooks.c | 66 ++++++++++++++++++ security/selinux/include/classmap.h | 2 + security/selinux/include/objsec.h | 4 ++ 11 files changed, 284 insertions(+), 16 deletions(-) create mode 100644 Documentation/security/GTP.rst -- 2.26.2

4 years, 8 months

[RFC] NS VTY interface

by Alexander 'lynxis' Couzens

Hi, with the new NS2 code [1] the vty keep compatible. However the new NS2 code is more flexible and support more use cases except the old vty doesn't allow it. I've created an osmocom ticket [2] to experiment and write a draft of the new VTY commands. I would be nice if you can give me some feedback here. Best, lynxis [1] NS <> NS2. it's still the same protocol, just a second implementation of NS. [2] https://osmocom.org/issues/4770 new vty example: 1.1. sgsn with udp bind - ipa style 1.2. sgsn with udp bind - with persistent nsvc 1.3. sgsn with sns listen on all interfaces 1.4. sgsn with sns listen on specific interface 1.5. sgsn with fr 2.1. TODO: pcu with binds to use when receiving info ind 2.2. TODO: pcu with static configuration <pre> ;; 1.1. sgsn with udp bind - dynamic with ipa style ns bind udp some listen 192.168.0.2 23000 allow-block-reset-nsvci </pre> <pre> ;; 1.2. sgsn with udp bind - no dynamic connection - only vty configured NSE (persistent) ns bind udp some listen 192.168.0.2 23000 nsei 1001 nsvc udp some 10.0.1.2 23000 </pre> <pre> ;; 1.2. sgsn with udp bind - no dynamic connection - only vty configured NSE (persistent) ns bind udp some listen 192.168.0.2 23000 bind udp other listen 192.168.1.2 23000 nsei 1001 ;; will use all bindings nsvc udp * 10.0.1.2 23000 nsei 1002 nsvc udp other 10.0.1.3 23000 nsvc udp some 10.0.1.3 23000 </pre> <pre> ;; 1.3. sgsn with sns listen on all interfaces ns bind udp some listen 192.168.0.2 23000 allow-sns group all bind udp other listen 192.168.1.2 23000 allow-sns group all </pre> <pre> ;; 1.4. sgsn with sns listen on specific interface ns bind udp some listen 192.168.0.2 23000 allow-sns group alice bind udp other listen 192.168.1.2 23000 allow-sns group bob </pre> <pre> ;; 1.5. sgsn with fr fr link hdlc1 link hdlc2 ns nsei 1002 nsvc fr hdlc1 dlci 10 nsvc fr hdlc2 dlci 10 </pre> -- Alexander Couzens mail: lynxis(a)fe80.eu jabber: lynxis(a)fe80.eu gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604

4 years, 8 months

[RFC PATCH 0/1] selinux-testsuite: Add GTP tests

by Richard Haines

These tests were performed on Fedora 32 Workstation with the 'targeted' policy using an updated kernel with the GTP RFC kernel patches. See the tests/gtp/GTP-README for detailed setup/testing. The libgtpnl patch is at: tests/gtp/Update-libgtpnl-for-SELinux-testsuite-GTP-tests.patch The basic process is: 1) Build kernel with RFC LSM/GTP/SELinux patches (use the selinux-testsuite/defconfig file to set correct config if required). 2) Setup the selinux-testsuite and add the GTP test patch. 3) Build/install the libgtpnl library using a patch from the selinux-testsuite as this will allow errors to be returned by the library functions. 4) Build/run selinux-testsuite for all SELinux tests (sets up the environment). 5) Run the GTP tests locally to see more info. 6) Remove the selinux-testsuite policy. Richard Haines (1): selinux-testsuite: Add GTP tests defconfig | 4 + policy/Makefile | 5 + policy/test_gtp.cil | 18 + policy/test_gtp.te | 96 +++++ tests/Makefile | 4 + tests/gtp/.gitignore | 2 + tests/gtp/GTP-README | 123 ++++++ tests/gtp/Makefile | 8 + ...tpnl-for-SELinux-testsuite-GTP-tests.patch | 366 ++++++++++++++++++ tests/gtp/gtp-link.c | 134 +++++++ tests/gtp/gtp-tunnel.c | 263 +++++++++++++ tests/gtp/test | 169 ++++++++ 12 files changed, 1192 insertions(+) create mode 100644 policy/test_gtp.cil create mode 100644 policy/test_gtp.te create mode 100644 tests/gtp/.gitignore create mode 100644 tests/gtp/GTP-README create mode 100644 tests/gtp/Makefile create mode 100644 tests/gtp/Update-libgtpnl-for-SELinux-testsuite-GTP-tests.patch create mode 100644 tests/gtp/gtp-link.c create mode 100644 tests/gtp/gtp-tunnel.c create mode 100755 tests/gtp/test -- 2.26.2

4 years, 8 months

ns2 thoughts

by Harald Welte

Hi List and Lynxis, I've been reading through the ns2 code more thoroughly and had some thoughts for improvement. As we have no users yet, and the code is unreleased, we can still make changes now. == unused argument in ns2_recv_vc int ns2_recv_vc(struct gprs_ns2_inst *nsi, struct gprs_ns2_vc *nsvc, struct msgb *msg) The 'nsi' is not used and should be redundant, as the nsvc has a back-pointer anyway, right? == consider using an osmo_ prefix to all symbols / types The fact that the old code doesn't have that is a tribute to its age, and not something we need to keep. The current code has quite a bit of 'gprs_ns2' prefixing for types, but not for the symbols/functions. At least that inconsistency should be resolved, so all have the same prefix, even if it is without osmo. == const-ify input arguments If arguments pointing to data are used read-only, let's express that by the const qualifier. The easy ones are the likes of "gprs_ns2_is_frgre_bind(struct gprs_ns2_vc_bind *bind)", but there are definitely many more. == use of msgb->dst In several other osmocom implementations we use msgb->dst to point to the underlying element receiving or transmitting a message. So I could imagine ns2_recv_vc() not only without the 'nsi' argument, but also without the 'nsvc' argument, if we introduce the convention that msgb->dst would always point to the ns-vc. Not sure here, it has pros and cons. Just brainstorming. == output arguments vs. return value There are functions like gprs_ns2_find_vc_by_sockaddr() where the result is not returned, but rather a **pointer output argument is used. What is the rationale here? I don't understand what benefit the extra 0/1 return value gives. The only other return value is -EINVAL if the **ptr was NULL - an error situation that wouldn't exist if we simply returned the pointer from the function. Regards, Harald -- - 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)

4 years, 8 months

GSM, GPRS

by Сергей Егоров

Hi! I with my friends-students got a task to investigate ciphering algorithm GEA3, using in GPRS/EDGE. While communication MS and Osmocom base station (BS) we've got the LLC-message: LLC MESSAGE (ciphered): 01C00F1840623297A594EE196714A2653D23D5A2AC52792F0434 with the following parameters: Cipher Algorithm: GEA3 Kc_GPRS: A8FC3A996A80D000 SAPI: 1 NU: 3 IOV_UI: 0 OC: 0 After applying algorithm GEA3 we've got deciphered LLC-message: LLC MESSAGE (deciphered): 01C00F0802012A0452F00300010017161805F4D7BF04CA 26176B We get, calculated FCS (6B1726) using deciphered LLC-message and contained in LLC-message FCS (6B1726) are equal. While communication MS and the real BS we've got the following LLC-message: LLC MESSAGE (ciphered) 41C00B9299A1EB51A1AD1FE71633786B23CBD8E6D41C9F658C89C9544AF2BAAC35 with the following parameters: Cipher Algorithm: GEA3 KC_GPRS: 8f94a69c3d9bdf48 SAPI: 1 NU: 2 IOV_UI: 0x10000000 (got from XID) OC: from 0 to 8388608 So we tried to apply the OC parameter from 0 to 8388608 to decipher the message (other parameters were not been changed). In every step, we calculated FCS and compared it with contained in LLC-message FCS and had no success. Finally the question: Can the value of IOV_UI (Osmocom BS: 0, real BS: 0x10000000) affect the deciphering, and if yes then how?? With regards, students of the telecommunication department. Thank you for your attention! Best regards, Sergei ----------------------------------------------------------------------

4 years, 8 months

GSM, GPRS

by Сергей Егоров

Good afternoon! I with my friends-students got a task to investigate ciphering algorithm GEA3, using in GPRS/EDGE. While communication MS and Osmocom base station (BS) we've got the LLC-message: LLC MESSAGE (ciphered): 01C00F1840623297A594EE196714A2653D23D5A2AC52792F0434 with the following parameters: Cipher Algorithm: GEA3 Kc_GPRS: A8FC3A996A80D000 SAPI: 1 NU: 3 IOV_UI: 0 OC: 0 After applying algorithm GEA3 we've got deciphered LLC-message: LLC MESSAGE (deciphered): 01C00F0802012A0452F00300010017161805F4D7BF04CA 26176B We get, calculated FCS (6B1726) using deciphered LLC-message and contained in LLC-message FCS (6B1726) are equal. While communication MS and the real BS we've got the following LLC-message: LLC MESSAGE (ciphered) 41C00B9299A1EB51A1AD1FE71633786B23CBD8E6D41C9F658C89C9544AF2BAAC35 with the following parameters: Cipher Algorithm: GEA3 KC_GPRS: 8f94a69c3d9bdf48 SAPI: 1 NU: 2 IOV_UI: 0x10000000 (got from XID) OC: from 0 to 8388608 So we tried to apply the OC parameter from 0 to 8388608 to decipher the message (other parameters were not been changed). In every step, we calculated FCS and compared it with contained in LLC-message FCS and had no success. Finally the question: Can the value of IOV_UI (Osmocom BS: 0, real BS: 0x10000000) affect the deciphering, and if yes then how?? With regards, students of the telecommunication department. Thank you for your attention! Best regards, Sergei ----------------------------------------------------------------------

4 years, 9 months

OsmoDevCon / COVID-19

by Harald Welte

Dear fellow Osmocom developers, as you all know, we've sadly had to postpone OsmoDevCon 2020 back in April this year. At the time, we discussed to re-visit the situation in October 2020. While legally it is no problem at all to host an event with ~ 20 participants in Berlin/Germany (specific regulations really only start from 50+ participants) - I'm not entirely convinced it would be the smartest move. Legality and public health regulations are only one part of the equation - common sense and profound care for the key members of our community for sure are more relevant considerations to me. I'm not 100% in favour and not 100% against. Hence, I would like to get your input. Should we a) try to get an event organized on-site in Berlin? We'd have to move to a larger venue than IN-Berlin with proper ventilation and sufficient space so we can keep physical distance, but I think that's manageable for sysmocom as organizer. b) simply postpone to 2021? I'm convinced the situation will not change significantly (in a positive way) until late April 2021, so it's not really a "solution" as it will likely mean we have to think of late 2021 or 2022. c) plan some kind of online conference? To be honest, I think this model works fine for events where a single speaker wants to give lectures to hundreds or thousands of participants. But OsmoDevCon is much more interactive. We could record or live-stream some talks or screencasts from home, sure. But that only captures one part of the event. We could also try to set a date for a collaborative mumble, or the like - for the "hallway track". What are your thoughts? Let's avoid cross-posting the discussion to all of the mailing lists and simply have it on openbsc(a)lists.osmocom.org. Regards, Harald -- - 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)

4 years, 9 months

[PATCH net-next 0/2] gtp: minor enhancements

by Nicolas Dichtel

The first patch removes a useless rcu lock and the second relax alloc constraints when a PDP context is added. drivers/net/gtp.c | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) Comments are welcomed, Nicolas

4 years, 9 months

← Newer
1
...
9
10
11
12
13
14
15
...
48
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

osmocom-net-gprs