MTR / tracepath don't work

[amoiseiev]

It would be super helpful for Ops engineers if you could make mtr and tracepath tools work.

Running as 'admin' with 'root privileges:

root@XXXX:~# mtr 8.8.8.8
mtr: unable to get raw sockets

root@XXXX:~# tracepath 8.8.8.8
IP_MTU_DISCOVER: Invalid argument

Windows Build number: 1607

[sunilmut]

@amoiseiev - Thanks for trying out WSL and the feedback. Yes, we are aware that these tools currently don't work on WSL and we are looking into what we can enable. Meanwhile, please also help us prioritize by upvoting (or adding a new task) in the User Voice Page. It will be helpful if you can add specific comments about what you are looking for.

[ghost]

Got the same issue.

[Cercaj]

Got the same issue.

[sunilmut]

@netroby, @Cercaj - thanks for the feedback. As suggested previously, please head out to the user voice page and open a new ticket (upvote, if already exists) for mtr/tracepath support. We use the user voice page to prioritize future work.

[gofirst2220]

its not fixed in latest bash build

[sunilmut]

@gofirst2220 - Thanks for the (re)post. Yes, we are aware that both mtr and 'tracepath` do not currently work on WSL and we are looking to enable them in WSL in future Insider builds. It requires some support in the native Windows networking stack and we are working with the respective team to enable those options. Stay tuned!

[EvilOlaf]

Would be awesome to get more networking stuff usable within WSL. So many ideas...

[ThiefMaster]

👍 on supporting mtr -- winmtr does not support --displaymode 1 for example, so being able to run the real mtr would be a big plus!

[ijesonchen]

Still not working on build 1709 (16299.248)
But ifconfig, ping, nslookup, dig works fine.

[brettus78]

/Bump
Not being able to use mtr is a pain in the neck.
Tried sudo (which is sometimes an issue on Linux boxes) - same issue.

[davidxdbp]

Same issue here... it would be definitely handy for Ops engineers for this to work.

[Ineluctable]

I am having this issue as well.

[chris-morgan]

The feature to make this work (AF_PACKET) is now being tracked in #1349, so this issue might as well be closed as a duplicate of that.

[therealkenc]

This is sort of the landing zone for IP_MTU_DISCOVER, not AF_PACKET. The OP reported two things which is most unfortunate.

[brettus78]

Sadly, until these issues - lack of ability to mtr/traceroute/nmap (to name but a few) - are resolved, there's really no point using WSL (for me) at all.
I guess this stuff is just too early days. Appreciate the efforts, will keep an eye and maybe look at using it again when this stuff is part of it.

[wobblybobz]

It appears that then running Bash for windows normally Permission is denied from opening IPv4 / IPv6 Sockets even with sudo / su. Running Bash on Ubuntu on Windows as Administrator (Right click Ubuntu Icon ->More-> Run as Administrator) and MTR works fine.

[zed76r]

It appears that then running Bash for windows normally Permission is denied from opening IPv4 / IPv6 Sockets even with sudo / su. Running Bash on Ubuntu on Windows as Administrator (Right click Ubuntu Icon ->More-> Run as Administrator) and MTR works fine.

In my case, MTR cannot display any ip(bash.exe run as admin). And traceroute does't work.

[Menci]

I can use mtr with IPv4 if a run WSL with admin and run mtr with root, but I still can't mtr a IPv6 address.

Menci@Menci-Surface:~$ mtr 2001:da8::666
mtr: Permission denied

[nwsparks]

works for me when running as admin

[Gowee]

@Menci Hi. For me, mtr shows nothing when tracing with IPv4 even though running with admin permission in Windows and root permission in WSL as long as the Windows Firewall is active. But non-privileged Windows-native program like tracert / winmtr do work. When you make it work with IPv4, did you disable Windows Firewall?

[Gowee]

"Run as Admin" can be circumvented by avoiding setting IP_HDRINCL socket option, here is a tiny patch that works for me: Gowee/mtr@c0e347c .
Note: To test, MTR_PACKET environment should be the path to mtr-packet, otherwise mtr will use the one given in PATH by default.

Root permission is not necessary as long as CAP_NET_RAW is activated for the program, that is:
# setcap cap_net_raw+ep ./pathto/mtr-packet && setcap cap_net_raw+ep ./pathto/mtr .
This cap should have been set by package managers on most distros when installing mtr.

But disabling Firewall is inevitable. The problem seems to be ICMP errors are not delivered to mtr properly (a test: ping 8.8.8.8 -t 1 should have told TTL exceeded error, but it shows nothing instead very confusing: even with Firewall disabled, ping still does not tell TTL exceeded error).

[besmirzanaj]

really strange

bzanaj@leaf:~$ mtr 8.8.8.8
Failure to open IPv4 sockets: Operation not permitted
Failure to open IPv6 sockets: Operation not permitted
mtr: Failure to start mtr-packet: Invalid argument
bzanaj@leaf:~$ ping 8.8.8.8 -c2
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=121 time=17.9 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=121 time=32.3 ms

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 17.994/25.177/32.360/7.183 ms

[SV-ZeroOne]

Just installed WSL with Kali Linux Distro,
Running as admin permission on Windows and Sudo MTR but this still doesnt work.

Windows version 10.0.17134 Build 17134

[pmop]

Same thing here,
Windows 10.0.18362 on Thinkpad x230;
Alpine Linux.

[kid1412621]

Windows 10.0.18363.535 Ubuntu still doesn't work.

[13xforever]

I see you've added a label fixed-in-wsl2, but my converted ubuntu image still has this problem. Are there some additional steps needed?

[therealkenc]

still has this problem

If "cat /proc/version" returns "Linux version 4.19-microsoft-standard", and simultaneously exhibits this problem ("mtr 8.8.8.8 mtr: unable to get raw sockets"), that would be difficult to explain. There are no additional steps.

[13xforever]

yes, that is the case

[therealkenc]

Appreciate the screencap, thanks. So... not this problem. You are getting an EPERM, which I am not able to reproduce. The OP couldn't get a raw socket (because WSL1 doesn't have 'em).

Spin up another issue, and include as many details about your Windows networking config (notably third party stuff). Also, for the data point, whether tracert.exe 8.8.8.8 succeeds from cmd.exe (as the same user that started WSL above).

[chrisbanm]

So to be clear, if using WSL1 then mtr, etc. you are out of luck because it does not have and never will have raw sockets so use WSL2 if you want that functionality? That's what I think @therealkenc said.

[besmirzanaj]

at this point this issue can be closed as not fixable

[d00rsfan]

at this point this issue can be closed as not fixable
you're wrong.
mtr works perfect if bash run 'Run as administrator".

[mbesemann]

It "works", but doesn't seem to get past localhost and you need to follow the following steps:

1. Run Terminal Preview or WSL as Administrator
2. sudo mtr:

3. sudo mtr google.ca:

For reference, I am running the latest Insider build:

[Fabian123333]

I can confirm, that mtr at least opens in admin mode, but does not send any requests properly:

16:33:15 gettimeofday({tv_sec=1587479595, tv_usec=719169}, NULL) = 0
16:33:15 write(4, "33007 send-probe ip-4 8.8.8.8 local-ip-4 192.168.0.50 protocol icmp size 64 bit-pattern 0 tos 0 ttl 8 timeout 10\n", 113) = 113
16:33:15 select(8, [0 5 7], NULL, NULL, {tv_sec=0, tv_usec=100000}) = 0 (Timeout)
16:33:15 time(NULL)                     = 1587479595 (2020-04-21T16:33:15+0200)
16:33:15 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
16:33:15 rt_sigaction(SIGTSTP, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f5706e61730}, {sa_handler=0x7f5707058940, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f5706e61730}, 8) = 0
16:33:15 poll([{fd=0, events=POLLIN}], 1, 0) = 0 (Timeout)
16:33:15 poll([{fd=0, events=POLLIN}], 1, 0) = 0 (Timeout)
16:33:15 rt_sigaction(SIGTSTP, {sa_handler=0x7f5707058940, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f5706e61730}, NULL, 8) = 0
16:33:15 gettimeofday({tv_sec=1587479595, tv_usec=824349}, NULL) = 0
16:33:15 write(4, "33008 send-probe ip-4 8.8.8.8 local-ip-4 192.168.0.50 protocol icmp size 64 bit-pattern 0 tos 0 ttl 9 timeout 10\n", 113) = 113
16:33:15 select(8, [0 5 7], NULL, NULL, {tv_sec=0, tv_usec=100000}) = 0 (Timeout)
16:33:15 time(NULL)                     = 1587479595 (2020-04-21T16:33:15+0200)
16:33:15 stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=2335, ...}) = 0
16:33:15 rt_sigaction(SIGTSTP, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f5706e61730}, {sa_handler=0x7f5707058940, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f5706e61730}, 8) = 0

It looks as if mtr is not able to get a proper network socket from the related WSL "kernel", also running the newest build.

When trying to dig deeper (strace -f) it totally not works, looks like Microsoft is isolating the WSL to much from the native linux kernel and functionality.

[leleobhz]

@therealkenc

I request reopenning this issue as the issue reported by @Fabian123333 happened here too. WSL2 is not a option for me because NAT-IPv6. WSL1 cannot open the socket properly and this is a issue to be fixed.

Thanks

[leleobhz]

Just reinforcing, this issue cannot be considered fixed-in-wsl2 because wsl2 introduces a totally different network stack and its not suitable by any terms while wsl2 at least support bridge mode + ipv6 without any kind of nat. MTR while used to detect hop issues needs raw sockets since we use all 3 protocols to check connectivity issues and even ecmp and other kind of network propriety.

[kilitary]

upvote to get working hping

[markquitoriano]

Encountered this just now. mtr still not working. Here's my kernel version.

# cat /proc/version
Linux version 4.4.0-18362-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #1049-Microsoft Thu Aug 14 12:01:00 PST 2020

You can't close an issue by creating a different network stack. That's not how it works ;)

Just reinforcing, this issue cannot be considered fixed-in-wsl2 because wsl2 introduces a totally different network stack and its not suitable by any terms while wsl2 at least support bridge mode + ipv6 without any kind of nat. MTR while used to detect hop issues needs raw sockets since we use all 3 protocols to check connectivity issues and even ecmp and other kind of network propriety.

[kilitary]

linux is network system, it should as base support network tools.
i think ms do not need to develop linux stack, just wrapping network stack to linux network libs

[trallnag]

tracert in powershell:

Tracing route to dns.google [8.8.8.8]
over a maximum of 30 hops:

  1     2 ms     1 ms     2 ms  172.16.48.1
  2    10 ms    10 ms     7 ms  cr-dui1-pwether10748.x-win.dfn.de [188.1.242.77]
  3    14 ms    13 ms    13 ms  cr-fra2-be16.x-win.dfn.de [188.1.144.178]
  4    11 ms    11 ms    14 ms  209.85.172.242
  5    17 ms    13 ms    14 ms  108.170.252.1
  6    19 ms    12 ms    11 ms

tracepath in wsl2 after resetting network, flushing dns and so on:

 1?: [LOCALHOST]                      pmtu 1500
 1:  no reply
 2:  ???                                                   3.669ms
 3:  ???                                                   9.725ms
 4:  ???                                                  51.344ms
 5:  no reply
 6:  no reply
 7:  no reply
 8:  no reply
 9:  no reply
10:  no reply
11:  no reply
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
     Too many hops: pmtu 1500
     Resume: pmtu 1500

[mqudsi]

There are two different permissions issues, and only one of them seems to have a workaround.

The first is that mtr in general doesn't run under wsl. The solution there is to start wsl w/ admin permissions (sudo wsl.exe in Windows) then run mtr, optionally w/ elevation ('sudo mtr 1.2.3.4` now works)

The second issue is that even when run w/ elevated Windows and Linux privileges (as above), MTR still cannot get the permissions it needs if the target is an IPv6 host (sudo mtr 1:2:3::4 exits with "mtr: Permission denied").