Speedtest uses an old IP from networks database


(Lovemussell) #1

I ran into this issue today and after checking the logs its using an old IP address I no longer have specified. Not sure how to get it to recognize my new IP.


Diagnostics SpeedTest: Cannot retrieve speedtest configuration
(Stéphane de Labrusse) #2

Please specify what you had in logs


(Lovemussell) #3
May 22 18:19:32 ns sudo:  srvmgr : TTY=unknown ; PWD=/usr/share/nethesis/nethserver-manager ; USER=root ; COMMAND=/usr/bin/speedtest-cli --source=192.168.4.20

and here is my wan interface

3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:01:2e:4e:df:91 brd ff:ff:ff:ff:ff:ff
inet 192.168.42.100/24 brd 192.168.42.255 scope global dynamic enp4s0
   valid_lft 83549sec preferred_lft 83549sec
inet6 fe80::201:2eff:fe4e:df91/64 scope link 
   valid_lft forever preferred_lft forever

(Stéphane de Labrusse) #4

Please what is the output of

db network show

And

ip address


(Lovemussell) #5
[root@ns ~]# db network show
[root@ns ~]# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:01:2e:4e:df:90 brd ff:ff:ff:ff:ff:ff
    inet 192.168.8.1/24 brd 192.168.8.255 scope global enp3s0
       valid_lft forever preferred_lft forever
3: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:01:2e:4e:df:91 brd ff:ff:ff:ff:ff:ff
    inet 192.168.42.100/24 brd 192.168.42.255 scope global dynamic enp4s0
       valid_lft 51477sec preferred_lft 51477sec
    inet6 fe80::201:2eff:fe4e:df91/64 scope link 
       valid_lft forever preferred_lft forever
4: wlp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 0c:d2:92:b8:8f:12 brd ff:ff:ff:ff:ff:ff
5: tunrw: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 
    inet 172.16.0.1 peer 172.16.0.2/32 scope global tunrw
       valid_lft forever preferred_lft forever
    inet6 fe80::c2ac:808c:3cc8:77f1/64 scope link flags 800 
       valid_lft forever preferred_lft forever
[root@ns ~]#

(Stéphane de Labrusse) #6

sorry

db networks show


(Stéphane de Labrusse) #7

Clear the browser cache, use another computer/browser ???

I cannot reproduce


(Lovemussell) #8

db networks show still shows the old IP address. how can I update that database?


(Stéphane de Labrusse) #9

then the bug is not in diagtools, but relative to another issue. You should go to the network panel and assign an IP

Do you are in dhcp or a fixed IP


(Lovemussell) #10

I had 192.168.4.20 configured as a static on the red interface. I set it to DHCP in the network panel after I setup a separate VLAN on my router. I went ahead and set it as static instead of DHCP and its working now.

Why wouldn’t it update the network DB after changing to DHCP in the network section of the web panel?


(Davide Principi) #11

IIUC the ipaddr prop is not cleared when DHCP is set on a red interface. It is not cleared because it isn’t used in the expanded configuration.

If some component still uses it, it’s a #bug.


(Stéphane de Labrusse) #12

for diagtools we use the static configuration from the red interface, I have no much ways to retrieve it but I can do a validator to avoid to get a red NIC with DHCP


(Stéphane de Labrusse) #13

We could do by another way, something has probably changed since some months.

  • We can sort the red nic with bootproto === ‘none’
  • if none valid red exists
  • then use green with bootproto === ‘none’
  • if none valid green exists
  • then use speedtest-cli with --source= (IP = NULL)

We must avoid to bind a bad IP, if no IP is specified, speedtest-cli find itself its source IP.


(Davide Principi) #14

Does speedtest fail to find the right IP by itself? Is it absolutely necessary to specify a source?

As alternative generic method, can we get the IP list by parsing ip -o addr list dev IFNAME output, instead of querying the networks DB?

Wouldn’t be useful from the user point of view to list the WAN providers instead of the network interface name? In the end, speedtest-cli is for WAN connections



(Giacomo Sanchietti) #15

The ipaddr property is updated for only green interfaces even when using DHCP.

I propose to change a little the content of the select box which should contain these options:

  • Any (default): do not specify the --source and let’s speedtest find the default gateway, this solution works for any scenario without multi wan
  • A list of interfaces with non-empty ipaddr and bootproto set to none

(Stéphane de Labrusse) #16

effectively no, speedtest-cli can find itself its gateway, but at the end I love to know what NIC it used, mainly if you want to test your multi-wan configuration.

Well not so easy to clean this and it is code that could fail
but it is realizable.

[root@prometheus ~]# ip -o addr list dev eth0
3: eth0    inet 164.132.77.xxx/24 brd 164.132.77.255 scope global eth0\       valid_lft forever preferred_lft forever
3: eth0    inet6 fe80::ff:fe44:xxxx/64 scope link \       valid_lft forever preferred_lft forever

Yes, but what about for people with just one green interface behind their router/firewall

glad to know :slight_smile:

Yes it is something close that today, even if speedtest-cli works with a ---source= empty.


(Davide Principi) #17

A “default route” option mapped to an empty --source could suit all green-only cases

The 4th field is the IP address


(Stéphane de Labrusse) #18

please can you test this version and report if with dhcp you can use speedtest-cli

TK

yum install http://packages.nethserver.org/nethserver/7.5.1804/autobuild/x86_64/Packages/nethserver-diagtools-1.0.1-1.4.pr4.gbde429c.ns7.noarch.rpm

(Giacomo Sanchietti) #19

As I already wrote in the PR, I tested the package on a machine with one DHCP green, it works good.