Print

[ajyip6]

My tunnel does work... but not enough to actually be useful!

First problem: outgoing pings often don't work until I've had an incoming ping

I can ping other sites, but the ping doesn't work until I do an incoming ping. So

ajy@seth:~ $ ping6 ip6only.me
PING ip6only.me(2604:90:1:1::69 (2604:90:1:1::69)) 56 data bytes
Nothing happens, until a differennt OS goes to something like https://ip6now.com.au/pingme.pgp and does a ping6 to test6a.pcpki.com. Suddenly ICMPv6 responses received
64 bytes from 2604:90:1:1::69 (2604:90:1:1::69): icmp_seq=56 ttl=58 time=85.1 ms
64 bytes from 2604:90:1:1::69 (2604:90:1:1::69): icmp_seq=57 ttl=58 time=83.7 ms
64 bytes from 2604:90:1:1::69 (2604:90:1:1::69): icmp_seq=58 ttl=58 time=131 ms
64 bytes from 2604:90:1:1::69 (2604:90:1:1::69): icmp_seq=59 ttl=58 time=83.1 ms
64 bytes from 2604:90:1:1::69 (2604:90:1:1::69): icmp_seq=60 ttl=58 time=82.8 ms
^C
--- ip6only.me ping statistics ---
60 packets transmitted, 5 received, 91.6667% packet loss, time 260ms
rtt min/avg/max/mdev = 82.810/93.077/130.612/18.787 ms


Second problem: The TCP handshake works, but not subsequent packets

ajy@seth:~ $ wget -O - ip6only.me
--2020-10-04 22:59:34--  http://ip6only.me/
Resolving ip6only.me (ip6only.me)... 2604:90:1:1::69
Connecting to ip6only.me (ip6only.me)|2604:90:1:1::69|:80... connected.
HTTP request sent, awaiting response... ^C


ajy@seth:~ $ sudo grep "he-ipv6" /var/log/syslog | tail
Oct  4 22:59:34 seth kernel: [1125389.716751] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=80 TC=0 HOPLIMIT=64 FLOWLBL=481646 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821190 ACK=0 WINDOW=65320 RES=0x00 SYN URGP=0
Oct  4 22:59:34 seth kernel: [1125389.798757] 6X: IN=he-ipv6 OUT= TUNNEL=216.66.80.26->192.168.1.132 SRC=2604:0090:0001:0001:0000:0000:0000:0069 DST=2001:0470:1f08:0445:0000:0000:0000:0002 LEN=80 TC=6 HOPLIMIT=58 FLOWLBL=149549 PROTO=TCP SPT=80 DPT=36740 SEQ=3127003181 ACK=1827821191 WINDOW=65535 RES=0x00 ACK SYN URGP=0
Oct  4 22:59:34 seth kernel: [1125389.799060] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=72 TC=0 HOPLIMIT=64 FLOWLBL=481646 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK URGP=0
>>>>TCP handshake complete. The next line is the GET, which is sent four times (ip6tables at the server end of other servers show it is not arriving)
Oct  4 22:59:34 seth kernel: [1125389.805883] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=215 TC=0 HOPLIMIT=64 FLOWLBL=481646 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK PSH URGP=0
Oct  4 22:59:34 seth kernel: [1125390.101358] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=215 TC=0 HOPLIMIT=64 FLOWLBL=481646 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK PSH URGP=0
Oct  4 22:59:34 seth kernel: [1125390.401375] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=215 TC=0 HOPLIMIT=64 FLOWLBL=656684 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK PSH URGP=0
Oct  4 22:59:35 seth kernel: [1125390.991395] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=215 TC=0 HOPLIMIT=64 FLOWLBL=561891 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK PSH URGP=0
Now a FIN is sent - the sending seems to be timing out very aggressively
Oct  4 22:59:36 seth kernel: [1125391.903617] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=72 TC=0 HOPLIMIT=64 FLOWLBL=561891 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821334 ACK=3127003182 WINDOW=1021 RES=0x00 ACK FIN URGP=0
Now the server ACKs the third part of the TCP handshake
Oct  4 22:59:36 seth kernel: [1125391.986074] 6X: IN=he-ipv6 OUT= TUNNEL=216.66.80.26->192.168.1.132 SRC=2604:0090:0001:0001:0000:0000:0000:0069 DST=2001:0470:1f08:0445:0000:0000:0000:0002 LEN=72 TC=0 HOPLIMIT=58 FLOWLBL=149549 PROTO=TCP SPT=80 DPT=36740 SEQ=3127003182 ACK=1827821191 WINDOW=1036 RES=0x00 ACK URGP=0
LEN=215 implies this is the GET sent again, with a PSH
Oct  4 22:59:36 seth kernel: [1125392.181473] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002
DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=215 TC=0 HOPLIMIT=64 FLOWLBL=168171 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821191 ACK=3127003182 WINDOW=1021 RES=0x00 ACK PSH FIN URGP=0
ACK=1827821335 looks like the 215 bytes are being ACKed, so they have got through but we've already sent a FIN, and so the second part of the FIN is sent
Oct  4 22:59:36 seth kernel: [1125392.283874] 6X: IN=he-ipv6 OUT= TUNNEL=216.66.80.26->192.168.1.132 SRC=2604:0090:0001:0001:0000:0000:0000:0069 DST=2001:0470:1f08:0445:0000:0000:0000:0002 LEN=72 TC=0 HOPLIMIT=58 FLOWLBL=149549 PROTO=TCP SPT=80 DPT=36740 SEQ=3127005542 ACK=1827821335 WINDOW=1036 RES=0x00 ACK FIN URGP=0
RST sent...
Oct  4 22:59:36 seth kernel: [1125392.284224] 6Y: IN= OUT=he-ipv6 SRC=2001:0470:1f08:0445:0000:0000:0000:0002 DST=2604:0090:0001:0001:0000:0000:0000:0069 LEN=60 TC=0 HOPLIMIT=64 FLOWLBL=290854 PROTO=TCP SPT=36740 DPT=80 SEQ=1827821335 ACK=0 WINDOW=0 RES=0x00 RST URGP=0

/etc/network/interfaces.d/he-ipv6 is
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
        address 2001:470:1f08:445::2
        netmask 64
        mtu 1480
        endpoint 216.66.80.26
        local 192.168.1.132
        ttl 255
        gateway 2001:470:1f08:445::1
        dns-nameservers 2001:4860:4860::8888

This all worked OK when I was using a Slax (3.6.11 kernel) endpoint through a standard PlusNet DSL router. Currently I am using a Raspbian (Debian Buster) Paspberry Pi sitting in the DMZ of a BT Hub 6 (I am still with PlusNet, so don't have native IPv6)

It seems to me so close to be working - I have bidirectional traffic - but with some wierdness.

Any suggestions gratefully received.

Andy

[cholzhauer]

I have no specific suggestions for you, other than to ask if there's a firewall in play here? If so, could you turn off for testing and see what you get?

[ajyip6]

Good question. My local ip[6]tables log everything before they do their stuff, so I am confident it is not them.

The Smarthub security was set to "allow outgoing, block unsolicited incoming" with the endpoint in the DMZ where (I thought) everything else incoming was sent and I could filter it. I have changed it to "disabled", and the first problem above seems to have gone away. So this means that something that wasn't getting in to the DMZ with the first settings is getting through with the second. Not sure what. So as long as I pay extra attention to security of my endpoint then fingers crossed that is OK.

To eliminate variables, I went back to having a virtual Slax in the DMZ as the endpoint, and configured it exactly as before (I had screenshotted it) when it had worked. The second problem still exists - the TCP connection is made but nothing application layer can then be sent along it. The smarthub now appears to be the only difference.

My suspicion is that it is a timing issue rather than a routing issue, but I can't think how to diagnose it

Andy

[ajyip6]

An observation in the attached image (which HE won't let me attach, but I hope you get the drift)...

• I did nc -6lp 8989 on a server that is LAN-side of the endpoint
• I did wget http://test6a.pcpki.com:8989/test on a Vultr VM on the Internet
• The wget end outputed its normal audit trail until "HTTP request sent, awaiting response..."
• Nothing appeared on the screen of the nc end until I pressed control-C on the wget end. The http request appears on the nc's terminal as soon as the client wget terminates.
• If I do the same with IPv4, the http request appears immediately
• Similarly, normal nc-to-nc pipes work normally for IPv4 (output appears when I press return) but for IPv6 the output doesn't appear at the server end until the client terminates

So I do have two way traffic. But something is wrong and it is driving me potty. Does this observation mean anything to anyone?

Andy

[tomkep]

I'll just comment to one observation you made:

Second problem: The TCP handshake works, but not subsequent packets

The fact that you have "empty" tcp packets through and not seeing the ones carrying payload may indicate problems with either incorrect MTU setting somewhere in your setup or PATH MTU DISCOVERY along the way.

Please make sure MTU on your WAN interface is correct (for whatever media end encapsulation you use) and that the tunnel interface MTU is correctly calculated from the previous one (usually this means it should be 20 bytes smaller to account for encapsulating IPv4 header). Please also make sure that MTU setting on tunnel server (you have it in advanced settings) is matching or smaller than your MTU.

PATH MTU DISCOVERY problems usually indicate overzealous FW dropping ICMPv6 packet too big messages somewhere. This may be you - which you should be able to fix after inspecting FW rules, or someone else - then forcing PMTU to lower value (you may have to experiment) for specific network(s) in Linux MANGLE tables is probably the only cure you have at hand (short of complaining to relevant network administrator if you can identify the offending node).

Of course you can also try to lower MTU on your IPv6 interfaces to 1280 bytes (mandated by RFC) and this is the shortest path to solution for abovementioned issues - at some performance cost.

[ajyip6]

Thanks for your reply.

I've set the tunnel MTU to 1280 at both ends, but it has not made a difference.

One thing to notice (from the iptables log in the first post) is that the HTTP "GET" packet is getting through (as the ack is eventuallly being returned). But by the time the ack gets back, the sender has already resent the GET three times and sent a TCP FIN. This makes me think either that something somewhere is very slow, or that I am resendig and timing out too quickly. Can this be changed?

Ping indicates that the RTT to ip6only.me is fine (82ms) but the timing in the iptables log might be interesting.

Andy

[ajyip6]

Some more diagnostics (taken while wget ip6only.me is waiting)...

# ss -i | tail -2
tcp     ESTAB    0         143            [2001:470:1f08:445::2]:35302              [2604:90:1:1::69]:http
    cubic wscale:6,6 rto:1600 backoff:2 rtt:130.447/65.223 mss:1208 pmtu:1280 rcvmss:536 advmss:1208 cwnd:1 ssthresh:7 bytes_sent:572 bytes_retrans:429 bytes_acked:1 segs_out:6 segs_in:1 data_segs_out:4 send 74.1Kbps lastsnd:1470 lastrcv:3140 lastack:3140 pacing_rate 1.5Mbps delivered:1 busy:3140ms unacked:1 retrans:1/3 lost:1 rcv_space:12080 rcv_ssthresh:64328 minrtt:130.447

and a bit later

# ss -i | tail -1
    cubic wscale:6,6 rto:18560 backoff:6 rtt:82.045/41.022 mss:1208 pmtu:1280 rcvmss:536 advmss:1208 cwnd:1 ssthresh:7 bytes_sent:1144 bytes_retrans:1001 bytes_acked:1 bytes_received:1 segs_out:11 segs_in:3 data_segs_out:8 send 117.8Kbps lastsnd:1980 lastrcv:21100 lastack:930 pacing_rate 471.2Kbps delivered:1 busy:21100ms unacked:2 retrans:1/7 lost:1 rcv_space:12080 rcv_ssthresh:64328 minrtt:82.045

Andy

[ajyip6]

Possible solution to "First problem: outgoing pings often don't work until I've had an incoming ping"

On https://wiki.dd-wrt.com/wiki/index.php/IPv6 I found:

I occasionally have issues with the tunnel dying randomly. Pinging the router's IPv6 address fixes it for some reason, I have no idea why. -- update 2009.12.14 by calraith: Try adding metric 1 as an argument to the ip route add directives. ip route add ::/0 dev he-ipv6 metric 1

The metric was 1024 before I changed it. I've put the smarthub firewall back into "Default" mode (rather than the worrying "Disabled") and I'll keep it under observation to see if the first problem has gone away.

Andy

[ajyip6]

Everything I can see describes "connects but won't download" as a "classic MTU problem".

I've set every MTU on my system to 1280. Here are some diagnostics...

ajy@seth:~ $ sudo ping6 ipv6now.com.au -M do -c 1 -s 1232
PING ipv6now.com.au(2600:3c01::f03c:91ff:fe93:48f8 (2600:3c01::f03c:91ff:fe93:48f8)) 1232 data bytes
1240 bytes from 2600:3c01::f03c:91ff:fe93:48f8 (2600:3c01::f03c:91ff:fe93:48f8): icmp_seq=1 ttl=57 time=142 ms

--- ipv6now.com.au ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 142.110/142.110/142.110/0.000 ms

ajy@seth:~ $ sudo ping6 ipv6now.com.au -M do -c 1 -s 1233
PING ipv6now.com.au(2600:3c01::f03c:91ff:fe93:48f8 (2600:3c01::f03c:91ff:fe93:48f8)) 1233 data bytes
ping: sendmsg: Message too long

--- ipv6now.com.au ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

ajy@seth:~ $ sudo ping6 -c 200 -s 2000 -f ipv6now.com.au
PING ipv6now.com.au(2600:3c01::f03c:91ff:fe93:48f8) 2000 data bytes
         
--- ipv6now.com.au ping statistics ---
200 packets transmitted, 200 received, 0% packet loss, time 196ms
rtt min/avg/max/mdev = 143.026/143.847/151.284/1.251 ms, pipe 10, ipg/ewma 16.047/143.595 ms
ajy@seth:~ $

Do these imply anything? (other than, perhaps, that it is a TCP problem and not specifically an MTU problem)

Andy

[ajyip6]

Many sources have talked about my smarthub might be munging the MSS. So I've done the following

• I’ve set MTU at the WWW server end to 1280. I’ve used tshark to check that the MSS is set to 1220 in both directions. It is set as expected, but the wget still does not work
• I’ve manually set the MSS to 800 in both directions. The wget still does not work

So I can rule out this.

To have a comparison, here is a capture of a wget successfully downloading a very small file over IPv4
ajy@seth:~ $ wget http://95.179.131.95 -q -O -
Test

root@ajy5:~# tshark -i ens3  -f "port 80"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'ens3'
    1 0.000000000 195.166.158.247 → 95.179.131.95 TCP 74 58260 → 80 [SYN] Seq=0 Win=64480 Len=0 MSS=1240 SACK_PERM=1 TSval=441391413 TSecr=0 WS=64
    2 0.000039715 95.179.131.95 → 195.166.158.247 TCP 74 80 → 58260 [SYN, ACK] Seq=0 Ack=1 Win=65084 Len=0 MSS=1240 SACK_PERM=1 TSval=1515355615 TSecr=441391413 WS=128
    3 0.015644239 195.166.158.247 → 95.179.131.95 TCP 66 58260 → 80 [ACK] Seq=1 Ack=1 Win=64512 Len=0 TSval=441391428 TSecr=1515355615
    4 0.016300400 195.166.158.247 → 95.179.131.95 HTTP 212 GET / HTTP/1.1
    5 0.016337062 95.179.131.95 → 195.166.158.247 TCP 66 80 → 58260 [ACK] Seq=1 Ack=147 Win=65024 Len=0 TSval=1515355631 TSecr=441391429
    6 0.016676133 95.179.131.95 → 195.166.158.247 HTTP 352 HTTP/1.1 200 OK  (text/html)
    7 0.031139990 195.166.158.247 → 95.179.131.95 TCP 66 58260 → 80 [ACK] Seq=147 Ack=287 Win=64256 Len=0 TSval=441391445 TSecr=1515355631
    8 0.040098964 195.166.158.247 → 95.179.131.95 TCP 66 58260 → 80 [FIN, ACK] Seq=147 Ack=287 Win=64320 Len=0 TSval=441391453 TSecr=1515355631
    9 0.040180969 95.179.131.95 → 195.166.158.247 TCP 66 80 → 58260 [FIN, ACK] Seq=287 Ack=148 Win=65024 Len=0 TSval=1515355655 TSecr=441391453
   10 0.055394769 195.166.158.247 → 95.179.131.95 TCP 66 58260 → 80 [ACK] Seq=148 Ack=288 Win=64320 Len=0 TSval=441391469 TSecr=1515355655
The largest packet here is 352b, so MTU cannot be involved.

This is the same client and same server using IPv6 with MSS set to 800 with separate captures of outgoing-from-client and incoming-to-server
ajy@seth:~ $ wget http://[2001:19f0:5001:20a0:5400:3ff:fe02:1269] -q -O –

ajy@seth:~ $ tshark -i he-ipv6 -f "host 2001:19f0:5001:20a0:5400:3ff:fe02:1269"
Capturing on 'he-ipv6'
    1 0.000000000 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 80 38620 → 80 [SYN] Seq=0 Win=64660 Len=0 MSS=800 SACK_PERM=1 TSval=4287604351 TSecr=0 WS=64
    2 0.017533430 2001:19f0:5001:20a0:5400:3ff:fe02:1269 → 2001:470:1f1c:300::2 TCP 80 80 → 38620 [SYN, ACK] Seq=0 Ack=1 Win=65232 Len=0 MSS=800 SACK_PERM=1 TSval=2618195449 TSecr=4287604351 WS=128
    3 0.018031414 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 72 38620 → 80 [ACK] Seq=1 Ack=1 Win=64704 Len=0 TSval=4287604369 TSecr=2618195449
    4 0.019276374 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 HTTP 245 GET / HTTP/1.1
    5 0.241147166 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 245 [TCP Retransmission] 38620 → 80 [PSH, ACK] Seq=1 Ack=1 Win=64704 Len=173 TSval=4287604593 TSecr=2618195449
    6 0.471122695 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 245 [TCP Retransmission] 38620 → 80 [PSH, ACK] Seq=1 Ack=1 Win=64704 Len=173 TSval=4287604823 TSecr=2618195449
    7 0.921118076 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 245 [TCP Retransmission] 38620 → 80 [PSH, ACK] Seq=1 Ack=1 Win=64704 Len=173 TSval=4287605273 TSecr=2618195449
    8 1.831124522 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 245 [TCP Retransmission] 38620 → 80 [PSH, ACK] Seq=1 Ack=1 Win=64704 Len=173 TSval=4287606183 TSecr=2618195449
    9 3.671178790 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 245 [TCP Retransmission] 38620 → 80 [PSH, ACK] Seq=1 Ack=1 Win=64704 Len=173 TSval=4287608023 TSecr=2618195449
   10 7.271177027 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 245 [TCP Retransmission] 38620 → 80 [PSH, ACK] Seq=1 Ack=1 Win=64704 Len=173 TSval=4287611623 TSecr=2618195449
   11 14.791161561 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 245 [TCP Retransmission] 38620 → 80 [PSH, ACK] Seq=1 Ack=1 Win=64704 Len=173 TSval=4287619143 TSecr=2618195449
   12 29.511173669 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 245 [TCP Retransmission] 38620 → 80 [PSH, ACK] Seq=1 Ack=1 Win=64704 Len=173 TSval=4287633863 TSecr=2618195449
   13 31.448140342 2001:19f0:5001:20a0:5400:3ff:fe02:1269 → 2001:470:1f1c:300::2 TCP 80 [TCP Retransmission] 80 → 38620 [SYN, ACK] Seq=0 Ack=1 Win=65232 Len=0 MSS=800 SACK_PERM=1 TSval=2618226881 TSecr=4287604369 WS=128
   14 31.448566328 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 72 [TCP Dup ACK 3#1] 38620 → 80 [ACK] Seq=174 Ack=1 Win=64704 Len=0 TSval=4287635800 TSecr=2618195449
   15 58.311195757 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 245 [TCP Retransmission] 38620 → 80 [PSH, ACK] Seq=1 Ack=1 Win=64704 Len=173 TSval=4287662663 TSecr=2618195449
^C15 packets captured

root@ajy5:~# tshark -i ens3  -f "host 2001:470:1f1c:300::2"
Running as user "root" and group "root". This could be dangerous.
Capturing on 'ens3'
    1 0.000000000 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 94 38620 → 80 [SYN] Seq=0 Win=64660 Len=0 MSS=800 SACK_PERM=1 TSval=4287604351 TSecr=0 WS=64
    2 0.000204260 2001:19f0:5001:20a0:5400:3ff:fe02:1269 → 2001:470:1f1c:300::2 TCP 94 80 → 38620 [SYN, ACK] Seq=0 Ack=1 Win=65232 Len=0 MSS=800 SACK_PERM=1 TSval=2618195449 TSecr=4287604351 WS=128
    3 0.017729925 2001:470:1f1c:300::2 → 2001:19f0:5001:20a0:5400:3ff:fe02:1269 TCP 86 38620 → 80 [ACK] Seq=1 Ack=1 Win=64704 Len=0 TSval=4287604369 TSecr=2618195449
    4 31.431567966 2001:19f0:5001:20a0:5400:3ff:fe02:1269 → 2001:470:1f1c:300::2 TCP 94 [TCP Retransmission] 80 → 38620 [SYN, ACK] Seq=0 Ack=1 Win=65232 Len=0 MSS=800 SACK_PERM=1 TSval=2618226881 TSecr=4287604369 WS=128
^C4 packets captured

In this capture, the 245 byte "HTTP GET" (sent packet 4) is not getting through at all, although "ping6 -s 40000 -c 1" works

Ruling some things out!

Andy

[mclovin]

Can you redo the capture with a filter allowing the IPv4 address of the tunnel and all ICMP?

[ajyip6]

Nohing interesting. 5 mins of capture gave 375 ICMPv6 messages, all of which contained Solicitation or Advertisement or Listener.

[ajyip6]

Not a solution

Possible solution to "First problem: outgoing pings often don't work until I've had an incoming ping"

On https://wiki.dd-wrt.com/wiki/index.php/IPv6 I found:

I occasionally have issues with the tunnel dying randomly. Pinging the router's IPv6 address fixes it for some reason, I have no idea why. -- update 2009.12.14 by calraith: Try adding metric 1 as an argument to the ip route add directives. ip route add ::/0 dev he-ipv6 metric 1

The metric was 1024 before I changed it. I've put the smarthub firewall back into "Default" mode (rather than the worrying "Disabled") and I'll keep it under observation to see if the first problem has gone away.

Andy

[snarked]

Note:  Your router’s “block unsolicited” setting is probably blocking the tunnel server’s periodic ping (via IPv6) that it issues to make certain your endpoint is still alive.  Perhaps allowing these may fix your problem.