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.
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.
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
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
