msuraev has posted comments on this change. ( https://gerrit.osmocom.org/c/libosmo-abis/+/29021 )
Change subject: pkgconf: require libosmocore
......................................................................
Set Ready For Review
--
To view, visit https://gerrit.osmocom.org/c/libosmo-abis/+/29021
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: libosmo-abis
Gerrit-Branch: master
Gerrit-Change-Id: Iacf4ccdb1c2a0e64ac997bda11161b8fe2548725
Gerrit-Change-Number: 29021
Gerrit-PatchSet: 1
Gerrit-Owner: msuraev <msuraev(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Comment-Date: Wed, 10 Aug 2022 09:28:05 +0000
Gerrit-HasComments: No
Gerrit-Has-Labels: No
Gerrit-MessageType: comment
Attention is currently required from: pespin.
Hello Jenkins Builder,
I'd like you to reexamine a change. Please visit
https://gerrit.osmocom.org/c/osmo-upf/+/28986
to look at the new patch set (#2).
Change subject: GTP mockup: allow single GTP devices in mockup mode
......................................................................
GTP mockup: allow single GTP devices in mockup mode
Drop the global GTP mockup mode, and instead allow single GTP devices to
be mockup devices.
Do not always open the mnl_socket, but only open it when an actual
non-mockup GTP device is being opened. (In the presence of non-mockup
GTP devices, this still happens directly upon program startup.)
The GTP mockup was first introduced for VTY tests during 'make check'.
So far, in mockup mode, all GTP tunnel actions were simply cut short,
and no tunnels were ever listed as active.
TTCN3 tests do query osmo-upf to list currently active tunnels, so the
GTP mockup fails these tests. To allow running TTCN3 tests without
cap_net_admin privileges, instead of a global GTP mockup mode, allow
creating single GTP device(s) in mockup mode, which then also list their
(fake) active GTP tunnels.
Also useful in a lab environment: send PFCP commands to osmo-upf and get
a listing of GTP tunnels that would have been active.
So far, osmo-upf always uses only the first GTP device configured, but
if we add support for multiple GTP devices, this patch allows putting
only single devices in mockup mode.
Related: SYS#5599
Change-Id: Ic09a5ccea24086eb04f46e6af669668e5fade752
---
M doc/examples/osmo-upf/osmo-upf-mockup.cfg
M include/osmocom/upf/upf.h
M include/osmocom/upf/upf_gtp.h
M src/osmo-upf/osmo_upf_main.c
M src/osmo-upf/up_gtp_action.c
M src/osmo-upf/upf.c
M src/osmo-upf/upf_gtp.c
M src/osmo-upf/upf_vty.c
M tests/upf.vty
9 files changed, 82 insertions(+), 66 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-upf refs/changes/86/28986/2
--
To view, visit https://gerrit.osmocom.org/c/osmo-upf/+/28986
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-upf
Gerrit-Branch: master
Gerrit-Change-Id: Ic09a5ccea24086eb04f46e6af669668e5fade752
Gerrit-Change-Number: 28986
Gerrit-PatchSet: 2
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: newpatchset
neels has uploaded this change for review. ( https://gerrit.osmocom.org/c/osmo-upf/+/29020 )
Change subject: vty doc tweaks
......................................................................
vty doc tweaks
Clarify "Add" and "Delete" of GTP devices.
Clarify GTP device in config vs. real GTP device.
Clarify s/kernel/Linux kernel
Related: SYS#5599
Change-Id: I918e0a9a332e4dd4b71965614c19481eb41004d6
---
M src/osmo-upf/upf_vty.c
M tests/upf.vty
2 files changed, 8 insertions(+), 7 deletions(-)
git pull ssh://gerrit.osmocom.org:29418/osmo-upf refs/changes/20/29020/1
diff --git a/src/osmo-upf/upf_vty.c b/src/osmo-upf/upf_vty.c
index 386aa2f..5227dba 100644
--- a/src/osmo-upf/upf_vty.c
+++ b/src/osmo-upf/upf_vty.c
@@ -86,7 +86,7 @@
DEFUN(cfg_gtp, cfg_gtp_cmd,
"gtp",
- "Enter the 'gtp' node to configure GTP kernel module usage\n")
+ "Enter the 'gtp' node to configure Linux GTP kernel module usage\n")
{
vty->node = GTP_NODE;
return CMD_SUCCESS;
@@ -135,7 +135,8 @@
DEFUN(cfg_gtp_dev_create, cfg_gtp_dev_create_cmd,
"dev create DEVNAME [LISTEN_ADDR]",
DEV_STR
- "create a new GTP device. Will listen on GTPv1 port " OSMO_STRINGIFY_VAL(PORT_GTP1_U)
+ "Add GTP device, creating a new Linux kernel GTP device. Will listen on GTPv1 port "
+ OSMO_STRINGIFY_VAL(PORT_GTP1_U)
" and GTPv0 port " OSMO_STRINGIFY_VAL(PORT_GTP0_U) " on the specified interface, or on ANY if LISTEN_ADDR is"
" omitted.\n"
"device name, e.g. 'apn0'\n"
@@ -154,7 +155,7 @@
DEFUN(cfg_gtp_dev_use, cfg_gtp_dev_use_cmd,
"dev use DEVNAME",
DEV_STR
- "use an existing GTP device, e.g. created by 'gtp-link'\n"
+ "Add GTP device, using an existing Linux kernel GTP device, e.g. created by 'gtp-link'\n"
"device name, e.g. 'apn0'\n")
{
struct gtp_vty_cfg_dev *d = talloc_zero(g_upf, struct gtp_vty_cfg_dev);
@@ -168,7 +169,7 @@
DEFUN(cfg_gtp_dev_del, cfg_gtp_dev_del_cmd,
"dev delete DEVNAME",
DEV_STR
- "Remove a GTP device from the configuration, and delete the device if it was created here.\n"
+ "Remove a GTP device from the configuration, and delete the Linux kernel GTP device if it was created here.\n"
"device name, e.g. 'apn0'\n")
{
const char *dev_name = argv[0];
diff --git a/tests/upf.vty b/tests/upf.vty
index 107909b..d1cebe5 100644
--- a/tests/upf.vty
+++ b/tests/upf.vty
@@ -23,9 +23,9 @@
OsmoUPF(config-gtp)# dev?
dev Configure the GTP device to use for encaps/decaps.
OsmoUPF(config-gtp)# dev ?
- create create a new GTP device. Will listen on GTPv1 port 2152 and GTPv0 port 3386 on the specified interface, or on ANY if LISTEN_ADDR is omitted.
- use use an existing GTP device, e.g. created by 'gtp-link'
- delete Remove a GTP device from the configuration, and delete the device if it was created here.
+ create Add GTP device, creating a new Linux kernel GTP device. Will listen on GTPv1 port 2152 and GTPv0 port 3386 on the specified interface, or on ANY if LISTEN_ADDR is omitted.
+ use Add GTP device, using an existing Linux kernel GTP device, e.g. created by 'gtp-link'
+ delete Remove a GTP device from the configuration, and delete the Linux kernel GTP device if it was created here.
OsmoUPF(config-gtp)# dev create ?
DEVNAME device name, e.g. 'apn0'
OsmoUPF(config-gtp)# dev create foo ?
--
To view, visit https://gerrit.osmocom.org/c/osmo-upf/+/29020
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-upf
Gerrit-Branch: master
Gerrit-Change-Id: I918e0a9a332e4dd4b71965614c19481eb41004d6
Gerrit-Change-Number: 29020
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-MessageType: newchange
Attention is currently required from: pespin.
neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-upf/+/28986 )
Change subject: GTP mockup: allow single GTP devices in mockup mode
......................................................................
Patch Set 1:
(1 comment)
Commit Message:
https://gerrit.osmocom.org/c/osmo-upf/+/28986/comment/36f92eaa_7e0f315e
PS1, Line 20: TTCN3 tests do query osmo-upf to list currently active tunnels, so the
> why do you need mockup mode in TTCN3 in first place? […]
The real-world reason is that so far there is no GTP testing in the TTCN3 tests yet.
So I ran in GTP mokup mode, and noticed that it is unfortunate that in mockup mode,
the VTY does not show any GTP actions. Active GTP actions are put in a list
located in the struct upf_gtp_dev, so to list mocked-up actions, i need a GTP device struct present.
That's how i came to implement a GTP device that does not do anything
but still lists the actions it would have done.
Now I am finding justifications for that useful code, after the fact.
In a lab or production environment, it could become a good thing to turn individual APNs into mockup mode.
The mockup mode should list the fake GTP actions.
idk, do you guys think the mockup stuff is a non-feature? maybe i'm spinning off
on a tangent here.
In general the mockup stuff is very useful for running tests
without root access, or on a linux kernel that does not have (recent
enough) GTP kernel support. But I don't really have that situation, I'm just
lazy to constantly put cap_net_admin on the binary... That's no good
justification on its own, but I figured it could still help someone some day.
If we keep the mockup, this patch makes it better by listing the fake actions.
--
To view, visit https://gerrit.osmocom.org/c/osmo-upf/+/28986
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-upf
Gerrit-Branch: master
Gerrit-Change-Id: Ic09a5ccea24086eb04f46e6af669668e5fade752
Gerrit-Change-Number: 28986
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-CC: pespin <pespin(a)sysmocom.de>
Gerrit-Attention: pespin <pespin(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 09 Aug 2022 23:19:24 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: No
Comment-In-Reply-To: pespin <pespin(a)sysmocom.de>
Gerrit-MessageType: comment
Attention is currently required from: laforge, fixeria.
neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-upf/+/28984 )
Change subject: main: show just a brief talloc report for vty
......................................................................
Patch Set 1: Code-Review+2
(2 comments)
Patchset:
PS1:
combine votes
File src/osmo-upf/osmo_upf_main.c:
https://gerrit.osmocom.org/c/osmo-upf/+/28984/comment/1d1eb6bf_1436209b
PS1, Line 380: talloc_report
> well, libosmovty could also have talloc memory leaks. […]
detecting vty leaks would work when remembering the talloc count+size before the main loop starts and comparing against that later
--
To view, visit https://gerrit.osmocom.org/c/osmo-upf/+/28984
To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings
Gerrit-Project: osmo-upf
Gerrit-Branch: master
Gerrit-Change-Id: I038951c6d62679e3cfcda51512768d1fbacaa0d1
Gerrit-Change-Number: 28984
Gerrit-PatchSet: 1
Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Reviewer: Jenkins Builder
Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Reviewer: laforge <laforge(a)osmocom.org>
Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de>
Gerrit-Attention: laforge <laforge(a)osmocom.org>
Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-Comment-Date: Tue, 09 Aug 2022 22:46:20 +0000
Gerrit-HasComments: Yes
Gerrit-Has-Labels: Yes
Comment-In-Reply-To: laforge <laforge(a)osmocom.org>
Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de>
Gerrit-MessageType: comment