Project

General

Profile

Bug #3208

automatic test setup for OsmoGGSN with kernel-gtp-u

Added by laforge almost 3 years ago. Updated 3 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
04/24/2018
Due date:
% Done:

10%

Spec Reference:
Tags:
GTP

Description

We do have some tests in GGSN_Tests.ttcn which are executed at https://jenkins.osmocom.org/jenkins/job/ttcn3-ggsn-test/

However, this runs osmo-ggsn only in userspace mode, i.e. we're not testing the interaction with kernel-gtp-u.

Let's create a setup in which we can test with [various version of the] kernel gtp-u module. I guess this would then mean we're running some qemu-kvm VM with a given kernel + distribution, in which we're running a specified version of osmo-ggsn.

Turning the VM into a jenkins build slave is not a good idea, as that would mean it's not possible to build + restart a different kernel as needed. So we should rather have something like a build slave which then (inside a jenkins job) starts the VM with OsmoGGSN, possibly after rebuilding kernel and/or osmo-ggsn.

.config .config 61.2 KB proposed .config file laforge, 01/19/2021 01:50 PM

Related issues

Related to OsmoGGSN (former OpenGGSN) - Bug #3215: GGSN_Tests.ttcn GTP-U sequence number handling incompatible with kernel GTP-UResolved04/25/2018

History

#1 Updated by laforge almost 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 10
I'm not working with an automatic setup yet, but what I have managed so far is:
  • script to create a qumu-kvm VM with Debian 9 and all required packages, plus the libmnl, libgtpnl and osmo-ggsn source code
  • another script to
    • build a given [newer] Linux kernel version on the host, followed by
    • scp the resulting kernel+modules into the running VM and
    • using update-grub to activate the new kernel [only works if new version is higher]

This setup can then be used to run GGSN_Tests.ttcn against it.

#2 Updated by laforge almost 3 years ago

  • Related to Bug #3215: GGSN_Tests.ttcn GTP-U sequence number handling incompatible with kernel GTP-U added

#3 Updated by laforge over 2 years ago

  • Tags set to GTP

#4 Updated by laforge over 2 years ago

  • Status changed from In Progress to Stalled

#5 Updated by laforge over 2 years ago

  • Priority changed from Urgent to Normal

#6 Updated by laforge 6 days ago

  • Assignee changed from laforge to osmith

laforge wrote:

I'm not working with an automatic setup yet, but what I have managed so far is:
[...]

Not sure if I will find those scripts again, I will try.

Meanwhile, I'm convinced that a different approach might be more applicable:
  • build a very minimal kernel from a user-sepcified git tree (git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git is a good deafult)
  • build a initrd containing the kernel modules, osmo-ggsn and the dependencies (I guess network:osmocom:nightly is fine)
  • build a libvirt XML description for the qemu-kvm VM that can be used with virsh
  • attach that VM to the same network as the ttcn3-ggsn-test conatiner
  • execute the TTCN3 test suite like normal, but against the GGSN in the VM, not in the osmo-ggsn-master docker image

In this approach there would be no need for a block storage device at all. The initrd would contain everything needed.

Some useful links I'm currently trying to come up with a relatively minimal kernel .config that includes only what we need for running OsmoGGSN and the GTP kernel module. Will update this ticket accordingly.

#7 Updated by laforge 6 days ago

I would expect the attached .config file to build a kernel with everything we need. It was created by starting with 'allnoconfig' and then manually enabling various features. For sure one could go even smaller than this, but I enabled features which might come in handy at some later point.

#8 Updated by osmith 3 days ago

  • Status changed from Stalled to In Progress

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)