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 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 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 on 2007-12-12 09:45 EST -- Created an attachment (id=285761) allow rebinding of ipip tunnels -- Additional comment from mschmidt 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 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 on 2007-12-14 17:46 EST -- Tomas, correct, no change is needed in iproute.
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.
Created attachment 309199 [details] rebinding of IPIP, GRE, SIT tunnels This is a backported patch for RHEL4. I'm testing it.
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.
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.
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
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
Updating PM score.
Committed in 80.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/
Partner has confirmed that the tunnels can be bound to another device when running the test kernel supplied to them.
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
~~ 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
Verified that the patch is the same as tested in .80. See comment #14.
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