Thanks for the details on VI editing. This is not a problem for me.
Look at the ipstatus output. class is already wan6. so would I need to set it anyway?
Was the source address correct in the ICMPv6 echo requests you captured or was OS X trying to send packets using an ULA IP as source address?
1 Like
macOS uses the public temp address, should be correct
its even weirder now:
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=0 hlim=118 time=16.595 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=1 hlim=118 time=17.643 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=2 hlim=118 time=15.781 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=3 hlim=118 time=18.801 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=12 hlim=118 time=1704.060 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=13 hlim=118 time=701.133 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=14 hlim=118 time=16.303 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=15 hlim=118 time=16.116 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=16 hlim=118 time=154.538 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=17 hlim=118 time=92.502 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=18 hlim=118 time=139.088 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=19 hlim=118 time=17.193 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=20 hlim=118 time=19.156 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=21 hlim=118 time=19.894 ms
^C
--- google.com ping6 statistics ---
25 packets transmitted, 14 packets received, 44.0% packet loss
round-trip min/avg/max/std-dev = 15.781/210.629/1704.060/449.513 ms
Then I tried again:
--- google.com ping6 statistics ---
58 packets transmitted, 0 packets received, 100.0% packet loss
SO sometimes the forwarding works, sometimes it does not.
More:
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=132 hlim=118 time=1434.988 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=133 hlim=118 time=431.995 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=135 hlim=118 time=72.817 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=136 hlim=118 time=69.173 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=137 hlim=118 time=75.593 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=138 hlim=118 time=80.792 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=139 hlim=118 time=70.163 ms
16 bytes from 2a00:1450:4016:806::200e, icmp_seq=140 hlim=118 time=254.585 ms
^C
--- google.com ping6 statistics ---
156 packets transmitted, 8 packets received, 94.9% packet loss
round-trip min/avg/max/std-dev = 69.173/311.263/1434.988/441.984 ms
Maybe it helps to understand what happens:
ip -6 route:
...
default from <public-wan-interface-address> via fe80::<provider-device-address> dev <wan(6)> proto static metric 384 pref medium
default from <delegated prefix>::/56 via fe80::<provider-device-address> dev <wan(6)> proto static metric 384 pref medium
...
ip -6 neigh:
...
fe80::redacted-provider-device dev <wan(6)> router INCOMPLETE
...
I found the culprit, it was well hidden in LUCI:
You need to enable both, correct?
The usual test pages run positive for me now, but here I am less successful:
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.