3381 (Incorrect, should be 173)

Why you using ethernet interface for pppoe traffic, when your transport is ISP vlan? If you meant that in your ISP infra exists vlan, you don't need worry about it, cause ISP had to pop up his l2 mtu on all his switches.

Why you using ethernet interface for pppoe traffic, when your transport is ISP vlan? If you meant that in your ISP infra exists vlan, you don't need worry about it, cause ISP had to pop up his l2 mtu on all his switches.

VLANs are only visible in the "outer" side, when I mirror the fibre into one of the ethernet ports of the HGU. I was not sure if my provider could take higher l2 mtu, so I stayed in the safe side. But I have tried auto, 1500 (upping my L2 MTU), 1492, 1488, 1480 (which is the one that gets selected when I say "auto"). All with the same results. It is NOT a MTU issue, though I lost a lot of time thinking it was.

In theory the HGU should not fiddle with the payload when it strips the VLAN payload, but obviously it does. The configuration I have is supposed to process the voice (mandatory) and TV (I didn't contract it) VLANs, but leave the data VLAN delivered (without the VLAN label) to its ether1. This is the where my MikroTik is connecting to.

Maybe there is a bug in its VLAN code, maybe in the QoS or firewall code. Maybe the code that computes the payload does not initialize to zero the variable. The length field contains apparently semi-random values, like 31234 or 4528, almost always much bigger than the real value.

My ISP HGU is forced into me because it does not exist a legal way to recover the keys and reprogram a different ONT to connect to the fibre. I'd love to be able to switch to a SFP+ ONT, it would save me a lot of electric power and space, but I can't at least for the moment. I highly doubt that it is legal to impose a service-providing ONT upon all the users, so I guess the European Union will end up forcing them to unbundle it to everyone via legal complaints by its competition.

But I have tried auto, 1500 (upping my L2 MTU), 1492, 1488, 1480 (which is the one that gets selected when I say "auto").

But I have tried auto, 1500 (upping my L2 MTU), 1492, 1488, 1480 (which is the one that gets selected when I say "auto").

PPPoE default is 1492, 6to4 substracts 20 (that is why “auto” is 1480=1500-20), so you should at least try 1472. And specify it on both ends - yours and in HE settings as well.
If it still doesn’t work, then you can rule out MTU

But I have tried auto, 1500 (upping my L2 MTU), 1492, 1488, 1480 (which is the one that gets selected when I say "auto").

PPPoE default is 1492, 6to4 substracts 20 (that is why “auto” is 1480=1500-20), so you should at least try 1472. And specify it on both ends - yours and in HE settings as well.
If it still doesn’t work, then you can rule out MTU

Those numbers were for the (outer) PPPoE tunnel. It is the PPPoE link that shows 1480 when left to auto, don't ask me why. It still might be a MikroTik bug, mistaking two stacked tunnels overheads, cause everything seems to work ok when forced to 1492.... The 6to4 link shows 1460 when left to auto. Everything works well for ICMP or UDP. It is the TCP bug that kills me, see above. In summary the problem is that the ONT+HGU, in theory as a transparent bridge, is corrupting the PPPoE length header field and both the MikroTik and my linux laptop using (kernel) pppoe drop those packets.

I'm yet to check if I can substitute their ONT, or they will replace the HGU, or upgrade its firmware, for one that does not have this annoying bug. A tech support issue is open, I'm waiting for an answer.

So what MTU do you have on the 6to4 after all?
And in the HE cabinet?

$ git clone git@github.com:Distrotech/rp-pppoe.git && cd rp-pppoe
$ # some editing until...
$ git diff
diff --git a/src/pppoe.c b/src/pppoe.c
index a513785..608234a 100644
--- a/src/pppoe.c
+++ b/src/pppoe.c
@@ -175,7 +175,7 @@ sessionDiscoveryPacket(PPPoEConnection *conn)
     if (ntohs(packet.length) + HDR_SIZE > len) {
        syslog(LOG_ERR, "Bogus PPPoE length field (%u)",
               (unsigned int) ntohs(packet.length));
-       return;
+       //return; // SGP: testing Broken HGU
     }
 
     if (packet.code != CODE_PADT) {
@@ -751,7 +751,7 @@ asyncReadFromEth(PPPoEConnection *conn, int sock, int clampMss)
     if (ntohs(packet.length) + HDR_SIZE > len) {
        syslog(LOG_ERR, "Bogus PPPoE length field (%u)",
               (unsigned int) ntohs(packet.length));
-       return;
+       //return; // SGP: testing Broken HGU
     }
 #ifdef DEBUGGING_ENABLED
     if (conn->debugFile) {
@@ -802,7 +802,8 @@ asyncReadFromEth(PPPoEConnection *conn, int sock, int clampMss)
     if (plen + HDR_SIZE > len) {
        syslog(LOG_ERR, "Bogus length field in session packet %d (%d)",
               (int) plen, (int) len);
-       return;
+       //return; // SGP: testing Broken HGU
+       plen = len - HDR_SIZE;
     }
 
     /* Clamp MSS */
@@ -880,7 +881,7 @@ syncReadFromEth(PPPoEConnection *conn, int sock, int clampMss)
     if (ntohs(packet.length) + HDR_SIZE > len) {
        syslog(LOG_ERR, "Bogus PPPoE length field (%u)",
               (unsigned int) ntohs(packet.length));
-       return;
+       //return; // SGP: testing Broken HGU
     }
 #ifdef DEBUGGING_ENABLED
     if (conn->debugFile) {
$ make
# unplug the cable going from HGU to MikroTik from router and plug it into my laptop
$ sudo pppd pty './pppoe -I enp0s31f6'  user "adslppp@telefonicanet.pa" noauth lcp-echo-interval 20 noipdefault defaultroute usepeerdns mtu 1492
$ sudo ifup my-he-ipv6

$ grep Bogus /var/log/syslog
(...)
Oct  9 22:56:05 chiron pppoe[32329]: Bogus length field in session packet 31486 (114)
Oct  9 22:56:05 chiron pppoe[32329]: Bogus PPPoE length field (31487)
Oct  9 22:56:05 chiron pppoe[32329]: Bogus length field in session packet 31487 (555)
Oct  9 22:56:05 chiron pppoe[32329]: Bogus PPPoE length field (31490)
Oct  9 22:56:05 chiron pppoe[32329]: Bogus length field in session packet 31490 (126)
Oct  9 22:56:05 chiron pppoe[32329]: Bogus PPPoE length field (31492)
Oct  9 22:56:05 chiron pppoe[32329]: Bogus length field in session packet 31492 (555)
Oct  9 22:56:06 chiron pppoe[32329]: Bogus PPPoE length field (31530)
(...)

• outer (pppoe-out1) MTU of 1492
• inner (sit2) MTU of 1472

Why you don't want to make HE tunnel mtu lower than pppoe tunnel mtu?

Why you don't want to make HE tunnel mtu lower than pppoe tunnel mtu?

Where have you got the idea that I don't want?

When PPPoE tunnel MTU is 1492, 6to4 tunnel MTU is 1472, 20 bytes smaller
when PPPoE tunnel MTU is 1480 (what MikroTik negotiates), 6to4 tunnel MTU is 1460... 20 bytes smaller again
and so on.

Solved!

I no longer need workarounds, and can confirm that for me HE tunnels work allright:

after a firmware upgrade of my HGU from _n43 to _n53 now myHE tunnel works like a charm!