Tuesday November 12th, 2024 NCLUG Meeting
Bob Proulx
bob at proulx.com
Sun Nov 17 22:52:32 UTC 2024
Stephen Warren wrote:
> Bob Proulx wrote:
> If you do the same experiment on both systems, so you know the working IPv6
> on both ends, can you then communicate across the local network? I.e. test
> all 6^2 combinations of IP on queasy and George's system..
It's in a strange mode today. Ping is pretty much univerally not
working. But TCP is working.
If I ssh from the test system into my Linode and look to see what
address was used then I can follow that address back with TCP. But
not ping.
rwp at rainy:~$ env | grep SSH_C
SSH_CONNECTION=2605:b40:1516:a200:1b01:7749:55f4:1ff3 41706 2600:3c00::f03c:91ff:fe18:62e4 22
SSH_CLIENT=2605:b40:1516:a200:1b01:7749:55f4:1ff3 41706 22
rwp at rainy:~$ ping 2605:b40:1516:a200:1b01:7749:55f4:1ff3
PING 2605:b40:1516:a200:1b01:7749:55f4:1ff3(2605:b40:1516:a200:1b01:7749:55f4:1ff3) 56 data bytes
^C
--- 2605:b40:1516:a200:1b01:7749:55f4:1ff3 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2034ms
rwp at rainy:~$ nc 2605:b40:1516:a200:1b01:7749:55f4:1ff3 22
SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.5
^C
So I am not sure that counts as working today. Since ping is not
pinging. I am thinking I might have to reboot all again and then see
if ping works. It did before.
As to your question it is the same from George's today.
root at yukiko# ping 2605:b40:1516:a200:1b01:7749:55f4:1ff3
PING 2605:b40:1516:a200:1b01:7749:55f4:1ff3(2605:b40:1516:a200:1b01:7749:55f4:1ff3) 56 data bytes
^C
--- 2605:b40:1516:a200:1b01:7749:55f4:1ff3 ping statistics ---
119 packets transmitted, 0 received, 100% packet loss, time 120807ms
root at yukiko# nc 2605:b40:1516:a200:1b01:7749:55f4:1ff3 22
SSH-2.0-OpenSSH_9.6p1 Ubuntu-3ubuntu13.5
^C
No ping but TCP works.
And now for an additional oddity. It's up to 14 IPv6 addresses now.
root at queasy:~# ip -6 addr show eth0
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
altname enp1s0
inet6 2605:b40:1516:a200:1b01:7749:55f4:1ff3/64 scope global temporary dynamic
valid_lft 43078sec preferred_lft 43078sec
inet6 2605:b40:13a3:8c00:4299:f7b7:be1d:a4fc/64 scope global temporary dynamic
valid_lft 43078sec preferred_lft 43078sec
inet6 2605:b40:13a3:8c00:349:8131:6d71:9c04/64 scope global temporary deprecated dynamic
valid_lft 43078sec preferred_lft 0sec
inet6 2605:b40:1516:a200:ef96:652f:204:a7f8/64 scope global temporary deprecated dynamic
valid_lft 43078sec preferred_lft 0sec
inet6 2605:b40:1516:a200:a602:10c:eab3:ba40/64 scope global temporary deprecated dynamic
valid_lft 43078sec preferred_lft 0sec
inet6 2605:b40:13a3:8c00:4c1a:74ab:8e5b:d99d/64 scope global temporary deprecated dynamic
valid_lft 43078sec preferred_lft 0sec
inet6 2605:b40:1516:a200:b12c:d96c:9307:217f/64 scope global temporary deprecated dynamic
valid_lft 43078sec preferred_lft 0sec
inet6 2605:b40:13a3:8c00:f08e:405b:7256:f19b/64 scope global temporary deprecated dynamic
valid_lft 43078sec preferred_lft 0sec
inet6 2605:b40:13a3:8c00:b978:210b:51bd:e23f/64 scope global temporary deprecated dynamic
valid_lft 43078sec preferred_lft 0sec
inet6 2605:b40:1516:a200:87db:ba30:b265:3c86/64 scope global temporary deprecated dynamic
valid_lft 43078sec preferred_lft 0sec
inet6 2605:b40:1516:a200:928d:8523:a296:f80b/64 scope global temporary deprecated dynamic
valid_lft 43078sec preferred_lft 0sec
inet6 2605:b40:1516:a200:37cb:35cf:cdec:71fe/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 43078sec preferred_lft 43078sec
inet6 2605:b40:13a3:8c00:fde7:1fca:2876:5419/64 scope global temporary deprecated dynamic
valid_lft 43078sec preferred_lft 0sec
inet6 2605:b40:13a3:8c00:6f33:ffb3:f4f6:9c7b/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 43078sec preferred_lft 43078sec
inet6 fe80::4425:2931:5fcd:845/64 scope link noprefixroute
valid_lft forever preferred_lft forever
It's in the working state now with a :a200 prefix up top. But if I
catch it at a different time with a :8c00 prefix up top then of course
it does not work. I think there is a rogue router advertisement
happening. That might be attributing to the growing list of
addresses in that it is flipflopping on prefixes.
The address is contantly changing. That's probably an anti-tracking
security feature. It's a dynamic assignment so that's okay. It's
probably stacking up addresses to accomodate long running connections
which need to keep those alive. As far as I can tell there are no
long running connections and the kernel should know this exactly.
Bob
More information about the NCLUG
mailing list