[Solved] busybox doesn't support gretap

Trying to get a gretap link to work, and having challenges even with command-line testing, even before trying to translate it to UCI.

TL;DR

Even when compiled with the tunnel option, busybox does not appear to support gretap tunnels. The ip-full package, as suggested by @mikma, allows gretap tunnel creation.

I've got busybox recompiled with ip tunnel enabled and installed in place, confirmed working. I believe I've got all the right modules for LEDE 17.01.4, including
gre - 1-7
kmod-gre - 4.4.92-1
kmod-iptunnel - 4.4.92-1

I can create and use a routed tunnel from the command line without issue, with one side looking like:

# ip tunnel add test-tunnel mode gre remote 10.11.12.2
# ip link set test-tunnel up
# ip link show test-tunnel
22: test-tunnel@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1476 qdisc noqueue state UNKNOWN qlen 1
    link/gre 0.0.0.0 peer 10.11.12.2
# ip addr add 10.1.1.1 dev test-tunnel
# ip route add 10.1.1.0/25 dev test-tunnel
# ping 10.1.1.2

However when I try to create a bridged tunnel, I can't seem to get anywhere either with the command line, or with UCI.

On boot, I get two links, which never seem to change:

4: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN qlen 1
    link/gre 0.0.0.0 brd 0.0.0.0
5: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

If I try to configure a gretap link manually, it fails

root@coop:/etc# ip link add test-gt type gretap remote 10.11.12.1
ip: RTNETLINK answers: File exists
root@coop:/etc# ip link add test-gt type gretap remote 10.11.12.1 local 10.11.12.2
ip: RTNETLINK answers: File exists

https://www.mail-archive.com/openwrt-tickets@lists.openwrt.org/msg12435.html seems to suggest that it was a problem at one time, but dev.openwrt.org is still inaccessible to investigate further what was done back then, if anything.

I checked on an Ubuntu box, and the syntax seems correct, as is the expectation that the link would show up in ip link

jeff@ubuntu:~$ sudo ip link add tunnel type gretap remote 10.10.10.1
jeff@ubuntu:~$ ip link show
[...]
5: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN mode DEFAULT group default qlen 1
    link/gre 0.0.0.0 brd 0.0.0.0
6: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
7: tunnel@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 16:2f:8e:fe:ed:e7 brd ff:ff:ff:ff:ff:ff

If I try to configure with UCI, based on https://wiki.openwrt.org/doc/uci/network#protocol_gretap_ethernet_gre_tunnel_over_ipv4, I don't see the link created either with ip link show or ifconfig -a.

config interface 'tunnel'
	option proto 'gretap'
	option peeraddr '10.11.12.1'
	option force_link '1'

It doesn't matter if I add the local address with ipaddr or not, or if force_link is present or not.

I've got three Archer C7 units, all show the same behavior. Two are on "official release" of 17.01.4 (with the replacement busybox) and one is running a local build from the 17.01 branch.

I'd like to be able to confirm that the tunnel is working properly before piling more onto it. If someone's got some suggestions as what I'm missing (or LEDE/OpenWRT might be missing), I'd definitely appreciate it!

root@coop:/etc# lsmod
ath                    17843  4 ath9k,ath9k_common,ath9k_hw,ath10k_core
ath10k_core           254734  1 ath10k_pci
ath10k_pci             30435  0 
ath9k                  93432  0 
ath9k_common           19534  1 ath9k
ath9k_hw              338444  2 ath9k,ath9k_common
cfg80211              234232  5 ath9k,ath9k_common,ath10k_core,ath,mac80211
compat                  9062  5 ath9k,ath9k_common,ath10k_pci,mac80211,cfg80211
crc_ccitt               1035  0 
ehci_hcd               32567  1 ehci_platform
ehci_platform           4272  0 
gpio_button_hotplug     6256  0 
gre                     1106  1 ip_gre
ip_gre                  9269  0 
ip_tables               9549  3 iptable_nat,iptable_mangle,iptable_filter
ip_tunnel              10902  1 ip_gre
ip6_tables              9377  2 ip6table_mangle,ip6table_filter
ip6t_REJECT              976  2 
ip6table_filter          656  1 
ip6table_mangle         1136  0 
ipt_MASQUERADE           688  0 
ipt_REJECT               944  2 
iptable_filter           720  1 
iptable_mangle           944  0 
iptable_nat              784  1 
ledtrig_usbport         2624  0 
mac80211              416898  2 ath9k,ath10k_core
nf_conntrack           47977  8 nf_nat_ipv4,nf_conntrack_ipv6,nf_conntrack_ipv4,xt_state,xt_conntrack,nf_nat_masquerade_ipv4,nf_nat,nf_conntrack_rtcache
nf_conntrack_ipv4       4784  9 
nf_conntrack_ipv6       5136  4 
nf_conntrack_rtcache    2480  0 
nf_defrag_ipv4           918  1 nf_conntrack_ipv4
nf_defrag_ipv6          9239  1 nf_conntrack_ipv6
nf_log_common           2351  2 nf_log_ipv4,nf_log_ipv6
nf_log_ipv4             3216  0 
nf_log_ipv6             3408  0 
nf_nat                  9083  4 nf_nat_ipv4,xt_nat,nf_nat_redirect,nf_nat_masquerade_ipv4
nf_nat_ipv4             3761  1 iptable_nat
nf_nat_masquerade_ipv4    1436  1 ipt_MASQUERADE
nf_nat_redirect          987  1 xt_REDIRECT
nf_reject_ipv4          2179  1 ipt_REJECT
nf_reject_ipv6          2344  1 ip6t_REJECT
nls_base                4992  1 usbcore
ohci_hcd               22207  1 ohci_platform
ohci_platform           3504  0 
usb_common              2221  1 usbcore
usbcore               122076  5 ledtrig_usbport,ohci_platform,ohci_hcd,ehci_platform,ehci_hcd
veth                    3088  0 
x_tables               11954 22 ipt_REJECT,ipt_MASQUERADE,xt_time,xt_tcpudp,xt_state,xt_nat,xt_multiport,xt_mark,xt_mac,xt_limit,xt_conntrack,xt_comment,xt_TCPMSS,xt_REDIRECT,xt_LOG,iptable_mangle,iptable_filter,ip_tables,ip6t_REJECT,ip6table_mangle,ip6table_filter,ip6_tables
xt_LOG                   784  0 
xt_REDIRECT              688  0 
xt_TCPMSS               2768  0 
xt_comment               528108 
xt_conntrack            2256 12 
xt_limit                1040 20 
xt_mac                   656  0 
xt_mark                  688  0 
xt_multiport            1232  0 
xt_nat                  1168  0 
xt_state                 720  0 
xt_tcpudp               1776  8 
xt_time                 1648  0 

OK -- fresh install on a TP-Link TP-WDR4300 v1.7 of LEDE-build 17.01.4

Since the kernel modules aren't in the standard distribution, that it fails prior to installing them is not surprising

root@LEDE:/etc/config# ip link add tunnel type gretap remote 192.168.1.66
ip: RTNETLINK answers: Not supported

However, after installing the required packages, this should have worked

root@LEDE:~# opkg install gre
Installing gre (1-7) to root...
Downloading http://downloads.lede-project.org/releases/17.01.4/packages/mips_24kc/base/gre_1-7_mips_24kc.ipk
Configuring gre.

root@LEDE:~# opkg install kmod-gre
Installing kmod-gre (4.4.92-1) to root...
Downloading http://downloads.lede-project.org/releases/17.01.4/targets/ar71xx/generic/packages/kmod-gre_4.4.92-1_mips_24kc.ipk
Installing kmod-iptunnel (4.4.92-1) to root...
Downloading http://downloads.lede-project.org/releases/17.01.4/targets/ar71xx/generic/packages/kmod-iptunnel_4.4.92-1_mips_24kc.ipk
Configuring kmod-iptunnel.
Configuring kmod-gre.
root@LEDE:~# ip link add tunnel type gretap remote 192.168.1.66
ip: RTNETLINK answers: File exists
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP qlen 1000
    link/ether c0:4a:00:9f:4b:5e brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether c0:4a:00:9f:4b:5f brd ff:ff:ff:ff:ff:ff
4: wlan1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether c0:4a:00:9f:4b:60 brd ff:ff:ff:ff:ff:ff
7: eth0.2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether c0:4a:00:9f:4b:5e brd ff:ff:ff:ff:ff:ff
8: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether c0:4a:00:9f:4b:5e brd ff:ff:ff:ff:ff:ff
9: eth0.1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether c0:4a:00:9f:4b:5e brd ff:ff:ff:ff:ff:ff
10: gre0@NONE: <NOARP> mtu 1476 qdisc noop state DOWN qlen 1
    link/gre 0.0.0.0 brd 0.0.0.0
11: gretap0@NONE: <BROADCAST,MULTICAST> mtu 1462 qdisc noop state DOWN qlen 1000
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

Before I file a bug, am I missing anything here?

ip link add tunnel type gretap remote 192.168.1.213 works for me with ip from ip-full.

2 Likes

Thanks!

Looks like that's going to to the trick

Hi Jeff,

did you get it working over uci? Will you link gets created now?

I can't even get it working with all the packages, including ip-full.

Best Regards

Yes, no challenges with getting gretap created, except for the little detail of name length:

gre4t-ABCD.1234

hits the 15-character limit, so you can't name longer than ABCD if you're going to associate it with VLANs.

config interface 'gt02'
        option proto 'gretap'
        option mtu 1558
        option ipaddr '172.16.0.1'
        option peeraddr '172.16.0.2'
        option delegate '0'

I'm not completely sure that 1558 is sufficient MTU, but I haven't hit any snags yet.

I do "hook" the start of the wireless (mesh) interface that the tunnels run over to set their MTU to 2304 with a quick-and-dirty script. There may be a way to do that in UCI as well, but since it's working, I haven't messed with it further.

I don't understand why my interface won't come up.
My config looks like this:

config interface 'gt'
option type 'gretap'
option ipaddr '192.168.255.253'
option peeraddr '192.168.255.254'
option delegate '0'

Like I've said in the other topic, I can't find a wrong configuration :frowning:

Let's keep this on Gretap interface not coming up so that there is only one thread on the specific issue.