Skip to contentSkip to conversation

Why is gre0 auto-created, and can we fix it?

DISCUSSION Ben Greear 4 participants 11 messages Jan 3, 2012 – Jan 22, 2012

Subsystems (2)
lore
Share & tools
lore

Ben Greear

author
#0 lore raw

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
maintainer
#1 lore raw

From: 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}/

author
#2 lore raw
Quoted 8 lines · David Miller

From: 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}/

So, no changing the behaviour?

Thanks,
Ben

Signature · 2 lines
Ben Greear <[email protected]>
Candela Technologies Inc  http://www.candelatech.com
maintainer
#3 lore raw

From: 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 -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}/

So, no changing the behaviour?

Probably too risky. I think the exposure is on the order of ~16 years.

#4 lore raw
In reply to Ben Greear
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() under net/{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
author
#5 lore raw
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() under net/{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
maintainer
#6 lore raw

From: 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() under net/{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.

author
#7 lore raw
Quoted 18 lines · David Miller

From: 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() under net/{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
maintainer
#8 lore raw

From: 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.

#9 lore raw
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 -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.

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.

author
#10 lore raw
In reply to David Miller
Quoted 11 lines · David Miller

From: 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.

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