Why is gre0 auto-created, and can we fix it?
Subsystems (2)
While trying to figure out why 'gre0' doesn't go away properly in my application, I noticed that it is auto-created if you just run 'ifconfig gre0'. (Same thing happens if you use 'ip link show gre0')
As far as I can tell, no other interfaces are auto-created in this manner.
If I cook up a patch to 'fix' this, would it be acceptable, or are we stuck with the current behaviour for backwards-compat reasons?
[root@lec2010-ath9k-1 lanforge]# rmmod ip_gre [root@lec2010-ath9k-1 lanforge]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
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 pfifo_fast state UP qlen 1000
link/ether 00:90:0b:13:ed:ea brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:90:0b:13:ed:eb brd ff:ff:ff:ff:ff:ff
[root@lec2010-ath9k-1 lanforge]# ifconfig gre0
gre0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-01-00-00-00-00-00-00-00-00-00
NOARP MTU:1476 Metric:1[root@lec2010-ath9k-1 lanforge]# ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
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 pfifo_fast state UP qlen 1000
link/ether 00:90:0b:13:ed:ea brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
link/ether 00:90:0b:13:ed:eb brd ff:ff:ff:ff:ff:ff
76: gre0: <NOARP> mtu 1476 qdisc noop state DOWN
link/gre 0.0.0.0 brd 0.0.0.0[root@lec2010-ath9k-1 lanforge]# ifconfig tap0
tap0: error fetching interface information: Device not found
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
David Miller
maintainerFrom: Ben Greear <[email protected]>
Date: Tue, 03 Jan 2012 11:49:50 -0800
Quoted 2 lines
As far as I can tell, no other interfaces are auto-created in this manner.
ip6tnl0 and sit0 do it too, just grep for alloc_netdev() under net/{ipv4,ipv6}/
Quoted 8 lines · David Miller
From: Ben Greear<[email protected]>
Date: Tue, 03 Jan 2012 11:49:50 -0800Quoted 2 lines
As far as I can tell, no other interfaces are auto-created in this manner.
ip6tnl0 and sit0 do it too, just grep for
alloc_netdev()undernet/{ipv4,ipv6}/
So, no changing the behaviour?
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
David Miller
maintainerFrom: Ben Greear <[email protected]>
Date: Tue, 03 Jan 2012 12:03:56 -0800
Quoted 11 lines · David Miller
Quoted 8 lines
From: Ben Greear<[email protected]>
Date: Tue, 03 Jan 2012 11:49:50 -0800Quoted 2 lines
As far as I can tell, no other interfaces are auto-created in this manner.
ip6tnl0 and sit0 do it too, just grep for
alloc_netdev()undernet/{ipv4,ipv6}/So, no changing the behaviour?
Probably too risky. I think the exposure is on the order of ~16 years.
Quoted 7 lines · Ben Greear
Quoted 5 lines
Quoted 2 lines
As far as I can tell, no other interfaces are auto-created in this manner.
ip6tnl0 and sit0 do it too, just grep for
alloc_netdev()undernet/{ipv4,ipv6}/So, no changing the behaviour?
Perhaps making it CONFIGurable would be safe enough, not that I like CONFIG options for all tiny details (one may argue it's not a tiny detail).
Haven't looked at the actual code.
Signature · 1 line
Krzysztof Halasa
Quoted 8 lines · Krzysztof Halasa
Quoted 6 lines · Ben Greear
Quoted 5 lines
Quoted 2 lines
As far as I can tell, no other interfaces are auto-created in this manner.
ip6tnl0 and sit0 do it too, just grep for
alloc_netdev()undernet/{ipv4,ipv6}/
Quoted 7 lines
Quoted 1 line
So, no changing the behaviour?
Perhaps making it CONFIGurable would be safe enough, not that I like CONFIG options for all tiny details (one may argue it's not a tiny detail).
Haven't looked at the actual code.
Seems like it could be a run-time configurable, maybe module or boot option or sysctl or something.
I haven't looked any more at the code either...maybe next week (tm).
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
David Miller
maintainerFrom: Ben Greear <[email protected]>
Date: Sat, 21 Jan 2012 09:48:52 -0800
Quoted 15 lines · Krzysztof Halasa
Quoted 14 lines
Quoted 7 lines · Ben Greear
Quoted 5 lines
Quoted 2 lines
As far as I can tell, no other interfaces are auto-created in this manner.
ip6tnl0 and sit0 do it too, just grep for
alloc_netdev()undernet/{ipv4,ipv6}/So, no changing the behaviour?
Perhaps making it CONFIGurable would be safe enough, not that I like CONFIG options for all tiny details (one may argue it's not a tiny detail).
Quoted 5 lines
Quoted 1 line
Haven't looked at the actual code.
Seems like it could be a run-time configurable, maybe module or boot option
or sysctl or something.
I would seriously prefer that you not do this.
Quoted 18 lines · David Miller
From: Ben Greear<[email protected]>
Date: Sat, 21 Jan 2012 09:48:52 -0800Quoted 15 lines · Krzysztof Halasa
Quoted 14 lines
Quoted 7 lines · Ben Greear
Quoted 5 lines
Quoted 2 lines
As far as I can tell, no other interfaces are auto-created in this manner.
ip6tnl0 and sit0 do it too, just grep for
alloc_netdev()undernet/{ipv4,ipv6}/So, no changing the behaviour?
Perhaps making it CONFIGurable would be safe enough, not that I like CONFIG options for all tiny details (one may argue it's not a tiny detail).
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Haven't looked at the actual code.
Seems like it could be a run-time configurable, maybe module or boot option
or sysctl or something.I would seriously prefer that you not do this.
Just to make sure I understand you: You dislike any possible method of changing the behaviour, not just the ones I listed?
If I do post a patch, it will be just for comment should someone else want to carry the patch privately, and I'll just carry the patch in my tree.
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com
David Miller
maintainerFrom: Ben Greear <[email protected]>
Date: Sun, 22 Jan 2012 08:48:53 -0800
Quoted 2 lines
Just to make sure I understand you: You dislike any possible method of changing the behaviour, not just the ones I listed?
That's correct.
And please don't create dependencies on such a change in behavior in distributions, otherwise you obliterate the entire reason why I don't want the behavior changed.
There is no reason to change this, it's been like this for more than 10 years and no alien planet has exploded as a result even after all of this time.
Just leave it be, I beg you.
Quoted 12 lines · On Sun, 22 Jan 2012 14:14:47 -0500 (EST) David Miller <[email protected]>…
From: Ben Greear <[email protected]>
Date: Sun, 22 Jan 2012 08:48:53 -0800Quoted 2 lines
Just to make sure I understand you: You dislike any possible method of changing the behaviour, not just the ones I listed?
That's correct.
And please don't create dependencies on such a change in behavior in distributions, otherwise you obliterate the entire reason why I don't want the behavior changed.
Quoted 5 lines
There is no reason to change this, it's been like this for more than 10 years and no alien planet has exploded as a result even after all of this time.
Just leave it be, I beg you.
Also, the iproute tunnel tools rely on the module autoload of gre0.
Quoted 11 lines · David Miller
From: Ben Greear<[email protected]>
Date: Sun, 22 Jan 2012 08:48:53 -0800Quoted 2 lines
Just to make sure I understand you: You dislike any possible method of changing the behaviour, not just the ones I listed?
That's correct.
And please don't create dependencies on such a change in behavior in distributions, otherwise you obliterate the entire reason why I don't want the behavior changed.
No worries, I don't have a real distribution and I can't imagine any real distribution picking up my changes against your wishes. Just to be safe, I'll default any changes to the current behaviour.
Quoted 3 lines
There is no reason to change this, it's been like this for more than 10 years and no alien planet has exploded as a result even after all of this time.
Well, it breaks my (proprietary, and already optimized for my own kernel hacks) user-space program, and though I could add hacks to fix it eventually, I think it will be much easier to hack the kernel.
Quoted 1 line
Just leave it be, I beg you.
I think you may be over-estimating my influence :)
I have much more horrible patches I've been carrying for years and years and as you say, the alien planets are all doing ok.
Thanks,
Ben
Signature · 2 lines
Ben Greear <[email protected]> Candela Technologies Inc http://www.candelatech.com