|
MTU-like problem, but it's not MTU
![[de]](/s/countries/de.gif) Shadow Hawkins on Saturday, 07 December 2013 19:32:15
Hey,
German provider M"net forced me to use a Fritzbox 7360 to replace my old 7570. As a consequence, I can no longer run `pppd` on a Linux machine and use the Fritzbox as a DSL modem, but I must let the Fritzbox handle the dialup connection and connect to it using IPv4.
So: "clegg" is my Linux router, "albatross" a machine on the network.
albatross --> clegg --> fritzbox --> Internet
This works for IPv4, and I found MTU to be 1492.
1: albatross.lehel 0.082ms pmtu 1500
1: clegg.lehel 0.583ms
1: clegg.lehel 0.546ms
2: fritzbox.lehel 0.954ms
3: ppp-93-104-113-11.dynamic.mnet-online.de 0.812ms pmtu 1492
3: ppp-default.m-online.net 15.046ms
[]
10: nlhaa01.sixxs.net 30.031ms reached
Resume: pmtu 1492 hops 10 back 53
Now, I have a heartbeat tunnel on "clegg", connecting to demuc02 (hosted at M"net itself).
Ping6 works fine. So does tracepath:
1?: [LOCALHOST] 0.009ms pmtu 1500
1: clegg.lehel 0.655ms
1: clegg.lehel 0.573ms
2: clegg.lehel 0.550ms pmtu 1472
2: gw-414.muc-02.de.sixxs.net 15.781ms
[]
12: tunnelserver.concepts-ict.net 35.237ms reached
Resume: pmtu 1472 hops 12 back 53
Normal connections, including SSH, however, just freeze, as if it were a MTU problem.
However, neither an MTU of 1472 on both sides (tunnel endpoint and sixxs.net webpage tunnel's settings) works, nor does a MTU of 1280 enable these connections.
I also tried clamping MSS to PMTU, but iptables only supports this for TCP, not proto-41.
Now I am at a loss.
What could the problem be?
MTU-like problem, but it's not MTU
This works for IPv4, and I found MTU to be 1492. ...
Ping6 works fine. So does tracepath:
While the routers might report 1492 with PTBs (which is what tracepath uses) it might not be true, just in case try pings with DF set (Don't Fragment) and see if packets really come trough or not.
You might want to check http://netalyzr.icsi.berkeley.edu/ too, just in case, as it might show something odd.
Normal connections, including SSH, however, just freeze, as if it were a MTU problem.
Which host is terminating the IPv6 tunnel, the Fritz!Box? Which tunnel ID does this concern?
Do you have a pcap that can be looked at?
I also tried clamping MSS to PMTU, but iptables only supports this for TCP, not proto-41.
As MSS is a TCP feature that makes sense. You could enforce this on the IPv6 tunnel interface.
Note that it would only 'fix' TCP, any other protocol (UDP, SCTP, IPSEC) would still have an MTU issues (if that really is the thing happening.
What could the problem be?
Variety of things, hard to say without data points. Might be an async path for instance too.
Also, check the logs on the hosts for any strange messages. PCAP is likely the best thing to look at, next to interface outputs etc,
MTU-like problem, but it's not MTU
Shadow Hawkins on Monday, 09 December 2013 11:52:16
Jeroen Massar wrote:
While the routers might report 1492 with PTBs (which is what tracepath uses) it might not be true, just in case try pings with DF set (Don't Fragment) and see if packets really come trough or not.
Good idea, here we go:
% i=1360; while ping -s $i -M do -nc1 82.135.16.28 >/dev/null; do i=$((i+1)); done; echo $((i-1+8))
1472
So the largest ping (IPv4) to cross the Fritzbox and the PPP link is 1472 bytes in size (incl. the 8 bytes of ICMP header). I get that value for a dozen different IPs, including the PoP endpoint 62.245.150.2.
A proto-41 packet adds 40 bytes of header data, leading me to believe that the largest packet that can be sent across the proto-41 tunnel is 1432 bytes, which is identical to the MTU settings I have on all the other proto-41 tunnels that go via M"net PPP. Let's run the same test to the host one hop beyond the PoP tunnel
% i=1360; while ping6 -s $i -M do -nc1 2001:a60:0:30::1:1 >/dev/null; do i=$((i+1)); done; echo $((i-1+8))
1392
This is strange, and I cannot really explain what is going on. If I lower the MTU on the tunnel from 1432 to 1392, then the largest ping that gets through will have to be another 40 bytes smaller, i.e. 1352.
What are those additional 40 bytes?
The ICSI Netalyzr reports "all green", with the exception of the NetBIOS ports blocked outgoing. That is configurable on the Fritzbox and useful to have.
Here's something else curious. If I send a large ping without the DF bit, I get a port-unreachable back!
% ping6 -s 1385 -nc1 -M dont 2001:a60:f000:19d::1
PING 2001:a60:f000:19d::1(2001:a60:f000:19d::1) 1385 data bytes
From 2001:a60:f000:19d::1 icmp_seq=1 Destination unreachable: Port unreachable
Time for some serious debugging
Which host is terminating the IPv6 tunnel, the Fritz!Box? Which tunnel ID does this concern?
The host terminating the IPv6 tunnel is "clegg", so it sits between the LAN and the Fritzbox. The two are connected v4-only on the network 10.178.17.0/30, the Fritzbox is .1 and the tunnel endpoing ("clegg") is .2.
Do you have a pcap that can be looked at?
How about this for a start:
Here's what's happening on the tunnel endpoint when I create a SSH session:
0.000000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 80 54201 > 22 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=1787402 TSecr=0 WS=128
0.032003 2001:1620:2018:2::4d6d:8b5c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 80 22 > 54201 [SYN, ACK] Seq=0 Ack=1 Win=14280 Len=0 MSS=1440 SACK_PERM=1 TSval=1215122613 TSecr=1787402 WS=16
0.032003 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 72 54201 > 22 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=1787410 TSecr=1215122613
0.032003 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c SSH 104 Client Protocol: SSH-2.0-OpenSSH_6.4p1 Debian-1\r
0.072006 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 72 [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=33 Ack=33 Win=28800 Len=0 TSval=1787420 TSecr=1215122623
0.284024 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c SSHv2 952 [TCP ACKed unseen segment] Client: Key Exchange Init
0.300026 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 84 [TCP Dup ACK 6#1] [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=913 Ack=33 Win=28800 Len=0 TSval=1787477 TSecr=1215122681 SLE=1 SRE=33
0.408035 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c SSHv2 952 [TCP ACKed unseen segment] [TCP Retransmission] Client: Key Exchange Init
0.664057 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 984 [TCP ACKed unseen segment] [TCP Retransmission] [TCP segment of a reassembled PDU]
0.764066 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 84 [TCP Dup ACK 9#1] [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=913 Ack=33 Win=28800 Len=0 TSval=1787593 TSecr=1215122797 SLE=1 SRE=33
1.176101 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 984 [TCP ACKed unseen segment] [TCP Retransmission] 54201 > 22 [PSH, ACK] Seq=1 Ack=33 Win=28800 Len=912 TSval=1787697 TSecr=1215122797
1.692146 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 84 [TCP Dup ACK 11#1] [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=913 Ack=33 Win=28800 Len=0 TSval=1787825 TSecr=1215123029 SLE=1 SRE=33
2.204190 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 984 [TCP ACKed unseen segment] [TCP Retransmission] 54201 > 22 [PSH, ACK] Seq=1 Ack=33 Win=28800 Len=912 TSval=1787954 TSecr=1215123029
3.552307 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 84 [TCP Dup ACK 13#1] [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=913 Ack=33 Win=28800 Len=0 TSval=1788290 TSecr=1215123494 SLE=1 SRE=33
4.260368 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 984 [TCP ACKed unseen segment] [TCP Retransmission] 54201 > 22 [PSH, ACK] Seq=1 Ack=33 Win=28800 Len=912 TSval=1788468 TSecr=1215123494
7.272628 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 84 [TCP Dup ACK 15#1] [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=913 Ack=33 Win=28800 Len=0 TSval=1789220 TSecr=1215124424 SLE=1 SRE=33
8.372723 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 984 [TCP ACKed unseen segment] [TCP Retransmission] 54201 > 22 [PSH, ACK] Seq=1 Ack=33 Win=28800 Len=912 TSval=1789496 TSecr=1215124424
At the same time, this is what I see on the remote hose:
0.000000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 94 54201 > 22 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=1787402 TSecr=0 WS=128
0.000124 2001:1620:2018:2::4d6d:8b5c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 94 22 > 54201 [SYN, ACK] Seq=0 Ack=1 Win=14280 Len=0 MSS=1440 SACK_PERM=1 TSval=1215122613 TSecr=1787402 WS=16
0.031813 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 86 54201 > 22 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=1787410 TSecr=1215122613
0.041835 2001:1620:2018:2::4d6d:8b5c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 SSH 118 Server Protocol: SSH-2.0-OpenSSH_6.0p1 Debian-4\r
0.270657 2001:1620:2018:2::4d6d:8b5c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 SSH 118 [TCP Retransmission] Encrypted response packet len=32
0.734635 2001:1620:2018:2::4d6d:8b5c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 SSH 118 [TCP Retransmission] Encrypted response packet len=32
1.662617 2001:1620:2018:2::4d6d:8b5c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 SSH 118 [TCP Retransmission] Encrypted response packet len=32
3.522379 2001:1620:2018:2::4d6d:8b5c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 SSH 118 [TCP Retransmission] Encrypted response packet len=32
7.242650 2001:1620:2018:2::4d6d:8b5c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 SSH 118 [TCP Retransmission] Encrypted response packet len=32
And this is the pcap on the tunnel interface, i.e. capturing all traffic to the IPv4 address of the PoP and relying on wireshark to look into the packets and display the actual IPv6 contents:
0.084353 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 114 54201 > 22 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=1787402 TSecr=0 WS=128
0.116356 2001:1620:2018:2::4d6d:8b5c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 114 22 > 54201 [SYN, ACK] Seq=0 Ack=1 Win=14280 Len=0 MSS=1440 SACK_PERM=1 TSval=1215122613 TSecr=1787402 WS=16
0.116356 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 106 54201 > 22 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=1787410 TSecr=1215122613
0.116356 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c SSH 138 Client Protocol: SSH-2.0-OpenSSH_6.4p1 Debian-1\r
0.156359 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 106 [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=33 Ack=33 Win=28800 Len=0 TSval=1787420 TSecr=1215122623
0.368377 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c SSHv2 986 [TCP ACKed unseen segment] Client: Key Exchange Init
0.384379 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 118 [TCP Dup ACK 7#1] [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=913 Ack=33 Win=28800 Len=0 TSval=1787477 TSecr=1215122681 SLE=1 SRE=33
0.492388 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c SSHv2 986 [TCP ACKed unseen segment] [TCP Retransmission] Client: Key Exchange Init
0.748410 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 1018 [TCP ACKed unseen segment] [TCP Retransmission] [TCP segment of a reassembled PDU]
0.848419 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 118 [TCP Dup ACK 10#1] [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=913 Ack=33 Win=28800 Len=0 TSval=1787593 TSecr=1215122797 SLE=1 SRE=33
1.260454 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 1018 [TCP ACKed unseen segment] [TCP Retransmission] 54201 > 22 [PSH, ACK] Seq=1 Ack=33 Win=28800 Len=912 TSval=1787697 TSecr=1215122797
1.776499 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 118 [TCP Dup ACK 12#1] [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=913 Ack=33 Win=28800 Len=0 TSval=1787825 TSecr=1215123029 SLE=1 SRE=33
2.288543 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 1018 [TCP ACKed unseen segment] [TCP Retransmission] 54201 > 22 [PSH, ACK] Seq=1 Ack=33 Win=28800 Len=912 TSval=1787954 TSecr=1215123029
3.636660 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 118 [TCP Dup ACK 14#1] [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=913 Ack=33 Win=28800 Len=0 TSval=1788290 TSecr=1215123494 SLE=1 SRE=33
4.344721 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 1018 [TCP ACKed unseen segment] [TCP Retransmission] 54201 > 22 [PSH, ACK] Seq=1 Ack=33 Win=28800 Len=912 TSval=1788468 TSecr=1215123494
7.356981 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 118 [TCP Dup ACK 16#1] [TCP ACKed unseen segment] 54201 > 22 [ACK] Seq=913 Ack=33 Win=28800 Len=0 TSval=1789220 TSecr=1215124424 SLE=1 SRE=33
8.457076 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:1620:2018:2::4d6d:8b5c TCP 1018 [TCP ACKed unseen segment] [TCP Retransmission] 54201 > 22 [PSH, ACK] Seq=1 Ack=33 Win=28800 Len=912 TSval=1789496 TSecr=1215124424
All this suggests to me that the traffic does not come back through the tunnel.
The behaviour is similar when trying to connect with SSH to the local host, so if you want to debug this from remote, try SSH'ing to 2001:a60:f10a::22cf:30ff:fe2a:7c07 and see where the packets get stopped.
MTU-like problem, but it's not MTU
(multiple responses, to tackle the sub-issues separately)
Here's something else curious. If I send a large ping without the DF bit, I get a port-unreachable back!
sixxsd does not support/handle fragments, thus as it is something unknown for it, it just replies with a "port unreachable", which is the default for something it does not know (next header == IPv6 fragment).
If you pcap then you'll actually see that you are sending out two IPv4 packets, one big one with a IPv6 fragment header, and one smaller one with the a fragment header and the remaining data.
If sixxsd was a full IPv6 implementation it might have merge those fragments, but alas it is not and thus just rejects it. Fragments should never reach any of the endpoints that is sixxsd anyway.
(Actually IMHO fragments should never exist on a network....)
Nevertheless one can ignore this part. It gets the correct response IMHO. Though, maybe I could mod it to return "Packet Too Big" instead when a fragment is sent to sixxsd.
Note that one can send fragments fine through sixxsd, as that is just forwarding the packets, sixxsd does not do anything but decreasing the hop count and forwarding it.
MTU-like problem, but it's not MTU
Hmm, what I could do to handle this is to just have a global ~128 packet 'fragment' buffer and then just look up in that range if there was a matching packet and/or that the packet is full.
And of course then have an expiry when the other fragments never arrive...
I don't see much advantage in supporting fragments though as well, they should never arrive at sixxsd in the first place. I'll put it on the wish-list of features though.
MTU-like problem, but it's not MTU
A proto-41 packet adds 40 bytes of header data, leading me to believe that the largest packet that can be sent across the proto-41 tunnel is 1432 bytes,
No, a IPv4 header is only 20 bytes. (see MTU FAQ)
which is identical to the MTU settings I have on all the other proto-41 tunnels that go via M"net PPP.
Can you show the ifconfig or 'ip link show' of that interface?
What are those additional 40 bytes?
Maybe M-net is doing internal tunneling and/or shoving some headers in between?
> Which host is terminating the IPv6 tunnel, the Fritz!Box? Which tunnel ID does this concern?
The host terminating the IPv6 tunnel is "clegg", so it sits between the LAN and the Fritzbox. The two are connected v4-only on the network 10.178.17.0/30, the Fritzbox is .1 and the tunnel endpoing ("clegg") is .2.
And thus the Fritz!Box is performing NAT (otherwise the RFC1918 would not work).
Maybe the Fritz!Box is stealing some of your IPv4 packets?
What is the (IPv4) MTU of the PPP interface on the Fritz!Box?
Here's what's happening on the tunnel endpoint when I create a SSH session:
You have to look at the IPv4 level. MTU issues are likely there, not on IPv6.
Also, on the IPv4 level there will be ICMP(v4)s that might indicate issues on that level.
You might want to check the Fritz!Box's pcap facility for this. (though it used to be there as /capture.html, I don't seem to have it on my current Fritz!Box)....)
MTU-like problem, but it's not MTU
Shadow Hawkins on Monday, 09 December 2013 13:20:11
Jeroen Massar wrote:
> A proto-41 packet adds 40 bytes of header data, leading me to believe that the largest packet that can be sent across the proto-41 tunnel is 1432 bytes, which is identical to the MTU settings I have on all the other proto-41 tunnels that go via M"net PPP.
Can you show the ifconfig or 'ip link show' of that interface?
5: fritzbox: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
link/ether 00:00:24:ce:6e:f3 brd ff:ff:ff:ff:ff:ff
21: sixxs: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1432 qdisc noqueue state UNKNOWN mode DEFAULT
link/sit 10.178.17.2 peer 62.245.150.2
Sorry, I forgot: this is tunnel ID T102914
And thus the Fritz!Box is performing NAT (otherwise the RFC1918 would not work).
Yes, it's doing NAT, though I don't exactly. The router is a so-called
"exposed-host", so the Fritzbox forwards all incoming packets to the router.
Theoretically, this means that it does not have to full NAT (port-based NAT),
just rewrite the IP address.
Maybe the Fritz!Box is stealing some of your IPv4 packets?
Likely. I have to see if I can get pcaps on the Fritzbox
What is the (IPv4) MTU of the PPP interface on the Fritz!Box?
116: dsl: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP200> mtu 1500 qdisc pfifo_fast qlen 100
link/ppp
MTU-like problem, but it's not MTU
Martin F. Krafft wrote:
5: fritzbox: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
While that interface is 1500, what is the MTU that the Fritz!Box itself has? (thus the PPP interface)
And does that match up with the MTU in tracepath?
> And thus the Fritz!Box is performing NAT (otherwise the RFC1918 would not work).
Yes, it's doing NAT, though I don't exactly. The router is a so-called "exposed-host", so the Fritzbox forwards all incoming packets to the router. Theoretically, this means that it does not have to full NAT (port-based NAT), just rewrite the IP address.
aka "DMZ-mode". Thus if a packet matches a NAT-rule it goes to the NAT rule, if it does not, it goes to another host. And that might complicate debugging, if you used another internal host to talk to a destination it might go to the wrong host... might want to do a tcpdump on/behind the Fritz!Box.
You should be 'safe' if you NAT on clegg as then all packets outbound are handled by clegg according to the Fritz!Box.
DMZ mode is a scary thing though.
Btw, why not terminate the tunnel on the Fritz!Box btw, it should be able to do that (SixXS settings are integrated, just username,pass, tunnel-id, click and presto), and then have the Fritz!Box forward the whole /48 to clegg which then really handles it.
Maybe the Fritz!Box is stealing some of your IPv4 packets?
Likely. I have to see if I can get pcaps on the Fritzbox
What is the (IPv4) MTU of the PPP interface on the Fritz!Box?
> 116: dsl: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP200> mtu 1500 qdisc pfifo_fast qlen > 100 link/ppp
MTU-like problem, but it's not MTU
Shadow Hawkins on Monday, 09 December 2013 14:55:24> 5: fritzbox: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT qlen 1000
While that interface is 1500, what is the MTU that the Fritz!Box itself has? (thus the PPP interface) And does that match up with the MTU in tracepath?
See below, the PPP interface ("dsl") has a MTU of 1500, which is odd, as you noted.
> 116: dsl: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP200> mtu 1500 qdisc pfifo_fast qlen > 100 > link/ppp
Is that from inside the Fritz!Box CLI? Can you check what the GUI states?
Yes, that was Fritzbox CLI. I don't see anything related to MTU in the GUI.
if you used another internal host to talk to a destination it might go to the wrong host... might want to do a tcpdump on/behind the Fritz!Box. You should be 'safe' if you NAT on clegg as then all packets outbound are handled by clegg according to the Fritz!Box.
"clegg" is the only host talking to the Fritzbox, and yes, it does PNAT of all the internal hosts connected to it. Yes, packets are being NATted twice. Yes, this sucks.
Btw, why not terminate the tunnel on the Fritz!Box btw, it should be able to do that (SixXS settings are integrated, just username,pass, tunnel-id, click and presto), and then have the Fritz!Box forward the whole /48 to clegg which then really handles it.
Because while the Fritzbox itself then has the /48, it automatically creates these routes, and I found no way to change them:
2001:a60:f10a::/64 dev lan metric 128
2001:a60:f10a::/64 dev lan metric 256
2001:a60:f10a:1::/64 dev guest metric 128
2001:a60:f10a:1::/64 dev guest metric 256
unreachable 2001:a60:f10a::/48 dev lo metric 256 error -128
I.e. there is no way to forward the /48 to "clegg", and I cannot even figure out how to forward a /56 network. This makes me want to terminate the tunnel on "clegg", where I have things under control with vim!
MTU-like problem, but it's not MTU
Because while the Fritzbox itself then has the /48, it automatically creates these routes, and I found no way to change them:
Well that /48 is just a null route, and IMHO a good thing that they install it that way.
Can't you route separate /64's to clegg, that would partially solve your routing issue (except if you have a 1000 of them ;). And that your WLAN won't be protected by clegg of course... unless you have a different box handling that.
I do have a Fritz!Box 7270 here, but it is only used for POTS termination (call blocking) and wifi, which it is doing by acting as a client to the LAN it is connected to. It does not do any RA/DHCP stuff, that is handled by a Linux gw box. I fortunately got a Thomson DOCSIS-3 modem here, which is in bridge mode onto a VLAN which then goes into that Linux box. Not everybody has the option to do that though.
But can't you not just get a cheapish VDSL2 modem somewhere that can be put into bridge mode and bypass the Fritz!Box or is it required by the ISP to use that (bit silly, but a known thing to happen)?
MTU-like problem, but it's not MTU
Shadow Hawkins on Monday, 09 December 2013 18:59:26Well that /48 is just a null route, and IMHO a good thing that they install it that way.
Agreed.
Can't you route separate /64's to clegg, that would partially solve your routing issue (except if you have a 1000 of them ;). And that your WLAN won't be protected by clegg of course... unless you have a different box handling that.
WIFI is on the internal side of clegg, so no worries. There is nothing in the GUI to add a static IPv6 route, and I'd rather not rely on having to figure out Fritz!OS first to know where one would add one persistently.
But can't you not just get a cheapish VDSL2 modem somewhere that can be put into bridge mode and bypass the Fritz!Box or is it required by the ISP to use that (bit silly, but a known thing to happen)?
No, M"net is forcing us to use their hardware. Sucks a lot.
MTU-like problem, but it's not MTU
The behaviour is similar when trying to connect with SSH to the local host, so if you want to debug this from remote, try SSH'ing to 2001:a60:f10a::22cf:30ff:fe2a:7c07 and see where the packets get stopped.
$ tracepath6 2001:a60:f10a::22cf:30ff:fe2a:7c07
1?: [LOCALHOST] 0.033ms pmtu 1500
1: ge-1-3-0.breda.ipv6.concepts-ict.net 0.797ms
1: ge-1-3-0.breda.ipv6.concepts-ict.net 0.692ms
2: 2001:838:5:11::2 0.886ms asymm 1
3: gi2-11.nikhef.ipv6.concepts-ict.net 2.305ms asymm 2
4: amsix-v6.irt1.ams01.nl.as13237.net 5.605ms
5: ae1.irt1.dus03.de.v6.as13237.net 5.618ms
6: ae3.irt1.fra44.de.v6.as13237.net 11.188ms
7: ae2.irt2.nue22.de.v6.as13237.net 12.165ms
8: M-net-NUE.v6.lambdanet.net 12.565ms
9: 2001:a60:0:30::1 19.311ms asymm 11
10: 2001:a60:0:30::1:1 16.451ms asymm 9
11: gw-414.muc-02.de.sixxs.net 16.874ms pmtu 1432
11: gw-414.muc-02.de.sixxs.net 16.670ms asymm 10
12: albatross.lehel.madduck.net 37.258ms reached
Resume: pmtu 1432 hops 12 back 53
$ ssh -v6 2001:a60:f10a::22cf:30ff:fe2a:7c07
OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
...
debug1: Connecting to 2001:a60:f10a::22cf:30ff:fe2a:7c07 [2001:a60:f10a:0:22cf:30ff:fe2a:7c07] port 22.
debug1: Connection established.
...
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.4p1 Debian-1
debug1: match: OpenSSH_6.4p1 Debian-1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-4
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 21:2b:0d:26:64:ce:77:42:33:9f:2d:97:bc:1e:2c:ba
The authenticity of host '2001:a60:f10a::22cf:30ff:fe2a:7c07 (2001:a60:f10a:0:22cf:30ff:fe2a:7c07)' can't be established.
RSA key fingerprint is 21:2b:0d:26:64:ce:77:42:33:9f:2d:97:bc:1e:2c:ba.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '2001:a60:f10a::22cf:30ff:fe2a:7c07,2001:a60:f10a:0:22cf:30ff:fe2a:7c07' (RSA) to the list of known hosts.
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
...
debug1: Next authentication method: password
jeroen@2001:a60:f10a::22cf:30ff:fe2a:7c07's password:
^C
There was only 1 large packet (the one with all the ciphers). It seems your host is sending a packet sized 20 (IPv4) + 40 (IPv6) + 1360 (TCP) = 1420 big.
Thus if your MTU is 1432 that would have fit.
Wireshark does highlight some of these packets as TCP retransmissions.
More traffic is needed to determine what goes wrong here.
MTU-like problem, but it's not MTU
Shadow Hawkins on Monday, 09 December 2013 13:43:46
Indeed, occasionally, the connection can be established! But then it randomly hangs. And pcap has a lot of retransmissions.
I figured out how to do packet capturing on the box. What sort of traffic would be useful to you?
MTU-like problem, but it's not MTU
Martin F. Krafft wrote:
Indeed, occasionally, the connection can be established! But then it randomly hangs. And pcap has a lot of retransmissions.
I saw those retransmissions too in the pcap when trying the SSH and a bit later HTTP query (though there is an Apache there is nothing at / when going by the IP, could be useful to throw a picture/html there >1500 bytes). More reliable and easier testing than SSH, especially as there are less round trips.
I figured out how to do packet capturing on the box.
What is the trick? Does it require shell-access?
What sort of traffic would be useful to you?
I typically look at "icmp or host <pop>". That way you catch all ICMP errors that might be related and get all traffic, but not catch your own traffic.
Run that in parallel with a tcpdump on clegg and if you want to, on the remote host. That way you should see the same packets everywhere, and if not you know at least partially where packets go missing.
Two other ideas to test:
a) tunnel to a different PoP
b) AYIYA tunnel
This to:
a) exclude that the PoP or the path to the PoP is a problem
b) that proto-41 packets specifically get corrupted somewhere
MTU-like problem, but it's not MTU
Shadow Hawkins on Monday, 09 December 2013 14:57:34
Jeroen Massar wrote:
I saw those retransmissions too in the pcap when trying the SSH and a bit later HTTP query (though there is an Apache there is nothing at / when going by the IP, could be useful to throw a picture/html there >1500 bytes). More reliable and easier testing than SSH, especially as there are less round trips.
You should not be able to get to port 80 at all
> I figured out how to do packet capturing on the box. What is the trick? Does it require shell-access?
http://fritz.box/html/capture.html
Note the extra /html/
I will try the other stuff you suggest tonight from home. No time left now, unfortunately. :(
Thanks for your help!
MTU-like problem, but it's not MTU
Martin F. Krafft wrote:
You should not be able to get to port 80 at all
The tunnel is down at the moment, but you should see accesses in your log. (it reported itself as Apache 2.4.6 btw)
> > I figured out how to do packet capturing on the box. > What is the trick? Does it require shell-access?
http://fritz.box/html/capture.html
Note the extra /html/
Awesome. (For google: Fritz!Box FRITZ!OS 05.51 Capture PCAP packets)
Thanks for your help!
No prob, figuring out weird bugs is always interesting...
MTU-like problem, but it's not MTU
Shadow Hawkins on Monday, 09 December 2013 19:28:35> You should not be able to get to port 80 at all
The tunnel is down at the moment, but you should see accesses in your log. (it reported itself as Apache 2.4.6 btw)
Oh, right. I did add for debugging purposes:
-A forward-new -d 2001:a60:f10a:0:22cf:30ff:fe2a:7c07/128 -i sixxs -o lan -j ACCEPT
*grin*
Here you go:
http://albatross.lehel.madduck.net/fonz_dog.jpg
And the tunnel is back up for now. I just disable outgoing IPv6 as it severely disturbs operations at the office. But the Apache machine and the image are available from the outside, I think that's enough for debugging at the moment...
MTU-like problem, but it's not MTU
Shadow Hawkins on Monday, 09 December 2013 19:34:27Two other ideas to test:
a) tunnel to a different PoP
b) AYIYA tunnel
Good ideas:
a) Same issue with T25778 (Init7), so this seems to be a proto-41 problem, because
b) AYIYA tunneling works.
MTU-like problem, but it's not MTU
Shadow Hawkins on Monday, 09 December 2013 19:36:47I typically look at "icmp or host <pop>". That way you catch all ICMP errors that might be related and get all traffic, but not catch your own traffic.
Run that in parallel with a tcpdump on clegg and if you want to, on the remote host. That way you should see the same packets everywhere, and if not you know at least partially where packets go missing.
I will top-level reply with those data. The two threads we have ongoing are a bit confusing, so I suggest we let them die and continue after I provide these pcaps, unless of course you have specific replies.
BBIAB...
MTU-like problem, but it's not MTU
Shadow Hawkins on Monday, 09 December 2013 20:21:48
Here's a new pcap of a connection from the outside to the HTTP server on the inside of the router/fritzbox combo, which exhibits the same sort of "connection freezing" problem.
First, on the host making the HTTP request, filtered by "host <destination> and port 80":
3 0.198476000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 94 56896 > 80 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=136016669 TSecr=0 WS=128
4 0.230221000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 94 80 > 56896 [SYN, ACK] Seq=0 Ack=1 Win=28560 Len=0 MSS=1440 SACK_PERM=1 TSval=9239725 TSecr=136016669 WS=128
5 0.230276000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 86 56896 > 80 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=136016677 TSecr=9239725
6 0.230406000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 GET /fonz_dog.jpg HTTP/1.1
7 0.472028000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
8 0.716044000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
9 1.204009000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
10 2.180041000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
11 4.136041000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
12 8.048028000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
15 15.872043000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
20 31.504029000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
29 62.800016000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
54 125.392039000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
55 125.444188000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 98 [TCP Previous segment not captured] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9271028 TSecr=136047968 SLE=1 SRE=138
64 148.872157000 2001:a60:f0fb::1 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c ICMPv6 1294 Packet Too Big
65 148.872453000 2001:a60:f0fb::1 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c ICMPv6 1294 Packet Too Big
66 148.872466000 2001:a60:f0fb::1 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c ICMPv6 1294 Packet Too Big
67 148.872808000 2001:a60:f0fb::1 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c ICMPv6 1294 Packet Too Big
68 148.872823000 2001:a60:f0fb::1 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c ICMPv6 1294 Packet Too Big
69 148.873107000 2001:a60:f0fb::1 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c ICMPv6 1294 Packet Too Big
125 269.787781000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 86 56896 > 80 [FIN, ACK] Seq=138 Ack=1 Win=28800 Len=0 TSval=136084066 TSecr=9239725
126 269.854201000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 86 80 > 56896 [ACK] Seq=8569 Ack=139 Win=29696 Len=0 TSval=9307130 TSecr=136084066
Second, on the Fritzbox's "Internet connection 1" interface:
1 0.000000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 255 GET /fonz_dog.jpg HTTP/1.1
24 23.039930 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 126 56896 > 80 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=136016669 TSecr=0 WS=128
25 23.040829 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 126 80 > 56896 [SYN, ACK] Seq=0 Ack=1 Win=28560 Len=0 MSS=1440 SACK_PERM=1 TSval=9239725 TSecr=136016669 WS=128
26 23.070184 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 118 56896 > 80 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=136016677 TSecr=9239725
142 148.250570 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 255 GET /fonz_dog.jpg HTTP/1.1
143 148.251977 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 130 [TCP Previous segment not captured] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9271028 TSecr=136047968 SLE=1 SRE=138
265 292.619110 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 118 56896 > 80 [FIN, ACK] Seq=138 Ack=1 Win=28800 Len=0 TSval=136084066 TSecr=9239725
266 292.658610 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 118 80 > 56896 [ACK] Seq=8569 Ack=139 Win=29696 Len=0 TSval=9307130 TSecr=136084066
Next in line is clegg's Fritzbox-facing IPv4 interface, where the filter is "host <pop> or icmp":
1 0.000000000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 114 56896 > 80 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=136016669 TSecr=0 WS=128
2 0.000000000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 114 80 > 56896 [SYN, ACK] Seq=0 Ack=1 Win=28560 Len=0 MSS=1440 SACK_PERM=1 TSval=9239725 TSecr=136016669 WS=128
3 0.028003000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 106 56896 > 80 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=136016677 TSecr=9239725
4 0.032003000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 106 [TCP ACKed unseen segment] 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=0 TSval=9239733 TSecr=136016677
5 0.032003000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1506 [TCP ACKed unseen segment] [TCP segment of a reassembled PDU]
6 0.032003000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 134 [TCP ACKed unseen segment] [TCP segment of a reassembled PDU]
7 0.032003000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1506 [TCP ACKed unseen segment] [TCP segment of a reassembled PDU]
8 0.032003000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 134 [TCP ACKed unseen segment] [TCP segment of a reassembled PDU]
9 0.032003000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1506 [TCP ACKed unseen segment] [TCP segment of a reassembled PDU]
10 0.032003000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 134 [TCP ACKed unseen segment] [TCP segment of a reassembled PDU]
11 0.032003000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1506 [TCP ACKed unseen segment] [TCP segment of a reassembled PDU]
12 0.032003000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 134 [TCP ACKed unseen segment] [TCP segment of a reassembled PDU]
13 0.276024000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1466 [TCP ACKed unseen segment] [TCP Retransmission] 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=1360 TSval=9239794 TSecr=136016738
14 0.276024000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 146 [TCP ACKed unseen segment] [TCP Retransmission] [TCP segment of a reassembled PDU]
15 0.276024000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1466 [TCP ACKed unseen segment] [TCP Retransmission] [TCP segment of a reassembled PDU]
16 0.276024000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 146 [TCP ACKed unseen segment] [TCP Retransmission] [TCP segment of a reassembled PDU]
17 0.276024000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1466 [TCP ACKed unseen segment] [TCP Retransmission] [TCP segment of a reassembled PDU]
18 0.276024000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 146 [TCP ACKed unseen segment] [TCP Retransmission] [TCP segment of a reassembled PDU]
19 0.276024000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 118 [TCP ACKed unseen segment] [TCP Previous segment not captured] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9239794 TSecr=136016738 SLE=1 SRE=138
20 0.512044000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 118 [TCP Dup ACK 19#1] [TCP ACKed unseen segment] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9239853 TSecr=136016799 SLE=1 SRE=138
21 1.000085000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 118 [TCP Dup ACK 19#2] [TCP ACKed unseen segment] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9239975 TSecr=136016921 SLE=1 SRE=138
22 1.736147000 10.178.17.2 -> 62.245.150.2 UDP 130 Source port: 35935 Destination port: 3740
23 1.972166000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 118 [TCP Dup ACK 19#3] [TCP ACKed unseen segment] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9240218 TSecr=136017165 SLE=1 SRE=138
24 3.940332000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 118 [TCP Dup ACK 19#4] [TCP ACKed unseen segment] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9240710 TSecr=136017654 SLE=1 SRE=138
27 7.844661000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 118 [TCP Dup ACK 19#5] [TCP ACKed unseen segment] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9241687 TSecr=136018632 SLE=1 SRE=138
28 15.677321000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 118 [TCP Dup ACK 19#6] [TCP ACKed unseen segment] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9243645 TSecr=136020588 SLE=1 SRE=138
29 31.302636000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1466 [TCP ACKed unseen segment] [TCP Retransmission] 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=1360 TSval=9247551 TSecr=136024496
30 31.302636000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 118 [TCP Dup ACK 29#1] [TCP ACKed unseen segment] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9247551 TSecr=136024496 SLE=1 SRE=138
31 61.737199000 10.178.17.2 -> 62.245.150.2 UDP 130 Source port: 53350 Destination port: 3740
32 62.589271000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 118 [TCP Dup ACK 29#2] [TCP ACKed unseen segment] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9255373 TSecr=136032320 SLE=1 SRE=138
35 121.738252000 10.178.17.2 -> 62.245.150.2 UDP 130 Source port: 46690 Destination port: 3740
38 125.210545000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 243 GET /fonz_dog.jpg HTTP/1.1
39 125.210545000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 118 [TCP Dup ACK 29#3] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9271028 TSecr=136047968 SLE=1 SRE=138
40 181.739305000 10.178.17.2 -> 62.245.150.2 UDP 130 Source port: 34508 Destination port: 3740
43 241.740359000 10.178.17.2 -> 62.245.150.2 UDP 130 Source port: 58885 Destination port: 3740
46 269.578703000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 106 56896 > 80 [FIN, ACK] Seq=138 Ack=1 Win=28800 Len=0 TSval=136084066 TSecr=9239725
47 269.614706000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 106 80 > 56896 [ACK] Seq=8569 Ack=139 Win=29696 Len=0 TSval=9307130 TSecr=136084066
And finally, on the HTTP server itself, filtered by "port 80":
1 0.000000000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 94 56896 > 80 [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=136016669 TSecr=0 WS=128
2 0.000036000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 94 80 > 56896 [SYN, ACK] Seq=0 Ack=1 Win=28560 Len=0 MSS=1440 SACK_PERM=1 TSval=9239725 TSecr=136016669 WS=128
3 0.030271000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 86 56896 > 80 [ACK] Seq=1 Ack=1 Win=28800 Len=0 TSval=136016677 TSecr=9239725
4 0.032366000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 GET /fonz_dog.jpg HTTP/1.1
5 0.032397000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 86 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=0 TSval=9239733 TSecr=136016677
6 0.032683000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP segment of a reassembled PDU]
7 0.032723000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP segment of a reassembled PDU]
8 0.032751000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP segment of a reassembled PDU]
9 0.032776000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP segment of a reassembled PDU]
10 0.032798000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP segment of a reassembled PDU]
11 0.032819000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP segment of a reassembled PDU]
12 0.033310000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
13 0.033332000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1486 [TCP Out-Of-Order] 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=1400 TSval=9239733 TSecr=136016677
14 0.033340000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 114 [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
15 0.033346000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1486 [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
16 0.033351000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 114 [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
17 0.033355000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1486 [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
18 0.033359000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 114 [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
19 0.033363000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1486 [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
20 0.033367000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 114 [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
21 0.033370000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1486 [TCP Out-Of-Order] [TCP segment of a reassembled PDU]
22 0.033376000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
23 0.033384000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
24 0.033881000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
25 0.033897000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
26 0.033905000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
27 0.034987000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
28 0.275792000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
29 0.275812000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1446 [TCP Retransmission] 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=1360 TSval=9239794 TSecr=136016738
30 0.275822000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 126 [TCP Retransmission] [TCP segment of a reassembled PDU]
31 0.275828000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1446 [TCP Retransmission] [TCP segment of a reassembled PDU]
32 0.275833000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 126 [TCP Retransmission] [TCP segment of a reassembled PDU]
33 0.275838000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1446 [TCP Retransmission] [TCP segment of a reassembled PDU]
34 0.275842000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 126 [TCP Retransmission] [TCP segment of a reassembled PDU]
35 0.275847000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 98 [TCP Dup ACK 34#1] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9239794 TSecr=136016738 SLE=1 SRE=138
36 0.512451000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
37 0.512470000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 98 [TCP Dup ACK 34#2] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9239853 TSecr=136016799 SLE=1 SRE=138
38 0.999569000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
39 0.999592000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 98 [TCP Dup ACK 34#3] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9239975 TSecr=136016921 SLE=1 SRE=138
40 1.972198000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
41 1.972221000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 98 [TCP Dup ACK 34#4] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9240218 TSecr=136017165 SLE=1 SRE=138
42 3.939871000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
43 3.939892000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 98 [TCP Dup ACK 34#5] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9240710 TSecr=136017654 SLE=1 SRE=138
44 7.846056000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
45 7.846080000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 98 [TCP Dup ACK 34#6] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9241687 TSecr=136018632 SLE=1 SRE=138
46 15.679310000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
47 15.679335000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 98 [TCP Dup ACK 34#7] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9243645 TSecr=136020588 SLE=1 SRE=138
48 24.457825000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP Retransmission] 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=1428 TSval=9245840 TSecr=136020588
49 24.458428000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
52 31.305550000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
53 31.305575000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1446 [TCP Retransmission] 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=1360 TSval=9247551 TSecr=136024496
54 31.305586000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 98 [TCP Dup ACK 53#1] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9247551 TSecr=136024496 SLE=1 SRE=138
55 62.591407000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
56 62.591455000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 98 [TCP Dup ACK 53#2] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9255373 TSecr=136032320 SLE=1 SRE=138
57 79.689831000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP Retransmission] 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=1428 TSval=9259648 TSecr=136032320
58 79.690529000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
65 90.441839000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP segment of a reassembled PDU]
66 90.442431000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
67 125.210881000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 HTTP 223 [TCP Retransmission] GET /fonz_dog.jpg HTTP/1.1
68 125.210920000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP Retransmission] 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=1428 TSval=9271028 TSecr=136047968
69 125.210931000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 98 [TCP Dup ACK 68#1] 80 > 56896 [ACK] Seq=8569 Ack=138 Win=29696 Len=0 TSval=9271028 TSecr=136047968 SLE=1 SRE=138
70 125.211533000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
77 210.761851000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP Retransmission] 80 > 56871 [ACK] Seq=1 Ack=1 Win=232 Len=1428 TSval=9292416 TSecr=136010912
80 210.762899000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
81 214.485963000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 86 [TCP Previous segment not captured] 80 > 56871 [FIN, ACK] Seq=8569 Ack=1 Win=232 Len=0 TSval=9293347 TSecr=136010912
82 214.486497000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 134 Destination Unreachable (Port unreachable)
87 222.025830000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP Retransmission] 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=1428 TSval=9295232 TSecr=136047968
88 222.026506000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
90 269.579232000 2001:a60:f0fb:0:224:d7ff:fe04:c82c -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 TCP 86 56896 > 80 [FIN, ACK] Seq=138 Ack=1 Win=28800 Len=0 TSval=136084066 TSecr=9239725
91 269.579276000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 1514 [TCP Retransmission] 80 > 56896 [ACK] Seq=1 Ack=138 Win=29696 Len=1428 TSval=9307120 TSecr=136084066
92 269.579885000 2001:a60:f10a::1 -> 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 ICMPv6 1294 Packet Too Big
93 269.617823000 2001:a60:f10a:0:22cf:30ff:fe2a:7c07 -> 2001:a60:f0fb:0:224:d7ff:fe04:c82c TCP 86 80 > 56896 [ACK] Seq=8569 Ack=139 Win=29696 Len=0 TSval=9307130 TSecr=136084066
All these files are available at
http://scratch.madduck.net/__tmp__madduck-captures.tar.xz, but beware that
these captures also contain some other packets.
MTU-like problem, but it's not MTU
Shadow Hawkins on Thursday, 19 December 2013 07:00:32
Any news? Anything else to try?
MTU-like problem, but it's not MTU
Martin F. Krafft wrote:
Any news? Anything else to try?
If AYIYA works, then I can only guess something is causing proto-41 packet corruption.
Thus you have two options:
1) debug debug debug....
2) just use AYIYA
It is very hard to figure out what is causing these kind of problems as there are many components involved that can cause it and none are under a single owner/administration to make the debugging easy.
MTU-like problem, but it's not MTU
Shadow Hawkins on Saturday, 18 October 2014 19:39:14
Jeroen Massar wrote:
If AYIYA works,
The problems are there too with AYIYA. This is really really disconcerting, baffling, confusing, annoying, and mind-boggling.
:(
MTU-like problem, but it's not MTU
Shadow Hawkins on Thursday, 19 December 2013 07:08:31
The HTTP server is currently offline; to reproduce the problem, please try to SSH to `clegg.lehel.madduck.net`.
|
![[ch]](/s/countries/ch.gif)
on Saturday, 07 December 2013 21:20:43
Posting is only allowed when you are