Everytime I try to test my internet netmetr gives me “Testing… FAILED”.
Turris OS: 5.0.0
When I try to login via ssh, this is what I get:
# netmetr
Checking uuid on the control server...
Requesting test config from the control server...
Starting ping test...
ping_1_msec = 9.64
ping_2_msec = 9.21
ping_3_msec = 9.44
ping_4_msec = 9.32
ping_5_msec = 9.17
ping_6_msec = 9.38
ping_7_msec = 9.06
ping_8_msec = 9.67
ping_9_msec = 8.98
ping_10_msec = 9.68
Starting speed test...
==== rmbt 09170aeef ====
connecting...
timeout
could not read from server
timeout
could not read from server
timeout
could not read from server
dl_throughput_mbps = 0.000000
ul_throughput_mbps = 0.000000
Exiting.
Traceback (most recent call last):
File "/usr/bin/netmetr", line 11, in <module>
load_entry_point('netmetr==1.5.4', 'console_scripts', 'netmetr')()
File "/usr/lib/python3.7/site-packages/netmetr/__main__.py", line 621, in main
File "/usr/lib/python3.7/site-packages/netmetr/__main__.py", line 254, in import_speed_flows
KeyError: 'dl'
Configuration:
config settings 'settings'
option control_server 'control.netmetr.cz'
option max_history_logs '10'
option autostart_enabled '1'
list hours_to_run '4'
option client 'HW-PROBE'
option uuid '95d030a0-94a1-48a2-b012-04d9727e7081'
option sync_code 'a95cf7434565'
Dig:
# dig control.netmetr.cz
; <<>> DiG 9.14.12 <<>> control.netmetr.cz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59222
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;control.netmetr.cz. IN A
;; ANSWER SECTION:
control.netmetr.cz. 360 IN A 217.31.202.96
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jun 06 14:11:13 CEST 2020
;; MSG SIZE rcvd: 63
Ping:
# ping -c1 -w1 control.netmetr.cz
PING control.netmetr.cz (217.31.202.96) 56(84) bytes of data.
64 bytes from control.netmetr.cz (217.31.202.96): icmp_req=1 ttl=58 time=10.6 ms
the app has an option for verbose debug output --debug, might help to see what happens (or not)
N.B. you might want to reconsider sharing this
option uuid ''
option sync_code ''
publicly and obfuscate instead, unless you do not mind.
Hi,
true story… forget to paste it here 
https://pastebin.com/7137Gvz1
Looks like an issue with the TCP connectivity between your node and the remote end. From my node the remote is reachable and and responsive.
You would probably have to run a TCP packet dump to figure out the sinkhole.
Strange is, that if I run it on computer behind a Turris directly on the page, everything is working well. I will try to check it tomorrow, but dont know if I will be able to see something in tcpdump output 
have a look at the mtr package, is a bit of advanced route trace
Hi, thank you for your report. This is a known bug - the fix is completed and is going to be merged in a few days & released soon.
2 Likes
Hey,
so I see the update is here. But netmetr is still not working for me :-/
Here is the log: https://pastebin.com/bD1L6jr5
I have optical line (selfnet), but I am actually behind ISP -> Microtic -> Switch -> Turris… but interesting part is that on computer behind Turris, all is working well…
Here is the output:
# check_connection
Pinging 192.168.0.1 ... OK
IPv4 Gateway: OK
Pinging 217.31.205.50 ... OK
Pinging 198.41.0.4 ... OK
Pinging 199.7.83.42 ... OK
Pinging 8.8.8.8 ... OK
IPv4: OK
IPv6 Gateway: UNKNOWN
Pinging 2001:1488:0:3::2 ... FAILED
Pinging 2001:500:3::42 ... FAILED
Pinging 2001:500:2d::d ... FAILED
Pinging 2606:2800:220:6d:26bf:1447:1097:aa7 ... FAILED
IPv6: FAILED
Resolving api.turris.cz ... OK
Resolving www.nic.cz ... OK
Resolving c.root-servers.net ... OK
DNS: OK
Resolving www.rhybar.cz ... OK
DNSSEC: OK
Meaning that you can access ipv4.speed.netmetr.cz from web browser?
Can you try with mtr (needs to be installed first) - mtr -Tzrbwe ipv4.speed.netmetr.cz (important is the -T, --tcp use TCP instead of ICMP echo)
Yep, I get following answer:
RMBTv0.3
ACCEPT TOKEN QUIT
And here is the output from mtr:
mtr -Tzrbwe ipv4.speed.netmetr.cz
Start: 2020-07-07T20:40:53+0200
HOST: turris Loss% Snt Last Avg Best Wrst StDev
@Not a TXT record
1. AS??? 192.168.0.1 (192.168.0.1) 0.0% 10 0.7 1.1 0.7 1.4 0.3
2. AS12570 109.105.51.1 (109.105.51.1) 0.0% 10 2.2 2.3 1.4 2.8 0.4
3. AS12570 vl66-d994-brq.itself.cz (212.96.178.6) 0.0% 10 2.7 2.9 2.3 3.4 0.3
4. AS12570 nic.cz.cust.itself.cz (212.4.152.57) 0.0% 10 4.1 3.1 2.1 4.1 0.5
5. AS25192 speed.netmetr.cz (217.31.202.97) 0.0% 10 10.1 10.7 9.8 11.7 0.6
IPv4 appears peachy and neither netmtr seems to be taking a wrong turn either, pings the remote host OK but then TCP fails mysteriously:
“res_status”:“fail_init”,
“res_status_msg”:“timeout; could not read from server”,
but that is not really verbose enough to identify the cause, fail_init could mean anything.
it should show whether the remote node responds at all (and if it does the sort of response) to the TCP packets generated by the netmetr routine.
So… when I do tcpdump -vv dst ipv4.speed.netmetr.cz and try netmetr from Turris… I do not see any output at all. But when I do test from browser, I see lot of packets going there.
Would seem that netmetr is not emitting any TCP packet then, coming full circle to
, perhaps @mprudek can provide insight on that?
Hi all,
I really think that the problem is not inside netmetr - it seems there’s rather an issue with connectivity to ipv4.speed.netmetr.cz.
@FrantisekFlinta, you posted the result of opening ipv4.speed.netmetr.cz in a web browser. You should get the same result by opening http://ipv4.speed.netmetr.cz:8081/(with measurement port) and a similar result when connecting to ipv4.speed.netmetr.cz directly from Turris & also using measurement port 8081.
To connect to ipv4.speed.netmetr.cz from Turris you can use either telnet client or netcat. If I use e.g.:
nc ipv4.speed.netmetr.cz 8081
The result is following:
RMBTv0.3
ACCEPT TOKEN QUIT
(and it takes less than one second to get the result)
1 Like
Hi,
true. Not working from Turris and also not from desktop… I will ask house owner if he can check it from Mikrotik. I will report back what is the problem.
But how the web test can work? It has some failback to some different port? From browser I see that its connecting to 8444 and telnet there is working well (from Desktop).
From browser:
1. client_remote_ip: "<hidden>"
2. error: []
3. result_qos_url: "https://www.netmetr.cz/en/resultQoS"
4. result_url: "https://www.netmetr.cz/en/result"
5. test_duration: "5"
6. test_id: 8053881
7. test_numpings: "10"
8. test_numthreads: "3"
9. test_server_address: "ipv4.speed.netmetr.cz"
10. test_server_encryption: true
11. test_server_name: "CZ.NIC (Prague)"
12. test_server_port: 8444
13. test_server_type: "RMBTws"
14. test_token: "<hidden>"
15. test_uuid: "<hidden>"
16. test_wait: 0
17. user_server_selection: false
Desktop:
user@desktop:~$ nc -vz ipv4.speed.netmetr.cz 8444
Connection to ipv4.speed.netmetr.cz 8444 port [tcp/*] succeeded!
user@desktop:~$ nc -vz ipv4.speed.netmetr.cz 8081
nc: connect to ipv4.speed.netmetr.cz port 8081 (tcp) failed: Connection refused
Turris:
root@turris:~# nc ipv4.speed.netmetr.cz 8081
nc: can't connect to remote host (217.31.202.97): Operation timed out
root@turris:~# nc ipv4.speed.netmetr.cz 8444
root@turris:~#
1 Like
for extended debug trace mtr -TzrbweP 8081 ipv4.speed.netmetr.cz
# mtr -TzrbweP 8081 ipv4.speed.netmetr.cz
Start: 2020-07-08T10:18:12+0200
HOST: turris Loss% Snt Last Avg Best Wrst StDev
1. AS25192 speed.netmetr.cz (217.31.202.97) 0.0% 10 1.0 1.4 0.8 1.9 0.4
This smacks a bit of a firewall block somewhere along the route. Could you turn on logging for the WAN zone on the O and check the logs for potential drops | rejects from netmetr | nc connectivity?
Also if available install ncat-full package as it has better verbosity output than the busybox applet and then try with ncat -vvv ipv4.speed.netmetr.cz 8081