Hi! In case you aren't aware from your monitoring, there seems to be packet loss between SYD1 and SJC1.

I am seeing high packet loss from a Sydney tunnel for traffic to the United States:

 2  e0-1.core2.syd1.he.net (2001:470:0:27b::1)  175.034 ms  181.569 ms  184.898 ms
 3  e0-35.core2.sjc1.he.net (2001:470:0:51c::1)  325.544 ms * *
 4  * * *
 5  * * 100ge8-2.core1.lax1.he.net (2001:470:0:534::1)  331.783 ms
 6  * hivelocity-ventures-corp.10gigabitethernet12-19.core1.lax1.he.net (2001:470:1:839::2)  331.858 ms *
 7  fd80::afe:21 (fd80::afe:21)  378.718 ms * *
 8  fd80::afe:e (fd80::afe:e)  387.989 ms  388.569 ms *
 9  fd80::afe:79 (fd80::afe:79)  388.426 ms  386.764 ms  386.726 ms
10  fd80::afe:4 (fd80::afe:4)  395.726 ms  387.439 ms  387.03 ms
11  * * *
...

This started at around 2021-08-05T01:32:00Z and is still happening 10 hours later, so doesn't appear to just be some short term thing. I've run mtr a few times and am seeing the same pattern (packet loss starting on and after e0-35.core2.sjc1.he.net), so I think it is your international link.

I really love and appreciate your tunnelbroker.net service - if there is anything I can do to help you diagnose or test this, happy to help!

Hello cannfoddr,

radvd sends by default multicast advertisements, so you have to instruct the TV not to listen to them, which might be an unsolvable problem as long there is no menu option to disable IPv6 in the TV.
An option for radvd is to send router advertisements to selected IPv6 addresses, but that's not attractive because you have to configure them manually...  I've to dig in the manuals, but I think you have to fire up a DHCPv6 server, and let radvd advertise the managed flag, so the clients get the default route but have to ask the DHCPv6 server for an address. The MAC's of the TV can be excluded there.
 
 

Hi lespinasse,

If your router is Linux based and you're still using ip6tables, (I did not learn the new nftables yet), you can place two rules in the mangle table for the provider's  interface:
POSTROUTING chain target SNPT maps HE's prefix to provider
PREROUTING chain target DNTP maps provider's prefix to HE. 

If those rules are in place, you can safely switch the default IPv6 route to the provider and  both provider's addresses and HE addresses go to the provider. What surprised me is that the 5th segment of the /64 changed too, but that's the way to keep the packet's checksum alive....

When using my tunnel and connecting to google search, I was getting for a while a thing that was asking me to confirm I wasn't a bot.

I'm getting redirected to google.com.hk now... (using chromium on linux gateway to test)
I'm getting a sort of 'permission denied to search google from this device'  (don't have the exact text)

(with some example search parameters)

who fixes this?

Code: [Select]

403. That’s an error.

Your client does not have permission to get URL /search?q=company+of+heros+3&oq=company+of+heros+3&aqs=chrome..69i57.376j0j7&sourceid=chrome&ie=UTF-8 from this server. That’s all we know.



Geolocation databases are THIRD party data.  HE has little control.

One of my blocks is missing from rwhois (the other 3 main ones are fine; both /64s are fine)..  The look at this was prompted by ARIN wanting to cancel my HE contact (I assume that this is because the rwhois is considered working...)
The blocks are all properly routed (I'm using the missing one for this message).  As far as geolocation goes, I've had good luck using maxmind's web portal to correct things (the missing block gets assigned to hong kong fairly often for some reason)  Still wish that either (or both) of Verizon and Charter/Spectrum would turn up V6 for customers; both of them have dual-stack core (and Spectrum provides V6 just fine in former RR areas, just not Charter...)  (and VZW LTE is all V6, like TMobile pioneered..  VZ FIOS isn't VZW, though.)

12:44 GMT - looks like it back up 

Stockholm has returned, but the Paris one is still down 

EDIT:  Tunnel server status page updated and paris server is showing as down 

Yup, and now the Stockholm tunnerserver is also showing down.

Just lost my tunnel to the Paris server - 10:40 UK time 29/07/2021.  Status page says the tunnel server is OK, however my traceroutes stop in AS1299 (Telia).  Think its probably a Telia issue?

EDIT:  Tunnel server status page updated and paris server is showing as down