OpenWrt/LEDE Project

  • Status Unconfirmed
  • Percent Complete
    0%
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Trunk
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Brian J. Murrell - 11.03.2020
Last edited by Baptiste Jonglez - 13.03.2020

FS#2897 - 6in4: pinging with -I 6in4-foo results in extra encapsulation layer

Supply the following if possible:
- Device problem occurs on
WNDR4300
- Software versions of OpenWrt/LEDE release, packages, etc.
19.07.2
- Steps to reproduce
1. Create a 6in4 tunnel
2. ping -I 6in4-interface-name 2001:4860:4860::8844

Observe you get no responses. Analyse the packets being sent to the tunnel broker endpoint and notice that there is an extra layer of IPv4 enapsuation.

So rather than an IPv6 packet in an IPv4 packet you get an IPv6 packet in an IPv4 packet which itself is in an IPv4 packet. As such:

Frame 1088: 158 bytes on wire (1264 bits), 158 bytes captured (1264 bits)
Ethernet II, Src: Netgear_f5:1e:4b (6c:b0:ce:f5:1e:4b), Dst: Cisco_60:a4:19 (00:c1:b1:60:a4:19)
Internet Protocol Version 4, Src: my.internet.connection.example.com (7.3.7.1), Dst: tunnelbroker.net (22.3.43.21)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 144
    Identification: 0x2248 (8776)
    Flags: 0x4000, Don't fragment
    ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 64
    Protocol: IPIP (4)
    Header checksum: 0x5ed3 [correct]
    [Header checksum status: Good]
    [Calculated Checksum: 0x5ed3]
    Source: my.internet.connection.example.com (7.3.7.1)
    Destination: tunnelbroker.net (22.3.43.21)
Internet Protocol Version 4, Src: my.internet.connection.example.com (7.3.7.1), Dst: tunnelbroker.net (22.3.43.21)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 124
    Identification: 0x7185 (29061)
    Flags: 0x4000, Don't fragment
    ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 64
    Protocol: IPv6 (41)
    Header checksum: 0x0f85 [correct]
    [Header checksum status: Good]
    [Calculated Checksum: 0x0f85]
    Source: my.internet.connection.example.com (7.3.7.1)
    Destination: tunnelbroker.net (22.3.43.21)
Internet Protocol Version 6, Src: 2001:123:ab:123::1 (2001:123:ab:123::1), Dst: dns.google (2001:4860:4860::8844)
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
    .... .... .... 0010 1010 0100 1101 0111 = Flow Label: 0x2a4d7
    Payload Length: 64
    Next Header: ICMPv6 (58)
    Hop Limit: 64
    Source: 2001:123:ab:123::1 (2001:123:ab:123::1)
    Destination: dns.google (2001:4860:4860::8844)
    [Source GeoIP: Moscow, RU]
    [Destination GeoIP: US]
Internet Control Message Protocol v6
 
Brian J. Murrell commented on 11.03.2020 18:49

Oh. I should have code-blocked the packet decode...

Frame 1088: 158 bytes on wire (1264 bits), 158 bytes captured (1264 bits)
Ethernet II, Src: Netgear_f5:1e:4b (6c:b0:ce:f5:1e:4b), Dst: Cisco_60:a4:19 (00:c1:b1:60:a4:19)
Internet Protocol Version 4, Src: my.internet.connection.example.com (7.3.7.1), Dst: tunnelbroker.net (22.3.43.21)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 144
    Identification: 0x2248 (8776)
    Flags: 0x4000, Don't fragment
    ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 64
    Protocol: IPIP (4)
    Header checksum: 0x5ed3 [correct]
    [Header checksum status: Good]
    [Calculated Checksum: 0x5ed3]
    Source: my.internet.connection.example.com (7.3.7.1)
    Destination: tunnelbroker.net (22.3.43.21)
Internet Protocol Version 4, Src: my.internet.connection.example.com (7.3.7.1), Dst: tunnelbroker.net (22.3.43.21)
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 124
    Identification: 0x7185 (29061)
    Flags: 0x4000, Don't fragment
    ...0 0000 0000 0000 = Fragment offset: 0
    Time to live: 64
    Protocol: IPv6 (41)
    Header checksum: 0x0f85 [correct]
    [Header checksum status: Good]
    [Calculated Checksum: 0x0f85]
    Source: my.internet.connection.example.com (7.3.7.1)
    Destination: tunnelbroker.net (22.3.43.21)
Internet Protocol Version 6, Src: 2001:123:ab:123::1 (2001:123:ab:123::1), Dst: dns.google (2001:4860:4860::8844)
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
    .... .... .... 0010 1010 0100 1101 0111 = Flow Label: 0x2a4d7
    Payload Length: 64
    Next Header: ICMPv6 (58)
    Hop Limit: 64
    Source: 2001:123:ab:123::1 (2001:123:ab:123::1)
    Destination: dns.google (2001:4860:4860::8844)
    [Source GeoIP: Moscow, RU]
    [Destination GeoIP: US]
Internet Control Message Protocol v6

I can't seem to edit my first comment to clean it up. :-(

Project Manager
Baptiste Jonglez commented on 13.03.2020 10:04

Is it only an issue with ping, or are 6in4 tunnels broken like this for any kind of traffic?

Can you share relevant configuration from /etc/config/network?

Brian J. Murrell commented on 13.03.2020 10:19

It is only with ping and only if you use an interface name with -I. If you use an address of the interface instead it works.

I.e. https://github.com/openwrt/packages/pull/11560

config interface 'tunnel'
	option proto '6in4'
	option peeraddr '[redacted]'
	option ip6addr '[redacted]/64'
	option ip6prefix '[redacted]/64'
	option tunnelid '[redacted]'
	option username '[redacted]'
	option password '[redacted]'
	option updatekey '[redacted]'

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing