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 ip.
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