lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20140207172130.54cf1f7d@samsung-9> Date: Fri, 7 Feb 2014 17:21:30 -0700 From: Stephen Hemminger <stephen@...workplumber.org> To: netdev@...r.kernel.org Subject: Fw: [Bug 70151] New: redundant GRE tunnel on same interface not brought down when gre link is downed Begin forwarded message: Date: Thu, 6 Feb 2014 07:19:48 -0800 From: "bugzilla-daemon@...zilla.kernel.org" <bugzilla-daemon@...zilla.kernel.org> To: "stephen@...workplumber.org" <stephen@...workplumber.org> Subject: [Bug 70151] New: redundant GRE tunnel on same interface not brought down when gre link is downed https://bugzilla.kernel.org/show_bug.cgi?id=70151 Bug ID: 70151 Summary: redundant GRE tunnel on same interface not brought down when gre link is downed Product: Networking Version: 2.5 Kernel Version: 3.10.0+ Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Other Assignee: shemminger@...ux-foundation.org Reporter: tbeadle@...il.com Regression: No Say I have two IP's assigned to an interface (either a physical interface or an 802.1q sub-interface) and I create two gre interface, using each of the IP addresses assigned above as the local endpoint. I can send GRE keepalives to either gre interface and a response is received. Now if I bring one of the gre interfaces down and then send a keepalive to it, a response is still received. Not until I bring down the other interface also do I stop getting responses. Prior to the GRE/tunnel refactoring introduced in 3.10.0 (commit c5441932), the keepalives to the downed gre interface would not elicit a response. I have tested kernels from 3.10.0 up through 3.13.0. Steps to reproduce: - Assign 192.168.56.1/24 to eth0 on a machine to be used to send the keepalives (SENDER). - Assign 192.168.56.3/24 and 192.168.56.4/24 to eth0 on the device under test (DUT). ip addr add 192.168.56.3/24 dev eth0 ip addr add 192.168.56.4/24 dev eth0 - Bring up the 2 GRE interfaces on DUT. ip tunnel add gre1 mode gre remote 192.168.56.1 local 192.168.56.3 ttl 255 ip link set gre1 up sysctl -w net.ipv4.conf.gre1.accept_local=1 sysctl -w net.ipv4.conf.gre1.forwarding=1 sysctl -w net.ipv6.conf.gre1.forwarding=1 ip tunnel add gre2 mode gre remote 192.168.56.1 local 192.168.56.4 ttl 255 ip link set gre2 up sysctl -w net.ipv4.conf.gre2.accept_local=1 sysctl -w net.ipv4.conf.gre2.forwarding=1 sysctl -w net.ipv6.conf.gre2.forwarding=1 - I used scapy on SENDER to generate a GRE keepalive packet to 192.168.56.3 (08:00:27:53:aa:c1 is the MAC address of eth0 on DUT): >>> ip = IP(src='192.168.56.1', dst='192.168.56.3') >>> pkt = Ether(dst='08:00:27:53:aa:c1')/ip/GRE()/IP(src=ip.dst, dst=ip.src)/GRE() >>> sendp(pkt, iface='eth0') - When issuing the sendp command, run "tcpdump -nvi eth0 proto gre" on SENDER. You should see the following request and reply: 22:24:09.608401 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE (47), length 48) 192.168.56.1 > 192.168.56.3: GREv0, Flags [none], length 28 IP (tos 0x0, ttl 64, id 1, offset 0, flags [none], proto GRE (47), length 24) 192.168.56.3 > 192.168.56.1: GREv0, Flags [none], length 4 gre-proto-0x0 22:24:09.608879 IP (tos 0x0, ttl 63, id 1, offset 0, flags [none], proto GRE (47), length 24) 192.168.56.3 > 192.168.56.1: GREv0, Flags [none], length 4 gre-proto-0x0 - On DUT, run "ip link set gre1 down" and do the sendp command again from SENDER, watching the tcpdump output as well. With kernels 3.10.0+, you'll still see a response packet. With earlier kernels, no response is sent, which is the appropriate behavior. Note that, with 3.10.0+, if you now run "ip link set gre2 down" and do the sendp again, no response is sent. -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists