Netmetr is not working

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 ====
 could not read from server
 could not read from server
 could not read from server
 dl_throughput_mbps = 0.000000
 ul_throughput_mbps = 0.000000
 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/", line 621, in main
   File "/usr/lib/python3.7/site-packages/netmetr/", line 254, in import_speed_flows
 KeyError: 'dl'


config settings 'settings'
    option control_server ''
    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 9.14.12 <<>>
;; 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

; EDNS: version: 0, flags:; udp: 4096
;            IN      A

;; ANSWER SECTION:     360     IN      A

;; Query time: 0 msec
;; WHEN: Sat Jun 06 14:11:13 CEST 2020
;; MSG SIZE  rcvd: 63


# ping -c1 -w1
PING ( 56(84) bytes of data.
64 bytes from ( 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.


true story… forget to paste it here :slightly_smiling_face:

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 :slight_smile:

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.



so I see the update is here. But netmetr is still not working for me :-/

Here is the log:

  • What sort of ISP subscriber line you got?
  • What is the output of check_connection?

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 ... OK
IPv4 Gateway: OK
Pinging ... OK
Pinging ... OK
Pinging ... OK
Pinging ... 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
Resolving ... OK
Resolving ... OK
Resolving ... OK
Resolving ... OK

Meaning that you can access from web browser?

Can you try with mtr (needs to be installed first) - mtr -Tzrbwe (important is the -T, --tcp use TCP instead of ICMP echo)

Yep, I get following answer:


And here is the output from mtr:

mtr -Tzrbwe
Start: 2020-07-07T20:40:53+0200
HOST: turris                                          Loss%   Snt   Last   Avg  Best  Wrst StDev
@Not a TXT record
1. AS??? (                0.0%    10    0.7   1.1   0.7   1.4   0.3
2. AS12570 (              0.0%    10    2.2   2.3   1.4   2.8   0.4
3. AS12570 (   0.0%    10    2.7   2.9   2.3   3.4   0.3
4. AS12570 (     0.0%    10    4.1   3.1   2.1   4.1   0.5
5. AS25192 (         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_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 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

@FrantisekFlinta, you posted the result of opening in a web browser. You should get the same result by opening measurement port) and a similar result when connecting to directly from Turris & also using measurement port 8081.

To connect to from Turris you can use either telnet client or netcat. If I use e.g.:
nc 8081

The result is following:


(and it takes less than one second to get the result)

1 Like


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: ""
4. result_url: ""
5. test_duration: "5"
6. test_id: 8053881
7. test_numpings: "10"
8. test_numthreads: "3"
9. test_server_address: ""
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


user@desktop:~$ nc -vz 8444
Connection to 8444 port [tcp/*] succeeded!
user@desktop:~$ nc -vz 8081
nc: connect to port 8081 (tcp) failed: Connection refused


root@turris:~# nc 8081
nc: can't connect to remote host ( Operation timed out
root@turris:~# nc 8444
1 Like

for extended debug trace mtr -TzrbweP 8081

# mtr -TzrbweP 8081
Start: 2020-07-08T10:18:12+0200
HOST: turris                                    Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. AS25192 (   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 8081