Update: I'm running
git bisect now, having found a "good" version.
I'm trying to figure out why a given configuration successfully creates an interface on
lede-17.01 but fails on
master. I've checked the change in
/lib/netifd/proto/gre.sh and that's not the issue. I've added
echo statements to
gre.sh and can see that the interface tries to come up and is immediately deleted in a different process.
What options do I have to trace/debug this further?
Tue Mar 20 09:34:20 2018 kern.info kernel: [ 12.032097] gre: GRE over IPv4 demultiplexor driver Tue Mar 20 09:34:20 2018 kern.info kernel: [ 12.038655] ip_gre: GRE over IPv4 tunneling driver Tue Mar 20 09:34:20 2018 kern.info kernel: [ 12.054413] ip6_gre: GRE over IPv6 tunneling driver [...] Tue Mar 20 09:34:28 2018 daemon.notice netifd: gt99 (1268): proto_gretap_setup() entry Tue Mar 20 09:34:28 2018 daemon.notice netifd: gt99 (1268): gre_setup() entry Tue Mar 20 09:34:29 2018 daemon.notice netifd: gt99 (1367): gretap_generic_teardown() entry
Edit: I can confirm that the kernel is capable of creating, connecting, and using a gretap tunnel through manual configuration using
Edit: Looking at the
ubus "setup" calls in
gre.sh as well as the end results. Looks like a clue is in there, as I wade through the
set -x output. https://openwrt.org/docs/techref/ubus