Bug #3214: osmo-ggsn fails to set route with kernel gtp-u - OsmoGGSN (former OpenGGSN) - Open Source Mobile Communications

Actions

Copy link

Bug #3214

closed

osmo-ggsn fails to set route with kernel gtp-u

Added by laforge almost 6 years ago. Updated almost 6 years ago.

Status:

Resolved

Priority:

Urgent

Assignee:

laforge

Category:

Target version:

Start date:

04/25/2018

Due date:

% Done:

100%

Spec Reference:

Description

When the config file contains statements like these:

ggsn ggsn0
 ...
 apn foobar
  ...
  ip ifconfig 10.1.1.254/24
  ...

then it fails as follows:

<0002> gtp-kernel.c:75 Initialized GTP kernel mode (genl ID is 25)
<0002> gtp-kernel.c:102 Setting route to reach 10.1.1.254/24 via gtp0
<0002> gtp-kernel.c:105 Cannot add route to reach network 10.1.1.254/24

This happens whenever the host-part of the address (i.e. the last 8 bits in the /24 example above) is not zeroed out.

So simply changing the config file to:

ggsn ggsn0
 ...
 apn foobar
  ...
  ip ifconfig 10.1.1.0/24
  ...

avoids the related error and the log file is

<0002> gtp-kernel.c:75 Initialized GTP kernel mode (genl ID is 25)
<0002> gtp-kernel.c:102 Setting route to reach 10.1.1.0/24 via gtp0
<0002> gtp-kernel.c:127 GTP kernel configured

and the related route shows up in "ip route":

root@ggsn:/etc# ip route show
...
10.1.1.0/24 dev gtp0 proto static 
...

Actions

Copy link

Updated by laforge almost 6 years ago

Status changed from New to In Progress
% Done changed from 0 to 30

We're using the gtp_dev_config() function of libgtpnl to configure the related route. This function actually doesn't configure an IP/netmask to the gtp0 net-device, but it adds a route using RTM_NEWROUTE, as can be seen at http://git.osmocom.org/libgtpnl/tree/src/gtp-rtnl.c#n171

The philosophy behind that is probably that the GGSN doesn't need an inner IP address on the cellular network side, and that the gtp0 device is not a link-layer that is multicast or broadcast capable (and hence has a netmask concept). Instead, every tunnel inside a gtp0 device is its own point-to-point tunnel. This is quite different from the way how we treat tun0 devices in the case of userspace GTP-U.

We could either

change this notion and simply add ip/netmask support to gtp0 style devices, or
document the differences and provide proper error handling, i.e. only allowing a zeroed host-part of the prefix when parsing the VTY in kernel-gtpu mode.

Manually adding ip/netmask to the gtp0 device seems to work:

root@ggsn:/etc# ip addr add 10.1.1.254/24 dev gtp0
root@ggsn:/etc# ip addr show dev gtp0
14: gtp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 0 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none 
    inet 10.1.1.254/24 scope global gtp0
       valid_lft forever preferred_lft forever

Actions

Copy link