I've had an interesting situation with osmo-ggsn and kernel GTP module that I wonder if someone could shed some light on.
I've set up osmo-ggsn (v1.7.1) on Debian 10. There are two ethernet interfaces on the system, ens224 (for the Gn Interface) and ens256 (for the Gi Interface).
Using the following ggsn configuration seems to work fine:
ggsn ggsn0 description Keith's Test APN gtp state-dir /tmp gtp bind-ip <ens224 IP> gtp control-ip <ens224 IP> apn keithtest gtpu-mode tun tun-device apn0 type-support v4 ip prefix dynamic 192.168.42.0/24 ip dns 0 <redacted> ip dns 1 <redacted> ip ifconfig 192.168.42.0/24 no shutdown default-apn keithtest no shutdown ggsn
I get the following tun device:
5: apn0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 500 link/none inet 192.168.42.0/24 scope global apn0 valid_lft forever preferred_lft forever inet6 fe80::fada:2e69:ad71:a61b/64 scope link stable-privacy valid_lft forever preferred_lft forever
Traffic routes, all is good with the world.
However, if I change to using Kernel GTP, by changing the gtpu-mode to "kernel-gtp", traffic will not route (and, yes, I have done modprobe gtp). After some exploration, it appears the tun device is being created with an MTU of zero which then, cannot pass traffic:
10: apn0: <POINTOPOINT,UP,LOWER_UP> mtu 0 qdisc noqueue state UNKNOWN group default qlen 1000 link/none inet 192.168.42.0/24 scope global apn0 valid_lft forever preferred_lft forever
Here are the logs:
Tue Apr 13 11:02:06 2021 DGGSN NOTICE <0002> ggsn.c:830 GGSN(ggsn0): Successfully started Tue Apr 13 11:02:06 2021 DGGSN INFO <0002> ggsn.c:186 APN(keithtest): Starting Tue Apr 13 11:02:06 2021 DGGSN INFO <0002> ggsn.c:204 APN(keithtest): Opening Kernel GTP device apn0 Tue Apr 13 11:02:06 2021 DGGSN NOTICE <0002> gtp-kernel.c:79 Initialized GTP kernel mode (genl ID is 24) Tue Apr 13 11:02:06 2021 DTUN NOTICE <0001> tun.c:217 GTP kernel configured Tue Apr 13 11:02:06 2021 DGGSN INFO <0002> ggsn.c:236 APN(keithtest): Setting tun IP address 192.168.42.0/24 Tue Apr 13 11:02:06 2021 DGGSN INFO <0002> ggsn.c:294 APN(keithtest): Creating IPv4 pool 192.168.42.0/24 Tue Apr 13 11:02:06 2021 DGGSN INFO <0002> ggsn.c:168 APN(keithtest): Blacklist tun IP 192.168.42.0/24 Tue Apr 13 11:02:06 2021 DGGSN NOTICE <0002> ggsn.c:325 APN(keithtest): Successfully started
Note that if I manually alter the MTU, everything starts working again: ip link set dev apn0 mtu 1500
So I can put this into a script and run it via ipup-script, and this works fine. I just get the impression I shouldn't have to do this, and the system should be setting the MTU, just as it does when I use tun mode.
Any thoughts on what I'm doing wrong here?
Cheers,
Keith
Hi Keith,
On Tue, Apr 13, 2021 at 11:10:18AM +0100, Keith A. Milner wrote:
However, if I change to using Kernel GTP, by changing the gtpu-mode to "kernel-gtp", traffic will not route (and, yes, I have done modprobe gtp). After some exploration, it appears the tun device is being created with an MTU of zero which then, cannot pass traffic:
I think this one is fixed in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/dr... but "of course" Debian 10 is using a too old kernel to contain that fix.
You could ask Debian if they'd back-port it to the stable kernel?
We would certainly also be happy to accept a patch mentioning this in the user manual, or a patch that makes osmo-ggsn check the MTU at startup time and print some big error message into the log.
On Tuesday, 13 April 2021 13:14:48 BST Harald Welte wrote:
Hi Keith,
On Tue, Apr 13, 2021 at 11:10:18AM +0100, Keith A. Milner wrote:
However, if I change to using Kernel GTP, by changing the gtpu-mode to "kernel-gtp", traffic will not route (and, yes, I have done modprobe gtp). After some exploration, it appears the tun device is being created with an MTU of zero which then, cannot pass traffic:
I think this one is fixed in https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/dr ivers/net?id=e21eb3a065a2d90ee3bb06cc2e77acad403ec7cd but "of course" Debian 10 is using a too old kernel to contain that fix.
Ah, missed that. Thanks Harald.
You could ask Debian if they'd back-port it to the stable kernel?
It's not that big of an issue for me, as this is just for some testing. I was mainly concerned I had missed some configuration somewhere. As I can use the ipup-script this will work for me.
We would certainly also be happy to accept a patch mentioning this in the user manual, or a patch that makes osmo-ggsn check the MTU at startup time and print some big error message into the log.
I will have a look at that, probably at the former rather than the latter.
Thanks once again.
Keith
osmocom-net-gprs@lists.osmocom.org