Since the modem iface and the GGSN iface are on the same host/netns,
it's really difficult to conveniently test data plane without getting
routing loops. As a result, either GGSN or modem iface must be moved to
a different namespace. The decision after a few discussions was finally
to move modem interfaces to a different netns.
Expected setup:
* ofono is patched to avoid removing modem if it detects
through udev that its net iface was removed (due to for instance, net
iface being moved to another netns and thus not being reachable anymore
by systemd-udev process running in root netns).
* After ofono is started (and successfully configured all the modems and
detected its net ifaces through syfs/udev), script "modem-netns-setup.py
start" which creates a netns for each modem, naming it after its usb
path ID. net ifaces for that modem are moved into its netns.
* Modem is configured to use 802-3 data format, and as a result the net
iface is configured through DHCP (DHCP req only replied AFTER pdp ctx is
activated!).
* Since osmo-gsm-tester knowns the modem USB path ID (available in
resources.conf), it can run required steps (ifup, DHCP) to configure the
interface. The interface name is provided by ofono to osmo-gsm-tester.
* As a result, any process willing to transmit data through the modem
must be in the modem netns.
Related: OS#2308
Change-Id: Icb06bdfcdd37c797be95ab5addb28da2d9f6681c
osmo-ggsn requires a link-local IPv6 address to be added to the
tun interface, otherwise the apn will not be configured correctly and it
won't be able to allocate addresses from the ipv6 pool later on.
Some OS don't support autoconfiguring link-local IPv6 addresses when the
interface is brought up (some linux versions are known to fail at it).
This is the case for our Prod osmo-gsm-tester setup (running debian8
with kernel 3.16.51).
Make sure we configure correctly the interface by forcing osmo-ggsn to
set on the interface and use a specific IPv6 link-local address. This is
done by using the "ipv6 link-local" vty cmd in osmo-ggsn.
After this modification, we can re-enable ipv6 gprs context creation as
it will work in Prod setup.
Related: OS#2746
Change-Id: Ib291c02a3c57a4189f9c4b1b856109be97ad2a34
osmo-ggsn is failing to create tun ipv6 device in Prod main unit.
Afterwards, as the iface is not created, it cannot find its link-local
ip and it doesn't configure the ipv6 pool. Later on, when an ipv4v6 ctx
is requested, it fails because apn doesn't support ipv6 (because the
pool is not created).
Related: OS#2746
Change-Id: I018c525a8a3d108233740ee1376b2671fefbbb59
Otherwise osmo-ggsn tries to allocate one IP of each type but fails
because the other APNs are ipv4-only or ipv6-only.
Change-Id: I53baa63dc1b83616a35af182cb6f56ee3d7fe38b
Only GPRS signalling setup is supported so far by osmo-gsm-tester, thus
we don't test sending data yet here, but at least we can already test
pdp context activation.
This test will be extended to run ping once we support setting up the
GPRS data plane in osmo-gsm-tester.
Change-Id: I8695029cb7a43cd48f650c88f38b4c054da0bc6b
Pau Espin