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.
Please specify what you had in logs
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
Please what is the output of
db network show
[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 ~]#
db networks show
Clear the browser cache, use another computer/browser ???
I cannot reproduce
db networks show still shows the old IP address. how can I update that database?
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
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?
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.
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
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.
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…
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
--sourceand let’s speedtest find the default gateway, this solution works for any scenario without multi wan
- A list of interfaces with non-empty
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 126.96.36.199 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
Yes it is something close that today, even if speedtest-cli works with a
A “default route” option mapped to an empty
--source could suit all green-only cases
The 4th field is the IP address
please can you test this version and report if with dhcp you can use speedtest-cli
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
As I already wrote in the PR, I tested the package on a machine with one DHCP green, it works good.