[oS-en] I have IPv6! Now what?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I asked to participate in a beta testing of deployment of IPv6 by my ISP, Telefónica. After many weeks, they mailed me to say they would activate it today. And yes, my machines are getting, besides the IPv4 local address, two _dynamic_ IPv6 addresses. Why two, what's the difference? Telcontar:~ # ip addr 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:d8:... altname enp34s0 inet 192.168.1.14/16 brd 192.168.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a02:9140:1180:0:634a:...:...:.../64 scope global temporary dynamic valid_lft 86397sec preferred_lft 80397sec inet6 2a02:9140:1180:0:2d8:..:...:.../64 scope global dynamic mngtmpaddr valid_lft 86397sec preferred_lft 86397sec inet6 fe80::2d8:...:...:.../64 scope link valid_lft forever preferred_lft forever Telcontar:~ # The site <https://test-ipv6.com/> confirms. It says, though, that: Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this. [more info] → https://test-ipv6.com/index.html.en_US#found I don't understand this. Meaning, what can I do to make firefox use IPv6 and why exactly it doesn't? If I point firefox to my IPv6 address, it instead asks google to search for that text. I asked google: https://support.mozilla.org/en-US/questions/1111992 How to type ipv6-address and port number in URL bar? which does not apply, it is about link-local addresses, and mine are not. Finally I found that the syntax is: http://[2a02:9140:...]:port/path/ and it does work :-) The route has not changed: Isengard:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router.valinor 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 Isengard:~ # Should it have also an IPv6 entry? I must try another machine that uses only DHCP. I have no idea which is the IPv6 address of the router or how to find it. Maybe "fe80::8626:2bff:fe6e:c571", but a ping6 to it fails. Ok, finally found one, 2a02:...:75b5... but that IP can change every day, I can not put that in my hosts file. Ok, I can find my own router address doing a traceroute6 to google or any outside address. The first line. Huh, will that be the external or the internal address of it? - -- Cheers Carlos E. R. (from 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZD2/kBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVU2AAnjsFlw7Dns9pQFiTp8Ic Xk7n3G7QAJ45lLwxcaYTXvMy6UeEMjkjuFpu7w== =3/ZO -----END PGP SIGNATURE-----
On 2023-04-17 17:52, Carlos E. R. wrote:
Why two, what's the difference?
The question should be why ONLY two. I get 2^72 addresses from mine. Yep, a gazillion addresses! Even my cell phone gets 2^64 addresses. As for two, check again tomorrow and the next day, etc. If they're using SLAAC, you get in addition to a consistent address, up to 7 privacy addresses, with a new one every day. The global dynamic address is your consistent address and may be based on your MAC address. The other one is a privacy address. Are you connecting directly to your ISP? Or through a router that supports IPv6? If a router, you may have more than 1 /64 available. I have 256. You can split off the /64s to different networks. For example, I have 1 for my guest WiFi, in addition to my main LAN. BTW, I run pfSense for my firewall/router and it supports multiple /64s. If my modem was in gateway mode, I'd only get a single /64.
On 2023-04-18 00:20, James Knott wrote:
On 2023-04-17 17:52, Carlos E. R. wrote:
Why two, what's the difference?
The question should be why ONLY two. I get 2^72 addresses from mine. Yep, a gazillion addresses! Even my cell phone gets 2^64 addresses.
Of course I have a /64. But each machine gets two on the DHCP.
As for two, check again tomorrow and the next day, etc. If they're using SLAAC, you get in addition to a consistent address, up to 7 privacy addresses, with a new one every day. The global dynamic address is your consistent address and may be based on your MAC address. The other one is a privacy address. Are you connecting directly to your ISP? Or through a router that supports IPv6?
A router, of course.
If a router, you may have more than 1 /64 available. I have 256. You can split off the /64s to different networks. For example, I have 1 for my guest WiFi, in addition to my main LAN.
BTW, I run pfSense for my firewall/router and it supports multiple /64s. If my modem was in gateway mode, I'd only get a single /64.
We can not change the router. Basically, not supported, despite what the law says. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-17 23:52, Carlos E. R. wrote:
Hi,
I asked to participate in a beta testing of deployment of IPv6 by my ISP, Telefónica. After many weeks, they mailed me to say they would activate it today.
...
Finally I found that the syntax is:
http://[2a02:9140:...]:port/path/
and it does work :-)
But on Firefox on my phone, the same syntax does not work and does a google search instead. I can not find my own server on IPv6 from outside. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 03:03, James Knott wrote:
On 2023-04-17 18:43, Carlos E. R. wrote:
But on Firefox on my phone, the same syntax does not work and does a google search instead. I can not find my own server on IPv6 from outside.
If you have an Android phone, it won't work with DHCPv6.
Why not? It gets an IPv6 address. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-17 21:39, Carlos E.R. wrote:
If you have an Android phone, it won't work with DHCPv6.
Why not? It gets an IPv6 address.
https://issuetracker.google.com/issues/36949085?pli=1 Of course that was a while ago, so things may have been fixed. However, I participate in a forum where the topic comes up occasionally as to why someone can't get it to work. If you can go to a test site, such as test-ipv6.com and it works, then I guess it has been fixed. If all is OK, you should get 10/10.
On 2023-04-18 04:00, James Knott wrote:
On 2023-04-17 21:39, Carlos E.R. wrote:
If you have an Android phone, it won't work with DHCPv6.
Why not? It gets an IPv6 address.
https://issuetracker.google.com/issues/36949085?pli=1
Of course that was a while ago, so things may have been fixed. However, I participate in a forum where the topic comes up occasionally as to why someone can't get it to work. If you can go to a test site, such as test-ipv6.com and it works, then I guess it has been fixed. If all is OK, you should get 10/10.
All tests blue, except dns test in green.. The problem is that Firefox in Android doesn't accept "http://[2a02:9140:...]:port/path/" syntax. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 04:03, Carlos E. R. wrote:
The problem is that Firefox in Android doesn't accept "http://[2a02:9140:...]:port/path/" syntax.
-
Why are you even worrying about that? Use DNS.
On 2023-04-18 14:25, James Knott wrote:
On 2023-04-18 04:03, Carlos E. R. wrote:
The problem is that Firefox in Android doesn't accept "http://[2a02:9140:...]:port/path/" syntax.
-
Why are you even worrying about that? Use DNS.
I haven't checked yet if my external dyn dns accepts IPv6. If they do, then I'll have to modify the scripts, which will take some time. For a quick test, which was all I was trying to do, I need to enter the IP address into firefox. And I wanted to do the test forcing FF to use IPv6. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 09:09, Carlos E. R. wrote:
Why are you even worrying about that? Use DNS.
I haven't checked yet if my external dyn dns accepts IPv6. If they do, then I'll have to modify the scripts, which will take some time.
For a quick test, which was all I was trying to do, I need to enter the IP address into firefox.
And I wanted to do the test forcing FF to use IPv6.
I have been using IPv6 for close to 13 years and almost never use the IPv6 address. If you don't have DNS available, use the hosts file.
On 2023-04-18 15:19, James Knott wrote:
On 2023-04-18 09:09, Carlos E. R. wrote:
Why are you even worrying about that? Use DNS.
I haven't checked yet if my external dyn dns accepts IPv6. If they do, then I'll have to modify the scripts, which will take some time.
For a quick test, which was all I was trying to do, I need to enter the IP address into firefox.
And I wanted to do the test forcing FF to use IPv6.
I have been using IPv6 for close to 13 years and almost never use the IPv6 address. If you don't have DNS available, use the hosts file.
You don't understand. I'm trying to reach my home server from internet, using IPv6, just for trying, for testing. From internet, meaning I need to do it from a machine that is not in my LAN. The only one I have this minute is my android phone. There is currently no DNS that will do that conversion, name to IPv6 address, nor a hosts file is possible (non rooted Android). So I simply write: http://[2a02:9140:...]:port/path/ in Firefox in Android, and the stupid thing asks google for that string. It does not recognize it as an address. FF in the computer does. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 14:13, Carlos E. R. wrote:
in Firefox in Android, and the stupid thing asks google for that string. It does not recognize it as an address. FF in the computer does.
The problem is the : in the address confuses some software. It's why you have to put the [ ] around the address, but sometimes even that isn't enough. As someone else mentioned, you can't access https sites. I also tried playing with using the addresses many years ago and soon stopped bothering with them.
On 2023-04-18 20:16, James Knott wrote:
On 2023-04-18 14:13, Carlos E. R. wrote:
in Firefox in Android, and the stupid thing asks google for that string. It does not recognize it as an address. FF in the computer does.
The problem is the : in the address confuses some software. It's why you have to put the [ ] around the address, but sometimes even that isn't enough. As someone else mentioned, you can't access https sites. I also tried playing with using the addresses many years ago and soon stopped bothering with them.
I currently have no alternative, for testing connectivity to my home server over IPv6. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023/4/19 02:16, James Knott wrote:
isn't enough. As someone else mentioned, you can't access https sites. I also tried playing with using the addresses many years ago and soon stopped bothering with them. I have some experience about playing the https://ipv4-address/
I use the openssl to create a private CA. Then use this CA to create/sign a server certificate. In the server certificate, I listed the IP address in the "Subject Alternative Name". You can see the manual page for openssl's x509v3_config. Assume that the IP address in the certificate is 192.168.0.123, it's a linux box. In the 192.168.0.123, I run below openssl command openssl s_server -accept 192.168.0.123:4433 -www -cert my-private-ip.crt -key my-private-ip.key On the other side. I run firefox from another PC that installed and trust the private CA then try to connect to the https://192.168.0.123:4433/. Guess what, it worked. On the manual page of x509v3_config, it also supports IPv6 address as the Subject Alternative Name.
Carlos E.R. wrote:
On 2023-04-18 03:03, James Knott wrote:
On 2023-04-17 18:43, Carlos E. R. wrote:
But on Firefox on my phone, the same syntax does not work and does a google search instead. I can not find my own server on IPv6 from outside.
If you have an Android phone, it won't work with DHCPv6.
Why not? It gets an IPv6 address.
For some reason, Android only supports stateless autoconfig, not DHCPv6. AFAIR, the ICMPv6 Router Advertisement isn't processed correctly, but I have not looked at this for over ten years. -- Per Jessen, Zürich (8.9°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 07:31, Per Jessen wrote:
Carlos E.R. wrote:
On 2023-04-18 03:03, James Knott wrote:
On 2023-04-17 18:43, Carlos E. R. wrote:
But on Firefox on my phone, the same syntax does not work and does a google search instead. I can not find my own server on IPv6 from outside.
If you have an Android phone, it won't work with DHCPv6.
Why not? It gets an IPv6 address.
For some reason, Android only supports stateless autoconfig, not DHCPv6. AFAIR, the ICMPv6 Router Advertisement isn't processed correctly, but I have not looked at this for over ten years.
Mind: When I have said in this thread "dhcp" in this thread, I have no idea what protocol my router actually uses to hand over automatically IPv6 address and routes and whatever. I said dhcp because that is the only method I know. Sorry if I have confused people. My mobile phone tests blue on IPv6, both on WiFi and not. The problem is Firefox with IPs. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-18 07:31, Per Jessen wrote:
Carlos E.R. wrote:
On 2023-04-18 03:03, James Knott wrote:
On 2023-04-17 18:43, Carlos E. R. wrote:
But on Firefox on my phone, the same syntax does not work and does a google search instead. I can not find my own server on IPv6 from outside.
If you have an Android phone, it won't work with DHCPv6.
Why not? It gets an IPv6 address.
For some reason, Android only supports stateless autoconfig, not DHCPv6. AFAIR, the ICMPv6 Router Advertisement isn't processed correctly, but I have not looked at this for over ten years.
Mind: When I have said in this thread "dhcp" in this thread, I have no idea what protocol my router actually uses to hand over automatically IPv6 address and routes and whatever. I said dhcp because that is the only method I know.
I'll venture a guess and say it is most likely not DHCPv6. There _are_ reasons for using DHCPv6, but I doubt if any apply in a consumer setting.
The problem is Firefox with IPs.
What exactly is the problem you are experiencing? ISTR something about an issue wrt the device name in an address, in a URL. It's a bit hazy, I'll have to google it. -- Per Jessen, Zürich (13.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Tue, Apr 18, 2023 at 11:38 AM Per Jessen <per@opensuse.org> wrote:
Mind: When I have said in this thread "dhcp" in this thread, I have no idea what protocol my router actually uses to hand over automatically IPv6 address and routes and whatever. I said dhcp because that is the only method I know.
I'll venture a guess and say it is most likely not DHCPv6. There _are_ reasons for using DHCPv6, but I doubt if any apply in a consumer setting.
DHCPv6 was the only way to provide DNS information for a long time, so it almost certainly *is* used, just not for address assignment.
Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 11:38 AM Per Jessen <per@opensuse.org> wrote:
Mind: When I have said in this thread "dhcp" in this thread, I have no idea what protocol my router actually uses to hand over automatically IPv6 address and routes and whatever. I said dhcp because that is the only method I know.
I'll venture a guess and say it is most likely not DHCPv6. There _are_ reasons for using DHCPv6, but I doubt if any apply in a consumer setting.
DHCPv6 was the only way to provide DNS information for a long time, so it almost certainly *is* used, just not for address assignment.
Hmm, you're right, assigning DNS doesn't work from radvd, I forgot. The comment in my dhcpd6 config says "2012/06/12" :-) -- Per Jessen, Zürich (12.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 04:42, Andrei Borzenkov wrote:
DHCPv6 was the only way to provide DNS information for a long time, so it almost certainly*is* used, just not for address assignment.
Actually, you would have relied on IPv4 DNS in a dual stack environment. It doesn't matter whether IPv4 or IPv6 was used, as both provided the exact same info. RDNSS is now used and is part of the router advertisement.
On 2023-04-18 10:38, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-18 07:31, Per Jessen wrote:
Carlos E.R. wrote:
On 2023-04-18 03:03, James Knott wrote:
On 2023-04-17 18:43, Carlos E. R. wrote:
But on Firefox on my phone, the same syntax does not work and does a google search instead. I can not find my own server on IPv6 from outside.
If you have an Android phone, it won't work with DHCPv6.
Why not? It gets an IPv6 address.
For some reason, Android only supports stateless autoconfig, not DHCPv6. AFAIR, the ICMPv6 Router Advertisement isn't processed correctly, but I have not looked at this for over ten years.
Mind: When I have said in this thread "dhcp" in this thread, I have no idea what protocol my router actually uses to hand over automatically IPv6 address and routes and whatever. I said dhcp because that is the only method I know.
I'll venture a guess and say it is most likely not DHCPv6. There _are_ reasons for using DHCPv6, but I doubt if any apply in a consumer setting.
The router does say DHCPv6 (stateless) and RADVD, and "MLD Snooping", whatever that is. The router config says: IPv6 LAN Auto Configuration Note: Stateful DHCPv6 is supported based on the assumption of prefix length less than 64. Interface ID does NOT support ZERO COMPRESSION "::". Please enter the complete information. For exampe: Please enter "0:0:0:2" instead of "::2".
The problem is Firefox with IPs.
What exactly is the problem you are experiencing? ISTR something about an issue wrt the device name in an address, in a URL. It's a bit hazy, I'll have to google it.
That if I write in the firefox box in Android: http://[2a02:...59cd] It tries to find that string in google, as a string. Thus I can not (yet) try reach my own server via IPv6 from outside. Maybe tethering my laptop to the phone. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Tue, Apr 18, 2023 at 1:13 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
That if I write in the firefox box in Android:
It tries to find that string in google, as a string.
This works in desktop firefox (Linux and Windows) so it seems to be an Android specific issue.
Carlos E. R. wrote:
On 2023-04-18 10:38, Per Jessen wrote:
I'll venture a guess and say it is most likely not DHCPv6. There _are_ reasons for using DHCPv6, but I doubt if any apply in a consumer setting.
The router does say DHCPv6 (stateless) and RADVD,
Yes, see what Andrei wrote earlier about the DNS config.
The problem is Firefox with IPs.
What exactly is the problem you are experiencing? ISTR something about an issue wrt the device name in an address, in a URL. It's a bit hazy, I'll have to google it.
That if I write in the firefox box in Android:
It tries to find that string in google, as a string.
With firefox on the desktop it works (with your external address, but I guess you don't have anything listening on port 80. -- Per Jessen, Zürich (12.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Tue, Apr 18, 2023 at 2:01 PM Per Jessen <per@opensuse.org> wrote:
That if I write in the firefox box in Android:
It tries to find that string in google, as a string.
With firefox on the desktop it works (with your external address, but I guess you don't have anything listening on port 80.
Do you mean it tries to connect, fails and then tries to search because the initial connection failed?
Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 2:01 PM Per Jessen <per@opensuse.org> wrote:
That if I write in the firefox box in Android:
It tries to find that string in google, as a string.
With firefox on the desktop it works (with your external address, but I guess you don't have anything listening on port 80.
Do you mean it tries to connect, fails and then tries to search because the initial connection failed?
Actually, scratch that - I was testing on the wrong machine .... duh. -- Per Jessen, Zürich (14.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
Per Jessen wrote:
Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 2:01 PM Per Jessen <per@opensuse.org> wrote:
That if I write in the firefox box in Android:
It tries to find that string in google, as a string.
With firefox on the desktop it works (with your external address, but I guess you don't have anything listening on port 80.
Do you mean it tries to connect, fails and then tries to search because the initial connection failed?
Actually, scratch that - I was testing on the wrong machine .... duh.
With FF on a machine that actually has ipv6 (hah!), FF tries to connect, but then times out. The connection has timed out The server at .....5abd is taking too long to respond. Remarkably, it responds on port 22: ssh ......:5abd The authenticity of host '....:5abd (....:5abd)' can't be established. ECDSA key fingerprint is SHA256:9Ge52md0CniZ4uUdC4famgZntww9TuNdohp+jHknbFs. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '......:5abd' (ECDSA) to the list of known hosts. Password: -- Per Jessen, Zürich (14.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 13:32, Per Jessen wrote:
Per Jessen wrote:
Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 2:01 PM Per Jessen <> wrote:
That if I write in the firefox box in Android:
It tries to find that string in google, as a string.
With firefox on the desktop it works (with your external address, but I guess you don't have anything listening on port 80.
Do you mean it tries to connect, fails and then tries to search because the initial connection failed?
Actually, scratch that - I was testing on the wrong machine .... duh.
With FF on a machine that actually has ipv6 (hah!), FF tries to connect, but then times out.
The connection has timed out The server at .....5abd is taking too long to respond.
Remarkably, it responds on port 22:
I know. I don't know what for, though. Maybe maintenance by the ISP. I haven't managed to connect to it from outside, but it works from the inside.
ssh ......:5abd The authenticity of host '....:5abd (....:5abd)' can't be established. ECDSA key fingerprint is SHA256:9Ge52md0CniZ4uUdC4famgZntww9TuNdohp+jHknbFs. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '......:5abd' (ECDSA) to the list of known hosts. Password:
cer@Telcontar:~> ssh router The authenticity of host 'router (192.168.1.1)' can't be established. RSA key fingerprint is SHA256:xin7RmqoxqaDU/YpsJTm7pXyZ7f+eH+6HIfASBULEwU. Are you sure you want to continue connecting (yes/no/[fingerprint])? I routinely connect to it (cron job) to interrogate the router about the external IPv4 address. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 13:01, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-18 10:38, Per Jessen wrote:
I'll venture a guess and say it is most likely not DHCPv6. There _are_ reasons for using DHCPv6, but I doubt if any apply in a consumer setting.
The router does say DHCPv6 (stateless) and RADVD,
Yes, see what Andrei wrote earlier about the DNS config.
The problem is Firefox with IPs.
What exactly is the problem you are experiencing? ISTR something about an issue wrt the device name in an address, in a URL. It's a bit hazy, I'll have to google it.
That if I write in the firefox box in Android:
It tries to find that string in google, as a string.
With firefox on the desktop it works (with your external address, but I guess you don't have anything listening on port 80.
Then (with IPv4) you get a "failed connection". -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 04:07, Carlos E. R. wrote:
Mind: When I have said in this thread "dhcp" in this thread, I have no idea what protocol my router actually uses to hand over automatically IPv6 address and routes and whatever. I said dhcp because that is the only method I know.
Sorry if I have confused people.
Use Wireshark to see what's on the wire. You can filter on port 546 or 547 for DHCPv6. You can also filter on ICMPv6, to see the router advertisements, to see if you're using SLAAC.
My mobile phone tests blue on IPv6, both on WiFi and not. The problem is Firefox with IPs.
With test-ipv6.com, you're looking for 10/10. That's all that matters.
James Knott wrote:
On 2023-04-17 18:43, Carlos E. R. wrote:
But on Firefox on my phone, the same syntax does not work and does a google search instead. I can not find my own server on IPv6 from outside.
If you have an Android phone, it won't work with DHCPv6.
+1. It is quite annoying. -- Per Jessen, Zürich (8.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
* Carlos E. R. <robin.listas@telefonica.net> [04-17-23 17:54]:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi,
I asked to participate in a beta testing of deployment of IPv6 by my ISP, Telefónica. After many weeks, they mailed me to say they would activate it today.
And yes, my machines are getting, besides the IPv4 local address, two _dynamic_ IPv6 addresses.
Why two, what's the difference?
Telcontar:~ # ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:d8:... altname enp34s0 inet 192.168.1.14/16 brd 192.168.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a02:9140:1180:0:634a:...:...:.../64 scope global temporary dynamic valid_lft 86397sec preferred_lft 80397sec inet6 2a02:9140:1180:0:2d8:..:...:.../64 scope global dynamic mngtmpaddr valid_lft 86397sec preferred_lft 86397sec inet6 fe80::2d8:...:...:.../64 scope link valid_lft forever preferred_lft forever Telcontar:~ #
The site <https://test-ipv6.com/> confirms. It says, though, that:
Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this. [more info]
→ https://test-ipv6.com/index.html.en_US#found
I don't understand this. Meaning, what can I do to make firefox use IPv6 and why exactly it doesn't?
If I point firefox to my IPv6 address, it instead asks google to search for that text.
I asked google:
https://support.mozilla.org/en-US/questions/1111992
How to type ipv6-address and port number in URL bar?
which does not apply, it is about link-local addresses, and mine are not. Finally I found that the syntax is:
http://[2a02:9140:...]:port/path/
and it does work :-)
The route has not changed:
Isengard:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router.valinor 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 Isengard:~ #
Should it have also an IPv6 entry?
I must try another machine that uses only DHCP.
just use the correct tool, "route -6" or more correctly "ip -6 route"
I have no idea which is the IPv6 address of the router or how to find it. Maybe "fe80::8626:2bff:fe6e:c571", but a ping6 to it fails. Ok, finally found one, 2a02:...:75b5... but that IP can change every day, I can not put that in my hosts file.
Ok, I can find my own router address doing a traceroute6 to google or any outside address. The first line. Huh, will that be the external or the internal address of it?
- -- Cheers
Carlos E. R. (from 15.4 x86_64 at Telcontar)
-----BEGIN PGP SIGNATURE-----
iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZD2/kBwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVU2AAnjsFlw7Dns9pQFiTp8Ic Xk7n3G7QAJ45lLwxcaYTXvMy6UeEMjkjuFpu7w== =3/ZO -----END PGP SIGNATURE-----
-- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
On 2023-04-18 02:17, Patrick Shanahan wrote:
* Carlos E. R. <> [04-17-23 17:54]:
Hi,
The route has not changed:
Isengard:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router.valinor 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 Isengard:~ #
Should it have also an IPv6 entry?
I must try another machine that uses only DHCP.
just use the correct tool, "route -6" or more correctly "ip -6 route"
Ah! I see :-) [...] Wow, that's a complicated output that I don't understand. Must go to bed. Tired. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-17 17:52, Carlos E. R. wrote:
Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this. [more info]
→https://test-ipv6.com/index.html.en_US#found
I don't understand this. Meaning, what can I do to make firefox use IPv6 and why exactly it doesn't?
You can configure your computer to prefer IPv4 or IPv6
How to type ipv6-address and port number in URL bar?
That can be tricky. Best to use host names. Any reason you're using DHCPv6 instead of SLAAC for the LAN? Thanks to some genius at Google, Android doesn't support DHCPv6.
Ok, I can find my own router address doing a traceroute6 to google or any outside address. The first line. Huh, will that be the external or the internal address of it?
Routers often use link local addresses.
On 2023-04-18 03:02, James Knott wrote:
On 2023-04-17 17:52, Carlos E. R. wrote:
Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this. [more info]
→https://test-ipv6.com/index.html.en_US#found
I don't understand this. Meaning, what can I do to make firefox use IPv6 and why exactly it doesn't?
You can configure your computer to prefer IPv4 or IPv6
After two decades of configuration, I don't remember what this machine is configured for. This moment I'm past bed time, so I don't remember where to check, either.
How to type ipv6-address and port number in URL bar?
That can be tricky. Best to use host names.
Ha! And which is the name of my computer? :-D Telcontar:~ # host isengard isengard.valinor has address 192.168.1.16 Telcontar:~ # It is an IPv4 address only. Not a surprise, I wrote the DNS entries, decades ago. I can not make the computers respond on IPv6 to names unless I write them myself in the hosts file or the DNS file, and I can not write them because they are dynamic.
Any reason you're using DHCPv6 instead of SLAAC for the LAN? Thanks to some genius at Google, Android doesn't support DHCPv6.
I'm not using anything. The router belongs to the ISP, they do the configuration and the choices. I have no idea what it does or how. I know my phone gets IPv6, both on WiFi or GSM.
Ok, I can find my own router address doing a traceroute6 to google or any outside address. The first line. Huh, will that be the external or the internal address of it?
Routers often use link local addresses.
Which can not be used in commands. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-17 21:48, Carlos E.R. wrote:
You can configure your computer to prefer IPv4 or IPv6
After two decades of configuration, I don't remember what this machine is configured for. This moment I'm past bed time, so I don't remember where to check, either.
It depends on the OS. Do a Google search. I've never bothered with it, as it normally defaults to IPv6, which is what I prefer.
Ha! And which is the name of my computer? 😂
HAL, isn't it? 😉 Put in your DNS. If you don't have one, use the /etc/hosts file.
I can not make the computers respond on IPv6 to names unless I write them myself in the hosts file or the DNS file, and I can not write them because they are dynamic.
One of those two addresses you mentioned is persistent. That's the one you use. My IPv6 prefix has been steady for over 4 years. If your ISP did things right, the address shouldn't be changing.
I'm not using anything. The router belongs to the ISP, they do the configuration and the choices. I have no idea what it does or how.
If you're familiar with Wireshark, you can easily find out which they configured. GSM??? Is that still available in Spain? In North America, even 3G is disappearing. Does your phone also have a crank on the side? 😉
Routers often use link local addresses.
Which can not be used in commands.
ping -I eth0 fe80::4262:31ff:fe12:b66c
They can, but you also have to specify which interface it's connected to. Here's an example, where I ping my my firewall/router: ping: Warning: source address might be selected on device other than: eth0 PING fe80::4262:31ff:fe12:b66c(fe80::4262:31ff:fe12:b66c) from :: eth0: 56 data bytes 64 bytes from fe80::4262:31ff:fe12:b66c%eth0: icmp_seq=1 ttl=64 time=0.142 ms 64 bytes from fe80::4262:31ff:fe12:b66c%eth0: icmp_seq=2 ttl=64 time=0.149 ms 64 bytes from fe80::4262:31ff:fe12:b66c%eth0: icmp_seq=3 ttl=64 time=0.129 ms
On 2023-04-18 04:16, James Knott wrote:
On 2023-04-17 21:48, Carlos E.R. wrote:
You can configure your computer to prefer IPv4 or IPv6
After two decades of configuration, I don't remember what this machine is configured for. This moment I'm past bed time, so I don't remember where to check, either.
It depends on the OS. Do a Google search. I've never bothered with it, as it normally defaults to IPv6, which is what I prefer.
Ha! And which is the name of my computer? 😂
HAL, isn't it? 😉 Put in your DNS. If you don't have one, use the /etc/hosts file.
I can not make the computers respond on IPv6 to names unless I write them myself in the hosts file or the DNS file, and I can not write them because they are dynamic.
One of those two addresses you mentioned is persistent. That's the one you use. My IPv6 prefix has been steady for over 4 years. If your ISP did things right, the address shouldn't be changing.
No, they are not. One, the ISP said they would not give persistent addresses. Two, the "ip addr" says they are temporary. See the command output in my first command. inet6 2a02:9140:.../64 scope global temporary *dynamic* valid_lft 86398sec preferred_lft 62571sec inet6 2a02:9140:.../64 scope global *dynamic* mngtmpaddr valid_lft 86398sec preferred_lft 86398sec
I'm not using anything. The router belongs to the ISP, they do the configuration and the choices. I have no idea what it does or how.
If you're familiar with Wireshark, you can easily find out which they configured.
GSM??? Is that still available in Spain? In North America, even 3G is disappearing. Does your phone also have a crank on the side? 😉
GRRR. Change GSM to the actual name.
Routers often use link local addresses.
Which can not be used in commands.
They can, but you also have to specify which interface it's connected to. Here's an example, where I ping my my firewall/router:
So, they can't, they are a pain. Firefox refuses to use them. Known old bug.
ping -I eth0 fe80::4262:31ff:fe12:b66c ping: Warning: source address might be selected on device other than: eth0 PING fe80::4262:31ff:fe12:b66c(fe80::4262:31ff:fe12:b66c) from :: eth0: 56 data bytes 64 bytes from fe80::4262:31ff:fe12:b66c%eth0: icmp_seq=1 ttl=64 time=0.142 ms 64 bytes from fe80::4262:31ff:fe12:b66c%eth0: icmp_seq=2 ttl=64 time=0.149 ms 64 bytes from fe80::4262:31ff:fe12:b66c%eth0: icmp_seq=3 ttl=64 time=0.129 ms
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 04:12, Carlos E. R. wrote:
One, the ISP said they would not give persistent addresses.
The more I talk to you the more I get the impression Spanish ISPs are deliberately incompetent.
Two, the "ip addr" says they are temporary. See the command output in my first command.
inet6 2a02:9140:.../64 scope global temporary *dynamic* valid_lft 86398sec preferred_lft 62571sec inet6 2a02:9140:.../64 scope global *dynamic* mngtmpaddr valid_lft 86398sec preferred_lft 86398sec
I get similar. If the computer has been up for more than a day, you should also start seeing "deprecated". Those are the temporary privacy addresses that have been replaced by newer ones.
So, they can't, they are a pain. Firefox refuses to use them. Known old bug.
Again, why bother? You're causing problems for yourself. Use DNS.
On 2023-04-18 14:34, James Knott wrote:
On 2023-04-18 04:12, Carlos E. R. wrote:
One, the ISP said they would not give persistent addresses.
The more I talk to you the more I get the impression Spanish ISPs are deliberately incompetent.
Oh, they are very competent in sucking all the money they can get from us :-/
Two, the "ip addr" says they are temporary. See the command output in my first command.
inet6 2a02:9140:.../64 scope global temporary *dynamic* valid_lft 86398sec preferred_lft 62571sec inet6 2a02:9140:.../64 scope global *dynamic* mngtmpaddr valid_lft 86398sec preferred_lft 86398sec
I get similar. If the computer has been up for more than a day, you should also start seeing "deprecated". Those are the temporary privacy addresses that have been replaced by newer ones.
Right, I realized this later.
So, they can't, they are a pain. Firefox refuses to use them. Known old bug.
Again, why bother? You're causing problems for yourself. Use DNS.
LOL. How? I am supposed to write the addresses of my local machines into my internal only DNS server, or the /etc/hosts file. HOW? They are dynamic addresses, they change. At least the prefix changes. The postfixes, one is temporary, so it is out, the other is fixed (concocted from the MAC, I think). How on earth can I arrange to write into the DNS server the actual IPv6 addresses of all my machines, if they are not fixed? Or you mean an external DNS server? Then what address do I write there for accessing my home server? It could be the IPv6 address of my server itself. Maybe not, the router firewall blocks it. Then it has to be the external IPv6 address of my router, which will do some virtual addressing trick, same as it does for IPv4, and send to the internal server. Huh? -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 08:57, Carlos E. R. wrote:
LOL. How?
I am supposed to write the addresses of my local machines into my internal only DNS server, or the /etc/hosts file.
HOW?
They are dynamic addresses, they change. At least the prefix changes. The postfixes, one is temporary, so it is out, the other is fixed (concocted from the MAC, I think).
How on earth can I arrange to write into the DNS server the actual IPv6 addresses of all my machines, if they are not fixed?
Or you mean an external DNS server?
Then what address do I write there for accessing my home server? It could be the IPv6 address of my server itself. Maybe not, the router firewall blocks it.
Then it has to be the external IPv6 address of my router, which will do some virtual addressing trick, same as it does for IPv4, and send to the internal server. Huh?
Let me start by describing what I have here. I have both an external DNS for when I want to access my network from elsewhere and an internal DNS on my firewall/router. While I have a consistent prefix and could put my global addresses in my local DNS, I instead enabled Unique Local Addresses and use those within my LAN. If your prefix changes, then you will have to enable ULA and use those addresses in your local DNS. If you don't have a local DNS, then you can use the hosts file. I assume you also have IPv4 addresses working, which could be used if needed.
Carlos E.R. wrote:
On 2023-04-18 03:02, James Knott wrote:
On 2023-04-17 17:52, Carlos E. R. wrote:
Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this. [more info]
→https://test-ipv6.com/index.html.en_US#found
I don't understand this. Meaning, what can I do to make firefox use IPv6 and why exactly it doesn't?
You can configure your computer to prefer IPv4 or IPv6
After two decades of configuration, I don't remember what this machine is configured for. This moment I'm past bed time, so I don't remember where to check, either.
/etc/gai.conf The default is to prefer ipv6.
Routers often use link local addresses.
Which can not be used in commands.
Of course they can. They are perfectly valid IPv6 addresses. -- Per Jessen, Zürich (9.0°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 07:24, Per Jessen wrote:
Carlos E.R. wrote:
On 2023-04-18 03:02, James Knott wrote:
On 2023-04-17 17:52, Carlos E. R. wrote:
Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this. [more info]
→https://test-ipv6.com/index.html.en_US#found
I don't understand this. Meaning, what can I do to make firefox use IPv6 and why exactly it doesn't?
You can configure your computer to prefer IPv4 or IPv6
After two decades of configuration, I don't remember what this machine is configured for. This moment I'm past bed time, so I don't remember where to check, either.
/etc/gai.conf
The default is to prefer ipv6.
Telcontar:~ # cat /etc/gai.conf | egrep -v "^[[:space:]]*$|^#" precedence ::ffff:0:0/96 100 Telcontar:~ # Ok, then it is all on defaults.
Routers often use link local addresses.
Which can not be used in commands.
Of course they can. They are perfectly valid IPv6 addresses.
Firefox refuses to accept them. Old bug. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Tue, Apr 18, 2023 at 11:14 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
Routers often use link local addresses.
Which can not be used in commands.
Of course they can. They are perfectly valid IPv6 addresses.
Firefox refuses to accept them. Old bug.
a) You never said anything about Firefox before that. Apparently, when you say "commands" we all have to read "Firefox". b) You never showed any example of a command that fails with the actual address you used. While you have been shown the example of a command that correctly works with IPv6 LL address.
On 2023-04-18 10:20, Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 11:14 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
Routers often use link local addresses.
Which can not be used in commands.
Of course they can. They are perfectly valid IPv6 addresses.
Firefox refuses to accept them. Old bug.
a) You never said anything about Firefox before that. Apparently, when you say "commands" we all have to read "Firefox". b) You never showed any example of a command that fails with the actual address you used. While you have been shown the example of a command that correctly works with IPv6 LL address.
I said firefox as an example. Yes, I know that ping works with a different syntax, that is a pain. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
Yes, I know that ping works with a different syntax, that is a pain.
Hmm, here the syntax is exactly the same: ping office38.local.net "ping" defaults to ipv6 for hosts with ipv6 addresses, but you can of course force it to ipv4 / ipv6 with -4 / -6 -- Per Jessen, Zürich (12.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Tue, Apr 18, 2023 at 11:54 AM Per Jessen <per@opensuse.org> wrote:
Carlos E. R. wrote:
Yes, I know that ping works with a different syntax, that is a pain.
Hmm, here the syntax is exactly the same:
ping office38.local.net
"ping" defaults to ipv6 for hosts with ipv6 addresses, but you can of course force it to ipv4 / ipv6 with -4 / -6
It is all about link local addresses which is a limitation of glibc (and using scoped IPv6 literal in the browser address bar is not supported by current RFCs). https://unix.stackexchange.com/questions/174767/ipv6-scope-id-in-etc-hosts https://sourceware.org/bugzilla/show_bug.cgi?id=14413 https://bugzilla.mozilla.org/show_bug.cgi?id=700999
On 18.04.2023 00:52, Carlos E. R. wrote:
Hi,
I asked to participate in a beta testing of deployment of IPv6 by my ISP, Telefónica. After many weeks, they mailed me to say they would activate it today.
And yes, my machines are getting, besides the IPv4 local address, two _dynamic_ IPv6 addresses.
Why two, what's the difference?
Telcontar:~ # ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:d8:... altname enp34s0 inet 192.168.1.14/16 brd 192.168.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a02:9140:1180:0:634a:...:...:.../64 scope global temporary dynamic valid_lft 86397sec preferred_lft 80397sec inet6 2a02:9140:1180:0:2d8:..:...:.../64 scope global dynamic mngtmpaddr valid_lft 86397sec preferred_lft 86397sec inet6 fe80::2d8:...:...:.../64 scope link valid_lft forever preferred_lft forever Telcontar:~ #
One address is permanent, another one is temporary which is changed by kernel periodically. Kernel will prefer temporary address for outgoing connection.
The site <https://test-ipv6.com/> confirms. It says, though, that:
Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this. [more info]
→ https://test-ipv6.com/index.html.en_US#found
I don't understand this. Meaning, what can I do to make firefox use IPv6 and why exactly it doesn't?
There could be multiple reasons, one that IPv4 is faster than IPv6 in your case.
If I point firefox to my IPv6 address, it instead asks google to search for that text.
I asked google:
https://support.mozilla.org/en-US/questions/1111992
How to type ipv6-address and port number in URL bar?
which does not apply, it is about link-local addresses, and mine are not. Finally I found that the syntax is:
http://[2a02:9140:...]:port/path/
and it does work :-)
Using IP addresses will not work for HTTPS (both IPv4 and IPv6).
The route has not changed:
Isengard:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router.valinor 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 Isengard:~ #
Should it have also an IPv6 entry?
Yes if you use the correct command to look for it. Did you try to read man page?
I must try another machine that uses only DHCP.
I have no idea which is the IPv6 address of the router or how to find it. Maybe "fe80::8626:2bff:fe6e:c571", but a ping6 to it fails. Ok, finally found one, 2a02:...:75b5... but that IP can change every day, I can not put that in my hosts file.
Ok, I can find my own router address doing a traceroute6 to google or any outside address. The first line. Huh, will that be the external or the internal address of it?
This will be address that your system is using as next hop.
On 2023-04-18 06:18, Andrei Borzenkov wrote:
On 18.04.2023 00:52, Carlos E. R. wrote:
Hi,
I asked to participate in a beta testing of deployment of IPv6 by my ISP, Telefónica. After many weeks, they mailed me to say they would activate it today.
And yes, my machines are getting, besides the IPv4 local address, two _dynamic_ IPv6 addresses.
Why two, what's the difference?
Telcontar:~ # ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:d8:... altname enp34s0 inet 192.168.1.14/16 brd 192.168.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a02:9140:1180:0:634a:...:...:.../64 scope global temporary dynamic valid_lft 86397sec preferred_lft 80397sec inet6 2a02:9140:1180:0:2d8:..:...:.../64 scope global dynamic mngtmpaddr valid_lft 86397sec preferred_lft 86397sec inet6 fe80::2d8:...:...:.../64 scope link valid_lft forever preferred_lft forever Telcontar:~ #
One address is permanent, another one is temporary which is changed by kernel periodically. Kernel will prefer temporary address for outgoing connection.
Ah. I see. But both change, the ISP changes it. It is a promise they did :-/
The site <https://test-ipv6.com/> confirms. It says, though, that:
Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this. [more info]
→ https://test-ipv6.com/index.html.en_US#found
I don't understand this. Meaning, what can I do to make firefox use IPv6 and why exactly it doesn't?
There could be multiple reasons, one that IPv4 is faster than IPv6 in your case.
Hum. I have a problem with my router: pings to it experiment a 10..40% random loss. It is the router fault, the previous incumbent worked fine. It just doesn't like my switch. Technician gave up. This causes a delay in all firefox connections to outside, packets have to retry.
If I point firefox to my IPv6 address, it instead asks google to search for that text.
I asked google:
https://support.mozilla.org/en-US/questions/1111992
How to type ipv6-address and port number in URL bar?
which does not apply, it is about link-local addresses, and mine are not. Finally I found that the syntax is:
http://[2a02:9140:...]:port/path/
and it does work :-)
Using IP addresses will not work for HTTPS (both IPv4 and IPv6).
Oh, did not know that.
The route has not changed:
Isengard:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router.valinor 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 Isengard:~ #
Should it have also an IPv6 entry?
Yes if you use the correct command to look for it. Did you try to read man page?
Not today :-D Did not occur to me that it would be another program. Today I know.
I must try another machine that uses only DHCP.
I have no idea which is the IPv6 address of the router or how to find it. Maybe "fe80::8626:2bff:fe6e:c571", but a ping6 to it fails. Ok, finally found one, 2a02:...:75b5... but that IP can change every day, I can not put that in my hosts file.
Ok, I can find my own router address doing a traceroute6 to google or any outside address. The first line. Huh, will that be the external or the internal address of it?
This will be address that your system is using as next hop.
Right... -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Tue, Apr 18, 2023 at 11:26 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
Why two, what's the difference?
Telcontar:~ # ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:d8:... altname enp34s0 inet 192.168.1.14/16 brd 192.168.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a02:9140:1180:0:634a:...:...:.../64 scope global temporary dynamic valid_lft 86397sec preferred_lft 80397sec inet6 2a02:9140:1180:0:2d8:..:...:.../64 scope global dynamic mngtmpaddr valid_lft 86397sec preferred_lft 86397sec inet6 fe80::2d8:...:...:.../64 scope link valid_lft forever preferred_lft forever Telcontar:~ #
One address is permanent, another one is temporary which is changed by kernel periodically. Kernel will prefer temporary address for outgoing connection.
Ah. I see.
But both change, the ISP changes it. It is a promise they did :-/
"permanent" vs "temporary" has nothing to do with ISP. It refers to a 64 bit interface identifier which is used to form a full IPv6 address and is managed by your system (user space, kernel or both). What happens to the prefix which is managed by the router (and finally by your ISP in this case) is out of scope here.
On 2023-04-18 10:34, Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 11:26 AM Carlos E. R. <> wrote:
Why two, what's the difference?
Telcontar:~ # ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:d8:... altname enp34s0 inet 192.168.1.14/16 brd 192.168.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a02:9140:1180:0:634a:...:...:.../64 scope global temporary dynamic valid_lft 86397sec preferred_lft 80397sec inet6 2a02:9140:1180:0:2d8:..:...:.../64 scope global dynamic mngtmpaddr valid_lft 86397sec preferred_lft 86397sec inet6 fe80::2d8:...:...:.../64 scope link valid_lft forever preferred_lft forever Telcontar:~ #
One address is permanent, another one is temporary which is changed by kernel periodically. Kernel will prefer temporary address for outgoing connection.
Ah. I see.
But both change, the ISP changes it. It is a promise they did :-/
"permanent" vs "temporary" has nothing to do with ISP. It refers to a 64 bit interface identifier which is used to form a full IPv6 address and is managed by your system (user space, kernel or both). What happens to the prefix which is managed by the router (and finally by your ISP in this case) is out of scope here.
Ok, understood. But a problem for me is that the ISP changes the prefix, it is "dynamic". Being the first time I actually see IPv6, I confuse the terms. That the prefix changes means that I can not write entries in my hosts or dns files to use names instead (for IPv6). -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Tue, Apr 18, 2023 at 12:44 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
But a problem for me is that the ISP changes the prefix, it is "dynamic". Being the first time I actually see IPv6, I confuse the terms.
That the prefix changes means that I can not write entries in my hosts or dns files to use names instead (for IPv6).
And how is it different from IPv4? Either you pay your ISP for a fixed address (in this case fixed prefix) or you use dynamic DNS to associate current address with permanent name.
On 2023-04-18 12:37, Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 12:44 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
But a problem for me is that the ISP changes the prefix, it is "dynamic". Being the first time I actually see IPv6, I confuse the terms.
That the prefix changes means that I can not write entries in my hosts or dns files to use names instead (for IPv6).
And how is it different from IPv4? Either you pay your ISP for a fixed address (in this case fixed prefix) or you use dynamic DNS to associate current address with permanent name.
Well, it is an artificial scheme to get money from clients. With IPv4 the excuse was they didn't have one address for everybody. No such excuse now. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Tue, Apr 18, 2023 at 3:33 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
And how is it different from IPv4? Either you pay your ISP for a fixed address (in this case fixed prefix) or you use dynamic DNS to associate current address with permanent name.
Well, it is an artificial scheme to get money from clients. With IPv4 the excuse was they didn't have one address for everybody. No such excuse now.
And how bitching on this list is going to change it?
On 2023-04-18 14:35, Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 3:33 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
And how is it different from IPv4? Either you pay your ISP for a fixed address (in this case fixed prefix) or you use dynamic DNS to associate current address with permanent name.
Well, it is an artificial scheme to get money from clients. With IPv4 the excuse was they didn't have one address for everybody. No such excuse now.
And how bitching on this list is going to change it?
I know it is not going to change. I'm just commenting how it is. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 06:37, Andrei Borzenkov wrote:
That the prefix changes means that I can not write entries in my hosts or dns files to use names instead (for IPv6).
And how is it different from IPv4? Either you pay your ISP for a fixed address (in this case fixed prefix) or you use dynamic DNS to associate current address with permanent name.
My prefix hasn't changed in over 4 years. In fact, it has survived replacing, at different times, both the modem and the computer I run my firewall on. Then again neither has my IPv4 address changed since I replaced my firewall computer. Given the immense IPv6 address space, there is no reason for an ISP to change a prefix other than being nasty.
On 2023-04-18 05:44, Carlos E. R. wrote:
But a problem for me is that the ISP changes the prefix, it is "dynamic". Being the first time I actually see IPv6, I confuse the terms.
That the prefix changes means that I can not write entries in my hosts or dns files to use names instead (for IPv6).
See if you can configure Unique Local Addresses (ULA). Those are the IPv6 equivalent of RFC 1918 addresses on IPv4. Even if your router doesn't support it, you should be able to configure openSUSE to provide them.
On 2023-04-18 14:47, James Knott wrote:
On 2023-04-18 05:44, Carlos E. R. wrote:
But a problem for me is that the ISP changes the prefix, it is "dynamic". Being the first time I actually see IPv6, I confuse the terms.
That the prefix changes means that I can not write entries in my hosts or dns files to use names instead (for IPv6).
See if you can configure Unique Local Addresses (ULA). Those are the IPv6 equivalent of RFC 1918 addresses on IPv4. Even if your router doesn't support it, you should be able to configure openSUSE to provide them.
Do you know of a help text on that? I guess I can, but I do not see the benefit. I can access all my machines by name using IPv4, internally. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 09:02, Carlos E. R. wrote:
See if you can configure Unique Local Addresses (ULA). Those are the IPv6 equivalent of RFC 1918 addresses on IPv4. Even if your router doesn't support it, you should be able to configure openSUSE to provide them.
Do you know of a help text on that?
I haven't done that on openSUSE, but I have on my pfSense firewall. Here's the info. https://forum.netgate.com/topic/163161/using-unique-local-addresses?_=162152... When I was using openSUSE for my firewall/router, I was using a tunnel and it provided SLAAC to my network. I had to move to pfSense when my ISP started providing native IPv6, as openSUSE didn't support DHCPv6-PD, which is what provides the prefix to my network. To enable ULA, you'd have to configure openSUSE with a static prefix within the ULA range. I used a 6in4 tunnel for almost 6 years and native IPv6 for over 7.
On 2023-04-18 15:11, James Knott wrote:
On 2023-04-18 09:02, Carlos E. R. wrote:
See if you can configure Unique Local Addresses (ULA). Those are the IPv6 equivalent of RFC 1918 addresses on IPv4. Even if your router doesn't support it, you should be able to configure openSUSE to provide them.
Do you know of a help text on that?
I haven't done that on openSUSE, but I have on my pfSense firewall. Here's the info. https://forum.netgate.com/topic/163161/using-unique-local-addresses?_=162152...
I see. Oh, I only wanted to understand what those addresses were, generically. I can not change the router. To do something similar, I would have to assign that address inside each machine, statically, and then write DNS entries. That's too much a chore for no advantage, as I can currently reach all my machines by name with IPv4. Well, most machines. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 14:01, Carlos E. R. wrote:
I haven't done that on openSUSE, but I have on my pfSense firewall. Here's the info. https://forum.netgate.com/topic/163161/using-unique-local-addresses?_=162152...
I see. Oh, I only wanted to understand what those addresses were, generically. I can not change the router.
To do something similar, I would have to assign that address inside each machine, statically, and then write DNS entries. That's too much a chore for no advantage, as I can currently reach all my machines by name with IPv4. Well, most machines.
One thing you'll learn about IPv6 is you can have a LOT of addresses on a device. For example, with SLAAC, you have a link local address, a persistent global address and up to 7 temporary addresses. If you add ULA, that's another 8 and if you have more than one router, then you can have up to 8 more addresses, for each router that's on the network. You can even give routers priority. All kinds of fun things. You might want to check if you can provide ULA from your modem. They can be useful, in cases where you don't have a persistent prefix. You can also set up a network for something like IoT, where you don't want access to the Internet and more. If you want to learn about IPv6, I can recommend this book: https://www.oreilly.com/library/view/ipv6-essentials-3rd/9781449335229/
On 2023-04-18 20:11, James Knott wrote:
On 2023-04-18 14:01, Carlos E. R. wrote:
I haven't done that on openSUSE, but I have on my pfSense firewall. Here's the info. https://forum.netgate.com/topic/163161/using-unique-local-addresses?_=162152...
I see. Oh, I only wanted to understand what those addresses were, generically. I can not change the router.
To do something similar, I would have to assign that address inside each machine, statically, and then write DNS entries. That's too much a chore for no advantage, as I can currently reach all my machines by name with IPv4. Well, most machines.
One thing you'll learn about IPv6 is you can have a LOT of addresses on a device. For example, with SLAAC, you have a link local address, a persistent global address and up to 7 temporary addresses. If you add ULA, that's another 8 and if you have more than one router, then you can have up to 8 more addresses, for each router that's on the network. You can even give routers priority. All kinds of fun things.
You might want to check if you can provide ULA from your modem.
No. I can only assign 32 IPv4 addresses to 32 machines. They call this "static IP lease".
They can be useful, in cases where you don't have a persistent prefix. You can also set up a network for something like IoT, where you don't want access to the Internet and more.
If you want to learn about IPv6, I can recommend this book: https://www.oreilly.com/library/view/ipv6-essentials-3rd/9781449335229/
Thanks. I rather need a guide on how to cope with Spanish providers. >:-) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023/4/19 02:11, James Knott wrote:
ULA, that's another 8 and if you have more than one router, then you can have up to 8 more addresses, for each router that's on the network. You can even give routers priority. All kinds of fun things.
Multiple routers ! Interesting topic. How the device handling the default gateway ? For example, if my device got a IPv6-address-A and gateway-A from the router-A. It also got another IPv6-address-B and gateway-B from the router-B. When my device try to connect to an internet site, it can choose IPV6-address-A or IPv6-address-B. Assume it chose the IPV6-address-A this time, then how the kernel knows it should go through the gateway-A and not the gateway-B ?
On 2023-04-19 10:08, Nohk Two wrote:
Multiple routers ! Interesting topic.
How the device handling the default gateway ?
For example, if my device got a IPv6-address-A and gateway-A from the router-A. It also got another IPv6-address-B and gateway-B from the router-B.
When my device try to connect to an internet site, it can choose IPV6-address-A or IPv6-address-B. Assume it chose the IPV6-address-A this time, then how the kernel knows it should go through the gateway-A and not the gateway-B ?
There's a preference field in the router advertisement and a setting in the router for priority. The device will go with the highest priority router. Should that router fail, then another will be used. I suspect this would be more useful in networks where routing protocols are used to determine best route, as then the same prefix would be used. If you simply had 2 ISPs, with different prefixes, then that might cause some issues if a router failed in the middle of a connection.
On 2023/4/19 22:19, James Knott wrote:
On 2023-04-19 10:08, Nohk Two wrote:
Multiple routers ! Interesting topic.
How the device handling the default gateway ?
For example, if my device got a IPv6-address-A and gateway-A from the router-A. It also got another IPv6-address-B and gateway-B from the router-B.
When my device try to connect to an internet site, it can choose IPV6-address-A or IPv6-address-B. Assume it chose the IPV6-address-A this time, then how the kernel knows it should go through the gateway-A and not the gateway-B ?
There's a preference field in the router advertisement and a setting in the router for priority. The device will go with the highest priority router. Should that router fail, then another will be used. I suspect It's true. I just found that there is a "pref medium" showed in the command `ip -6 route show`
this would be more useful in networks where routing protocols are used to determine best route, as then the same prefix would be used. If you simply had 2 ISPs, with different prefixes, then that might cause some issues if a router failed in the middle of a connection.
In my case, I have 2 routers but the same ISP and same modem. My ISP allows limited multiple PPPoE sessions per account. I just enabled the IPv6 in a router (router-A) and leave another router (router-B) IPV4-only. If I could understand this default gateway problem, I could decide to enable the second router's IPv6 or not. I had, for short experiment, enabled the IPv6 on the second router but disable all configuration mechanisms to its LAN to avoid messing up my network. And I found the routers' IPv6 prefixes are different on these two routers. I'm not sure whether I understand your words correctly. Is that bad idea for my case that to enable the IPv6 on both routers ? Because they have different IPv6 prefixes. But they are the same ISP. I thought that IPv6-address-A must go through router-A to reach the internet and IPv6-address-B must go through router-B to reach the internet. Maybe I'm wrong.
On 2023-04-19 11:50, Nohk Two wrote:
I'm not sure whether I understand your words correctly. Is that bad idea for my case that to enable the IPv6 on both routers ? Because they have different IPv6 prefixes. But they are the same ISP.
I thought that IPv6-address-A must go through router-A to reach the internet and IPv6-address-B must go through router-B to reach the internet. Maybe I'm wrong.
Large organizations, instead of using an ISP, will arrange for their own autonomous system, where they have their own block of addresses. They can then arrange for more than one connection to the Internet, perhaps through 2 telecoms. They then use a routing protocol, such as OSPF or BGP to advertise their network to the world, which enables routing to them. In this situation, they could have a primary connection, with higher priority and a secondary connection with lower priority. There are 3 priority levels available. Then, if the primary connection fails, the secondary one will be used. If you are using 2 ISPs, each with their own addresses, then you will have the situation you describe, with 2 addresses.
On 2023/4/20 00:00, James Knott wrote:
On 2023-04-19 11:50, Nohk Two wrote:
I'm not sure whether I understand your words correctly. Is that bad idea for my case that to enable the IPv6 on both routers ? Because they have different IPv6 prefixes. But they are the same ISP.
I thought that IPv6-address-A must go through router-A to reach the internet and IPv6-address-B must go through router-B to reach the internet. Maybe I'm wrong.
Large organizations, instead of using an ISP, will arrange for their own autonomous system, where they have their own block of addresses. They can then arrange for more than one connection to the Internet, perhaps through 2 telecoms. They then use a routing protocol, such as OSPF or BGP to advertise their network to the world, which enables routing to them. In this situation, they could have a primary connection, with higher priority and a secondary connection with lower priority. There are 3 priority levels available. Then, if the primary connection fails, the secondary one will be used.
If you are using 2 ISPs, each with their own addresses, then you will have the situation you describe, with 2 addresses.
I got it now. I learned many today. Thank you very much !!
James Knott wrote:
On 2023-04-19 11:50, Nohk Two wrote:
I'm not sure whether I understand your words correctly. Is that bad idea for my case that to enable the IPv6 on both routers ? Because they have different IPv6 prefixes. But they are the same ISP.
I thought that IPv6-address-A must go through router-A to reach the internet and IPv6-address-B must go through router-B to reach the internet. Maybe I'm wrong.
Large organizations, instead of using an ISP, will arrange for their own autonomous system, where they have their own block of addresses.
Even smaller organisation can have their own ranges, but may still use an uplink ISP for routing. My company does. -- Per Jessen, Zürich (12.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 04:26, Carlos E. R. wrote:
But both change, the ISP changes it. It is a promise they did :-/
If the ISP changes the prefix and you want consistent local addresses, you can use Unique Local Addresses (ULA). Since I don't know what you have, I can't advise you. However, with my cable modem, when in gateway mode, I would get both global and unique local addresses. With ULA, you create a /7 prefix, that is starting with fc or fd. You can use any 7 bit number for that.
Yes if you use the correct command to look for it. Did you try to read man page?
Not today 😂
man RTFM. 😉
On 2023-04-18 14:39, James Knott wrote:
On 2023-04-18 04:26, Carlos E. R. wrote:
But both change, the ISP changes it. It is a promise they did :-/
If the ISP changes the prefix and you want consistent local addresses, you can use Unique Local Addresses (ULA). Since I don't know what you have, I can't advise you. However, with my cable modem, when in gateway mode, I would get both global and unique local addresses. With ULA, you create a /7 prefix, that is starting with fc or fd. You can use any 7 bit number for that.
I have consistent local addresses, LAN only, using IPv4, and my internal DNS knows them. That works. I don't see the advantage replicating with IPv6. If the addresses are global, then yes, there may be some advantage. Or just because.
Yes if you use the correct command to look for it. Did you try to read man page?
Not today 😂
man RTFM. 😉
cer@Telcontar:~> man RTFM No manual entry for RTFM cer@Telcontar:~> :-P -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 15:17, James Knott wrote:
On 2023-04-18 09:05, Carlos E. R. wrote:
man RTFM. 😉
cer@Telcontar:~> man RTFM No manual entry for RTFM
It's a joke, son. 😉 man Read The F'n Manual
Yes, I know. So I wrote another joke, which this time failed. There was a smiley. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
And yes, my machines are getting, besides the IPv4 local address, two _dynamic_ IPv6 addresses. [snip] I don't understand this. Meaning, what can I do to make firefox use IPv6 and why exactly it doesn't?
Try this site - http://testipv6.hostsuisse.net Only reachable over IPV6. I believe Firefox uses "happy eyeballs" to determine whether to use ipv4 or ipv6. I think(!) it can be disabled in the config - look for "fast-fallback". -- Per Jessen, Zürich (9.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 07:49, Per Jessen wrote:
Carlos E. R. wrote:
And yes, my machines are getting, besides the IPv4 local address, two _dynamic_ IPv6 addresses. [snip] I don't understand this. Meaning, what can I do to make firefox use IPv6 and why exactly it doesn't?
Try this site - http://testipv6.hostsuisse.net
Works :-)
Only reachable over IPV6.
I believe Firefox uses "happy eyeballs" to determine whether to use ipv4 or ipv6. I think(!) it can be disabled in the config - look for "fast-fallback".
Will look later. Now I have to go. Thanks. Thanks all. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Hey Carlos, the first one says temporary, which should be an temporary address given by IPv6 privacy extension. This should be your global unique address known to the internet. The other address is your "real" IP address given to you by dhcp configuration from your ISP. have a lot of fun, Bernd Am 17.04.23 um 23:52 schrieb Carlos E. R.:
Hi,
I asked to participate in a beta testing of deployment of IPv6 by my ISP, Telefónica. After many weeks, they mailed me to say they would activate it today.
And yes, my machines are getting, besides the IPv4 local address, two _dynamic_ IPv6 addresses.
Why two, what's the difference?
Telcontar:~ # ip addr
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:d8:... altname enp34s0 inet 192.168.1.14/16 brd 192.168.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 2a02:9140:1180:0:634a:...:...:.../64 scope global temporary dynamic valid_lft 86397sec preferred_lft 80397sec inet6 2a02:9140:1180:0:2d8:..:...:.../64 scope global dynamic mngtmpaddr valid_lft 86397sec preferred_lft 86397sec inet6 fe80::2d8:...:...:.../64 scope link valid_lft forever preferred_lft forever Telcontar:~ #
The site <https://test-ipv6.com/> confirms. It says, though, that:
Your browser has real working IPv6 address - but is avoiding using it. We're concerned about this. [more info]
→ https://test-ipv6.com/index.html.en_US#found
I don't understand this. Meaning, what can I do to make firefox use IPv6 and why exactly it doesn't?
If I point firefox to my IPv6 address, it instead asks google to search for that text.
I asked google:
https://support.mozilla.org/en-US/questions/1111992
How to type ipv6-address and port number in URL bar?
which does not apply, it is about link-local addresses, and mine are not. Finally I found that the syntax is:
http://[2a02:9140:...]:port/path/
and it does work :-)
The route has not changed:
Isengard:~ # route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default router.valinor 0.0.0.0 UG 0 0 0 eth0 192.168.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0 Isengard:~ #
Should it have also an IPv6 entry?
I must try another machine that uses only DHCP.
I have no idea which is the IPv6 address of the router or how to find it. Maybe "fe80::8626:2bff:fe6e:c571", but a ping6 to it fails. Ok, finally found one, 2a02:...:75b5... but that IP can change every day, I can not put that in my hosts file.
Ok, I can find my own router address doing a traceroute6 to google or any outside address. The first line. Huh, will that be the external or the internal address of it?
-- Cheers
Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Tue, Apr 18, 2023 at 12:52 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
I have no idea which is the IPv6 address of the router or how to find it. Maybe "fe80::8626:2bff:fe6e:c571", but a ping6 to it fails. Ok, finally found one, 2a02:...:75b5... but that IP can change every day, I can not put that in my hosts file.
Why do you need to know the IPv6 address of your router in the first place? What are you going to do with it?
On 2023-04-18 09:47, Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 12:52 AM Carlos E. R. <robin.listas@telefonica.net> wrote:
I have no idea which is the IPv6 address of the router or how to find it. Maybe "fe80::8626:2bff:fe6e:c571", but a ping6 to it fails. Ok, finally found one, 2a02:...:75b5... but that IP can change every day, I can not put that in my hosts file.
Why do you need to know the IPv6 address of your router in the first place? What are you going to do with it?
pings, ssh, http... try to put it in hosts file... Specially pings. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
I have no idea which is the IPv6 address of the router or how to find it.
Maybe this will do the trick - ip -6 neigh | grep router Otherwise ip -6 neigh | grep mac-addr-of-router -- Per Jessen, Zürich (14.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 11:34, Per Jessen wrote:
Carlos E. R. wrote:
I have no idea which is the IPv6 address of the router or how to find it.
Maybe this will do the trick -
ip -6 neigh | grep router
Nah. Telcontar:~ # ip -6 neigh fe80::ceed:dcff:fe05:80d4 dev eth0 lladdr cc:ed:dc:05:80:d4 router STALE Telcontar:~ # Not the one I want. Where do you expect the word "router" to come from, from the DNS server? :-? Ah. Too early, just booted the machine. Telcontar:~ # traceroute6 google.es traceroute to google.es (2a00:1450:4003:80f::2003), 30 hops max, 80 byte packets 1 2a02:9140:... (2a02:9140:...) 6.273 ms 6.283 ms 6.286 ms 2 * * * 3 2a02:9002:400::6 (2a02:9002:400::6) 14.124 ms * 15.058 ms 4 2001:1498:1:75f::1 (2001:1498:1:75f::1) 19.412 ms 19.499 ms 19.581 ms 5 2001:4860:1:1::2036 (2001:4860:1:1::2036) 16.155 ms 2001:1498:1:81d::1 (2001:1498:1:81d::1) 21.405 ms 2001:4860:1:1::2036 (2001:4860:1:1::2036) 17.295 ms 6 2001:4860:0:1347::1 (2001:4860:0:1347::1) 17.193 ms 13.308 ms 2001:4860::12:0:ba2d (2001:4860::12:0:ba2d) 15.083 ms 7 * 2001:4860:0:1::5319 (2001:4860:0:1::5319) 12.052 ms 2001:4860:0:1::56e2 (2001:4860:0:1::56e2) 12.306 ms 8 mad41s14-in-x03.1e100.net (2a00:1450:4003:80f::2003) 13.654 ms 14.236 ms 14.952 ms Telcontar:~ # ip -6 neigh fe80::ceed:dcff:fe05:80d4 dev eth0 lladdr cc:ed:dc:05:80:d4 router STALE 2a02:9140:...:ceed:dcff:fe05:80d4 dev eth0 FAILED Telcontar:~ # Ok, so the router address is 2a02:9140:...:ceed:dcff:fe05:80d4. I found the correct address yesterday, with my convoluted method. That's today's address, the ISP "promised" to use dynamic prefixes. I run this from the server, 24*7: while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; \ fping -c 100 --quiet 2a02:...ceed:dcff:fe05:80d4 ; \ done Result: 2023-04-18T11:37:23+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.45/0.58/0.92 2023-04-18T11:39:04+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.39/0.69/5.99 2023-04-18T11:40:45+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.42/0.92/13.9 2023-04-18T11:42:26+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.45/0.80/18.8 2023-04-18T11:44:07+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.43/0.66/7.53 2023-04-18T11:45:48+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.43/0.59/1.39 2023-04-18T11:47:29+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.43/0.88/13.5 2023-04-18T11:49:10+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.42/0.75/4.31 2023-04-18T11:50:51+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.43/0.58/1.15 2023-04-18T11:52:33+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.42/0.97/7.59 2023-04-18T11:54:14+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.40/1.44/16.6 Notice the losses. Same as with IPv4.
Otherwise
ip -6 neigh | grep mac-addr-of-router
Ok... Now how do I find the mac of the router... Oh, yes, I see it. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
Telcontar:~ # ip -6 neigh fe80::ceed:dcff:fe05:80d4 dev eth0 lladdr cc:ed:dc:05:80:d4 router STALE Telcontar:~ #
Not the one I want.
Ah, I forgot, you wanted the external address, sorry.
Where do you expect the word "router" to come from, from the DNS server? :-?
No, it is a 'role' dished out with ICMPv6 RAs. Your router basically broadcasts its address as the router for the local network.
Ok, so the router address is 2a02:9140:...:ceed:dcff:fe05:80d4. I found the correct address yesterday, with my convoluted method.
That's today's address, the ISP "promised" to use dynamic prefixes.
Which isn't the same as a guaranteed change, I expect.
I run this from the server, 24*7:
while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; \ fping -c 100 --quiet 2a02:...ceed:dcff:fe05:80d4 ; \ done
Result:
2023-04-18T11:37:23+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.45/0.58/0.92 [snip]
Notice the losses. Same as with IPv4.
Try increasing the interval, the default is 10ms. -- Per Jessen, Zürich (14.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 12:22, Per Jessen wrote:
Carlos E. R. wrote:
Telcontar:~ # ip -6 neigh fe80::ceed:dcff:fe05:80d4 dev eth0 lladdr cc:ed:dc:05:80:d4 router STALE Telcontar:~ #
Not the one I want.
Ah, I forgot, you wanted the external address, sorry.
No, the internal. The external I can ask some web pages, and maybe the router itself.
Where do you expect the word "router" to come from, from the DNS server? :-?
No, it is a 'role' dished out with ICMPv6 RAs. Your router basically broadcasts its address as the router for the local network.
Ah.
Ok, so the router address is 2a02:9140:...:ceed:dcff:fe05:80d4. I found the correct address yesterday, with my convoluted method.
That's today's address, the ISP "promised" to use dynamic prefixes.
Which isn't the same as a guaranteed change, I expect.
Every time the rooter reboots, same as with IPv4. Intentionally.
I run this from the server, 24*7:
while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; \ fping -c 100 --quiet 2a02:...ceed:dcff:fe05:80d4 ; \ done
Result:
2023-04-18T11:37:23+02:00 2a02:...80d4 : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.45/0.58/0.92 [snip]
Notice the losses. Same as with IPv4.
Try increasing the interval, the default is 10ms.
Why? :-? It doesn't matter how I test the connection, the router loses packages coming from the switch. It works perfectly when connecting directly to it. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-18 12:22, Per Jessen wrote:
Carlos E. R. wrote:
Telcontar:~ # ip -6 neigh fe80::ceed:dcff:fe05:80d4 dev eth0 lladdr cc:ed:dc:05:80:d4 router STALE Telcontar:~ #
Not the one I want.
Ah, I forgot, you wanted the external address, sorry.
No, the internal.
I meant external as opposed to link-local. There is no more internal/external, your machines all have public ipv6 addresses.
The external I can ask some web pages, and maybe the router itself.
Yep, got it - you want the LAN side address of the router.
That's today's address, the ISP "promised" to use dynamic prefixes.
Which isn't the same as a guaranteed change, I expect.
Every time the rooter reboots, same as with IPv4.
Really? That is not how most providers do it.
Notice the losses. Same as with IPv4.
Try increasing the interval, the default is 10ms.
Why? :-?
To avoid having packets dropped. ICMPs may be dropped, they have the lowest priority. If you are flood pinging your network - which I suggest 100 pings per second is - some will be dropped. -- Per Jessen, Zürich (15.6°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Tue, Apr 18, 2023 at 5:23 PM Per Jessen <per@opensuse.org> wrote:
Yep, got it - you want the LAN side address of the router.
I still wonder why everyone talks about *router* address and what it has to do with IPv6 connectivity to *host* which has its own, completely separate, address.
Every time the rooter reboots, same as with IPv4.
Really? That is not how most providers do it.
Well, in my case the router does not reboot often, but the prefix does change, probably as often as every night (I forgot, I set up logging once to check and the prefix changed). And as the provider does not even support IPv6 officially (even though it works for a couple of years already), there is no way to request a permanent prefix, for love or money.
Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 5:23 PM Per Jessen <per@opensuse.org> wrote:
Yep, got it - you want the LAN side address of the router.
I still wonder why everyone talks about *router* address and what it has to do with IPv6 connectivity to *host* which has its own, completely separate, address.
Carlos wants to connect a browser to his internet router over ipv6, that's all I think. As a test perhaps?
Every time the rooter reboots, same as with IPv4.
Really? That is not how most providers do it.
Well, in my case the router does not reboot often, but the prefix does change, probably as often as every night (I forgot, I set up logging once to check and the prefix changed).
That's interesting, I wonder why they do that. Granted, I've never had a prefix allocated dynamically, I have always had fixed or my own, so I could be talking complete rubbish. -- Per Jessen, Zürich (15.1°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 10:44, Per Jessen wrote:
Well, in my case the router does not reboot often, but the prefix does change, probably as often as every night (I forgot, I set up logging once to check and the prefix changed). That's interesting, I wonder why they do that. Granted, I've never had a prefix allocated dynamically, I have always had fixed or my own, so I could be talking complete rubbish.
The prefix shouldn't change. There's a file called "duid" which the ISP uses to map a prefix to a user. As long as that doesn't change, the prefix shouldn't either. I've had my prefix for over 4 years and I have an ordinary user account. My prefix has survived, at different times, replacing both the modem and the computer I run pfSense on. When I replaced the computer, a couple of years ago, I just copied the config.xml file from the old computer to the new. I only had to adjust the interface names and I was up & running again with the same prefix.
James Knott wrote:
On 2023-04-18 10:44, Per Jessen wrote:
Well, in my case the router does not reboot often, but the prefix does change, probably as often as every night (I forgot, I set up logging once to check and the prefix changed). That's interesting, I wonder why they do that. Granted, I've never had a prefix allocated dynamically, I have always had fixed or my own, so I could be talking complete rubbish.
The prefix shouldn't change. There's a file called "duid" which the ISP uses to map a prefix to a user. As long as that doesn't change, the prefix shouldn't either.
Yes, that's what I _thought_ too. The duid is also used when allocating a fixed address with dhcp. -- Per Jessen, Zürich (16.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 16:44, Per Jessen wrote:
Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 5:23 PM Per Jessen <per@opensuse.org> wrote:
Yep, got it - you want the LAN side address of the router.
I still wonder why everyone talks about *router* address and what it has to do with IPv6 connectivity to *host* which has its own, completely separate, address.
Carlos wants to connect a browser to his internet router over ipv6, that's all I think. As a test perhaps?
Yes, the connectivity ping test, to find out if I loose fewer packages on IPv6. I don't.
Every time the rooter reboots, same as with IPv4.
Really? That is not how most providers do it.
Well, in my case the router does not reboot often, but the prefix does change, probably as often as every night (I forgot, I set up logging once to check and the prefix changed).
That's interesting, I wonder why they do that. Granted, I've never had a prefix allocated dynamically, I have always had fixed or my own, so I could be talking complete rubbish.
Common sense says fixed prefix. Commercial dumb sense, says charge extra for it (they don't offer it - yet?) -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-18 16:44, Per Jessen wrote:
Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 5:23 PM Per Jessen <per@opensuse.org> wrote:
Yep, got it - you want the LAN side address of the router.
I still wonder why everyone talks about *router* address and what it has to do with IPv6 connectivity to *host* which has its own, completely separate, address.
Carlos wants to connect a browser to his internet router over ipv6, that's all I think. As a test perhaps?
Yes, the connectivity ping test, to find out if I loose fewer packages on IPv6. I don't.
Stop flooding your network :-) I would look at your general stats, not the ones you provoke. ip -s link show -- Per Jessen, Zürich (10.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday, 2023-04-18 at 21:02 +0200, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-18 16:44, Per Jessen wrote:
Andrei Borzenkov wrote:
On Tue, Apr 18, 2023 at 5:23 PM Per Jessen <per@opensuse.org> wrote:
Yep, got it - you want the LAN side address of the router.
I still wonder why everyone talks about *router* address and what it has to do with IPv6 connectivity to *host* which has its own, completely separate, address.
Carlos wants to connect a browser to his internet router over ipv6, that's all I think. As a test perhaps?
Yes, the connectivity ping test, to find out if I loose fewer packages on IPv6. I don't.
Stop flooding your network :-)
Internet Web is slow to load, with my testing stopped. This is a powerful machine. I have fast fibre. If you know of an external web site that measures page load time, for a small page, I can measure that.
I would look at your general stats, not the ones you provoke.
ip -s link show
Isengard: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 4c:cc:6a:61:50:a1 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 23406734220 16321239 0 5700 9849 79742 TX: bytes packets errors dropped carrier collsns 693306794 4560203 0 0 0 0 altname enp3s0 telcontar: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:d8:61:a1:5a:bd brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 1713292131 5141166 0 2838 0 73508 TX: bytes packets errors dropped carrier collsns 23220931044 16206762 0 0 0 0 altname enp34s0 Now you help me interpret that, I'm not familiar with it, but I see "dropped" and "missed" stats. Both machines are connected to the sw2. There is no connectivity problem with them: Telcontar:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 100 --quiet --interval=1 isengard ; done 2023-04-18T21:13:04+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.10/0.15/0.28 2023-04-18T21:14:44+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.08/0.14/0.23 2023-04-18T21:16:24+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.09/0.15/0.26 2023-04-18T21:18:04+02:00 ^Cisengard : xmt/rcv/%loss = 45/45/0%, min/avg/max = 0.08/0.15/0.29 2023-04-18T21:18:49+02:00 ^Cisengard : xmt/rcv/%loss = 1/1/0%, min/avg/max = 0.14/0.14/0.14 ^C Telcontar:~ # The problem is ONLY with the router (means internet is affected). Telcontar:~ # ping router PING router.valinor (192.168.1.1) 56(84) bytes of data. 64 bytes from router.valinor (192.168.1.1): icmp_seq=1 ttl=64 time=0.446 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=2 ttl=64 time=0.316 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=3 ttl=64 time=0.285 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=4 ttl=64 time=0.273 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=6 ttl=64 time=0.296 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=7 ttl=64 time=0.338 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=8 ttl=64 time=0.339 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=9 ttl=64 time=0.297 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=10 ttl=64 time=0.289 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=11 ttl=64 time=0.290 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=12 ttl=64 time=0.291 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=13 ttl=64 time=0.276 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=14 ttl=64 time=0.286 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=15 ttl=64 time=0.292 ms 64 bytes from router.valinor (192.168.1.1): icmp_seq=16 ttl=64 time=54.6 ms ^C - --- router.valinor ping statistics --- 17 packets transmitted, 15 received, 11.7647% packet loss, time 16350ms rtt min/avg/max/mdev = 0.273/3.925/54.563/13.533 ms Telcontar:~ # Isengard:~ # ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ... RX packets 16324236 bytes 23407062384 (21.7 GiB) RX errors 0 dropped 15561 overruns 0 frame 0 TX packets 4563080 bytes 693845719 (661.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 Telcontar:~ # ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 ... RX packets 5144209 bytes 1713874090 (1.5 GiB) RX errors 0 dropped 2848 overruns 0 frame 0 TX packets 16209419 bytes 23221176023 (21.6 GiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHIEARECADIWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZD7vLhQccm9iaW4ubGlz dGFzQGdteC5lcwAKCRC1MxgcbY1H1RNRAJ4kQ4ezgxUxFe4IHGB4PqSS4HberwCf dESaJvtyrd2flLdQ321musqjrn4= =LemM -----END PGP SIGNATURE-----
Carlos E. R. wrote:
Internet Web is slow to load, with my testing stopped. This is a powerful machine. I have fast fibre.
None of that matters if the switch is poor.
I would look at your general stats, not the ones you provoke.
ip -s link show
Isengard:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 4c:cc:6a:61:50:a1 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 23406734220 16321239 0 5700 9849 79742
First impression - that's a _lot_ dropped and missed.
telcontar:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:d8:61:a1:5a:bd brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 1713292131 5141166 0 2838 0 73508
Also seems like a lot. -- Per Jessen, Zürich (10.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 21:48, Per Jessen wrote:
Carlos E. R. wrote:
Internet Web is slow to load, with my testing stopped. This is a powerful machine. I have fast fibre.
None of that matters if the switch is poor.
Nono. The switch is good. TP-Link TL_SG1016DE And reread what I said: - I had one router per years, maybe a decade. No problems. - They changed the router: I had no connectivity at all to any of the two switches. - They changed the router again: I got connectivity, 30% packet loss. The router is CRAP (Mitrastar HGW-2501GN). Don't blame the switches. Just working with its config web page, you notice things that fail to work.
I would look at your general stats, not the ones you provoke.
ip -s link show
Isengard:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 4c:cc:6a:61:50:a1 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 23406734220 16321239 0 5700 9849 79742
First impression - that's a _lot_ dropped and missed.
Told you.
telcontar:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:d8:61:a1:5a:bd brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 1713292131 5141166 0 2838 0 73508
Also seems like a lot.
The difference is that the ping test runs on Isengard. Telcontar is the desktop machine. Running ethereal you can see retries. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-18 21:48, Per Jessen wrote:
Carlos E. R. wrote:
Internet Web is slow to load, with my testing stopped. This is a powerful machine. I have fast fibre.
None of that matters if the switch is poor.
Nono. The switch is good. TP-Link TL_SG1016DE
Hmm, in my experience, TP-link is sh*te. I have only had trouble with my TP-Link access points. (three of them).
The router is CRAP (Mitrastar HGW-2501GN). Don't blame the switches.
Given your interface stats, I suggest that is at most a guess.
Just working with its config web page, you notice things that fail to work.
Yeah that does give one a bad impression, but it doesn't necessarily mean the tcp stack is also bad.
Isengard:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 4c:cc:6a:61:50:a1 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 23406734220 16321239 0 5700 9849 79742
First impression - that's a _lot_ dropped and missed.
Told you.
You did? when your machine is dropping packets, either there is a problem with that machine or your network is overloaded. I have no idea what "missed" means.
telcontar:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:d8:61:a1:5a:bd brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 1713292131 5141166 0 2838 0 73508
Also seems like a lot.
The difference is that the ping test runs on Isengard. Telcontar is the desktop machine.
Well, if it were me, I would investigate - those numbers seem way too high. -- Per Jessen, Zürich (9.7°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Wed, Apr 19, 2023 at 10:16 AM Per Jessen <per@opensuse.org> wrote:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 4c:cc:6a:61:50:a1 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 23406734220 16321239 0 5700 9849 79742
First impression - that's a _lot_ dropped and missed.
Told you.
You did? when your machine is dropping packets, either there is a problem with that machine or your network is overloaded.
"dropped" also includes packets with the wrong MAC address so it could be due to e.g. switch packet flooding (or maybe the switch is actually a hub in disguise). In any case, it counts good packets (without error) received by interface but ignored. So it does not necessarily indicate host, rather overall network configuration issues.
I have no idea what "missed" means.
--><-- Counts number of packets dropped by the device due to lack of buffer space. This usually indicates that the host interface is slower than the network interface, or host is not keeping up with the receive packet rate. --><-- ...
Well, if it were me, I would investigate - those numbers seem way too high.
That's about 0.1% of all received packets and we do not know for which period. Are those numbers increasing?
Andrei Borzenkov wrote:
"dropped" also includes packets with the wrong MAC address so it could be due to e.g. switch packet flooding (or maybe the switch is actually a hub in disguise). In any case, it counts good packets (without error) received by interface but ignored. So it does not necessarily indicate host, rather overall network configuration issues.
I have no idea what "missed" means.
--><-- Counts number of packets dropped by the device due to lack of buffer space. This usually indicates that the host interface is slower than the network interface, or host is not keeping up with the receive packet rate. --><--
Ah, thanks, I swapped the meaning of the two.
Well, if it were me, I would investigate - those numbers seem way too high.
That's about 0.1% of all received packets and we do not know for which period. Are those numbers increasing?
For comparison, I took a look at a couple of my machines. (I just wanted to get a feel for the general situation). "alumni" - uptime 645 days, 4.6E9 packets, 0 dropped, 0 overrun on all interfaces. (lvs frontend, nameserver). "tattoo16" - uptime 343 days, 800E6 packets, 0 dropped, 0 overrun on all interfaces. (mail server). "dresden" - uptime 313 days, 2.6E9 packets, 0 dropped, 0 overrun on all interfaces. (main dhcp, dns, ntp, tftp server). "janeway" - uptime 43min - 100k packets, 1 dropped. (leap 15.5 test machine) Not sure why my stats don't list any 'missed' number, I'm guessing 'overrun' is the same. Maybe my 'ip' is old. Of course, now I am curious to know what that one dropped packet was :-) -- Per Jessen, Zürich (11.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-19 09:32, Andrei Borzenkov wrote:
On Wed, Apr 19, 2023 at 10:16 AM Per Jessen <per@opensuse.org> wrote:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 4c:cc:6a:61:50:a1 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 23406734220 16321239 0 5700 9849 79742
First impression - that's a _lot_ dropped and missed.
Told you.
You did? when your machine is dropping packets, either there is a problem with that machine or your network is overloaded.
"dropped" also includes packets with the wrong MAC address so it could be due to e.g. switch packet flooding (or maybe the switch is actually a hub in disguise). In any case, it counts good packets (without error) received by interface but ignored. So it does not necessarily indicate host, rather overall network configuration issues.
I have no idea what "missed" means.
--><-- Counts number of packets dropped by the device due to lack of buffer space. This usually indicates that the host interface is slower than the network interface, or host is not keeping up with the receive packet rate. --><--
...
Well, if it were me, I would investigate - those numbers seem way too high.
That's about 0.1% of all received packets and we do not know for which period. Are those numbers increasing?
Isengard, now: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 4c:cc:6a:61:50:a1 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 23485290655 17088751 0 6494 9849 90980 TX: bytes packets errors dropped carrier collsns 781557805 5297212 0 0 0 0 altname enp3s0 Yesterday: Isengard: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 4c:cc:6a:61:50:a1 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 23406734220 16321239 0 5700 9849 79742 TX: bytes packets errors dropped carrier collsns 693306794 4560203 0 0 0 0 altname enp3s0 Telcontar, now: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:d8:61:a1:5a:bd brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 1752303369 5230439 0 3190 0 82323 TX: bytes packets errors dropped carrier collsns 23227299542 16277311 0 0 0 0 altname enp34s0 Yesterday: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:d8:61:a1:5a:bd brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 1713292131 5141166 0 2838 0 73508 -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Wed, Apr 19, 2023 at 11:09 AM Carlos E.R. <robin.listas@gmx.es> wrote:
Isengard, now:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 4c:cc:6a:61:50:a1 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 23485290655 17088751 0 6494 9849 90980 TX: bytes packets errors dropped carrier collsns 781557805 5297212 0 0 0 0 altname enp3s0
Yesterday:
Isengard:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 4c:cc:6a:61:50:a1 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 23406734220 16321239 0 5700 9849 79742 TX: bytes packets errors dropped carrier collsns 693306794 4560203 0 0 0 0 altname enp3s0
"missed" did not increase, so whatever it was it was in the past. "dropped" can well be due to multicast (I am not sure whether they overlap; according to documentation multicast numbers "may include packets which did not reach the host"). So I personally do not see anything outstanding here.
On 2023-04-19 09:16, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-18 21:48, Per Jessen wrote:
Carlos E. R. wrote:
Internet Web is slow to load, with my testing stopped. This is a powerful machine. I have fast fibre.
None of that matters if the switch is poor.
Nono. The switch is good. TP-Link TL_SG1016DE
Hmm, in my experience, TP-link is sh*te. I have only had trouble with my TP-Link access points. (three of them).
The router is CRAP (Mitrastar HGW-2501GN). Don't blame the switches.
Given your interface stats, I suggest that is at most a guess.
Not a guess. Network is going perfect. Router is replaced, network fails, the problem is the router, period.
Just working with its config web page, you notice things that fail to work.
Yeah that does give one a bad impression, but it doesn't necessarily mean the tcp stack is also bad.
Isengard:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 4c:cc:6a:61:50:a1 brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 23406734220 16321239 0 5700 9849 79742
First impression - that's a _lot_ dropped and missed.
Told you.
You did? when your machine is dropping packets, either there is a problem with that machine or your network is overloaded. I have no idea what "missed" means.
No, the problem is in the router. Told you.
telcontar:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000 link/ether 00:d8:61:a1:5a:bd brd ff:ff:ff:ff:ff:ff RX: bytes packets errors dropped missed mcast 1713292131 5141166 0 2838 0 73508
Also seems like a lot.
The difference is that the ping test runs on Isengard. Telcontar is the desktop machine.
Well, if it were me, I would investigate - those numbers seem way too high.
I have investigated. It is the router. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-19 03:16, Per Jessen wrote:
Nono. The switch is good. TP-Link TL_SG1016DE Hmm, in my experience, TP-link is sh*te. I have only had trouble with my TP-Link access points. (three of them).
+1 I had a TP-Link access point. It had a "feature" where multicasts on the main LAN leaked into the VLAN & 2nd SSID. This made it impossible for me to have IPv6 on my guest WiFi. I have since replaced it with a Unifi AC-Lite AP, which works properly. The same issue affected some models of TP-Link switches.
On 2023-04-18 16:23, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-18 12:22, Per Jessen wrote:
Carlos E. R. wrote:
Telcontar:~ # ip -6 neigh fe80::ceed:dcff:fe05:80d4 dev eth0 lladdr cc:ed:dc:05:80:d4 router STALE Telcontar:~ #
Not the one I want.
Ah, I forgot, you wanted the external address, sorry.
No, the internal.
I meant external as opposed to link-local. There is no more internal/external, your machines all have public ipv6 addresses.
Yes, so I read somewhere else today. I assumed the router would have one address on the external, fibre, interface and another on the internal, eth, interface.
The external I can ask some web pages, and maybe the router itself.
Yep, got it - you want the LAN side address of the router.
Yes.
That's today's address, the ISP "promised" to use dynamic prefixes.
Which isn't the same as a guaranteed change, I expect.
Every time the rooter reboots, same as with IPv4.
Really? That is not how most providers do it.
Welcome to Spain. (I suspect Andrei is familiar with this setup, though) It may be even worse, though: on a reboot, I might loose IPv6. I would have to email the Beta Testing Group, and they would activate it again. I read something about that, so I'm not going to try a router reboot unless absolutely needed. I know read Andre's next email. I can not set up logging on this router. It worked on the previous incumbent, on this one the interface is missing. And, since this afternoon I can no longer ssh to my router: cer@Telcontar:~> ssh 1234@router.valinor kex_exchange_identification: read: Connection reset by peer Connection reset by 192.168.1.1 port 22 cer@Telcontar:~> The cron job that does an ssh on the router is failing. I fear the ISP has manually closed it, or the daemon (inside the router) has crashed.
Notice the losses. Same as with IPv4.
Try increasing the interval, the default is 10ms.
Why? :-?
To avoid having packets dropped. ICMPs may be dropped, they have the lowest priority. If you are flood pinging your network - which I suggest 100 pings per second is - some will be dropped.
The test takes a minute to run. I tried 25 mS, no difference. Any command that does ping tests fails the test. The same test, if run directly, without a switch, works perfectly. The old router worked fine. They replaced the router, and I lost ALL connectivity switch-router. They replaced the router, and I have this, 30% loss. When I try any web site, there is a delay, compared to the old router. Many packages fail, but being TCP it tries again. Ok, I'll put "--interval=100", count 20. I'll let it run for a while and report again. (1) Oh, the switch is fine. router----SW1-----SW2---computer_room | laptop laptop to computer room runs perfectly the same test. The Telefónica technician gave up. (1)
Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 20 --quiet --interval=100 router ; done 2023-04-18T20:43:28+02:00 router : xmt/rcv/%loss = 20/14/30%, min/avg/max = 0.28/0.43/0.88 2023-04-18T20:43:50+02:00 router : xmt/rcv/%loss = 20/19/5%, min/avg/max = 0.31/0.37/0.52 2023-04-18T20:44:11+02:00 router : xmt/rcv/%loss = 20/20/0%, min/avg/max = 0.30/1.56/7.81 2023-04-18T20:44:31+02:00 router : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.30/0.98/4.89 2023-04-18T20:44:52+02:00 router : xmt/rcv/%loss = 20/17/15%, min/avg/max = 0.31/1.11/7.49 2023-04-18T20:45:13+02:00 router : xmt/rcv/%loss = 20/18/10%, min/avg/max = 0.28/0.35/0.58 2023-04-18T20:45:34+02:00 router : xmt/rcv/%loss = 20/15/25%, min/avg/max = 0.31/0.39/0.68 2023-04-18T20:45:55+02:00 router : xmt/rcv/%loss = 20/14/30%, min/avg/max = 0.32/0.39/0.66 2023-04-18T20:46:16+02:00 router : xmt/rcv/%loss = 20/20/0%, min/avg/max = 0.31/0.34/0.45 2023-04-18T20:46:36+02:00 router : xmt/rcv/%loss = 20/15/25%, min/avg/max = 0.30/0.40/0.73 2023-04-18T20:46:58+02:00 router : xmt/rcv/%loss = 20/18/10%, min/avg/max = 0.30/0.35/0.49 2023-04-18T20:47:19+02:00 router : xmt/rcv/%loss = 20/12/40%, min/avg/max = 0.32/1.22/10.1
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
To avoid having packets dropped. ICMPs may be dropped, they have the lowest priority. If you are flood pinging your network - which I suggest 100 pings per second is - some will be dropped.
The test takes a minute to run. I tried 25 mS, no difference. Any command that does ping tests fails the test.
The '-i' argument seems to set the time between pings to different machines, try using '-p' instead.
The same test, if run directly, without a switch, works perfectly.
On a ptp link, I'm sure it does.
The old router worked fine. They replaced the router, and I lost ALL connectivity switch-router. They replaced the router, and I have this, 30% loss. When I try any web site, there is a delay, compared to the old router. Many packages fail, but being TCP it tries again.
FWIW, between two office machines on the same Netgear Gbit switch, I think it is only shared with a printer - I ran fping --quiet -6 -p1 -c1000 - 0% loss. Okay, with your invocation, it does a ping per second, which you would think ought to be fine - still, from my TW test machine to our main firewall, at 1ping/sec, I also see 10% loss. (I think it traverses maybe three switches, I'm not sure). ICMPs can be ignored, just like UDP. -- Per Jessen, Zürich (10.8°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-18 21:43, Per Jessen wrote:
Carlos E. R. wrote:
To avoid having packets dropped. ICMPs may be dropped, they have the lowest priority. If you are flood pinging your network - which I suggest 100 pings per second is - some will be dropped.
The test takes a minute to run. I tried 25 mS, no difference. Any command that does ping tests fails the test.
The '-i' argument seems to set the time between pings to different machines, try using '-p' instead.
Runs faster.
The same test, if run directly, without a switch, works perfectly.
On a ptp link, I'm sure it does.
It proves that the router has no problem responding a ping flood.
The old router worked fine. They replaced the router, and I lost ALL connectivity switch-router. They replaced the router, and I have this, 30% loss. When I try any web site, there is a delay, compared to the old router. Many packages fail, but being TCP it tries again.
FWIW, between two office machines on the same Netgear Gbit switch, I think it is only shared with a printer - I ran
fping --quiet -6 -p1 -c1000 - 0% loss.
Okay, with your invocation, it does a ping per second, which you would think ought to be fine - still, from my TW test machine to our main firewall, at 1ping/sec, I also see 10% loss. (I think it traverses maybe three switches, I'm not sure).
ICMPs can be ignored, just like UDP.
Fine, suggest some other way to prove/test connectivity from computer to router. I think I also tested with some other protocol instead of ICMP. Again: many web pages take seconds to start responding and load. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E.R. wrote:
On 2023-04-18 21:43, Per Jessen wrote:
The same test, if run directly, without a switch, works perfectly.
On a ptp link, I'm sure it does.
It proves that the router has no problem responding a ping flood.
Well, yesterday I read the fping man page - with your scheme, you're not flooding anything (my mistake, I misread the meaning of the '-i' argument). It is one ping per second. If instead you use '-p' to reduce the interval between pings, you can indeed flood your router (or anything else). If I were running those ping tests, and if I kept seeing lost packets, I would try to identify the culprit. Look at the interface stats - maybe your router is responding just fine, but somehow the response is dropped.
Fine, suggest some other way to prove/test connectivity from computer to router.
I think I would try some large download, maybe an ISO file and then keep an eye on the interface stats. Run wireshark and look for tcp errors. Something like that.
Again: many web pages take seconds to start responding and load.
Yes, many websites have been getting increasingly top-heavy :-) I am not sure if testing with ping (icmp) is a particularly useful way of diagnosing slow-to-load websites (tcp). -- Per Jessen, Zürich (10.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-19 09:34, Per Jessen wrote:
Carlos E.R. wrote:
On 2023-04-18 21:43, Per Jessen wrote:
The same test, if run directly, without a switch, works perfectly.
On a ptp link, I'm sure it does.
It proves that the router has no problem responding a ping flood.
Well, yesterday I read the fping man page - with your scheme, you're not flooding anything (my mistake, I misread the meaning of the '-i' argument). It is one ping per second.
Ah. Then back to "fping -c 100 --quiet {host}"
If instead you use '-p' to reduce the interval between pings, you can indeed flood your router (or anything else).
If I were running those ping tests, and if I kept seeing lost packets, I would try to identify the culprit. Look at the interface stats - maybe your router is responding just fine, but somehow the response is dropped.
quoted to avoid wrap:
Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 20 --period=100 --quiet 2a02:...80d4 ; done
2023-04-19T10:11:07+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.45/0.53/0.69 2023-04-19T10:11:10+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/0/100% 2023-04-19T10:11:13+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/11/45%, min/avg/max = 0.47/1.09/5.45
What do you make of 100%& loss? telcontar, same period
2023-04-19T10:10:01+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.27/0.39/4.83 2023-04-19T10:10:12+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.22/0.38/4.82 2023-04-19T10:10:23+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.27/0.39/4.13
Fine, suggest some other way to prove/test connectivity from computer to router.
I think I would try some large download, maybe an ISO file and then keep an eye on the interface stats. Run wireshark and look for tcp errors. Something like that.
I'll buy that. But I don't know if this will show the errors between router and switch: router--1--SW1--2--SW2--3---telcontar The problem is in "1" when going to SW2. (I'm not running those pings below) quoted to avoid wrap:
No Time Source Dest Protocol Length Info
14 10:24:53.325852218 2a02:xxxx:xxxx:xxxx:xxxx:xxxx:5abd 2a02:9000::aaaa ICMPv6 165 Destination Unreachable (Port unreachable)
16 10:24:53.327894931 192.168.1.14 192.168.1.16 ICMP 125 Destination unreachable (Port unreachable)
18 10:24:53.327937181 192.168.1.14 1.1.1.1 ICMP 125 Destination unreachable (Port unreachable)
20 10:24:53.328056641 192.168.1.14 1.0.0.1 ICMP 125 Destination unreachable (Port unreachable)
116 10:24:54.359268356 192.168.1.14 90.147.160.73 TCP 54 [TCP Dup ACK 115#1] 43862 → 443 [ACK] Seq=398 Ack=4097 Win=62720 Len=0
167 10:24:54.500600914 193.190.198.27 192.168.1.14 TLSv1.2 1506 Application Data [TCP segment of a reassembled PDU]
203 10:24:54.521271960 80.58.61.250 192.168.1.14 DNS 187 Standard query response 0x3a0c AAAA opensuse.mirror.garr.it CNAME proxy.mirror.garr.it AAAA 2001:760:ffff:b6:4:100:0:73 AAAA 2001:760:ffff:b6:4:100:0:72 AAAA 2001:760:ffff:b6:4:100:0:70
in black:
19546 10:24:55.202498460 90.147.160.73 192.168.1.14 TLSv1.3 1506 Continuation Data 19547 10:24:55.202502270 192.168.1.14 90.147.160.73 TCP 74 [TCP Window Update] 43862 → 443 [ACK] Seq=775 Ack=1232191 Win=2421632 Len=0 SLE=1261231 SRE=1306243 SLE=1235095 SRE=1259779 19548 10:24:55.202511210 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=806801 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 [TCP segment of a reassembled PDU] 19549 10:24:55.202516740 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=808241 Win=1110144 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19550 10:24:55.202524820 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [PSH, ACK] Seq=808241 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 [TCP segment of a reassembled PDU] 19551 10:24:55.202528680 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=809681 Win=1113088 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19552 10:24:55.202536560 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=809681 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19553 10:24:55.202540000 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=811121 Win=1115904 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19554 10:24:55.202548090 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=811121 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19555 10:24:55.202551850 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=812561 Win=1118848 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19556 10:24:55.202560830 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=812561 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19557 10:24:55.202563840 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=814001 Win=1121792 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19558 10:24:55.202572380 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=814001 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19559 10:24:55.202575380 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=815441 Win=1124608 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19560 10:24:55.202715280 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=815441 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19561 10:24:55.202719400 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=816881 Win=1127552 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19562 10:24:55.202727950 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=816881 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19563 10:24:55.202731980 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=818321 Win=1130496 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19564 10:24:55.202740680 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=818321 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19565 10:24:55.202744630 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=819761 Win=1133312 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19566 10:24:55.202753160 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=819761 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19567 10:24:55.202757100 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=821201 Win=1136256 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19568 10:24:55.202765240 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [PSH, ACK] Seq=821201 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19569 10:24:55.202769280 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=822641 Win=1139072 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19570 10:24:55.202937250 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=822641 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19571 10:24:55.202941510 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=824081 Win=1142016 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19572 10:24:55.202949900 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=824081 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19573 10:24:55.202953930 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=825521 Win=1144960 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19574 10:24:55.202962770 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=825521 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19575 10:24:55.202966880 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=826961 Win=1147776 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19576 10:24:55.202975080 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=826961 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19577 10:24:55.202978930 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=828401 Win=1150720 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19578 10:24:55.202987710 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=828401 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19579 10:24:55.202990770 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=829841 Win=1153664 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19580 10:24:55.202999540 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=829841 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19581 10:24:55.203002790 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=831281 Win=1156480 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19582 10:24:55.203011150 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=831281 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19583 10:24:55.203015120 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=832721 Win=1159424 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19584 10:24:55.203161830 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=832721 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19585 10:24:55.203165680 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=834161 Win=1162240 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19586 10:24:55.203174760 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [PSH, ACK] Seq=834161 Ack=1157 Win=64128 Len=1440 TSval=4088485036 TSecr=3811019451 19587 10:24:55.203178690 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=835601 Win=1165184 Len=0 TSval=3811019510 TSecr=4088485036 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19588 10:24:55.203186950 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=835601 Ack=1157 Win=64128 Len=1440 TSval=4088485038 TSecr=3811019451 19589 10:24:55.203190980 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=837041 Win=1168128 Len=0 TSval=3811019510 TSecr=4088485038 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19590 10:24:55.203200080 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=837041 Ack=1157 Win=64128 Len=1440 TSval=4088485038 TSecr=3811019451 19591 10:24:55.203204050 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=838481 Win=1170944 Len=0 TSval=3811019510 TSecr=4088485038 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19592 10:24:55.203212150 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [ACK] Seq=838481 Ack=1157 Win=6frame.number == 5839634128 Len=1440 TSval=4088485038 TSecr=3811019451 19593 10:24:55.203216090 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=839921 Win=1173888 Len=0 TSval=3811019510 TSecr=4088485038 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19594 10:24:55.203382651 37.58.58.140 192.168.1.14 TCP 1506 [TCP Out-Of-Order] 443 → 54680 [PSH, ACK] Seq=839921 Ack=1157 Win=64128 Len=1440 TSval=4088485038 TSecr=3811019451 19595 10:24:55.203386541 192.168.1.14 37.58.58.140 TCP 94 54680 → 443 [ACK] Seq=1157 Ack=841361 Win=1176832 Len=0 TSval=3811019510 TSecr=4088485038 SLE=1030001 SRE=1234481 SLE=1015601 SRE=1024241 SLE=898961 SRE=973841 19596 10:24:55.203395441 90.147.160.73 192.168.1.14 TLSv1.3 1506 Continuation Data 19597 10:24:55.203398551 192.168.1.14 90.147.160.73 TCP 74 [TCP Window Update] 43862 → 443 [ACK] Seq=775 Ack=1232191 Win=2424576 Len=0 SLE=1261231 SRE=1307695 SLE=1235095 SRE=1259779
(many more)
268035 10:25:01.640709300 192.168.1.14 37.58.58.140 TCP 86 [TCP Dup ACK 266294#37] 54680 → 443 [ACK] Seq=1157 Ack=55924241 Win=3144704 Len=0 TSval=3811025948 TSecr=4088491411 SLE=55935761 SRE=56428241 SLE=55925681 SRE=55934321
in red:
583963 10:25:10.400657213 192.168.1.14 90.147.160.73 TCP 54 43862 → 443 [ACK] Seq=775 Ack=33996571 Win=3144704 Len=0 583964 10:25:10.400754783 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583965 10:25:10.400759913 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583966 10:25:10.400913113 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583967 10:25:10.400916153 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583968 10:25:10.400975843 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583969 10:25:10.400978793 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583970 10:25:10.401016263 90.147.160.73 192.168.1.14 TCP 1506 443 → 43862 [ACK] Seq=33996571 Ack=775 Win=69632 Len=1452 [TCP segment of a reassembled PDU] 583971 10:25:10.401029713 90.147.160.73 192.168.1.14 TCP 1506 443 → 43862 [PSH, ACK] Seq=33998023 Ack=775 Win=69632 Len=1452 [TCP segment of a reassembled PDU] 583972 10:25:10.401034293 192.168.1.14 90.147.160.73 TCP 54 43862 → 443 [ACK] Seq=775 Ack=33999475 Win=3144704 Len=0 583973 10:25:10.401044243 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583974 10:25:10.401049093 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583975 10:25:10.401093223 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583976 10:25:10.401096433 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583977 10:25:10.401149523 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583978 10:25:10.401152453 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583979 10:25:10.401207003 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583980 10:25:10.401209903 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583981 10:25:10.401262063 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583982 10:25:10.401264963 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583983 10:25:10.401318583 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583984 10:25:10.401321573 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583985 10:25:10.401382743 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583986 10:25:10.401385653 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583987 10:25:10.401442894 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583988 10:25:10.401445814 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583989 10:25:10.401511574 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583990 10:25:10.401524144 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583991 10:25:10.401561054 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 583992 10:25:10.401564454 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 583993 10:25:10.401574184 193.190.198.27 192.168.1.14 TLSv1.2 1506 Ignored Unknown Record 583994 10:25:10.401588394 193.190.198.27 192.168.1.14 TLSv1.2 1506 Ignored Unknown Record 583995 10:25:10.401603824 193.190.198.27 192.168.1.14 TLSv1.2 1506 Ignored Unknown Record 583996 10:25:10.401610354 192.168.1.14 193.190.198.27 TCP 66 51418 → 443 [ACK] Seq=1411 Ack=210158682 Win=3145728 Len=0 TSval=4086237329 TSecr=1758017860 583997 10:25:10.401613834 193.190.198.27 192.168.1.14 TLSv1.2 1506 Ignored Unknown Record 583998 10:25:10.401625474 193.136.164.6 192.168.1.14 TLSv1.3 1506 Continuation Data 583999 10:25:10.401631914 192.168.1.14 193.136.164.6 TCP 66 52634 → 443 [ACK] Seq=1064 Ack=137955591 Win=3144704 Len=0 TSval=284870429 TSecr=571459330 584000 10:25:10.401641774 37.58.58.140 192.168.1.14 TLSv1.3 1506 Continuation Data 584001 10:25:10.401648354 192.168.1.14 37.58.58.140 TCP 54 54680 → 443 [RST] Seq=1157 Win=0 Len=0 584002 10:25:10.401658784 193.136.164.6 192.168.1.14 TLSv1.3 2946 Continuation Data 584003 10:25:10.401666734 192.168.1.14 193.136.164.6 TCP 66 52634 → 443 [ACK] Seq=1064 Ack=137958471 Win=3145728 Len=0 TSval=284870429 TSecr=571459333
(many more) The capture file is 600 MB, if you want it.
Again: many web pages take seconds to start responding and load.
Yes, many websites have been getting increasingly top-heavy :-)
I am not sure if testing with ping (icmp) is a particularly useful way of diagnosing slow-to-load websites (tcp).
No, it is just two problems that started when the router was changed. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 20 --period=100 --quiet 2a02:...80d4 ; done
2023-04-19T10:11:07+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.45/0.53/0.69 2023-04-19T10:11:10+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/0/100% 2023-04-19T10:11:13+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/11/45%, min/avg/max = 0.47/1.09/5.45
What do you make of 100%& loss?
Even at 10 pings/second, that is surely not right. Some questions are - a) do the echo requests reach your router? b) does your router respond with echo replies? c) does isengard receive the echo reply?
telcontar, same period
2023-04-19T10:10:01+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.27/0.39/4.83 2023-04-19T10:10:12+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.22/0.38/4.82 2023-04-19T10:10:23+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.27/0.39/4.13
10% unanswered pings still seems pretty high, even at 10/sec, but way better. What is the difference between isengard and telcontar?
I think I would try some large download, maybe an ISO file and then keep an eye on the interface stats. Run wireshark and look for tcp errors. Something like that.
I'll buy that. But I don't know if this will show the errors between router and switch:
router--1--SW1--2--SW2--3---telcontar
The problem is in "1" when going to SW2.
I assume 1, 2 and 3 are cables/connections? physical or wireless? Your pings from telcontar (above) traverse both switches, yet "performance" is better. I presume isengard is connected to sw1 ?
in black:
I don't do html :-)
The capture file is 600 MB, if you want it.
Even if I did, I would want the raw file. A lot of "TCP Out-of-Order" would make me curious. In the very beginning, I also see a couple of interesting entries:
16 10:24:53.327894931 192.168.1.14 192.168.1.16 ICMP 125 Destination unreachable (Port unreachable)
18 10:24:53.327937181 192.168.1.14 1.1.1.1 ICMP 125 Destination unreachable (Port unreachable)
20 10:24:53.328056641 192.168.1.14 1.0.0.1 ICMP 125 Destination unreachable (Port unreachable)
-- Per Jessen, Zürich (12.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Wed, Apr 19, 2023 at 2:47 PM Per Jessen <per@opensuse.org> wrote:
Carlos E. R. wrote:
Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 20 --period=100 --quiet 2a02:...80d4 ; done
2023-04-19T10:11:07+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.45/0.53/0.69 2023-04-19T10:11:10+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/0/100% 2023-04-19T10:11:13+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/11/45%, min/avg/max = 0.47/1.09/5.45
What do you make of 100%& loss?
Even at 10 pings/second, that is surely not right. Some questions are -
a) do the echo requests reach your router? b) does your router respond with echo replies? c) does isengard receive the echo reply?
Briefly looking at documentation for this switch, it should support port mirroring so one could capture what happens on the router side.
telcontar, same period
2023-04-19T10:10:01+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.27/0.39/4.83 2023-04-19T10:10:12+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.22/0.38/4.82 2023-04-19T10:10:23+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.27/0.39/4.13
10% unanswered pings still seems pretty high, even at 10/sec, but way better. What is the difference between isengard and telcontar?
Yes, the very first question :)
On 2023-04-19 13:52, Andrei Borzenkov wrote:
On Wed, Apr 19, 2023 at 2:47 PM Per Jessen <per@opensuse.org> wrote:
Carlos E. R. wrote:
Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 20 --period=100 --quiet 2a02:...80d4 ; done
2023-04-19T10:11:07+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.45/0.53/0.69 2023-04-19T10:11:10+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/0/100% 2023-04-19T10:11:13+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/11/45%, min/avg/max = 0.47/1.09/5.45
What do you make of 100%& loss?
Even at 10 pings/second, that is surely not right. Some questions are -
a) do the echo requests reach your router? b) does your router respond with echo replies? c) does isengard receive the echo reply?
Briefly looking at documentation for this switch, it should support port mirroring so one could capture what happens on the router side.
I did that on sw1, maybe a month ago, which is the one directly connected to the router. About sw2, I lost the login/password, so I have to factory reset it in order to do anything on it. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-19 13:46, Per Jessen wrote:
Carlos E. R. wrote:
Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 20 --period=100 --quiet 2a02:...80d4 ; done
2023-04-19T10:11:07+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.45/0.53/0.69 2023-04-19T10:11:10+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/0/100% 2023-04-19T10:11:13+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/11/45%, min/avg/max = 0.47/1.09/5.45
What do you make of 100%& loss?
Even at 10 pings/second, that is surely not right. Some questions are -
a) do the echo requests reach your router?
AFAIK, yes. Once I connected the laptop to the switch_1, with everything mirrored to that port, running ethereal. AFAIK there were pings coming from upstairs that were not answered.
b) does your router respond with echo replies?
Not all.
c) does isengard receive the echo reply?
Those that are sent, yes, AFAIK.
telcontar, same period
2023-04-19T10:10:01+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.27/0.39/4.83 2023-04-19T10:10:12+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.22/0.38/4.82 2023-04-19T10:10:23+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.27/0.39/4.13
10% unanswered pings still seems pretty high, even at 10/sec, but way better. What is the difference between isengard and telcontar?
They were not running the exact same command at time. For that, I have to leave the commands running while, telcontar is not running a constant ping.
Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 100 --quiet router ; done 2023-04-19T14:03:57+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.26/0.39/1.04 2023-04-19T14:05:38+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.27/0.39/1.09 2023-04-19T14:07:19+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.26/0.40/1.53 2023-04-19T14:09:00+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.24/0.42/0.84 2023-04-19T14:10:41+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.24/0.70/25.1 2023-04-19T14:12:22+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.26/0.35/0.66 2023-04-19T14:14:03+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.28/0.43/2.15 2023-04-19T14:15:44+02:00
Telcontar:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 100 --quiet router ; done 2023-04-19T14:03:54+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.25/0.73/26.9 2023-04-19T14:05:35+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.27/0.33/1.30 2023-04-19T14:07:16+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.25/0.51/7.74 2023-04-19T14:08:58+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.24/0.82/22.9 2023-04-19T14:10:39+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.25/1.00/24.9 2023-04-19T14:12:20+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.26/1.51/47.3 2023-04-19T14:14:01+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.20/0.85/45.5 2023-04-19T14:15:42+02:00
They look similar to me. A bit higher in Isengard, perhaps.z Both are machine upstairs, same switch. Telcontar is the desktop machine, AMD, powerful. Isengard is the mini server, Intel, MSI Cubi N MiniPC. After lunch I'll have more data.
I think I would try some large download, maybe an ISO file and then keep an eye on the interface stats. Run wireshark and look for tcp errors. Something like that.
I'll buy that. But I don't know if this will show the errors between router and switch:
router--1--SW1--2--SW2--3---telcontar
The problem is in "1" when going to SW2.
I assume 1, 2 and 3 are cables/connections? physical or wireless?
Ethernet cable.
Your pings from telcontar (above) traverse both switches, yet "performance" is better. I presume isengard is connected to sw1 ?
No, both to sw2, upstairs. This moment I have both machines running the same fping command; we have to wait some time to collect data and compare.
in black:
I don't do html :-)
The mail was sent plain. I refer to "black" inside ethereal. Packets are coloured.
The capture file is 600 MB, if you want it.
Even if I did, I would want the raw file.
-rw------- 1 root root 708638880 Apr 19 10:25 capture_iso_download.pcapng I have still not closed ethereal, so I can still save the capture in any other format ;-)
A lot of "TCP Out-of-Order" would make me curious.
In the very beginning, I also see a couple of interesting entries:
16 10:24:53.327894931 192.168.1.14 192.168.1.16 ICMP 125 Destination unreachable (Port unreachable)
18 10:24:53.327937181 192.168.1.14 1.1.1.1 ICMP 125 Destination unreachable (Port unreachable)
20 10:24:53.328056641 192.168.1.14 1.0.0.1 ICMP 125 Destination unreachable (Port unreachable)
Yes, I pasted some that made me curious. I could also download same file from Isengard down to a laptop on sw1 and run a capture. I say Isengard because it has apache, the laptop doesn't. To do reverse direction, has to be different protocol, like sftp. Also connect laptop directly on router, and compare both captures. Those captures should not have private information if run on the new laptop, so I could share easily. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
On 2023-04-19 13:46, Per Jessen wrote:
Carlos E. R. wrote:
Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 20 --period=100 --quiet 2a02:...80d4 ; done
2023-04-19T10:11:07+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.45/0.53/0.69 2023-04-19T10:11:10+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/0/100% 2023-04-19T10:11:13+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/11/45%, min/avg/max = 0.47/1.09/5.45
What do you make of 100%& loss?
Even at 10 pings/second, that is surely not right. Some questions are -
a) do the echo requests reach your router?
AFAIK, yes.
Once I connected the laptop to the switch_1, with everything mirrored to that port, running ethereal. AFAIK there were pings coming from upstairs that were not answered.
b) does your router respond with echo replies?
Not all.
c) does isengard receive the echo reply?
Those that are sent, yes, AFAIK.
I meant "some questions you need to ask in order to diagnose the issue" :-) a) it isn't easy to tell, but yes, with port mirroring it's doable. b) at a rate 1/sec, that is certainly unusual. c) "as far as I know" is not good enough ...
10% unanswered pings still seems pretty high, even at 10/sec, but way better. What is the difference between isengard and telcontar?
They were not running the exact same command at time. For that, I have to leave the commands running while, telcontar is not running a constant ping.
Given how different the results were, there has to be more than "not running the exact same command". I mean, their connections, maybe some hardware, cabling? [snip]
They look similar to me. A bit higher in Isengard, perhaps.
Yes, now they look quite similar. What changed? what happened to the 100% loss ? you also changed the ping interval back to 1/sec.
Both are machine upstairs, same switch. Telcontar is the desktop machine, AMD, powerful. Isengard is the mini server, Intel, MSI Cubi N MiniPC.
isengard showed much worse results, despite being connected in exactly the same way, that is where I would start looking.
I could also download same file from Isengard down to a laptop on sw1 and run a capture.
I see five elements in this test - isengard, telcontar, sw1, sw2 and router. sofar, in your ping-test isengard has shown the worst results. Does isengard also exhibit the slow loading website problem? -- Per Jessen, Zürich (12.5°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On Wed, Apr 19, 2023 at 5:19 PM Per Jessen <per@opensuse.org> wrote:
Yes, now they look quite similar. What changed? what happened to the 100% loss ? you also changed the ping interval back to 1/sec.
Test with 100% packet loss used 100ms timeout. All other tests used default 1s timeout.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday, 2023-04-19 at 16:19 +0200, Per Jessen wrote:
Carlos E. R. wrote:
On 2023-04-19 13:46, Per Jessen wrote:
Carlos E. R. wrote:
Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 20 --period=100 --quiet 2a02:...80d4 ; done
2023-04-19T10:11:07+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.45/0.53/0.69 2023-04-19T10:11:10+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/0/100% 2023-04-19T10:11:13+02:00 2a02:...:80d4 : xmt/rcv/%loss = 20/11/45%, min/avg/max = 0.47/1.09/5.45
What do you make of 100%& loss?
Even at 10 pings/second, that is surely not right. Some questions are -
a) do the echo requests reach your router?
AFAIK, yes.
Once I connected the laptop to the switch_1, with everything mirrored to that port, running ethereal. AFAIK there were pings coming from upstairs that were not answered.
b) does your router respond with echo replies?
Not all.
c) does isengard receive the echo reply?
Those that are sent, yes, AFAIK.
I meant "some questions you need to ask in order to diagnose the issue" :-)
a) it isn't easy to tell, but yes, with port mirroring it's doable. b) at a rate 1/sec, that is certainly unusual. c) "as far as I know" is not good enough ...
10% unanswered pings still seems pretty high, even at 10/sec, but way better. What is the difference between isengard and telcontar?
They were not running the exact same command at time. For that, I have to leave the commands running while, telcontar is not running a constant ping.
Given how different the results were, there has to be more than "not running the exact same command". I mean, their connections, maybe some hardware, cabling?
Nope. I can send files on those two machines at gigabit speed. I am running the ping now from machine to machine, I expect 0 loses. cer@Telcontar:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 100 --quiet isengard ; done 2023-04-19T19:15:08+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.13/0.17/0.27 2023-04-19T19:16:48+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.13/0.16/0.27 2023-04-19T19:18:28+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.13/0.16/0.28 2023-04-19T19:20:08+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.13/0.17/0.33 2023-04-19T19:21:48+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.10/0.16/0.27 2023-04-19T19:23:28+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.13/0.16/0.26 2023-04-19T19:25:08+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.11/0.16/0.26 2023-04-19T19:26:48+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.12/0.16/0.24 2023-04-19T19:28:28+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.13/0.16/0.27 2023-04-19T19:30:08+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.13/0.16/0.31 2023-04-19T19:31:48+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.11/0.16/0.27 2023-04-19T19:33:28+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.14/0.17/0.32 2023-04-19T19:35:08+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.13/0.16/0.42 2023-04-19T19:36:48+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.14/0.16/0.25 2023-04-19T19:38:28+02:00 isengard : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.12/0.17/0.33 2023-04-19T19:40:08+02:00 And reverse direction: Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 100 --quiet telcontar ; done 2023-04-19T19:16:08+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.09/0.14/0.43 2023-04-19T19:17:48+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.11/0.13/0.29 2023-04-19T19:19:28+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.10/0.13/0.20 2023-04-19T19:21:08+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.11/0.13/0.30 2023-04-19T19:22:48+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.10/0.13/0.20 2023-04-19T19:24:28+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.11/0.14/0.31 2023-04-19T19:26:08+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.11/0.14/0.44 2023-04-19T19:27:48+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.11/0.14/0.32 2023-04-19T19:29:29+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.10/0.13/0.29 2023-04-19T19:31:09+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.10/0.14/0.39 2023-04-19T19:32:49+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.08/0.12/0.23 2023-04-19T19:34:29+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.08/0.12/0.17 2023-04-19T19:36:09+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.08/0.12/0.39 2023-04-19T19:37:49+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.08/0.12/0.27 2023-04-19T19:39:29+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.08/0.12/0.21 2023-04-19T19:41:09+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.07/0.11/0.21 2023-04-19T19:42:49+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.08/0.12/0.30 2023-04-19T19:44:29+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.07/0.13/0.43 2023-04-19T19:46:09+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.08/0.12/0.21 2023-04-19T19:47:49+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.08/0.12/0.29 2023-04-19T19:49:29+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.08/0.12/0.27 2023-04-19T19:51:09+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.07/0.11/0.27 2023-04-19T19:52:49+02:00 telcontar : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.07/0.11/0.18 2023-04-19T19:54:29+02:00 See? Perfect connection.
[snip]
They look similar to me. A bit higher in Isengard, perhaps.
Yes, now they look quite similar. What changed? what happened to the 100% loss ? you also changed the ping interval back to 1/sec.
I told you, different command line. Change -c 20 to -c 100. Look: xmt/rcv/%loss = 20/16/20% xmt/rcv/%loss = 100/86/14% *** Bigger period, the average is smoother.
Both are machine upstairs, same switch. Telcontar is the desktop machine, AMD, powerful. Isengard is the mini server, Intel, MSI Cubi N MiniPC.
isengard showed much worse results, despite being connected in exactly the same way, that is where I would start looking.
I could also download same file from Isengard down to a laptop on sw1 and run a capture.
I see five elements in this test - isengard, telcontar, sw1, sw2 and router. sofar, in your ping-test isengard has shown the worst results. Does isengard also exhibit the slow loading website problem?
Isengard loads page slowly because it has a worse CPU and only 8 GB of ram. Telcontar has 64. Not comparable No, that Isengard looked worse is only an artifact of the command. I can reverse the 20/100 and telcontar will show worse results. Look: telcontar to router, -c 20: cer@Telcontar:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 20 --quiet router ; done 2023-04-19T19:22:22+02:00 router : xmt/rcv/%loss = 20/12/40%, min/avg/max = 0.28/0.30/0.38 2023-04-19T19:22:43+02:00 router : xmt/rcv/%loss = 20/20/0%, min/avg/max = 0.27/0.32/0.65 2023-04-19T19:23:03+02:00 router : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.26/0.29/0.43 2023-04-19T19:23:24+02:00 router : xmt/rcv/%loss = 20/18/10%, min/avg/max = 0.26/0.32/0.50 2023-04-19T19:23:45+02:00 router : xmt/rcv/%loss = 20/20/0%, min/avg/max = 0.26/0.32/0.74 2023-04-19T19:24:05+02:00 router : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.25/0.37/0.91 2023-04-19T19:24:26+02:00 router : xmt/rcv/%loss = 20/17/15%, min/avg/max = 0.25/0.33/0.55 2023-04-19T19:24:47+02:00 router : xmt/rcv/%loss = 20/18/10%, min/avg/max = 0.27/0.75/4.99 2023-04-19T19:25:08+02:00 router : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.23/0.30/0.49 2023-04-19T19:25:29+02:00 router : xmt/rcv/%loss = 20/19/5%, min/avg/max = 0.25/0.37/0.72 2023-04-19T19:25:50+02:00 router : xmt/rcv/%loss = 20/20/0%, min/avg/max = 0.25/0.35/0.93 2023-04-19T19:26:10+02:00 router : xmt/rcv/%loss = 20/10/50%, min/avg/max = 0.25/0.28/0.36 2023-04-19T19:26:31+02:00 router : xmt/rcv/%loss = 20/20/0%, min/avg/max = 0.26/0.32/0.58 2023-04-19T19:26:52+02:00 router : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.26/0.34/0.67 2023-04-19T19:27:13+02:00 router : xmt/rcv/%loss = 20/19/5%, min/avg/max = 0.26/0.31/0.53 2023-04-19T19:27:34+02:00 router : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.26/0.29/0.35 2023-04-19T19:27:55+02:00 router : xmt/rcv/%loss = 20/19/5%, min/avg/max = 0.25/0.32/0.65 2023-04-19T19:28:16+02:00 router : xmt/rcv/%loss = 20/19/5%, min/avg/max = 0.24/0.30/0.39 2023-04-19T19:28:37+02:00 router : xmt/rcv/%loss = 20/18/10%, min/avg/max = 0.25/0.34/0.55 2023-04-19T19:28:58+02:00 router : xmt/rcv/%loss = 20/19/5%, min/avg/max = 0.25/0.69/5.04 2023-04-19T19:29:19+02:00 router : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.27/0.39/0.71 2023-04-19T19:29:40+02:00 router : xmt/rcv/%loss = 20/20/0%, min/avg/max = 0.24/0.31/0.53 2023-04-19T19:30:00+02:00 router : xmt/rcv/%loss = 20/14/30%, min/avg/max = 0.24/0.26/0.32 2023-04-19T19:30:21+02:00 router : xmt/rcv/%loss = 20/20/0%, min/avg/max = 0.25/0.49/2.04 2023-04-19T19:30:41+02:00 router : xmt/rcv/%loss = 20/15/25%, min/avg/max = 0.23/0.31/0.72 2023-04-19T19:31:02+02:00 router : xmt/rcv/%loss = 20/18/10%, min/avg/max = 0.24/0.38/1.13 2023-04-19T19:31:23+02:00 router : xmt/rcv/%loss = 20/17/15%, min/avg/max = 0.26/0.30/0.52 2023-04-19T19:31:44+02:00 router : xmt/rcv/%loss = 20/19/5%, min/avg/max = 0.27/0.31/0.54 2023-04-19T19:32:05+02:00 router : xmt/rcv/%loss = 20/19/5%, min/avg/max = 0.27/0.31/0.84 2023-04-19T19:32:26+02:00 router : xmt/rcv/%loss = 20/19/5%, min/avg/max = 0.26/0.41/1.72 2023-04-19T19:32:47+02:00 router : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.27/0.30/0.42 2023-04-19T19:33:08+02:00 router : xmt/rcv/%loss = 20/18/10%, min/avg/max = 0.27/0.31/0.58 2023-04-19T19:33:29+02:00 router : xmt/rcv/%loss = 20/14/30%, min/avg/max = 0.23/0.30/0.49 2023-04-19T19:33:50+02:00 router : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.26/0.47/3.24 2023-04-19T19:34:11+02:00 router : xmt/rcv/%loss = 20/20/0%, min/avg/max = 0.26/1.61/16.7 2023-04-19T19:34:31+02:00 router : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.24/0.34/0.51 2023-04-19T19:34:52+02:00 router : xmt/rcv/%loss = 20/19/5%, min/avg/max = 0.27/0.34/0.68 2023-04-19T19:35:13+02:00 router : xmt/rcv/%loss = 20/15/25%, min/avg/max = 0.26/0.36/0.71 2023-04-19T19:35:34+02:00 router : xmt/rcv/%loss = 20/17/15%, min/avg/max = 0.26/0.94/7.14 2023-04-19T19:35:55+02:00 router : xmt/rcv/%loss = 20/18/10%, min/avg/max = 0.27/0.32/0.55 2023-04-19T19:36:16+02:00 router : xmt/rcv/%loss = 20/17/15%, min/avg/max = 0.27/0.34/0.57 2023-04-19T19:36:37+02:00 router : xmt/rcv/%loss = 20/20/0%, min/avg/max = 0.27/0.39/1.44 2023-04-19T19:36:57+02:00 router : xmt/rcv/%loss = 20/17/15%, min/avg/max = 0.26/0.33/0.47 2023-04-19T19:37:18+02:00 router : xmt/rcv/%loss = 20/17/15%, min/avg/max = 0.26/0.36/0.64 2023-04-19T19:37:39+02:00 router : xmt/rcv/%loss = 20/16/20%, min/avg/max = 0.27/0.62/4.34 2023-04-19T19:38:00+02:00 router : xmt/rcv/%loss = 20/19/5%, min/avg/max = 0.25/0.84/9.94 2023-04-19T19:38:21+02:00 ^Crouter : xmt/rcv/%loss = 5/3/40%, min/avg/max = 0.28/0.43/0.61 ^C cer@Telcontar:~> ^C Notice the large variance. telcontar to router, -c 100: Telcontar:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 100 --quiet router ; done 2023-04-19T14:03:54+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.25/0.73/26.9 2023-04-19T14:05:35+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.27/0.33/1.30 2023-04-19T14:07:16+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.25/0.51/7.74 2023-04-19T14:08:58+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.24/0.82/22.9 2023-04-19T14:10:39+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.25/1.00/24.9 2023-04-19T14:12:20+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.26/1.51/47.3 2023-04-19T14:14:01+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.20/0.85/45.5 2023-04-19T14:15:42+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.24/0.43/6.43 2023-04-19T14:17:23+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.24/0.31/0.72 2023-04-19T14:19:04+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.24/0.55/5.02 2023-04-19T14:20:45+02:00 router : xmt/rcv/%loss = 100/67/33%, min/avg/max = 0.26/0.31/0.53 2023-04-19T14:22:26+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.25/0.41/4.01 2023-04-19T14:24:07+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.26/0.68/19.4 2023-04-19T14:25:48+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.26/0.34/0.87 2023-04-19T14:27:30+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.25/0.38/1.56 2023-04-19T14:29:11+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.25/0.32/0.67 2023-04-19T14:30:52+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.25/1.48/28.7 2023-04-19T14:32:33+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.26/0.88/7.45 2023-04-19T14:34:14+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.24/0.64/9.68 2023-04-19T14:35:55+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.24/0.36/2.93 2023-04-19T14:37:36+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.25/0.67/21.9 2023-04-19T14:39:17+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.25/0.64/10.8 2023-04-19T14:40:58+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.25/0.32/0.73 2023-04-19T14:42:39+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.25/0.39/2.38 2023-04-19T14:44:21+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.23/0.37/1.69 2023-04-19T14:46:02+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.25/0.36/3.99 2023-04-19T14:47:43+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.25/0.38/2.87 2023-04-19T14:49:24+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.25/0.70/25.2 2023-04-19T14:51:05+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.26/1.38/34.4 2023-04-19T14:52:46+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.24/2.02/45.6 2023-04-19T14:54:27+02:00 router : xmt/rcv/%loss = 100/96/4%, min/avg/max = 0.25/1.64/72.2 2023-04-19T14:56:08+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.23/0.34/0.69 2023-04-19T14:57:49+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.25/0.56/6.75 2023-04-19T14:59:30+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.24/0.41/7.90 2023-04-19T15:01:12+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.26/0.35/2.75 2023-04-19T15:02:53+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.25/0.50/7.31 2023-04-19T15:04:34+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.24/0.37/3.25 2023-04-19T15:06:15+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.25/1.18/70.4 2023-04-19T15:07:56+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.25/0.72/23.2 2023-04-19T15:09:37+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.25/0.41/6.04 2023-04-19T15:11:18+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.25/0.33/0.79 2023-04-19T15:12:59+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.26/1.14/27.2 2023-04-19T15:14:40+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.25/0.65/7.33 2023-04-19T15:16:21+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.25/0.61/7.87 2023-04-19T15:18:03+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.25/0.64/10.2 2023-04-19T15:19:44+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.25/0.45/7.50 2023-04-19T15:21:25+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.24/0.32/0.68 2023-04-19T15:23:06+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.25/0.42/2.67 2023-04-19T15:24:47+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.24/0.58/16.6 2023-04-19T15:26:28+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.24/0.32/0.75 2023-04-19T15:28:09+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.26/0.35/0.74 2023-04-19T15:29:50+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.25/0.38/3.58 2023-04-19T15:31:31+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.26/0.32/0.64 2023-04-19T15:33:12+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.27/2.04/47.1 2023-04-19T15:34:54+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.24/0.76/7.50 2023-04-19T15:36:35+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.27/1.04/9.80 2023-04-19T15:38:16+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.24/1.35/40.8 2023-04-19T15:39:57+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.24/0.45/3.28 2023-04-19T15:41:38+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.23/0.32/0.70 2023-04-19T15:43:19+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.24/0.60/21.9 2023-04-19T15:45:00+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.25/0.48/15.6 2023-04-19T15:46:41+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.24/0.32/0.73 2023-04-19T15:48:22+02:00 router : xmt/rcv/%loss = 100/96/4%, min/avg/max = 0.26/0.40/2.78 2023-04-19T15:50:03+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.24/0.32/0.97 2023-04-19T15:51:45+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.24/0.41/7.14 2023-04-19T15:53:26+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.19/1.27/12.5 2023-04-19T15:55:07+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.24/0.82/7.18 2023-04-19T15:56:48+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.25/0.93/19.3 2023-04-19T15:58:29+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.25/0.48/5.33 2023-04-19T16:00:10+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.24/0.34/1.40 2023-04-19T16:01:51+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.24/0.41/8.88 2023-04-19T16:03:32+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.24/0.38/3.53 2023-04-19T16:05:13+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.25/0.40/7.94 2023-04-19T16:06:54+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.27/0.39/4.90 2023-04-19T16:08:36+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.24/0.37/1.89 2023-04-19T16:10:17+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.26/0.33/0.73 2023-04-19T16:11:58+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.24/0.37/3.74 2023-04-19T16:13:39+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.26/0.72/7.55 2023-04-19T16:15:20+02:00 router : xmt/rcv/%loss = 100/71/29%, min/avg/max = 0.26/0.72/11.3 2023-04-19T16:17:01+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.26/0.62/7.74 2023-04-19T16:18:42+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.25/0.44/2.96 2023-04-19T16:20:23+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.25/0.32/0.69 2023-04-19T16:22:04+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.25/0.64/16.6 2023-04-19T16:23:45+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.26/0.61/17.0 2023-04-19T16:25:27+02:00 router : xmt/rcv/%loss = 100/74/26%, min/avg/max = 0.24/0.33/0.85 2023-04-19T16:27:08+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.24/0.38/5.22 2023-04-19T16:28:49+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.25/0.34/0.88 2023-04-19T16:30:30+02:00 router : xmt/rcv/%loss = 100/72/28%, min/avg/max = 0.25/0.32/0.64 2023-04-19T16:32:11+02:00 router : xmt/rcv/%loss = 100/70/30%, min/avg/max = 0.24/0.33/1.36 2023-04-19T16:33:52+02:00 router : xmt/rcv/%loss = 100/70/30%, min/avg/max = 0.25/0.80/7.19 2023-04-19T16:35:33+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.26/0.63/6.40 2023-04-19T16:37:14+02:00 router : xmt/rcv/%loss = 100/74/26%, min/avg/max = 0.23/1.72/27.7 2023-04-19T16:38:55+02:00 router : xmt/rcv/%loss = 100/74/26%, min/avg/max = 0.24/0.65/11.0 2023-04-19T16:40:36+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.23/0.55/17.8 2023-04-19T16:42:18+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.26/0.93/36.0 2023-04-19T16:43:59+02:00 router : xmt/rcv/%loss = 100/71/29%, min/avg/max = 0.25/0.42/4.94 2023-04-19T16:45:40+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.24/0.38/4.23 2023-04-19T16:47:21+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.25/0.40/7.09 2023-04-19T16:49:02+02:00 router : xmt/rcv/%loss = 100/64/36%, min/avg/max = 0.25/0.41/3.51 2023-04-19T16:50:43+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.25/0.40/6.44 2023-04-19T16:52:24+02:00 router : xmt/rcv/%loss = 100/71/29%, min/avg/max = 0.25/0.39/2.54 2023-04-19T16:54:05+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.24/0.51/12.1 2023-04-19T16:55:46+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.25/1.63/30.2 2023-04-19T16:57:27+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.25/0.75/5.91 2023-04-19T16:59:09+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.27/0.90/9.15 2023-04-19T17:00:50+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.25/0.45/4.67 2023-04-19T17:02:31+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.25/0.32/0.74 2023-04-19T17:04:12+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.25/0.44/3.14 2023-04-19T17:05:53+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.20/0.32/0.78 2023-04-19T17:07:34+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.22/0.63/7.99 2023-04-19T17:09:15+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.25/0.40/3.21 2023-04-19T17:10:56+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.24/0.34/1.19 2023-04-19T17:12:37+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.26/0.40/5.10 2023-04-19T17:14:18+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.25/0.64/25.3 2023-04-19T17:16:00+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.25/0.99/17.4 2023-04-19T17:17:41+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.23/0.97/8.80 2023-04-19T17:19:22+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.27/0.85/5.11 2023-04-19T17:21:03+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.26/0.33/0.92 2023-04-19T17:22:44+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.24/0.45/5.29 2023-04-19T17:24:25+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.25/0.32/0.72 2023-04-19T17:26:06+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.27/0.36/2.49 2023-04-19T17:27:47+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.25/0.35/1.15 2023-04-19T17:29:28+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.22/0.56/19.2 2023-04-19T17:31:09+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.26/0.37/5.32 2023-04-19T17:32:51+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.26/0.35/0.67 2023-04-19T17:34:32+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.25/0.33/0.68 2023-04-19T17:36:13+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.24/0.75/16.5 2023-04-19T17:37:54+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.26/0.49/5.08 2023-04-19T17:39:35+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.24/0.90/10.5 2023-04-19T17:41:16+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.24/0.33/0.73 2023-04-19T17:42:57+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.25/0.48/6.82 2023-04-19T17:44:38+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.23/0.31/0.72 2023-04-19T17:46:19+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.26/0.34/0.96 2023-04-19T17:48:00+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.25/0.38/2.20 2023-04-19T17:49:42+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.25/0.34/1.83 2023-04-19T17:51:23+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.22/0.39/2.43 2023-04-19T17:53:04+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.25/0.40/3.37 2023-04-19T17:54:45+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.24/0.59/19.1 2023-04-19T17:56:26+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.26/0.37/1.60 2023-04-19T17:58:07+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.24/0.74/10.3 2023-04-19T17:59:48+02:00 router : xmt/rcv/%loss = 100/95/5%, min/avg/max = 0.23/0.85/9.51 2023-04-19T18:01:29+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.23/0.65/6.07 2023-04-19T18:03:10+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.26/0.62/7.03 2023-04-19T18:04:51+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.23/0.31/0.66 2023-04-19T18:06:33+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.26/0.42/5.34 2023-04-19T18:08:14+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.24/0.35/1.71 2023-04-19T18:09:55+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.25/0.60/22.0 2023-04-19T18:11:36+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.26/0.38/2.86 2023-04-19T18:13:17+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.25/0.58/19.6 2023-04-19T18:14:58+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.22/0.32/0.88 2023-04-19T18:16:39+02:00 router : xmt/rcv/%loss = 100/71/29%, min/avg/max = 0.24/0.42/3.89 2023-04-19T18:18:20+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.24/0.63/17.3 2023-04-19T18:20:01+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.25/0.65/7.45 2023-04-19T18:21:42+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.25/0.83/8.51 2023-04-19T18:23:24+02:00 router : xmt/rcv/%loss = 100/73/27%, min/avg/max = 0.26/0.62/8.27 2023-04-19T18:25:05+02:00 router : xmt/rcv/%loss = 100/59/41%, min/avg/max = 0.25/0.45/7.62 2023-04-19T18:26:46+02:00 router : xmt/rcv/%loss = 100/71/29%, min/avg/max = 0.25/0.42/6.86 2023-04-19T18:28:27+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.19/0.88/39.4 2023-04-19T18:30:08+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.26/0.32/1.00 2023-04-19T18:31:49+02:00 router : xmt/rcv/%loss = 100/69/31%, min/avg/max = 0.26/0.31/0.52 2023-04-19T18:33:30+02:00 router : xmt/rcv/%loss = 100/70/30%, min/avg/max = 0.26/0.36/0.94 2023-04-19T18:35:11+02:00 router : xmt/rcv/%loss = 100/71/29%, min/avg/max = 0.20/0.40/1.96 2023-04-19T18:36:52+02:00 router : xmt/rcv/%loss = 100/73/27%, min/avg/max = 0.21/0.32/1.45 2023-04-19T18:38:33+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.24/0.35/2.62 2023-04-19T18:40:15+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.25/0.37/2.91 2023-04-19T18:41:56+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.25/0.68/7.88 2023-04-19T18:43:37+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.25/0.83/11.4 2023-04-19T18:45:18+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.23/0.39/6.64 2023-04-19T18:46:59+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.25/1.14/65.5 2023-04-19T18:48:40+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.24/0.62/13.1 2023-04-19T18:50:21+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.25/0.33/1.25 2023-04-19T18:52:02+02:00 router : xmt/rcv/%loss = 100/98/2%, min/avg/max = 0.24/0.35/1.36 2023-04-19T18:53:43+02:00 router : xmt/rcv/%loss = 100/94/6%, min/avg/max = 0.25/0.39/4.64 2023-04-19T18:55:24+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.25/0.40/6.37 2023-04-19T18:57:06+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.26/0.32/0.68 2023-04-19T18:58:47+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.25/0.70/26.5 2023-04-19T19:00:28+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.25/0.93/27.5 2023-04-19T19:02:09+02:00 router : xmt/rcv/%loss = 100/94/6%, min/avg/max = 0.25/0.75/7.79 2023-04-19T19:03:50+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.25/1.02/40.1 2023-04-19T19:05:31+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.22/0.95/49.1 2023-04-19T19:07:12+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.26/0.33/0.67 2023-04-19T19:08:53+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.25/0.66/24.7 2023-04-19T19:10:34+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.25/1.05/37.7 2023-04-19T19:12:15+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.25/0.51/16.2 2023-04-19T19:13:56+02:00 router : xmt/rcv/%loss = 100/94/6%, min/avg/max = 0.23/0.35/0.88 2023-04-19T19:15:38+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.24/0.34/3.61 2023-04-19T19:17:19+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.22/0.31/0.69 2023-04-19T19:19:00+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.25/0.34/0.71 2023-04-19T19:20:41+02:00 router : xmt/rcv/%loss = 100/93/7%, min/avg/max = 0.19/0.31/0.87 2023-04-19T19:22:22+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.24/0.32/0.81 2023-04-19T19:24:03+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.25/0.33/1.49 2023-04-19T19:25:44+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.24/0.42/4.85 2023-04-19T19:27:25+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.24/0.42/6.52 2023-04-19T19:29:06+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.24/1.12/34.8 2023-04-19T19:30:47+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.25/0.81/41.9 2023-04-19T19:32:28+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.24/0.32/0.66 2023-04-19T19:34:09+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.24/0.67/25.0 2023-04-19T19:35:50+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.24/0.32/0.78 2023-04-19T19:37:31+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.26/0.32/0.69 2023-04-19T19:39:12+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.22/0.35/1.60 2023-04-19T19:40:53+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.25/0.56/17.7 2023-04-19T19:42:34+02:00 router : xmt/rcv/%loss = 100/96/4%, min/avg/max = 0.22/0.37/3.26 2023-04-19T19:44:15+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.23/0.34/2.59 2023-04-19T19:45:56+02:00 Isengard to router: Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 100 --quiet router ; done 2023-04-19T14:03:57+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.26/0.39/1.04 2023-04-19T14:05:38+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.27/0.39/1.09 2023-04-19T14:07:19+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.26/0.40/1.53 2023-04-19T14:09:00+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.24/0.42/0.84 2023-04-19T14:10:41+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.24/0.70/25.1 2023-04-19T14:12:22+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.26/0.35/0.66 2023-04-19T14:14:03+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.28/0.43/2.15 2023-04-19T14:15:44+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.24/0.58/9.48 2023-04-19T14:17:26+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.26/0.39/1.30 2023-04-19T14:19:07+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.26/0.52/7.93 2023-04-19T14:20:48+02:00 router : xmt/rcv/%loss = 100/70/30%, min/avg/max = 0.26/2.33/41.3 2023-04-19T14:22:29+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.26/1.31/24.7 2023-04-19T14:24:10+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.24/0.60/7.26 2023-04-19T14:25:51+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.26/0.37/1.28 2023-04-19T14:27:32+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.28/0.39/0.86 2023-04-19T14:29:13+02:00 router : xmt/rcv/%loss = 100/74/26%, min/avg/max = 0.26/0.40/1.15 2023-04-19T14:30:54+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.27/0.53/3.29 2023-04-19T14:32:35+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.26/1.13/48.3 2023-04-19T14:34:16+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.26/0.43/1.59 2023-04-19T14:35:58+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.27/0.40/0.87 2023-04-19T14:37:39+02:00 router : xmt/rcv/%loss = 100/72/28%, min/avg/max = 0.26/0.92/36.8 2023-04-19T14:39:20+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.28/0.50/3.50 2023-04-19T14:41:01+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.26/0.39/1.63 2023-04-19T14:42:42+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.27/0.39/2.28 2023-04-19T14:44:23+02:00 router : xmt/rcv/%loss = 100/74/26%, min/avg/max = 0.25/1.67/22.4 2023-04-19T14:46:04+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.26/1.01/9.75 2023-04-19T14:47:45+02:00 router : xmt/rcv/%loss = 100/73/27%, min/avg/max = 0.26/2.76/66.7 2023-04-19T14:49:26+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.24/0.70/22.3 2023-04-19T14:51:07+02:00 router : xmt/rcv/%loss = 100/73/27%, min/avg/max = 0.25/0.41/1.09 2023-04-19T14:52:48+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.26/0.84/33.4 2023-04-19T14:54:29+02:00 router : xmt/rcv/%loss = 100/96/4%, min/avg/max = 0.24/0.49/8.49 2023-04-19T14:56:11+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.24/0.83/34.2 2023-04-19T14:57:52+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.26/0.62/13.0 2023-04-19T14:59:33+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.26/0.42/3.25 2023-04-19T15:01:14+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.24/0.58/17.9 2023-04-19T15:02:55+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.26/0.40/1.18 2023-04-19T15:04:36+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.26/0.72/20.2 2023-04-19T15:06:17+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.28/0.64/22.1 2023-04-19T15:07:58+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.26/0.48/5.84 2023-04-19T15:09:39+02:00 router : xmt/rcv/%loss = 100/93/7%, min/avg/max = 0.27/1.08/23.0 2023-04-19T15:11:20+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.26/0.67/6.82 2023-04-19T15:13:01+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.27/0.92/15.1 2023-04-19T15:14:43+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.27/1.35/45.1 2023-04-19T15:16:24+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.26/0.39/1.22 2023-04-19T15:18:05+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.25/0.47/4.20 2023-04-19T15:19:46+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.23/0.42/1.52 2023-04-19T15:21:27+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.27/0.37/1.06 2023-04-19T15:23:08+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.26/0.49/4.57 2023-04-19T15:24:49+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.26/0.43/2.44 2023-04-19T15:26:30+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.27/0.38/0.74 2023-04-19T15:28:11+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.23/0.39/0.78 2023-04-19T15:29:52+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.25/0.42/4.89 2023-04-19T15:31:33+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.27/0.95/6.23 2023-04-19T15:33:15+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.28/0.66/5.59 2023-04-19T15:34:56+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.23/1.41/25.6 2023-04-19T15:36:37+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.26/0.86/14.2 2023-04-19T15:38:18+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.25/0.94/30.0 2023-04-19T15:39:59+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.25/0.43/1.16 2023-04-19T15:41:40+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.23/0.37/1.44 2023-04-19T15:43:21+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.27/0.41/3.08 2023-04-19T15:45:02+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.25/0.37/1.21 2023-04-19T15:46:43+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.25/0.39/1.39 2023-04-19T15:48:24+02:00 router : xmt/rcv/%loss = 100/96/4%, min/avg/max = 0.27/0.59/15.2 2023-04-19T15:50:05+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.26/0.39/1.54 2023-04-19T15:51:47+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.26/0.39/0.97 2023-04-19T15:53:28+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.26/0.59/6.71 2023-04-19T15:55:09+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.27/1.37/44.2 2023-04-19T15:56:50+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.28/1.00/16.3 2023-04-19T15:58:31+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.25/0.97/20.1 2023-04-19T16:00:12+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.26/0.37/0.82 2023-04-19T16:01:53+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.27/0.39/0.85 2023-04-19T16:03:34+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.26/0.41/1.50 2023-04-19T16:05:15+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.26/0.38/4.58 2023-04-19T16:06:56+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.28/0.35/0.62 2023-04-19T16:08:37+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.25/0.43/1.69 2023-04-19T16:10:19+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.27/0.36/0.89 2023-04-19T16:12:00+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.26/0.45/6.85 2023-04-19T16:13:41+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.23/0.47/6.29 2023-04-19T16:15:22+02:00 router : xmt/rcv/%loss = 100/69/31%, min/avg/max = 0.27/0.39/1.06 2023-04-19T16:17:03+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.28/1.23/48.7 2023-04-19T16:18:44+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.27/1.90/96.7 2023-04-19T16:20:25+02:00 router : xmt/rcv/%loss = 100/74/26%, min/avg/max = 0.27/0.70/5.82 2023-04-19T16:22:06+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.27/0.44/2.63 2023-04-19T16:23:47+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.26/0.41/1.69 2023-04-19T16:25:28+02:00 router : xmt/rcv/%loss = 100/67/33%, min/avg/max = 0.27/0.47/7.36 2023-04-19T16:27:09+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.26/0.46/3.88 2023-04-19T16:28:51+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.27/0.43/3.96 2023-04-19T16:30:32+02:00 router : xmt/rcv/%loss = 100/66/34%, min/avg/max = 0.26/0.45/5.36 2023-04-19T16:32:13+02:00 router : xmt/rcv/%loss = 100/69/31%, min/avg/max = 0.27/0.36/1.30 2023-04-19T16:33:54+02:00 router : xmt/rcv/%loss = 100/67/33%, min/avg/max = 0.27/0.43/1.35 2023-04-19T16:35:35+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.24/0.52/13.1 2023-04-19T16:37:16+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.28/0.40/1.14 2023-04-19T16:38:57+02:00 router : xmt/rcv/%loss = 100/79/21%, min/avg/max = 0.25/0.43/1.87 2023-04-19T16:40:38+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.28/0.76/12.5 2023-04-19T16:42:19+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.26/1.46/41.2 2023-04-19T16:44:00+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.27/2.00/43.1 2023-04-19T16:45:41+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.24/0.86/25.5 2023-04-19T16:47:22+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.28/0.57/14.0 2023-04-19T16:49:04+02:00 router : xmt/rcv/%loss = 100/74/26%, min/avg/max = 0.27/1.03/39.8 2023-04-19T16:50:45+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.26/0.36/0.90 2023-04-19T16:52:26+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.26/0.50/8.20 2023-04-19T16:54:07+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.27/0.40/1.30 2023-04-19T16:54:07+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.27/0.40/1.30 2023-04-19T16:55:48+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.28/0.39/3.34 2023-04-19T16:57:29+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.25/0.36/0.74 2023-04-19T16:59:10+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.26/0.55/7.99 2023-04-19T17:00:51+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.26/0.46/4.67 2023-04-19T17:02:32+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.27/0.59/14.3 2023-04-19T17:04:13+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.29/0.58/5.72 2023-04-19T17:05:54+02:00 router : xmt/rcv/%loss = 100/74/26%, min/avg/max = 0.27/1.20/8.64 2023-04-19T17:07:36+02:00 router : xmt/rcv/%loss = 100/71/29%, min/avg/max = 0.27/1.32/25.4 2023-04-19T17:09:17+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.27/1.36/21.3 2023-04-19T17:10:58+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.23/0.38/0.83 2023-04-19T17:12:39+02:00 router : xmt/rcv/%loss = 100/72/28%, min/avg/max = 0.26/0.37/0.69 2023-04-19T17:14:20+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.27/0.68/20.3 2023-04-19T17:16:01+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.22/0.59/14.1 2023-04-19T17:17:42+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.26/0.40/2.54 2023-04-19T17:19:23+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.26/0.51/6.24 2023-04-19T17:21:04+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.25/0.54/16.5 2023-04-19T17:22:45+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.27/0.63/15.7 2023-04-19T17:24:26+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.26/0.42/1.98 2023-04-19T17:26:08+02:00 router : xmt/rcv/%loss = 100/72/28%, min/avg/max = 0.26/0.44/3.60 2023-04-19T17:27:49+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.26/0.59/7.82 2023-04-19T17:29:30+02:00 router : xmt/rcv/%loss = 100/72/28%, min/avg/max = 0.23/0.93/8.81 2023-04-19T17:31:11+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.28/1.03/10.0 2023-04-19T17:32:52+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.26/1.27/15.9 2023-04-19T17:34:33+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.28/0.50/6.83 2023-04-19T17:36:14+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.26/0.44/7.16 2023-04-19T17:37:55+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.26/0.46/7.13 2023-04-19T17:39:36+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.23/0.36/1.47 2023-04-19T17:41:17+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.26/0.39/1.76 2023-04-19T17:42:58+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.26/0.39/0.97 2023-04-19T17:44:40+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.25/0.35/0.74 2023-04-19T17:46:21+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.26/0.38/2.44 2023-04-19T17:48:02+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.26/0.46/4.37 2023-04-19T17:49:43+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.23/0.46/4.66 2023-04-19T17:51:24+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.27/0.39/1.19 2023-04-19T17:53:05+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.25/1.56/53.1 2023-04-19T17:54:46+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.27/1.03/11.2 2023-04-19T17:56:27+02:00 router : xmt/rcv/%loss = 100/81/19%, min/avg/max = 0.26/0.71/6.26 2023-04-19T17:58:08+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.26/0.45/3.79 2023-04-19T17:59:49+02:00 router : xmt/rcv/%loss = 100/95/5%, min/avg/max = 0.27/0.38/0.80 2023-04-19T18:01:30+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.28/0.35/0.71 2023-04-19T18:03:12+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.27/0.69/18.3 2023-04-19T18:04:53+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.26/0.42/4.20 2023-04-19T18:06:34+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.25/0.38/2.07 2023-04-19T18:08:15+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.23/0.42/2.51 2023-04-19T18:09:56+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.25/0.37/0.96 2023-04-19T18:11:37+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.25/0.58/6.98 2023-04-19T18:13:18+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.26/0.41/1.90 2023-04-19T18:14:59+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.23/0.37/0.79 2023-04-19T18:16:40+02:00 router : xmt/rcv/%loss = 100/73/27%, min/avg/max = 0.26/0.87/10.1 2023-04-19T18:18:21+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.26/0.78/23.6 2023-04-19T18:20:02+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.24/0.56/5.01 2023-04-19T18:21:43+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.26/0.81/24.2 2023-04-19T18:23:25+02:00 router : xmt/rcv/%loss = 100/72/28%, min/avg/max = 0.25/0.53/7.64 2023-04-19T18:25:06+02:00 router : xmt/rcv/%loss = 100/62/38%, min/avg/max = 0.25/0.40/1.44 2023-04-19T18:26:47+02:00 router : xmt/rcv/%loss = 100/71/29%, min/avg/max = 0.25/0.38/1.60 2023-04-19T18:28:28+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.23/0.48/3.91 2023-04-19T18:30:09+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.25/0.35/0.61 2023-04-19T18:31:50+02:00 router : xmt/rcv/%loss = 100/71/29%, min/avg/max = 0.27/0.39/3.66 2023-04-19T18:33:31+02:00 router : xmt/rcv/%loss = 100/70/30%, min/avg/max = 0.28/0.47/3.68 2023-04-19T18:35:12+02:00 router : xmt/rcv/%loss = 100/72/28%, min/avg/max = 0.25/0.36/1.26 2023-04-19T18:36:53+02:00 router : xmt/rcv/%loss = 100/72/28%, min/avg/max = 0.26/0.38/0.84 2023-04-19T18:38:34+02:00 router : xmt/rcv/%loss = 100/91/9%, min/avg/max = 0.24/0.48/3.19 2023-04-19T18:40:15+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.27/0.95/44.5 2023-04-19T18:41:57+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.26/1.35/30.8 2023-04-19T18:43:38+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.26/1.11/15.0 2023-04-19T18:45:19+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.27/0.92/14.3 2023-04-19T18:47:00+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.25/0.35/0.64 2023-04-19T18:48:41+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.27/0.79/8.68 2023-04-19T18:50:22+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.26/0.39/1.42 2023-04-19T18:52:03+02:00 router : xmt/rcv/%loss = 100/98/2%, min/avg/max = 0.22/0.39/0.99 2023-04-19T18:53:44+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.27/0.44/5.14 2023-04-19T18:55:25+02:00 router : xmt/rcv/%loss = 100/87/13%, min/avg/max = 0.28/0.40/1.35 2023-04-19T18:57:06+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.26/0.60/15.7 2023-04-19T18:58:47+02:00 router : xmt/rcv/%loss = 100/90/10%, min/avg/max = 0.26/0.56/13.6 2023-04-19T19:00:29+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.23/0.35/0.89 2023-04-19T19:02:10+02:00 router : xmt/rcv/%loss = 100/94/6%, min/avg/max = 0.26/0.38/1.40 2023-04-19T19:03:51+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.27/0.94/12.1 2023-04-19T19:05:32+02:00 router : xmt/rcv/%loss = 100/77/23%, min/avg/max = 0.26/1.50/33.2 2023-04-19T19:07:13+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.27/0.74/8.47 2023-04-19T19:08:54+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.26/0.85/22.6 2023-04-19T19:10:35+02:00 router : xmt/rcv/%loss = 100/88/12%, min/avg/max = 0.26/0.78/32.2 2023-04-19T19:12:16+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.27/0.65/20.4 2023-04-19T19:13:57+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.27/0.51/3.21 2023-04-19T19:15:38+02:00 router : xmt/rcv/%loss = 100/83/17%, min/avg/max = 0.28/0.37/1.00 2023-04-19T19:17:19+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.28/0.41/4.54 2023-04-19T19:19:00+02:00 router : xmt/rcv/%loss = 100/75/25%, min/avg/max = 0.23/0.41/2.41 2023-04-19T19:20:41+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.27/0.40/1.59 2023-04-19T19:22:22+02:00 router : xmt/rcv/%loss = 100/76/24%, min/avg/max = 0.28/0.35/1.06 2023-04-19T19:24:04+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.27/0.37/2.39 2023-04-19T19:25:45+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.27/0.34/0.77 2023-04-19T19:27:26+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.26/0.38/4.07 2023-04-19T19:29:07+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.26/0.36/1.78 2023-04-19T19:30:48+02:00 router : xmt/rcv/%loss = 100/89/11%, min/avg/max = 0.23/0.34/0.66 2023-04-19T19:32:29+02:00 router : xmt/rcv/%loss = 100/82/18%, min/avg/max = 0.27/1.00/39.6 2023-04-19T19:34:10+02:00 router : xmt/rcv/%loss = 100/85/15%, min/avg/max = 0.26/0.55/4.86 2023-04-19T19:35:51+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.25/0.34/0.75 2023-04-19T19:37:32+02:00 router : xmt/rcv/%loss = 100/80/20%, min/avg/max = 0.25/0.36/0.74 2023-04-19T19:39:13+02:00 router : xmt/rcv/%loss = 100/84/16%, min/avg/max = 0.26/0.49/5.92 2023-04-19T19:40:54+02:00 router : xmt/rcv/%loss = 100/78/22%, min/avg/max = 0.25/0.58/9.86 2023-04-19T19:42:35+02:00 router : xmt/rcv/%loss = 100/92/8%, min/avg/max = 0.26/0.44/4.96 2023-04-19T19:44:16+02:00 router : xmt/rcv/%loss = 100/86/14%, min/avg/max = 0.26/0.56/13.9 2023-04-19T19:45:57+02:00 1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas I have now placed Legolas on SW1. ping from isengard to Legolas, 0 loses: Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 100 --quiet legolas-e ; done 2023-04-19T19:33:32+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.20/0.51/0.81 2023-04-19T19:35:12+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.18/0.49/0.83 2023-04-19T19:36:52+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.19/0.51/0.86 2023-04-19T19:38:32+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.25/0.53/0.82 2023-04-19T19:40:12+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.19/0.52/0.83 2023-04-19T19:41:53+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.22/0.51/0.79 2023-04-19T19:43:33+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.21/0.51/0.86 2023-04-19T19:45:13+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.19/0.47/0.86 2023-04-19T19:46:53+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.22/0.53/0.81 2023-04-19T19:48:33+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.22/0.47/0.78 2023-04-19T19:50:13+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.21/0.48/0.76 2023-04-19T19:51:53+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.20/0.48/0.78 2023-04-19T19:53:33+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.18/0.44/0.78 2023-04-19T19:55:13+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.19/0.32/0.64 2023-04-19T19:56:53+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.18/0.39/0.74 2023-04-19T19:58:33+02:00 ping from Isengard to SW1 (-c20): cer@Telcontar:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 20 --quiet switch-dn ; done 2023-04-19T19:57:10+02:00 switch-dn : xmt/rcv/%loss = 20/20/0%, min/avg/max = 2.90/3.29/3.68 2023-04-19T19:57:30+02:00 switch-dn : xmt/rcv/%loss = 20/20/0%, min/avg/max = 2.83/3.30/3.72 2023-04-19T19:57:50+02:00 switch-dn : xmt/rcv/%loss = 20/20/0%, min/avg/max = 2.89/3.35/4.45 2023-04-19T19:58:10+02:00 switch-dn : xmt/rcv/%loss = 20/20/0%, min/avg/max = 2.94/3.42/3.77 2023-04-19T19:58:30+02:00 switch-dn : xmt/rcv/%loss = 20/20/0%, min/avg/max = 2.87/3.27/3.72 2023-04-19T19:58:50+02:00 switch-dn : xmt/rcv/%loss = 20/20/0%, min/avg/max = 3.02/3.34/3.74 2023-04-19T19:59:10+02:00 switch-dn : xmt/rcv/%loss = 20/20/0%, min/avg/max = 2.89/3.30/3.73 I can try ping google: cer@Telcontar:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 20 --quiet google.es ; done 2023-04-19T20:01:04+02:00 google.es : xmt/rcv/%loss = 20/17/15%, min/avg/max = 13.7/14.1/15.2 2023-04-19T20:01:25+02:00 google.es : xmt/rcv/%loss = 20/18/10%, min/avg/max = 13.7/14.2/19.9 2023-04-19T20:01:46+02:00 google.es : xmt/rcv/%loss = 20/14/30%, min/avg/max = 13.7/14.0/15.1 2023-04-19T20:02:07+02:00 google.es : xmt/rcv/%loss = 20/15/25%, min/avg/max = 13.7/13.9/14.4 2023-04-19T20:02:28+02:00 google.es : xmt/rcv/%loss = 20/16/20%, min/avg/max = 13.7/13.8/14.1 2023-04-19T20:02:49+02:00 google.es : xmt/rcv/%loss = 20/18/10%, min/avg/max = 13.7/13.9/14.3 2023-04-19T20:03:10+02:00 google.es : xmt/rcv/%loss = 20/18/10%, min/avg/max = 13.5/13.8/15.8 2023-04-19T20:03:31+02:00 google.es : xmt/rcv/%loss = 20/19/5%, min/avg/max = 13.3/14.2/23.4 2023-04-19T20:03:52+02:00 google.es : xmt/rcv/%loss = 20/17/15%, min/avg/max = 13.4/14.4/24.7 2023-04-19T20:04:13+02:00 google.es : xmt/rcv/%loss = 20/19/5%, min/avg/max = 13.6/14.3/19.2 2023-04-19T20:04:34+02:00 google.es : xmt/rcv/%loss = 20/18/10%, min/avg/max = 13.4/13.8/15.2 2023-04-19T20:04:55+02:00 google.es : xmt/rcv/%loss = 20/16/20%, min/avg/max = 13.5/13.6/14.0 2023-04-19T20:05:16+02:00 google.es : xmt/rcv/%loss = 20/18/10%, min/avg/max = 13.5/15.3/35.6 2023-04-19T20:05:37+02:00 google.es : xmt/rcv/%loss = 20/19/5%, min/avg/max = 13.5/14.1/16.6 2023-04-19T20:05:58+02:00 google.es : xmt/rcv/%loss = 20/17/15%, min/avg/max = 11.5/11.6/11.7 2023-04-19T20:06:19+02:00 google.es : xmt/rcv/%loss = 20/16/20%, min/avg/max = 11.6/11.6/11.8 2023-04-19T20:06:40+02:00 ^Cgoogle.es : xmt/rcv/%loss = 6/6/0%, min/avg/max = 11.6/11.7/11.9 ^C cer@Telcontar:~> Now I change the wiring, placing the laptop Legolas directly on the router (same cable): 1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas I have to wait a bit to collect the data. Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 100 --quiet legolas-e ; done 2023-04-19T20:10:56+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.30/0.53/0.96 2023-04-19T20:12:36+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.21/0.52/0.96 2023-04-19T20:14:16+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.22/0.53/0.75 2023-04-19T20:15:56+02:00 legolas-e : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.22/0.53/0.82 2023-04-19T20:17:36+02:00 See? zero loses. My hardware is fine, the problem is inside the router, its sofware. The switching part of the router is fine. I can put now Legolas on WiFi, on the router. Isengard:~ # while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; fping -c 100 --quiet legolas ; done 2023-04-19T20:26:32+02:00 legolas : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.69/119/232 2023-04-19T20:28:12+02:00 legolas : xmt/rcv/%loss = 100/100/0%, min/avg/max = 3.06/114/257 2023-04-19T20:29:52+02:00 legolas : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.87/115/232 2023-04-19T20:31:32+02:00 That section is also fine. Are you convinced now that it is the router, or do you want more tests? - -- Cheers, Carlos E. R. (from openSUSE 15.4 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCZEA0Ihwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfVeUEAn1WOsPW9Y8I7TAiZjnNs ccc44ZjBAJ9ntGxKRt5VyIlQOTk4fLw+DMNC0g== =Pl70 -----END PGP SIGNATURE-----
Carlos E. R. wrote:
On Wednesday, 2023-04-19 at 16:19 +0200, Per Jessen wrote:
Given how different the results were, there has to be more than "not running the exact same command". I mean, their connections, maybe some hardware, cabling?
Nope.
I'm sorry, but I give up. I can't keep up with you. I have no idea how you hope to diagnose anything when you change variables and topic all the time. -- Per Jessen, Zürich (9.2°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-19 20:48, Per Jessen wrote:
Carlos E. R. wrote:
On Wednesday, 2023-04-19 at 16:19 +0200, Per Jessen wrote:
Given how different the results were, there has to be more than "not running the exact same command". I mean, their connections, maybe some hardware, cabling?
Nope.
I'm sorry, but I give up. I can't keep up with you. I have no idea how you hope to diagnose anything when you change variables and topic all the time.
Just see the output of my commands that prove the problem is inside the router. It refuses to talk with my SW2. It is crystal clear. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-19 20:55, Carlos E. R. wrote:
On 2023-04-19 20:48, Per Jessen wrote:
Carlos E. R. wrote:
On Wednesday, 2023-04-19 at 16:19 +0200, Per Jessen wrote:
Given how different the results were, there has to be more than "not running the exact same command". I mean, their connections, maybe some hardware, cabling?
Nope.
I'm sorry, but I give up. I can't keep up with you. I have no idea how you hope to diagnose anything when you change variables and topic all the time.
Just see the output of my commands that prove the problem is inside the router. It refuses to talk with my SW2. It is crystal clear.
Summary: 1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas ping telcontar → isengard : 0% loss ping isengard → telcontar : 0% loss ping telcontar → router : 0..30% loss ping isengard → router : 0..30% loss ping isengard → legolas : 0% loss ping isengard → sw1 : 0% loss 1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas ping isengard → legolas : 0% loss (uses the switch part of the router) ping isengard → legolas : 0% loss wifi of router I repeat: I had one router for years, no trouble. Comes the technician, changes the router. Connectivity from computer room to router and internet is fully lost. Comes another technician, days later. He looks around for an hour or two. He is baffled. Finally, I manage to convince him to TRY another router. Goes to the car, brings another router, connects it ad hoc, temporary like, not believing me, and hey presto, connectivity is back. Caveat: 30% loses with computer room. He does the replacement. He does look around for half an hour or more, doesn't find the problem. Ok, fine, I say, this is better, don't touch it. He leaves. If the router change caused the problem, the culprit is the router, period. I don't have to test anything else, but I did. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 4/19/23 12:06, Carlos E. R. wrote:
If the router change caused the problem, the culprit is the router, period. I don't have to test anything else, but I did.
It sure looks like it's the router somehow. I know the answer to this question, but I'll ask it anyway. Do you have to use their router? Can you purchase and use your own? I know, probably not. Did you ping the router from Legolas when it was directly connected? Did you try looking at the connection specifics with ethtool when Legolas was connected directly to the router? Was the connection full-duplex at the expected speed? I doubt if that's the problem, but I have seen surprises when using ethtool. Can you replace sw1 with your own router/firewall? Regards, Lew
On 2023-04-19 21:37, Lew Wolfgang wrote:
On 4/19/23 12:06, Carlos E. R. wrote:
If the router change caused the problem, the culprit is the router, period. I don't have to test anything else, but I did.
It sure looks like it's the router somehow.
I know the answer to this question, but I'll ask it anyway. Do you have to use their router? Can you purchase and use your own? I know, probably not.
Regulation say yes, but the ISP does not publish the configuration needed, and it is complex. You have to reverse engineer it. In times of ADSL, I bought a router, and it had a menu to choose which ISP to configure for. So it was easy. I have not seen routers for fibre announcing this feature.
Did you ping the router from Legolas when it was directly connected?
Trying now. Good idea. [...] Yes, there are some losses, using WiFi.
cer@Legolas:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; /usr/sbin/fping -c 100 --quiet router ; done 2023-04-19T22:02:46+02:00 router : xmt/rcv/%loss = 100/95/5%, min/avg/max = 2.73/5.06/30.4 2023-04-19T22:04:27+02:00 router : xmt/rcv/%loss = 100/97/3%, min/avg/max = 2.61/4.82/34.8 2023-04-19T22:06:08+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.15/7.35/112 2023-04-19T22:07:48+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.71/4.27/38.6 2023-04-19T22:09:29+02:00 ^Crouter : xmt/rcv/%loss = 2/2/0%, min/avg/max = 3.47/3.79/4.12 ^C cer@Legolas:~>
Small loses, AFAIK the problem is router ←→ SW2. Notice the strangeness that SW1 is in the middle, but pings from a machine connected on SW1 pinging the router seem not to be affected (recollection say they were affected when the technician looked). Connecting the cable now. Nah, I have to also reset NM for the cable to work. No loses:
cer@Legolas:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; /usr/sbin/fping -c 100 --quiet router ; done 2023-04-19T22:15:04+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.34/0.62/2.66 2023-04-19T22:16:44+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.32/0.62/7.95 2023-04-19T22:18:24+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.35/1.35/31.4 2023-04-19T22:20:04+02:00 ^Crouter : xmt/rcv/%loss = 2/2/0%, min/avg/max = 0.62/0.62/0.62 ^C cer@Legolas:~>
Did you try looking at the connection specifics with ethtool when Legolas was connected directly to the router? Was the connection full-duplex at the expected speed? I doubt if that's the problem, but I have seen surprises when using ethtool.
Ok, can try later, now it is connected on WiFi. [...] Legolas:~ # ethtool -I eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: Twisted Pair PHYAD: 0 Transceiver: external MDI-X: Unknown Supports Wake-on: pumbg Wake-on: d Link detected: yes Legolas:~ #
Can you replace sw1 with your own router/firewall?
sw1 is my own switch, 8 eth sockets. It is the router which I can not replace. SW1 is my older switch; I had it on the computer room, eventually realized 8 mouths were not enough, so got another one with 16, and SW1 went downstairs, close to the router. Ok, connecting now "Legolas" to SW1 and trying pinging the router. I have to wait 5 minutes. 1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas No loses:
cer@Legolas:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; /usr/sbin/fping -c 100 --quiet router ; done 2023-04-19T22:24:52+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.97/4.58/29.8 2023-04-19T22:26:32+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.98/4.01/24.1 2023-04-19T22:28:12+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.92/4.41/28.6 2023-04-19T22:29:52+02:00 ^Crouter : xmt/rcv/%loss = 8/8/0%, min/avg/max = 3.01/3.38/3.81 ^C cer@Legolas:~>
The problems are only on machines on the computer room connected to SW2 and going to the router and internet. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 4/19/23 13:31, Carlos E. R. wrote:
On 2023-04-19 21:37, Lew Wolfgang wrote:
On 4/19/23 12:06, Carlos E. R. wrote:
If the router change caused the problem, the culprit is the router, period. I don't have to test anything else, but I did.
It sure looks like it's the router somehow.
I know the answer to this question, but I'll ask it anyway. Do you have to use their router? Can you purchase and use your own? I know, probably not.
Regulation say yes, but the ISP does not publish the configuration needed, and it is complex. You have to reverse engineer it.
I wonder, since there's a regulation, if you could buy your own router then have your ISP come out and configure it for you?
In times of ADSL, I bought a router, and it had a menu to choose which ISP to configure for. So it was easy. I have not seen routers for fibre announcing this feature.
Did you ping the router from Legolas when it was directly connected?
Trying now. Good idea. [...] Yes, there are some losses, using WiFi.
Those Wifi losses seem a bit high, I'll have to try that here.
cer@Legolas:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; /usr/sbin/fping -c 100 --quiet router ; done 2023-04-19T22:02:46+02:00 router : xmt/rcv/%loss = 100/95/5%, min/avg/max = 2.73/5.06/30.4 2023-04-19T22:04:27+02:00 router : xmt/rcv/%loss = 100/97/3%, min/avg/max = 2.61/4.82/34.8 2023-04-19T22:06:08+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.15/7.35/112 2023-04-19T22:07:48+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.71/4.27/38.6 2023-04-19T22:09:29+02:00 ^Crouter : xmt/rcv/%loss = 2/2/0%, min/avg/max = 3.47/3.79/4.12 ^C cer@Legolas:~>
Small loses, AFAIK the problem is router ←→ SW2. Notice the strangeness that SW1 is in the middle, but pings from a machine connected on SW1 pinging the router seem not to be affected (recollection say they were affected when the technician looked).
Connecting the cable now. Nah, I have to also reset NM for the cable to work.
No loses:
cer@Legolas:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; /usr/sbin/fping -c 100 --quiet router ; done 2023-04-19T22:15:04+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.34/0.62/2.66 2023-04-19T22:16:44+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.32/0.62/7.95 2023-04-19T22:18:24+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.35/1.35/31.4 2023-04-19T22:20:04+02:00 ^Crouter : xmt/rcv/%loss = 2/2/0%, min/avg/max = 0.62/0.62/0.62 ^C cer@Legolas:~>
So could the problem be the connection between sw1 and sw2?
Did you try looking at the connection specifics with ethtool when Legolas was connected directly to the router? Was the connection full-duplex at the expected speed? I doubt if that's the problem, but I have seen surprises when using ethtool.
Ok, can try later, now it is connected on WiFi. [...] Legolas:~ # ethtool -I eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: Twisted Pair PHYAD: 0 Transceiver: external MDI-X: Unknown Supports Wake-on: pumbg Wake-on: d Link detected: yes Legolas:~ #
That all seems okay.
Can you replace sw1 with your own router/firewall?
sw1 is my own switch, 8 eth sockets. It is the router which I can not replace.
SW1 is my older switch; I had it on the computer room, eventually realized 8 mouths were not enough, so got another one with 16, and SW1 went downstairs, close to the router.
Ok, connecting now "Legolas" to SW1 and trying pinging the router. I have to wait 5 minutes.
1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas
No loses:
cer@Legolas:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; /usr/sbin/fping -c 100 --quiet router ; done 2023-04-19T22:24:52+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.97/4.58/29.8 2023-04-19T22:26:32+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.98/4.01/24.1 2023-04-19T22:28:12+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.92/4.41/28.6 2023-04-19T22:29:52+02:00 ^Crouter : xmt/rcv/%loss = 8/8/0%, min/avg/max = 3.01/3.38/3.81 ^C cer@Legolas:~>
The problems are only on machines on the computer room connected to SW2 and going to the router and internet.
Strange, it's a real mystery. Regards, Lew
On 4/19/23 13:57, Lew Wolfgang wrote:
Trying now. Good idea. [...] Yes, there are some losses, using WiFi.
Those Wifi losses seem a bit high, I'll have to try that here.
cer@Legolas:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; /usr/sbin/fping -c 100 --quiet router ; done 2023-04-19T22:02:46+02:00 router : xmt/rcv/%loss = 100/95/5%, min/avg/max = 2.73/5.06/30.4 2023-04-19T22:04:27+02:00 router : xmt/rcv/%loss = 100/97/3%, min/avg/max = 2.61/4.82/34.8 2023-04-19T22:06:08+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.15/7.35/112 2023-04-19T22:07:48+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.71/4.27/38.6 2023-04-19T22:09:29+02:00 ^Crouter : xmt/rcv/%loss = 2/2/0%, min/avg/max = 3.47/3.79/4.12 ^C cer@Legolas:~>
Small loses, AFAIK the problem is router ←→ SW2. Notice the strangeness that SW1 is in the middle, but pings from a machine connected on SW1 pinging the router seem not to be affected (recollection say they were affected when the technician looked).
I just tried fping to my Asus WiFi router from a HP laptop and got better numbers. The router is located about 12-meters away with a number of walls and furniture in the way. 192.168.10.213 : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.03/0.05/0.07 Notice the round-trip packet times though! You've got 112-msec max! My packet times are more than three-orders of magnitude less than yours! IIRC NM reported 62% signal strength when it connected. Do you have access to another WiFi hub that you could plug in temporarily for testing? My WiFi router is fed from my Zyxel router/firewall which is fed from my Motorola DOCIS 3.1 cable modem, not that it makes any difference here. Regards, Lew
On 2023-04-20 00:24, Lew Wolfgang wrote:
On 4/19/23 13:57, Lew Wolfgang wrote:
Trying now. Good idea. [...] Yes, there are some losses, using WiFi.
Those Wifi losses seem a bit high, I'll have to try that here.
cer@Legolas:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; /usr/sbin/fping -c 100 --quiet router ; done 2023-04-19T22:02:46+02:00 router : xmt/rcv/%loss = 100/95/5%, min/avg/max = 2.73/5.06/30.4 2023-04-19T22:04:27+02:00 router : xmt/rcv/%loss = 100/97/3%, min/avg/max = 2.61/4.82/34.8 2023-04-19T22:06:08+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.15/7.35/112 2023-04-19T22:07:48+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.71/4.27/38.6 2023-04-19T22:09:29+02:00 ^Crouter : xmt/rcv/%loss = 2/2/0%, min/avg/max = 3.47/3.79/4.12 ^C cer@Legolas:~>
Small loses, AFAIK the problem is router ←→ SW2. Notice the strangeness that SW1 is in the middle, but pings from a machine connected on SW1 pinging the router seem not to be affected (recollection say they were affected when the technician looked).
I just tried fping to my Asus WiFi router from a HP laptop and got better numbers. The router is located about 12-meters away with a number of walls and furniture in the way.
192.168.10.213 : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.03/0.05/0.07
Notice the round-trip packet times though! You've got 112-msec max! My packet times are more than three-orders of magnitude less than yours! IIRC NM reported 62% signal strength when it connected. Do you have access to another WiFi hub that you could plug in temporarily for testing?
Yes, near SW2. It doesn't serve to test router or SW1. Older WiFi, actually. Doesn't bother me, the wifi speed or latency. Not a problem. Packet loss is.
My WiFi router is fed from my Zyxel router/firewall which is fed from my Motorola DOCIS 3.1 cable modem, not that it makes any difference here.
-- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-19 22:57, Lew Wolfgang wrote:
On 4/19/23 13:31, Carlos E. R. wrote:
On 2023-04-19 21:37, Lew Wolfgang wrote:
On 4/19/23 12:06, Carlos E. R. wrote:
If the router change caused the problem, the culprit is the router, period. I don't have to test anything else, but I did.
It sure looks like it's the router somehow.
I know the answer to this question, but I'll ask it anyway. Do you have to use their router? Can you purchase and use your own? I know, probably not.
Regulation say yes, but the ISP does not publish the configuration needed, and it is complex. You have to reverse engineer it.
I wonder, since there's a regulation, if you could buy your own router then have your ISP come out and configure it for you?
No. I would need to fight Goliath in the EU court at my expense.
In times of ADSL, I bought a router, and it had a menu to choose which ISP to configure for. So it was easy. I have not seen routers for fibre announcing this feature.
Did you ping the router from Legolas when it was directly connected?
Trying now. Good idea. [...] Yes, there are some losses, using WiFi.
Those Wifi losses seem a bit high, I'll have to try that here.
cer@Legolas:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; /usr/sbin/fping -c 100 --quiet router ; done 2023-04-19T22:02:46+02:00 router : xmt/rcv/%loss = 100/95/5%, min/avg/max = 2.73/5.06/30.4 2023-04-19T22:04:27+02:00 router : xmt/rcv/%loss = 100/97/3%, min/avg/max = 2.61/4.82/34.8 2023-04-19T22:06:08+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.15/7.35/112 2023-04-19T22:07:48+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 2.71/4.27/38.6 2023-04-19T22:09:29+02:00 ^Crouter : xmt/rcv/%loss = 2/2/0%, min/avg/max = 3.47/3.79/4.12 ^C cer@Legolas:~>
Small loses, AFAIK the problem is router ←→ SW2. Notice the strangeness that SW1 is in the middle, but pings from a machine connected on SW1 pinging the router seem not to be affected (recollection say they were affected when the technician looked).
Connecting the cable now. Nah, I have to also reset NM for the cable to work.
No loses:
cer@Legolas:~> while sleep 1 ; do DATE=`date --iso=s` ; echo -n "$DATE " ; /usr/sbin/fping -c 100 --quiet router ; done 2023-04-19T22:15:04+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.34/0.62/2.66 2023-04-19T22:16:44+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.32/0.62/7.95 2023-04-19T22:18:24+02:00 router : xmt/rcv/%loss = 100/100/0%, min/avg/max = 0.35/1.35/31.4 2023-04-19T22:20:04+02:00 ^Crouter : xmt/rcv/%loss = 2/2/0%, min/avg/max = 0.62/0.62/0.62 ^C cer@Legolas:~>
So could the problem be the connection between sw1 and sw2?
No. With this setup: 1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas Or this: 1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas There are zero loses Isengard ←→ Legolas.
The problems are only on machines on the computer room connected to SW2 and going to the router and internet.
Strange, it's a real mystery.
I know, the Telefónica technician gave up. He said, buy a cheap plain switch instead. These routers are cheap, so get a cheap router. It will work better. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-19 16:31, Carlos E. R. wrote:
Regulation say yes, but the ISP does not publish the configuration needed, and it is complex. You have to reverse engineer it.
My ISP didn't publish it either. I went with what others in the pfSense forum were doing and later, someone in my ISP's community forum posted what was needed for pfSense. However, I have never seen anything official from them.
On 2023-04-19 23:01, James Knott wrote:
On 2023-04-19 16:31, Carlos E. R. wrote:
Regulation say yes, but the ISP does not publish the configuration needed, and it is complex. You have to reverse engineer it.
My ISP didn't publish it either. I went with what others in the pfSense forum were doing and later, someone in my ISP's community forum posted what was needed for pfSense. However, I have never seen anything official from them.
My router has to cover TV, internet, and possibly, voice phone. It is complicated. Forget anything about making my own box, it has to be something purchased and almost ready to go by a dedicated manufacturer that understands these people. A box that says "Telefónica Spain fibre router ready". They maintain it remotely, and without that, IPv6 would not be working now. If I have to replace something, I'd bet on SW2. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Wed, Apr 19, 2023 at 10:06 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2023-04-19 20:55, Carlos E. R. wrote:
On 2023-04-19 20:48, Per Jessen wrote:
Carlos E. R. wrote:
On Wednesday, 2023-04-19 at 16:19 +0200, Per Jessen wrote:
Given how different the results were, there has to be more than "not running the exact same command". I mean, their connections, maybe some hardware, cabling?
Nope.
I'm sorry, but I give up. I can't keep up with you. I have no idea how you hope to diagnose anything when you change variables and topic all the time.
Just see the output of my commands that prove the problem is inside the router. It refuses to talk with my SW2. It is crystal clear.
Summary:
1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas
ping telcontar → isengard : 0% loss ping isengard → telcontar : 0% loss
ping telcontar → router : 0..30% loss
ping isengard → router : 0..30% loss
"router" is hopelessly ambiguous here. "Router" by definition has multiple addresses and you neither showed your complete addressing plan nor told what router address you access.
ping isengard → legolas : 0% loss
ping isengard → sw1 : 0% loss
This lacks legolas - router tests.
1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas
ping isengard → legolas : 0% loss
(uses the switch part of the router)
ping isengard → legolas : 0% loss wifi of router
So far from this summary, pings inside your LAN are OK and pings to an unknown address that you call "router" are not OK. I fail to see how it points at one of the switches as the root cause. And it certainly lacks tests from the switches themselves.
I repeat:
I had one router for years, no trouble. Comes the technician, changes the router.
Connectivity from computer room to router and internet is fully lost.
How are we expected to know what a "computer room" is and what devices are there?
On 2023-04-20 09:01, Andrei Borzenkov wrote:
On Wed, Apr 19, 2023 at 10:06 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
On 2023-04-19 20:55, Carlos E. R. wrote:
On 2023-04-19 20:48, Per Jessen wrote:
Carlos E. R. wrote:
On Wednesday, 2023-04-19 at 16:19 +0200, Per Jessen wrote:
Given how different the results were, there has to be more than "not running the exact same command". I mean, their connections, maybe some hardware, cabling?
Nope.
I'm sorry, but I give up. I can't keep up with you. I have no idea how you hope to diagnose anything when you change variables and topic all the time.
Just see the output of my commands that prove the problem is inside the router. It refuses to talk with my SW2. It is crystal clear.
Summary:
1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas
ping telcontar → isengard : 0% loss ping isengard → telcontar : 0% loss
ping telcontar → router : 0..30% loss
ping isengard → router : 0..30% loss
"router" is hopelessly ambiguous here. "Router" by definition has multiple addresses and you neither showed your complete addressing plan nor told what router address you access.
The problem goes back for months, since the technician installed it, thus before I had IPv6. The only address it has, for the purpose of this test, is the usual 192.168.1.1. It is the typical consumer router provided by an ISP: it connects to the internet on one side, using fiber, and to the home LAN on the other, using 4 ethernet mouths and wifi. Model is "Mitrastar-HGW-2501GN". I have the manual in Spanish, dated 2014. The router is probably manufactured to specs from Telefónica, so I have not found an English manual to download. It is a piece of crap. I can not access its log. Route on this computer is: default via 192.168.1.1 dev eth0 192.168.0.0/16 dev eth0 proto kernel scope link src 192.168.1.14 So the router and network is configured for a /16 network. The installer did the typical /24, made no difference to this problem. https://www.manualslib.com/manual/2475708/Mitrastar-Hgw-2501gn-R2.html (English manual online, no download) https://accesorouter.com/router-mitrastar-hgw-2501gn-r2/ <https://www.movistar.es/particulares/atencion-cliente/internet/adsl/equipamiento-adsl/routers/mitrastar/> (ISP doc page)
ping isengard → legolas : 0% loss
ping isengard → sw1 : 0% loss
This lacks legolas - router tests.
Lew asked for that yesterday, it is on another post. Zero loses. Same results connecting Legolas to SW1, to router, or to router via WiFi.
1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas
ping isengard → legolas : 0% loss
(uses the switch part of the router)
ping isengard → legolas : 0% loss wifi of router
So far from this summary, pings inside your LAN are OK and pings to an unknown address that you call "router" are not OK. I fail to see how it points at one of the switches as the root cause.
Because (currently) only pings traversing SW2 and going to the router (192.168.1.1) or internet have loses. When the router was installed, pings traversing SW2 or SW1 had trouble.
And it certainly lacks tests from the switches themselves.
Because I can not do them. SW1 management is only via a Windows app (TP Link Easy Smart). SW2 I lost the password, so I have no access. I have on my ToDo list to to a factory reset on it. Looking at SW1 with TP Link Easy Smart inside Windows virtual machine: It has a "cable test facility". Success. Stats say that port 2 received 158080670 packets, and 864 bad (that could be two months, but it does not say). It send 317033596, none bad. That's the cable going to SW2. Status is "1000M Full". Flow control is off. IGMP snooping is on (needed for TV). Report message suppression is neither on nor off. No VLAN nor LAG groups defined. Loop prevention is disabled. Port mirror is disabled. QOS is port based, and is set to highest on port 1 (to router) and port 2 (SW2). I could change it to 802.1P based, whatever that means. Bandwidth control is set to unlimited. Storm control is disabled. I do not see anywhere a facility to send pings, sorry.
I repeat:
I had one router for years, no trouble. Comes the technician, changes the router.
Connectivity from computer room to router and internet is fully lost.
How are we expected to know what a "computer room" is and what devices are there?
Well, it is simply a bedroom in my house that I call that, where I sit with my computers. No bed. There is a switch, SW2, connected to downstairs SW1 (50 metres of cable, gigabit speed). I have my desktop computer, a mini server, a printer, an access point, a scanner, a new laptop, a TV recorder... Does it really matter? Any information you need, just ask. Better if you tell what command to try to obtain that information. I'm not hiding information, I just do not know you want it. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Thu, Apr 20, 2023 at 1:12 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
"router" is hopelessly ambiguous here. "Router" by definition has multiple addresses and you neither showed your complete addressing plan nor told what router address you access.
The problem goes back for months, since the technician installed it, thus before I had IPv6. The only address it has, for the purpose of this test, is the usual 192.168.1.1.
One of your earlier posts showed an IPv6 address, not 192.168.1.1.
On 2023-04-20 12:44, Andrei Borzenkov wrote:
On Thu, Apr 20, 2023 at 1:12 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
"router" is hopelessly ambiguous here. "Router" by definition has multiple addresses and you neither showed your complete addressing plan nor told what router address you access.
The problem goes back for months, since the technician installed it, thus before I had IPv6. The only address it has, for the purpose of this test, is the usual 192.168.1.1.
One of your earlier posts showed an IPv6 address, not 192.168.1.1.
Yes, but that address is only since Monday. The problem started the minute the router was installed, with only IPv4 service. My tests on this thread are only using IPv4, but those I have done using IPv6 show the same problem. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On Thu, Apr 20, 2023 at 1:12 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
Does it really matter?
When you talk to others you are expected to use common language. "My server room" certainly is not commonly understood unless you explain what equipment is located in this server room. And no, I am not really interested in it, it is just an extra step and extra noise. What I expect from you, is a clear explanation which devices have problems and how they are interconnected. The diagram was enough for this purpose. Adding "my computer room lost access" added nothing to it, but if you felt important to mention it I assume it provided some additional information. But it failed to convey this information in the form others can understand.
On 2023-04-20 12:53, Andrei Borzenkov wrote:
On Thu, Apr 20, 2023 at 1:12 PM Carlos E. R. <robin.listas@telefonica.net> wrote:
Does it really matter?
When you talk to others you are expected to use common language. "My server room" certainly is not commonly understood unless you explain what equipment is located in this server room.
And no, I am not really interested in it, it is just an extra step and extra noise. What I expect from you, is a clear explanation which devices have problems and how they are interconnected. The diagram was enough for this purpose. Adding "my computer room lost access" added nothing to it, but if you felt important to mention it I assume it provided some additional information. But it failed to convey this information in the form others can understand.
Ok, it meant this: 1 2 router-----sw1------sw2-----telcontar \ \-----isengard \Legolas ("computer room" is SW2) All machines connected to SW2 lost connectivity to internet when the old router was replaced by "Telefónica technician #1". Also machines connected to sw1 lost connectivity to internet. Machines connected directly to the router worked. But any machine connected to SW1 could connect fine to any machine connected to SW2. Then the "Telefónica technician #2" came, and after 2 hours of testing, I could convince him to replace the router. Instantly connectivity was back, albeit with loses, varying from 5 to 30%. After a month or two, the errors going from things connected at SW1 to the router or internet, stopped. That's all. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
Carlos E. R. wrote:
fiber, and to the home LAN on the other, using 4 ethernet mouths and wifi. Model is "Mitrastar-HGW-2501GN". I have the manual in Spanish, dated 2014. The router is probably manufactured to specs from Telefónica, so I have not found an English manual to download.
Funny - that was the first I found. It is 98% in English. https://www.movistar.es/rpmm/estaticos/residencial/fijo/banda-ancha-adsl/man... Mitrastar used to be called Zyxel, but Zyxel spun off their ODM business and called it Mitrastar, somewhere around 2010. -- Per Jessen, Zürich (7.4°C) Member, openSUSE Heroes (2016 - present) We're hiring - https://en.opensuse.org/openSUSE:Heroes
On 2023-04-20 13:18, Per Jessen wrote:
Carlos E. R. wrote:
fiber, and to the home LAN on the other, using 4 ethernet mouths and wifi. Model is "Mitrastar-HGW-2501GN". I have the manual in Spanish, dated 2014. The router is probably manufactured to specs from Telefónica, so I have not found an English manual to download.
Funny - that was the first I found. It is 98% in English. https://www.movistar.es/rpmm/estaticos/residencial/fijo/banda-ancha-adsl/man...
Ah, you are right, the name on the link is in Spanish, but the PDF itself is in Spanish.
Mitrastar used to be called Zyxel, but Zyxel spun off their ODM business and called it Mitrastar, somewhere around 2010.
Ah! I did not know this. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-20 12:12, Carlos E. R. wrote:
On 2023-04-20 09:01, Andrei Borzenkov wrote:
On Wed, Apr 19, 2023 at 10:06 PM Carlos E. R. <> wrote:
And it certainly lacks tests from the switches themselves.
Because I can not do them.
SW1 management is only via a Windows app (TP Link Easy Smart).
SW2 I lost the password, so I have no access. I have on my ToDo list to to a factory reset on it.
I recovered SW2, it was the default password, admin/admin. That's why it was not saved in my password store, because I had not changed it. Done. Yiks. Still I can not do pings from inside SW2. It does have a web page. I do not see anything relevant. Maybe the mask, which was 255.255.255.0, now changed to 255.255.0.0, but makes no difference. Model is TP Link TL-SG1016DE I will have to check firmware upgrades. [...] <https://www.tp-link.com/es/support/download/tl-sg1016de/v3/#Firmware> I did the upgrade to Firmware Version 1.0.1 Build 20180629 Rel.58355 <== Hardware Version TL-SG1016DE 3.0 And the problem has solved itself :-)) Zero ping errors to the router. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-19 18:05, Lew Wolfgang wrote:
On 4/19/23 05:26, Carlos E. R. wrote:
I assume 1, 2 and 3 are cables/connections? physical or wireless?
Ethernet cable.
Out of curiosity, have you tried new cables? We've seen strange network problems caused by bad cables.
Considering that I know that the problem is the router, I changed the cable between the router and sw1, no change. The technician also tried that. I repeat: I had one router for years, no trouble. Comes the technician, changes the router. Connectivity from computer room to router and internet is fully lost. Comes another technician, days later. He looks around for an hour or two. He is baffled. Finally, I can convince him to TRY another router. Goes to the car, brings another router, connects it ad hoc, and hey presto, connectivity is back. Caveat: 30% loses with computer room. He does the replacement. He does look around for half an hour or more, doesn't find the problem. Ok, fine, I say, this is better, don't touch it. See pings on another post. -- Cheers / Saludos, Carlos E. R. (from 15.4 x86_64 at Telcontar)
On 2023-04-18 05:34, Per Jessen wrote:
I have no idea which is the IPv6 address of the router or how to find it. Maybe this will do the trick -
ip -6 neigh | grep router
Otherwise
ip -6 neigh | grep mac-addr-of-router
Or just fire up Wireshark and see where all the router advertisements are coming from.
participants (12)
-
Andrei Borzenkov -
Bernd Ritter -
Carlos E. R. -
Carlos E. R. -
Carlos E.R.
-
James Knott -
Lew Wolfgang -
Nohk Two -
Patrick Shanahan -
Per Jessen -
Per Jessen -
Per Jessen