All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Schultz <aschultz@tpip.net>
To: laforge <laforge@gnumonks.org>
Cc: osmocom-net-gprs <osmocom-net-gprs@lists.osmocom.org>,
	netdev <netdev@vger.kernel.org>,
	Pablo Neira Ayuso <pablo@gnumonks.org>
Subject: Re: RFC: unit tests for kernel GTP module
Date: Fri, 17 Feb 2017 16:02:59 +0100 (CET)	[thread overview]
Message-ID: <1507789126.143172.1487343779235.JavaMail.zimbra@tpip.net> (raw)
In-Reply-To: <20170216220801.o3fajacj4sx3iere@nataraja>

Hi,

----- On Feb 16, 2017, at 11:08 PM, laforge laforge@gnumonks.org wrote:

> Dear GTP-interested folks,
> 
> I would love to somehow get towards some degree of unit testing (or even
> "continuous integration") for teh kernel GTP code.
> 
> We currently have the original code in the kernel, we had some recent
> small fixes and now are getting more patches into place.  With
> relatively few active users out there (and probably none of them in
> production yet), it's particularly easy to introduce regressions while
> working on the code.  Also, having tested new code even against a
> test set with limited covrage could help to get more confidence in new
> patches and thus get them merged sooner.

We do run the current kernel code in production. The version I have
been push patches for will be deployed into prod soonish.

Automated testing is something we are also looking at. Currently, we
have cooperation going on with a vendor of a an RAN and EPC protocol
testing solution. The goal is to have a automated testing setup for
our GGSN/PDN-GW OpenSource project. That setup will also exercise the
kernel parts.
The test suite is proprietary, so we can only share the results but
not the test setup itself.

> Using tools like sgsnemu of OpenGGSN and the command line tools included
> in libgtpnl, it should be possibel to cook up some scripts for testing.
> Even the most basic set of tests would be an improvement over what we
> have now.  One could also think about pcap replay to test with
> hand-crafted or real-world packets from other GTP implementations.

We more or less removed static GTP tunnels. The tools in libgtpnl
only work when an application is keeping the GTP socket alive.

Andreas

> As much as I'd like to put something like this into place myself, I
> don't think I will be able to work much on this in the near future. The
> GTP module at this point is a pure hobby and contrary to some years ago
> while I started it, I don't have any contract work in the GTP area at
> this point, so other projects currently unfortunately get more
> attention.
> 
> So in case somebody among the GTP-interested parties (Travelping, OAI,
> ...) would want to do something in terms of testing, I'd be more than
> happy if somebody would step ahead.  Otherwise it's all just vapourware
> going to end up on my ever-growing TODO list :/
> 
> Also, if netdev folks have some ideas/pointers about possible
> frameworks/tools for this kind of testing [it must exist for at least
> some other kernel networking code?]: Please let me know.  I'd be
> interested to have a look if there's something that can be used as a
> basis (starting network namespaces, sending/transmitting packets, test
> case startup/teardown, ...)
> 
> My "old school" approach would have been to start one or multiple
> user-mode-linux kernels (those that are to be tested), and then have
> scripts that set up a gtp socket and gtp tunnels via the libgtp command
> line tools, and throw packets at that.   But I'm sure there must be
> quite powerful frameworks for that kind of testing in the 21st century?
> How do other tunneling implementations handle this?
> 
> Regards,
>	Harald
> --
> - Harald Welte <laforge@gnumonks.org>           http://laforge.gnumonks.org/
> ============================================================================
> "Privacy in residential applications is a desirable marketing option."
>                                                   (ETSI EN 300 175-7 Ch. A6)

  parent reply	other threads:[~2017-02-17 15:03 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-16 22:08 RFC: unit tests for kernel GTP module Harald Welte
2017-02-17 10:22 ` Ido Schimmel
2017-02-17 15:02 ` Andreas Schultz [this message]
2017-02-17 18:03   ` Harald Welte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1507789126.143172.1487343779235.JavaMail.zimbra@tpip.net \
    --to=aschultz@tpip.net \
    --cc=laforge@gnumonks.org \
    --cc=netdev@vger.kernel.org \
    --cc=osmocom-net-gprs@lists.osmocom.org \
    --cc=pablo@gnumonks.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.