Ipv6 problem with ping, ssh, osc

English Network/Internet
1

A week ago, Comcast sent me a new gateway/router, ostensibly to take advantage of the faster speeds they’ve given me. Web and email work fine (and do seem a bit faster), but ssh and osc did not–they were unbearably slow (over 5 minutes to get a response)–and ping ipv6.google.com showed 100% packet loss.

I have to use ssh for work, and with the help of a coworker, we narrowed the problem to ipv6.

We found that disabling ipv6 on my system with
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=1 && sudo sysctl -w net.ipv6.conf.default.disable_ipv6=1
solved the problem.

But here’s the weird part: if I reenable ipv6 afterwards with
sudo sysctl -w net.ipv6.conf.all.disable_ipv6=0 && sudo sysctl -w net.ipv6.conf.default.disable_ipv6=0
the problem does not recur, until the next reboot. This is true even if I run the second command immediately after the first.

I thought perhaps my system was defaulting to ipv6 being disabled, but running just the sysctl command to enable it does not work: I have to explicitly disable it, then enable it. I can do that, but I’d rather not have to.

I am using Network Manager, and it does show ipv6 enabled. The gateway/router settings are locked down by Comcast, so there’s nothing I can change there (and yes, ipv6 is enabled there).

Any ideas what could be causing this and how to fix it?

2

Response to what? The initial connection? Every key press?

3

The initial connection. For example, osc up takes minutes instead of seconds before I get the Updating… responses. Once I do the disable/enable, it stays at seconds.

4

Then compare the network configuration before and after “disable/enable”.

5

Comparing ip a:

BEFORE (not working):

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 1c:6f:65:c8:48:76 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 10.0.0.29/24 brd 10.0.0.255 scope global dynamic noprefixroute eth0
       valid_lft 147601sec preferred_lft 147601sec
    inet6 2601:249:9303:bf0:f242:96e:ac98:4014/64 scope global temporary dynamic
       valid_lft 300sec preferred_lft 300sec
    inet6 2601:249:9301:3a50::e9b/128 scope global dynamic noprefixroute
       valid_lft 4355sec preferred_lft 4355sec
    inet6 2601:249:9303:bf0:dddf:f499:1b15:9b10/64 scope global temporary deprecated dynamic
       valid_lft 300sec preferred_lft 0sec
    inet6 2601:249:9303:bf0:1e6f:65ff:fec8:4876/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 300sec preferred_lft 300sec
    inet6 fe80::1e6f:65ff:fec8:4876/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

AFTER (working):

 ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 1c:6f:65:c8:48:76 brd ff:ff:ff:ff:ff:ff
    altname enp3s0
    inet 10.0.0.29/24 brd 10.0.0.255 scope global dynamic noprefixroute eth0
       valid_lft 147133sec preferred_lft 147133sec
    inet6 2601:249:9303:bf0:5472:5903:e6b4:9b1/64 scope global temporary dynamic
       valid_lft 301sec preferred_lft 301sec
    inet6 2601:249:9303:bf0:1e6f:65ff:fec8:4876/64 scope global dynamic mngtmpaddr noprefixroute
       valid_lft 301sec preferred_lft 301sec
    inet6 fe80::1e6f:65ff:fec8:4876/64 scope link noprefixroute
       valid_lft forever preferred_lft forever

So the ipv6 addresses have changed after enabling/disabling.

(Note this is from a second computer that has 15.5 installed, but shows the same problem as my main computer.)

6

Network configuration is not limited to IP addresses. It also needs at least route entries and DNS to be functional.

But anyway …

It has different prefix. You may test which of the addresses work/do not work, e.g. by using

ping -6 -I 2601:249:9301:3a50::e9b ...
7

It has different prefix. You may test which of the addresses work/do not work,

I tested the addresses on my main computer this morning:

Before:

    inet6 2601:249:9301:3a50::1462/128 scope global dynamic noprefixroute
       valid_lft 208593sec preferred_lft 208593sec (NOT WORKING)
    inet6 2601:249:9303:bf0:8939:48d4:d88a:6e1c/64 scope global temporary dynamic
       valid_lft 299sec preferred_lft 299sec (NOT WORKING)
    inet6 2601:249:9303:bf0:a552:5a0f:bd74:98d3/64 scope global dynamic mngtmpaddr noprefixroute  valid_lft 299sec preferred_lft 299sec (WORKING)

After doing disable/enable, there were only two addresses, and both worked:

    inet6 2601:249:9303:bf0:8107:8579:f6aa:6c3f/64 scope global temporary dynamic
       valid_lft 300sec preferred_lft 300sec
    inet6 2601:249:9303:bf0:a552:5a0f:bd74:98d3/64 scope global dynamic mngtmpaddr noprefixroute  valid_lft 300sec preferred_lft 300sec
8

Well, find out where it comes from. Educated guess is DHCPv6 at which point it probably becomes the question to your provider.

That is strange and I do not have an explanation for it. This and the next address should be equally usabe. Did you try again later, after 10 - 15 seconds?

9

Is it possible that’s left over from the old gateway/router, cached somewhere on my computer, and for some reason not being updated? If so, where should I look?

10

The obvious place to start is system logs with messages from the NetworkManager. Reboot, upload the full output of

journalctl -b --no-pager --full

to the https://paste.opensuse.org/

11

This is right after login, before doing disable/enable.

https://paste.opensuse.org/pastes/83a8ee3fec46

12

As expected, it comes from your DHCPv6 server

Mar 24 10:23:42 rivendell NetworkManager[1206]: <info>  [1711293822.7479] dhcp6 (eth0):   address 2601:249:9301:3a50::1462

Other prefix apparently comes from SLAAC. It may be announced by the same router actually.

Do you need IPv6?

13

At present, not that I know of. But I’d still rather fix it than disable it altogether. So this is coming from the new gateway/router? That entry does disappear when I disable/enable ipv6 on my computer.

14

Then ask your provider why their router gives you this prefix. May be it is supposed to work but there are other issues on provider side. It is your router that tells clients to try DHCPv6 in the first place.

Because NetworkManager is not aware of it and does not initiate DHCPv6 transaction again.

As a workaround you could try setting ipv6.method connection property to ignore. This should give you the same working prefix but avoid attempt to get address from DHCPv6.

15

That worked! Thank you for all your help, I’ve learned a lot.

16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.