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

I've added some tshark captures, though I don't think these show the same as you.

Sad thing is we're probably about 10 years to late for these forums to have enough traffic to help us 

Andy

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

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

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

"I can PING, but TCP connections hangs" sounds very much like the problem I describe in the "Tunnel Problems" thread in the "Questions & Answers" forum in the "Tunnelbroker.net Specific Topics" section. There is no solution there either, but it would be interesting to know if your diagnostics are comparable with my diagnostics

Andy

My wget looks the same as yours. If you run wireshark (or maybe tcpdump) it should be quite easy to see if it's the same problem.

We ran into this a few weeks ago as well, after having worked perfectly for a year or more.  Setup is unbound, as site resolver, forwarding netflix domain requests to a bind instance that strips AAAA responses.  After some digging with tcpdump, found, as did the original poster, that some of the netflix responses were now cnames to aws, and other, domains.  These are then resolved in the usual way and AAAA responses are returned breaking netflix.  We fixed it by getting unbound to forward the specific cname destinations to the bind stripping instance.  This has been working, for us, for a couple of weeks now.  We are located in Northern Britain and obviously the cnames returned will be region specific.  Just thought I'd list the domains/hosts we are forwarding for AAAA stripping in case this helps anyone else.
netflix.com.
netflix.net.
nflxext.com.
nflximg.net.
nflximg.com.
nflxvideo.net.
nflxso.net.
e13252.dscg.akamaiedge.net.
dualstack.ichnaea-vpc0-1803858966.eu-west-1.elb.amazonaws.com.
dualstack.beaconserver-ce-vpc0-1537565064.eu-west-1.elb.amazonaws.com.
dualstack.wwwservice2--frontend-san-vpc0-138074574.eu-west-1.elb.amazonaws.com.
dualstack.wwwservice--frontend-san-vpc0-445693027.eu-west-1.elb.amazonaws.com.
dualstack.ichnaea-web-323206729.eu-west-1.elb.amazonaws.com.

Really sucks that we have to jump through hoops like this to watch content we've paid for especially as netflix lists our /48 as being from the UK!!!!

"I can PING, but TCP connections hangs" sounds very much like the problem I describe in the "Tunnel Problems" thread in the "Questions & Answers" forum in the "Tunnelbroker.net Specific Topics" section. There is no solution there either, but it would be interesting to know if your diagnostics are comparable with my diagnostics

Andy

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

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