Project

General

Profile

Bug #3214

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

Added by laforge over 3 years ago. Updated over 3 years ago.

Status:
Resolved
Priority:
Urgent
Assignee:
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 
...

History

#1 Updated by laforge over 3 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

#2 Updated by laforge over 3 years ago

  • % Done changed from 30 to 80

Patch in https://gerrit.osmocom.org/7928 - unfortunately it required quite some restruturing

#3 Updated by laforge over 3 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

patch merged

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)