You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi Szépe,
mtr uses "raw sockets" to generate "weird" networking packets. These are carefully controlled to generate "errors" that tell us something about the network.
But if you can craft "weird" packets you can also make "malicious" packets: Maybe something that would make a server allow you to log in without a password (you tell the server: "No, really, my name is root, not Szépe").
So operating systems will not allow normal users to open "raw" sockets.
Under Linux you have two options: First is to run the program as the "root" user. That's the "sudo su - " option. The superuser has the right to open raw sockets, the superuser can do anything.
The other is to give "the mtr program" the right to run as the root user: "chmod 4755 which mtr". The problem with this approach is that the responsibility: "only crafted packets, not malicious ones" falls on the program, mtr in this case. mtr takes care, but no guarantees can be made. So, although in the past there have been little problems with this last approach, I and many others use it.
How to "elevate privileges for a single program" under windows: I have no idea. Run as administrator sounds like an option.
I have no idea what could be the cause of "displays nothing". Under Linux I'd at least run "strace" on the program to see what it is trying to do. If your operating system has this option: I don't know.
I downloaded the 0.87 release and unzipped it within the Cygwin home directory
I ran ./bootstrap.sh
I ran ./configure --disable-ipv6 --without-gtk
I edited mtr.c and net.c to comment out all instances of SCTP, as Windows does not have native support for that and Cygwin does not ship a compatibility layer for it either.
I edited mtr.c to bypass the UID 0 check on interval.
I ran make.
I used Microsoft's Manifest Tool (mt.exe) to add a manifest to mtr.exe to require running as an Administrator.
How I'm running:
I restarted Cygwin with Administrative privileges.
I ran mtr ${TARGET_IP}.
The ncurses interface initialized successfully, but no output of the tracing process is shown on the screen.
I ran mtr -bewz -c 10 -i 0.01 -s 1400 ${TARGET_IP}. mtr runs to completion, but no report is actually produced.
Issue persists in commit c0bb08b (current HEAD of master branch).
Build instructions:
Download and extract archive of commit in question within Cygwin environment.
Run ./bootstrap.sh.
Run ./configure --disable-ipv6 --disable-bash-completion --without-gtk.
Edit mtr.c to comment out UID 0 check within interval parameter processing.
Add #define _BSD_SOURCE 1 to generated config.h file so u_char, u_int, u_long, u_short, res_send_qhook, res_send_rhook, and timersub are available in order for compilation/linking to complete successfully.
Use mt.exe to add manifest to mtr.exe to require running with Administrative privileges.
I do not have any Windows machines. I get a headache when I have to use them. So if you guys manage to find a way that works, fine. I can try to add a thing or two that mean that you don't have to edit the sources again, but I can't test what I do. So I have to be careful to prevent breaking Linux, BSD, Solaris and others, while trying to make windows/cygwin work.
I took a serious look at what it would take to get mtr running on Windows 7 over the last two days, and things look pretty dire. The real deal-breaker is that I can't manage to receive any ICMP TTL-expired message, with one weird exception, which I'll get to in a moment. Here are some of my observations:
You'd want to use Cygwin as a base. mtr uses select() as its main event loop, waiting for both incoming network packets, keyboard input, and timeouts. Replacing this would be a lot of work, so Cygwin is pretty much the only way to go.
The current code doesn't properly set up raw socket transmission for Windows. Windows requires the sending socket to be bound to the interface you would like to send packets from. mtr would need to figure out which interface is the right one to route to the destination, but the code in net_set_interfaceaddress_udp() already does this for the UDP case. You'd just need to re-purpose this code to be used for ICMP, TCP, etc. This is pretty easy, and after hacking things up a bit, I had mtr sending the correct raw packets without too much trouble.
For receiving, the first wrinkle, though, is that to receive any packets from a raw socket at all, you need to use WSAIoctl to set the receiving socket's SIO_RCVALL parameter to true. This doesn't sound too hard, but WSAIoctl only works on Windows SOCKET handles, and Cygwin's space of socket fd's is a completely different animal than a SOCKET handle. After some digging through the Cygwin source code, I found that you can use Cygwin's 'get_osfhandle' to get the underlying Windows handle from a Cygwin fd object. So, putting that together, you can do something like WSAIoctl(get_osfhandle(recvsock4), SIO_RCVALL, &true_opt, sizeof(true_opt), NULL, 0, &rsize, NULL, NULL) to enable receiving on a raw socket. (Who says the Windows API's aren't a joy to work with? I kid, I kid.)
With the above changes, I can receive ICMP ECHO replies, but not TTL expired messages. I was running Wireshark during my testing, and I could see the TTL expired messages arriving at the Ethernet adapter just fine. As I was running mtr, my DSL modem and hosts beyond were all doing what they should be and sending back TTL expirations, but the Windows TCP/IP stack was filtering these out for some reason. I found the netsh interface ipv4 show ipstats command, and I noticed that for every TTL-expired message received by windows, the counter for "In Unknown Protocol" incremented by one. Very suspicious. However, I know that Windows knows about ICMP, because it was happy to pass along the ICMP echo replies!
Here's where things get weird. If I run tracert.exe (Windows' built-in traceroute), I can actually get those TTL expired messages. Even mtr can receive tracert.exe's TTL expired messages, but not any TTL expired messages in response to packets actually generated by mtr. I thought Windows might have some hackery to indentify "good" TTL expired packets, so I started massaging the ICMP ids, sequence numbers and payload sizes until I was getting response packets that were bit-for-bit identical to the ones generated by tracert.exe's probes, as evidenced by Wireshark. Still no dice. Those seemed to be filtered out too.
I'm grasping at straws here, and I hope someone who knows more about the Windows TCP/IP stack can tell me I'm wrong, but I am beginning to suspect that Windows is doing early discards of any unexpected ICMP traffic that isn't in response to a ping that it knows it sent. How would it be able to distinguish? Well, Windows has this ICMP.DLL library built-in which is used to send and receive pings through a fairly limited API. It's not a raw socket interface -- you can't send arbitrary packets -- but you can send ICMP echos with a particular TTL, and listen for their replies. Both ping.exe and tracert.exe used ICMP.DLL. The only explanation for the weird behavior I am seeing that I can think of is that Windows is whitelisting the TTL expired replies only for packets which were sent through ICMP.DLL.
This rasies the question, could mtr use ICMP.DLL? Yes, I think it could, but the API is significantly different from the Unix-like socket API mtr is currently using, and it is limited to only ICMP, so you'd have to give up support for UDP, TCP and SCTP mtr traces if you did that.
Another, more powerful option, would be to bypass the Windows TCP/IP stack for receiving raw packets and use WinPcap to capture ethernet frames directly, and decode those to find your TTL replies. That's kind of an interesting idea, because since WinPcap operates at the device driver level and timestamps packets when they are received in kernel-land, you'd get more precise timings on round trip time than mtr is currently able to provide. (I'm not sure that any timing jitter due to user-space scheduling matters much in practice on machines which aren't under heavy CPU load, but for serious work, kernel level timings might be nice.)
However, either of these options would require some significant changes to the mtr code. Getting mtr to work on Windows is going to be a matter of quite a bit more than just finding the right build instructions.
I've done some work on getting a Windows port of mtr going. I've got a running version of mtr, though it only support IP version 4, and it only supports ICMP probes. (Not UDP, TCP, SCTP.)
@blackjack4494 -- I've been working on a Python package for using the backend to mtr ("mtr-packet") to send network probes. It is cross platform. You could use it to implement something like mtr in Python.
@matt-kimball yes, kinda like that. my first step was also to utilize mtr-packet. But I would like to port mtr-packet to python as well.
Your project right now is basically a pythron wrapper.
Maybe you are interested as well :)
Activity
szepeviktor commentedon Jul 16, 2014
strace
szepeviktor commentedon Jul 16, 2014
With elevated permission it starts but displays nothing.
szepeviktor commentedon Jul 16, 2014
Even on Debian Wheezy
But the mtr-tiny Debian packages works.
After
sudo su -it works on Debian.szepeviktor commentedon Jul 16, 2014
How could mtr-tiny work with a regular user?
rewolff commentedon Jul 17, 2014
Hi Szépe,
mtr uses "raw sockets" to generate "weird" networking packets. These are carefully controlled to generate "errors" that tell us something about the network.
But if you can craft "weird" packets you can also make "malicious" packets: Maybe something that would make a server allow you to log in without a password (you tell the server: "No, really, my name is root, not Szépe").
So operating systems will not allow normal users to open "raw" sockets.
Under Linux you have two options: First is to run the program as the "root" user. That's the "sudo su - " option. The superuser has the right to open raw sockets, the superuser can do anything.
The other is to give "the mtr program" the right to run as the root user: "chmod 4755
which mtr". The problem with this approach is that the responsibility: "only crafted packets, not malicious ones" falls on the program, mtr in this case. mtr takes care, but no guarantees can be made. So, although in the past there have been little problems with this last approach, I and many others use it.How to "elevate privileges for a single program" under windows: I have no idea. Run as administrator sounds like an option.
I have no idea what could be the cause of "displays nothing". Under Linux I'd at least run "strace" on the program to see what it is trying to do. If your operating system has this option: I don't know.
szepeviktor commentedon Jul 17, 2014
This is
strace ./mtr.exe --raw index.huunder Windows 7 Pro 64 bit + cygwin 32 bit with elevated privilegeshttp://pastebin.com/FP8FsMSU
szepeviktor commentedon Jul 17, 2014
@rewolff I hope it does tell you the cause of "displays nothing"
szepeviktor commentedon Jul 17, 2014
... and yes I see that mtr-tiny has the set-UID flag on. Thank you for clarifying that.
tholu commentedon Oct 3, 2014
How did you build it on Cygwin? For me netinet/icmp6.h was missing.
Edit: ./configure --disable-ipv6
szepeviktor commentedon Oct 3, 2014
Yes. For reference there were all my installed packages: http://pastebin.com/a7npBQAU
Use apt-cyg
adpoliak commentedon Sep 13, 2016
This is still occurring.
How I built:
0.87release and unzipped it within the Cygwin home directory./bootstrap.sh./configure --disable-ipv6 --without-gtkmtr.candnet.cto comment out all instances of SCTP, as Windows does not have native support for that and Cygwin does not ship a compatibility layer for it either.mtr.cto bypass the UID 0 check on interval.make.mt.exe) to add a manifest tomtr.exeto require running as an Administrator.How I'm running:
mtr ${TARGET_IP}.The
ncursesinterface initialized successfully, but no output of the tracing process is shown on the screen.mtr -bewz -c 10 -i 0.01 -s 1400 ${TARGET_IP}.mtrruns to completion, but no report is actually produced.adpoliak commentedon Sep 13, 2016
Issue persists in commit c0bb08b (current HEAD of
masterbranch).Build instructions:
./bootstrap.sh../configure --disable-ipv6 --disable-bash-completion --without-gtk.mtr.cto comment out UID 0 check within interval parameter processing.#define _BSD_SOURCE 1to generatedconfig.hfile sou_char,u_int,u_long,u_short,res_send_qhook,res_send_rhook, andtimersubare available in order for compilation/linking to complete successfully.mt.exeto add manifest tomtr.exeto require running with Administrative privileges.Slightly redacted output of executing
./mtr.exe -bewz -c 2 -i 0.5 -s 1400 4.2.2.1follows:szepeviktor commentedon Sep 13, 2016
@rewolff Could we have official Windows/Cygwin build instructions?
rewolff commentedon Sep 14, 2016
I do not have any Windows machines. I get a headache when I have to use them. So if you guys manage to find a way that works, fine. I can try to add a thing or two that mean that you don't have to edit the sources again, but I can't test what I do. So I have to be careful to prevent breaking Linux, BSD, Solaris and others, while trying to make windows/cygwin work.
matt-kimball commentedon Nov 2, 2016
I took a serious look at what it would take to get mtr running on Windows 7 over the last two days, and things look pretty dire. The real deal-breaker is that I can't manage to receive any ICMP TTL-expired message, with one weird exception, which I'll get to in a moment. Here are some of my observations:
WSAIoctl(get_osfhandle(recvsock4), SIO_RCVALL, &true_opt, sizeof(true_opt), NULL, 0, &rsize, NULL, NULL)to enable receiving on a raw socket. (Who says the Windows API's aren't a joy to work with? I kid, I kid.)netsh interface ipv4 show ipstatscommand, and I noticed that for every TTL-expired message received by windows, the counter for "In Unknown Protocol" incremented by one. Very suspicious. However, I know that Windows knows about ICMP, because it was happy to pass along the ICMP echo replies!Here's where things get weird. If I run tracert.exe (Windows' built-in traceroute), I can actually get those TTL expired messages. Even mtr can receive tracert.exe's TTL expired messages, but not any TTL expired messages in response to packets actually generated by mtr. I thought Windows might have some hackery to indentify "good" TTL expired packets, so I started massaging the ICMP ids, sequence numbers and payload sizes until I was getting response packets that were bit-for-bit identical to the ones generated by tracert.exe's probes, as evidenced by Wireshark. Still no dice. Those seemed to be filtered out too.
I'm grasping at straws here, and I hope someone who knows more about the Windows TCP/IP stack can tell me I'm wrong, but I am beginning to suspect that Windows is doing early discards of any unexpected ICMP traffic that isn't in response to a ping that it knows it sent. How would it be able to distinguish? Well, Windows has this ICMP.DLL library built-in which is used to send and receive pings through a fairly limited API. It's not a raw socket interface -- you can't send arbitrary packets -- but you can send ICMP echos with a particular TTL, and listen for their replies. Both ping.exe and tracert.exe used ICMP.DLL. The only explanation for the weird behavior I am seeing that I can think of is that Windows is whitelisting the TTL expired replies only for packets which were sent through ICMP.DLL.
This rasies the question, could mtr use ICMP.DLL? Yes, I think it could, but the API is significantly different from the Unix-like socket API mtr is currently using, and it is limited to only ICMP, so you'd have to give up support for UDP, TCP and SCTP mtr traces if you did that.
Another, more powerful option, would be to bypass the Windows TCP/IP stack for receiving raw packets and use WinPcap to capture ethernet frames directly, and decode those to find your TTL replies. That's kind of an interesting idea, because since WinPcap operates at the device driver level and timestamps packets when they are received in kernel-land, you'd get more precise timings on round trip time than mtr is currently able to provide. (I'm not sure that any timing jitter due to user-space scheduling matters much in practice on machines which aren't under heavy CPU load, but for serious work, kernel level timings might be nice.)
However, either of these options would require some significant changes to the mtr code. Getting mtr to work on Windows is going to be a matter of quite a bit more than just finding the right build instructions.
matt-kimball commentedon Dec 1, 2016
I've done some work on getting a Windows port of mtr going. I've got a running version of mtr, though it only support IP version 4, and it only supports ICMP probes. (Not UDP, TCP, SCTP.)
I made some compiled x86_64 binaries available here: https://github.com/matt-kimball/mtr/releases
flawrist commentedon Nov 19, 2017
@matt-kimball, is there a way to make a static release (single
.exe)?matt-kimball commentedon Nov 19, 2017
No. The current architecture requires two .exe's, and the curses library requires external files to function.
flawrist commentedon Mar 13, 2019
@matt-kimball, perhaps it’s very time to update Windows binary?
You compiled 0.87, whereas 0.92 is the latest.
matt-kimball commentedon Mar 14, 2019
Sure thing. You'll find a binary built with the latest code here: https://github.com/matt-kimball/mtr/releases
flawrist commentedon Mar 14, 2019
@matt-kimball, thank you, sir.
blackjack4494 commentedon Mar 18, 2019
The windows version works like a charm so far. I haven't looked really into it. For my needs I have to use a modified version of mtr.
Tho I trying to port this c program to python with multiplatform support.
matt-kimball commentedon Mar 18, 2019
@blackjack4494 -- I've been working on a Python package for using the backend to mtr ("mtr-packet") to send network probes. It is cross platform. You could use it to implement something like mtr in Python.
https://github.com/matt-kimball/mtr-packet-python
Take a look at "examples/trace-concurrent.py". It is like a simple version of mtr.
Will that help you?
blackjack4494 commentedon Mar 25, 2019
@matt-kimball yes, kinda like that. my first step was also to utilize mtr-packet. But I would like to port mtr-packet to python as well.
Your project right now is basically a pythron wrapper.
Maybe you are interested as well :)