-1 on this.  If you want to check the certificate, install CACert's root certificate.

(Personally, I don't understand how "Let's Encrypt" got into the lists... but then that could apply to most of the listed CAs.)

By the way... it looks like Let's Encrypt does not use a Let's Encrypt certificate.  Should anyone?

1424 is the maximum size of a packet that can go through.
MTU of the link is 1472.

Close, but not quite.  1424 is the maximum payload length that, with the addition of 48 bytes of header, can fit in an MTU of 1472.  1424+48=1472  Specifying 1424 actually gets you a packet length of 1472.

What's wrong with the 1472 MTU uplink. How can I debug it?

Myself, I would probably start by "tcpdump"ing to a file on both end, and then analyzing the files with wireshark.  Look for what differs.  Look of ICMP messages.

Code: [Select]

# tcpdump -i eth0 -s 9999 -w first_end.tcpdump tcp port 22 and host otherhostname
--David

Ah, okay!


root@bh:~$ ping6 -s 1424 -M do ipv6.he.net
PING ipv6.he.net(ipv6.he.net) 1424 data bytes
1432 bytes from ipv6.he.net: icmp_seq=1 ttl=58 time=152 ms

root@bh:~$ ping6 -s 1425 -M do ipv6.he.net
PING ipv6.he.net(ipv6.he.net) 1425 data bytes
ping: local error: Message too long, mtu=1472


1424 is the maximum size of a packet that can go through.
MTU of the link is 1472.

If I do an ssh from one tunnel endpoint on the frankfurt server (with 1480 bytes, because it's nit PPPoE) to another having PPPoE, the ssh session gets stuck after some bytes.
ssh from the 1480 MTU to a internet server with native ipv6 works fine.
ssh from the 1472 MTU gives the same problem  - ssh gets stuck.

What's wrong with the 1472 MTU uplink. How can I debug it?

+1. Anything so that we're not bypassing security checks.

Truncation?  Well, I think it is because google's box is truncating the reply to 64 bytes of data.
Try pinging ipv6.he.net instead.

Truncating the reply is a reasonable sanity measure.  It allows you do send a 64 byte reply to a 64000 byte request, thus no clogging up your own outgoing packets.  It also makes it more likely for the reply to get through an asymetric MTU problem.  On the other hand, one gets problems like what you are seeing.

My issue with all this is that wireshark doesn't manage to pair up the truncated reply with the request.  Somebody never saw a truncated reply.

edit: That 48 byte discrepancy is the IPv6 header (40 bytes) and the ICMPv6 header (8 bytes).  The byte count specified is the payload length.

Hi folks,

I have a strange problem with one of my IPv6 uplinks.
The uplink is a VDSL100 of Deutsche Telekom with PPPoE and MTU of 1492 terminated on a linux-based PC (Brand "PC Engines" model APU2 with Ubuntu 14.04).

Here's the uplink interface:

ppp0      Link encap:Point-to-Point Protocol
          inet addr:84.119.111.111  P-t-P:62.155.246.13  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1492  Metric:1

Basically, I set the MTU of the he-ipv6 interface as well as in the tunnelbroker web-interface to 1472.
The tunnel goes to Frankfurt (216.66.80.30).

he-ipv6   Link encap:IPv6-in-IPv4
          inet6 addr: fe80::5495:b377/64 Scope:Link
          inet6 addr: 2001:470:1111:aaaa::2/64 Scope:Global
          UP POINTOPOINT RUNNING NOARP  MTU:1472  Metric:1


root@bh:~$ ip tun sh
he-ipv6: ipv6/ip  remote 216.66.80.30  local any  ttl 255  6rd-prefix 2002::/16

In iptables and ip6tables I enabled mss-clamping for ppp0 or rather he-ipv6.

Ping works but TCP-Connections get interrupted after a few packets which looks like an MTU issue.
Tracepath claims the MTU of 1472 as okay:

root@bh:~$ tracepath6 xxx
 1?: [LOCALHOST]                        0.139ms pmtu 1472
 1: xxx-2.tunnel.tserv6.fra1.ipv6.he.net              12.648ms
 1:  xxx-2.tunnel.tserv6.fra1.ipv6.he.net              13.633ms
 2:  ve399.core1.fra1.he.net                              16.649ms
[....]
 7:  xxx2.kettenbach-it.de                                  12.957ms reached
     Resume: pmtu 1472 hops 7 back 7

Here's what ping with different packet sizes says:


root@bh:~$ ping6 -s 1472 -M do ipv6.google.com
PING ipv6.google.com(fra16s18-in-x0e.1e100.net) 1472 data bytes
ping: local error: Message too long, mtu=1472

root@bh:~$ ping6 -s 1425 -M do ipv6.google.com
PING ipv6.google.com(fra16s18-in-x0e.1e100.net) 1425 data bytes
ping: local error: Message too long, mtu=1472

root@bh:~$ ping6 -s 1424 -M do ipv6.google.com
PING ipv6.google.com(fra16s18-in-x0e.1e100.net) 1424 data bytes
72 bytes from fra16s18-in-x0e.1e100.net: icmp_seq=1 ttl=58 (truncated)


Obviously, packets larger than 1424 do not go through and packets smaller or equal 1424 get truncated.

If I lower the MTU to the minimun of 1280, the pings look like this:


PING ipv6.google.com(fra16s18-in-x0e.1e100.net) 1280 data bytes
ping: local error: Message too long, mtu=1280

PING ipv6.google.com(fra16s18-in-x0e.1e100.net) 1233 data bytes
ping: local error: Message too long, mtu=1280

PING ipv6.google.com(fra16s18-in-x0e.1e100.net) 1232 data bytes
72 bytes from fra16s18-in-x0e.1e100.net: icmp_seq=1 ttl=58 (truncated)



Wha do packets always get truncated???

I don't know what's going on here and I don't know could be the next (debugging) steps.
Does anybody have a hint for me?

Volker

so i should just simply push the update button and not alter the ns1 through ns5.he.net in any way there?
unafunk.com in the name area and just ns1.he.net in the nameserver area?

OK. First off, "unafunk.com" is not a registered domain.  If you are actually trying to use that, you should register and pay the fees first.  I currently use godaddy.com, but there are hundreds of registrars available.

If you were using unafunk as an example, you should write "example.com".

Second, I'm afraid you've lost me.  Sorry.

--David

Thanx for reply..
so i should just simply push the update button and not alter the ns1 through ns5.he.net in any way there?
unafunk.com in the name area and just ns1.he.net in the nameserver area?

thank you for reply..

newbie at this, but how do i delegate my domain name with nameserver?

Delegation is part of domain name registration.  Having registered "unafunk.com" at some registrar, you go back to the regiistrars website and tell them that you want to specify the name servers.  (Many registrars expect to host your DNS too, so this can be tough, or out of the way.)  Then you specify ns1.he.net through ns5.he.net as your nameservers.  Then you may have to wait up to two days for things to propagate (or maybe not).  Then you should be able to get HE.NET's dns support working for you.

--David

But with numeric input, at least you get an output.....

The output could only be "Unknown record of type n with undecodable content".  The content bytes could be output, but domain names would often be undecipherable due to trailing domain compression.  OK, there might be some value to showing the unknown records. 

Note that you really are better off with an ANY query to fetch this.  (Frankly, if you are trying to browse DNS, I would always recommend "ANY", except if you are trying to deal with a partially expired cache.)