Bug 437410 - ip tunnel can't be bound to another device
Summary: ip tunnel can't be bound to another device
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.6
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: 4.8
Assignee: Michal Schmidt
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On: 419671
Blocks: 391511 447953 458123 461297 494835
TreeView+ depends on / blocked
 
Reported: 2008-03-13 21:48 UTC by Vince Worthington
Modified: 2018-10-20 00:23 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-05-18 19:21:40 UTC


Attachments (Terms of Use)
rebinding of IPIP, GRE, SIT tunnels (9.36 KB, patch)
2008-06-13 12:18 UTC, Michal Schmidt
no flags Details | Diff
testing script (525 bytes, application/x-shellscript)
2008-06-13 12:22 UTC, Michal Schmidt
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1024 normal SHIPPED_LIVE Important: Red Hat Enterprise Linux 4.8 kernel security and bug fix update 2009-05-18 14:57:26 UTC

Description Vince Worthington 2008-03-13 21:48:59 UTC
Cloning for RHEL4 since we have a customer looking for this solution.

+++ This bug was initially created as a clone of Bug #419671 +++

Description of problem:
ip tunnel can't be bound to another device

Version-Release number of selected component (if applicable):
kernel-2.6.23.8-63.fc8 with latest iproute-2.6.22

How reproducible:
always

Steps to Reproduce:
1. create tunnel
# ip tunnel add tunneltest0 mode ipip remote 10.0.0.1 dev eth0
2. try to change the bounding device from eth0 to eth1
# ip tunnel change tunneltest0 dev eth1
3. show the result
# ip tunnel show tunneltest0
# tunneltest0: ip/ip  remote 10.0.0.1  local any  dev eth0  ttl inherit

Actual results:
The tunnel bounding can't be change on the other device.

Expected results:
The tunnel bounding can be change on the other device.

-- Additional comment from tjanouse@redhat.com on 2007-12-11 08:05 EST --
Our short investigation showed that the SIOCCHGTUNNEL case in
net/ipv6/sit.c:ipip6_tunnel_ioctl does not care about the p->link at all. And
it's probably the same for ipip and gre.

-- Additional comment from mschmidt@redhat.com on 2007-12-12 09:44 EST --
I took a look at net/ipv4/ipip.c (this one is relevant for the provided
testcase). Tomas, you're right that the handler for SIOCCHGTUNNEL ioctl ignores
p.link completely.

I have a patch to allow re-binding the tunnel to another device. It also
recalculates the MTU of the tunnel from the known MTU of the newly bound device.
I believe it's the right thing to do in this case. I'll send the patch to netdev
and if it's accepted, I'll make similar changes to gre and sit.

(Assigning the bug to myself.)

-- Additional comment from mschmidt@redhat.com on 2007-12-12 09:45 EST --
Created an attachment (id=285761)
allow rebinding of ipip tunnels


-- Additional comment from mschmidt@redhat.com on 2007-12-14 07:18 EST --
The patch was sent to netdev (http://www.spinics.net/lists/netdev/msg49844.html). 
It was accepted with a small modification.

I submitted similar patches for GRE and SIT
(http://www.spinics.net/lists/netdev/msg49983.html).

Dave Miller applied all three patches to his git tree. They will be in Linux 2.6.25.


-- Additional comment from tjanouse@redhat.com on 2007-12-14 16:00 EST --
Thanks, Michal.
If I'm not mistaken, no further modification to iproute should be needed.

-- Additional comment from mschmidt@redhat.com on 2007-12-14 17:46 EST --
Tomas,
correct, no change is needed in iproute.

Comment 3 RHEL Product and Program Management 2008-05-14 13:25:30 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 4 Michal Schmidt 2008-06-13 12:18:48 UTC
Created attachment 309199 [details]
rebinding of IPIP, GRE, SIT tunnels

This is a backported patch for RHEL4. I'm testing it.

Comment 5 Michal Schmidt 2008-06-13 12:22:24 UTC
Created attachment 309200 [details]
testing script

A script to test rebinding of IPIP, GRE and SIT tunnels. "Before" and "After"
must differ for each type. "After" must show the new bound device and MTU.

Comment 6 Michal Schmidt 2008-06-16 14:42:49 UTC
I uploaded a test kernel with the patch applied to my personal Jabber disk:

http://disk.jabbim.cz/michich@jabber.cz/kernel-2.6.9-72.mschmidt1.EL.src.rpm
http://disk.jabbim.cz/michich@jabber.cz/kernel-2.6.9-72.mschmidt1.EL.i686.rpm
http://disk.jabbim.cz/michich@jabber.cz/kernel-2.6.9-72.mschmidt1.EL.x86_64.rpm
http://disk.jabbim.cz/michich@jabber.cz/kernel-smp-2.6.9-72.mschmidt1.EL.i686.rpm
http://disk.jabbim.cz/michich@jabber.cz/kernel-smp-2.6.9-72.mschmidt1.EL.x86_64.rpm

Changing the bound device should work with this kernel for IPIP, GRE and SIT
tunnels. Could you please test one of these kernels to verify the fix works as
you expect? You do not have to test all three types of tunnels, just the types
you use.

Note: This kernel build is for testing only and it did not go through proper QA.

Comment 7 Issue Tracker 2008-06-17 11:34:35 UTC
Sorr, Janne was not on notification list, fixed.

So onece again, Janne Karhunen to please test packages linked at
https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=139309&gid=836&view_type=lifoall#eid_2115835


This event sent from IssueTracker by pernzer 
 issue 139309

Comment 8 Issue Tracker 2008-06-19 08:36:20 UTC
Works as expected. Tested on i386. 

Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by sprabhu 
 issue 139309

Comment 10 RHEL Product and Program Management 2008-09-03 12:51:31 UTC
Updating PM score.

Comment 11 Vivek Goyal 2009-01-26 15:10:44 UTC
Committed in 80.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/

Comment 13 J.H.M. Dassen (Ray) 2009-02-16 13:55:01 UTC
Partner has confirmed that the tunnels can be bound to another device when running the test kernel supplied to them.

Comment 14 J.H.M. Dassen (Ray) 2009-02-16 14:59:59 UTC
For completeness, here's the partner's response:
Seems to work. Thank you.


[root@carpet ~]# uname -a
Linux carpet 2.6.9-80.ELsmp #1 SMP Fri Jan 23 16:30:12 EST 2009 i686 i686 i386 GNU/Linux

[root@carpet ~]# ip a
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:90:27:8e:09:52 brd ff:ff:ff:ff:ff:ff
   inet 10.144.71.126/22 brd 10.144.71.255 scope global eth0
   inet6 fe80::290:27ff:fe8e:952/64 scope link
      valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:06:29:89:6b:d5 brd ff:ff:ff:ff:ff:ff
   inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1
4: sit0: <NOARP> mtu 1480 qdisc noop
   link/sit 0.0.0.0 brd 0.0.0.0
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]# ip tunnel add tunneltest0 mode ipip remote 10.0.0.1 dev eth0
[root@carpet ~]#
[root@carpet ~]# ip a
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:90:27:8e:09:52 brd ff:ff:ff:ff:ff:ff
   inet 10.144.71.126/22 brd 10.144.71.255 scope global eth0
   inet6 fe80::290:27ff:fe8e:952/64 scope link
      valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
   link/ether 00:06:29:89:6b:d5 brd ff:ff:ff:ff:ff:ff
   inet 192.168.0.2/24 brd 192.168.0.255 scope global eth1
4: sit0: <NOARP> mtu 1480 qdisc noop
   link/sit 0.0.0.0 brd 0.0.0.0
5: tunl0: <NOARP> mtu 1480 qdisc noop
   link/ipip 0.0.0.0 brd 0.0.0.0
6: tunneltest0@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop
   link/ipip 0.0.0.0 peer 10.0.0.1
[root@carpet ~]#
[root@carpet ~]# ip tunnel show tunneltest0
tunneltest0: ip/ip  remote 10.0.0.1  local any  dev eth0  ttl inherit
[root@carpet ~]#  ip link show tunneltest0
6: tunneltest0@eth0: <POINTOPOINT,NOARP> mtu 1480 qdisc noop
   link/ipip 0.0.0.0 peer 10.0.0.1
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]# ip tunnel change tunneltest0 dev eth1
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]# ip tunnel show tunneltest0
tunneltest0: ip/ip  remote 10.0.0.1  local any  dev eth1  ttl inherit
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#
[root@carpet ~]#  ip link show tunneltest0
6: tunneltest0@eth1: <POINTOPOINT,NOARP> mtu 1480 qdisc noop
   link/ipip 0.0.0.0 peer 10.0.0.1

Comment 16 Chris Ward 2009-03-27 14:18:55 UTC
~~ Attention Partners! Snap 1 Released ~~
RHEL 4.8 Snapshot 1 has been released on partners.redhat.com. There should
be a fix present, which addresses this bug. NOTE: there is only a short time
left to test, please test and report back results on this bug
at your earliest convenience.

If you encounter any issues, please set the bug back to the ASSIGNED state and
describe the issues you encountered. If you have found a NEW bug, clone this
bug and describe the issues you encountered. Further questions can be
directed to your Red Hat Partner Manager.

If you have VERIFIED the bug fix. Please select your PartnerID from the
Verified field above. Please leave a comment with your test results details.
Include which arches tested, package version and any applicable logs.

 - Red Hat QE Partner Management

Comment 17 Chris Ward 2009-04-14 16:11:53 UTC
Verified that the patch is the same as tested in .80. See comment #14.

Comment 19 errata-xmlrpc 2009-05-18 19:21:40 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1024.html


Note You need to log in before you can comment on or make changes to this bug.