Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
openwrt-bot opened this issue Mar 11, 2020 · 3 comments
Labels

Comments

@openwrt-bot
Copy link

brianjmurrell:

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
@openwrt-bot
Copy link
Author

brianjmurrell:

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

@openwrt-bot
Copy link
Author

bjonglez:

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?

@openwrt-bot
Copy link
Author

brianjmurrell:

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. openwrt/packages#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]'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant