0.92 mtr: Failure to start mtr-packet: Invalid argument on macOS 10.12 #204

ilovezfs · 2017-06-17T08:48:34Z

This was reported to Homebrew in Homebrew/homebrew-core#14669 and does not appear to affect 0.87, which the previous version we had before recently updating the formula.

Tested on macOS 10.12.5 and built with Xcode 8.3.2.

bash-3.2$ sudo /usr/local/sbin/mtr
mtr: Failure to start mtr-packet: Invalid argument

~~This does not appear to be an issue on OS X 10.11.6.~~ UPDATE: I had /usr/local/sbin in the PATH on the 10.11.6 box.

The text was updated successfully, but these errors were encountered:

matt-kimball · 2017-06-17T22:13:15Z

Is mtr-packet in your PATH? It is a new subprocess, introduced since 0.87, but it must be installed along with the mtr binary, usually also in /usr/local/sbin, and also in your PATH.

FYI, mtr is working as expected for me on MacOS 10.12.5, though I still have Xcode 8.2 installed.

JCount · 2017-06-18T03:28:34Z

This appears to have been a user configuration issue. The user was calling the mtr executable directly, but without /usr/local/sbin in the path, mtr was unable to execute the installed mtr-packet binary.

rewolff · 2017-06-18T04:59:33Z

Matt, would it be an idea to add

char buf[256];
strcpy (buf, orig_argv0);
strcat (buf, "-packet");
execl (buf, buf,  NULL);

to the exec_packet_child function? (and orig_argv0 = argv[0] to main(). )

ilovezfs · 2017-06-18T08:53:33Z

Thanks @matt-kimball. Yes, it does work if I add /usr/local/sbin to the PATH. However, this still seems like a bug since it "should" be possible to use mtr by invoking the full path to the executable without having to add all of /usr/local/sbin to your PATH.

matt-kimball · 2017-06-18T10:01:21Z

Indeed -- it would be a good idea to do something similar to what @rewolff suggests to help find mtr-packet when it is not in the PATH.

aquerubin · 2017-07-15T22:51:29Z

Is mtr-packet installed with the correct permissions or capabilities? Tony

…

On Jul 14, 2017, at 13:58, Dominic ***@***.***> wrote: can't confirm... `sd~$ env | grep PATH PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin sd~$ which mtr /usr/local/sbin/mtr sd~$ which mtr-packet /usr/local/sbin/mtr-packet sd~$ mtr google.com Failure to open IPv4 sockets: Operation not permitted Failure to open IPv6 sockets: Operation not permitted mtr: Failure to start mtr-packet: Invalid argument` — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

jmosmap · 2017-08-29T13:32:06Z

Can't run mtr for the same reason from two different machines.

jnjeG · 2017-09-21T07:04:07Z

how to add them to "PATH"
http://www.flakor.cn/2014-09-14-714.html

mhutter · 2017-09-21T21:17:17Z

Use this alias as a workaround:

mtr='PATH=/usr/local/sbin:$PATH sudo mtr'

7rakesh · 2018-05-14T21:54:25Z

I was able to fix this issue with following path

export PATH=/opt/local/bin:/usr/local/Cellar/mtr/0.92/sbin/:$PATH

rewolff · 2018-05-15T08:17:36Z

I added the fix to the code almost a year ago, but it could very well be that I have not yet tagged another "release". Sorry about that.

Chr0213 · 2018-05-20T00:23:42Z

Thanks @7rakesh !!

slmingol · 2018-09-14T03:57:43Z

Simply adding this to your ~/.bash_profile on OSX does the trick:

export PATH=$PATH:/usr/local/sbin

Then to use it:

$ . ~/.bash_profile
$ sudo mtr www.google.com

RuyProserv · 2019-02-27T19:12:01Z

thanks

carlnc · 2019-04-18T04:53:48Z

Alternative to alias method:

Create new file: /usr/local/bin/mtr

#!/bin/bash
PATH=$PATH:/usr/local/sbin sudo /usr/local/sbin/mtr "$@"

Fix up permissions:

chmod 775 /usr/local/bin/mtr

Run:

mtr 192.168.0.1

rewolff · 2019-04-18T10:51:22Z

The whole idea of the mtr / mtr-packet split is that mtr has grown to a big gui application with lots of IO modules. Programs like that should not run with root permissions. So mtr-packet is a small simple extract that just does the things that need root-permissions. That should be the only thing that runs with root permissions. Your suggestion subverts this security measure by again running the big mtr application with root privileges.....

carlnc · 2019-04-27T22:55:50Z

@rewolff
I take your point and totally agree.

tl;dr

The way Brew installs mtr could do with some "polish".

Details

https://github.com/Homebrew/homebrew-core/blob/master/Formula/mtr.rb#L36

What brew currently does

# ls -l /usr/local/sbin/mtr*
lrwxr-xr-x <myusername> admin /usr/local/sbin/mtr -> /usr/local/Cellar/mtr/0.92/sbin/mtr*
lrwxr-xr-x <myusername> admin /usr/local/sbin/mtr-packet -> /usr/local/Cellar/mtr/0.92/sbin/mtr-packet*

# ls -l  /usr/local/Cellar/mtr/0.92/sbin/
-r-xr-xr-x <myusername> staff mtr*
-r-xr-xr-x <myusername> staff mtr-packet*

What brew should do (or something like it)

Both mtr and mtr-packet should be accessible via /usr/local/bin (not sbin), and
setuid root on mtr-packet (ie: chmod 4555 mtr-packet)

Unfortunately the problem with point 2 above is that /usr/local/bin is not owned by root (and thus setuid will no work)

# ls -ld /usr{,/bin,/sbin,/local{,/bin,/sbin}}
drwxr-xr-x@   9 root            wheel    288 21 Sep  2018 /usr
drwxr-xr-x  971 root            wheel  31072  4 Apr 10:25 /usr/bin
drwxr-xr-x   15 root            wheel    480 28 Apr 08:47 /usr/local
drwxrwxr-x  402 <myusername>    admin  12864 28 Apr 08:07 /usr/local/bin
drwxrwxr-x    4 <myusername>    admin    128 18 Apr 14:42 /usr/local/sbin
drwxr-xr-x  239 root            wheel   7648  4 Apr 10:25 /usr/sbin

Edit: I just broke my internets googling for "brew setuid /usr/local/bin".

moovs · 2020-11-09T11:19:02Z

Simply adding this to your ~/.bash_profile on OSX does the trick:
export PATH=$PATH:/usr/local/sbin
Then to use it:
$ . ~/.bash_profile
$ sudo mtr www.google.com

why it works only with sudo?

rewolff · 2020-11-09T11:42:08Z

MTR needs low-level access to the packets flying around on the wire. The normal API: "Connect me to this website please" does not work to do the things that mtr needs to do. With such low-level access, you could also compromise the security of the local network (Some computers are configured to allow: "Hey there computerY, this is computerX, joe wants to login, you can trust me, I checked it is really joe") Low level access would allow you to fake/forge that conversation.

So for cases like this, the OS allows a program to be trusted to A) not allow such fakery and B) provide their own security measures. So a program like "ping" and "mtr" is installed "setuid root". It will obtain superuser privileges when started. It can then access all files, change essential system parameters and access the network in funny ways. These programs are then written so that they don't do any of the first few things, and only some funny things with the network. The "own security rules" are for example, repeating frequency not above 1x per second. The superuser can request such network-bogging requests, but normal users cannot.

If your mtr only works with sudo, then it is not fully installed with elevated privileges. Modern systems provide a slightly more restricted version of "setuid-root", so that the system operator does not need to trust mtr not to divulge other users' file contents. It has happened in the past that a program that required "setuid root" for networking stuff then had a bug that allowed a malicious user to abuse the "all files" permission. So nowadays these extra permissions are only assigned "as needed". If mtr were to have a bug that gave a hacker access to all mtr's privileges, then he'd be restricted to only the networking privileges. As less-and-less computers are configured to trust "computerX" on its word "Joe? Really? Prove it! " this is not as critical as it used to be. Still the potential for messing with things is there. Forging packets with "Hey, google here, your connection could not be serviced. Get lost!" is something that you'd be able to annoy other users with....

moovs · 2020-11-09T16:03:51Z

MTR needs low-level access to the packets flying around on the wire. The normal API: "Connect me to this website please" does not work to do the things that mtr needs to do. With such low-level access, you could also compromise the security of the local network (Some computers are configured to allow: "Hey there computerY, this is computerX, joe wants to login, you can trust me, I checked it is really joe") Low level access would allow you to fake/forge that conversation.

So for cases like this, the OS allows a program to be trusted to A) not allow such fakery and B) provide their own security measures. So a program like "ping" and "mtr" is installed "setuid root". It will obtain superuser privileges when started. It can then access all files, change essential system parameters and access the network in funny ways. These programs are then written so that they don't do any of the first few things, and only some funny things with the network. The "own security rules" are for example, repeating frequency not above 1x per second. The superuser can request such network-bogging requests, but normal users cannot.

If your mtr only works with sudo, then it is not fully installed with elevated privileges. Modern systems provide a slightly more restricted version of "setuid-root", so that the system operator does not need to trust mtr not to divulge other users' file contents. It has happened in the past that a program that required "setuid root" for networking stuff then had a bug that allowed a malicious user to abuse the "all files" permission. So nowadays these extra permissions are only assigned "as needed". If mtr were to have a bug that gave a hacker access to all mtr's privileges, then he'd be restricted to only the networking privileges. As less-and-less computers are configured to trust "computerX" on its word "Joe? Really? Prove it! " this is not as critical as it used to be. Still the potential for messing with things is there. Forging packets with "Hey, google here, your connection could not be serviced. Get lost!" is something that you'd be able to annoy other users with....

gracefully thanks you!)

jkldgoefgkljefogeg · 2021-10-21T00:25:24Z

note that /usr/local/sbin/ needs to be in root's $PATH, I ended up also adding alias mtr='sudo -E mtr' to .bash_profile

host:~ $ which mtr
/usr/local/sbin/mtr
host:~ $ which mtr-packet
/usr/local/sbin/mtr-packet
host:~ $ sudo mtr 8.8.8.8
mtr: Failure to start mtr-packet: Invalid argument

host:~ $ sudo su
sh-3.2# echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin

aakashvarma · 2022-08-23T18:34:20Z

It was a permission issue. Do the following:

cd /usr/local/bin
sudo ln -s /usr/local/Cellar/mtr/0.95/sbin/mtr mtr
sudo ln -s /usr/local/Cellar/mtr/0.95/sbin/mtr-packet mtr-packet
sudo mtr < hostname>

this worked for me.

gaurav9822 · 2023-07-28T07:02:24Z

running it like sudo mtr www.google.com worked for me

Olshansk · 2023-11-20T05:00:03Z

alias mtr='sudo mtr'

I suggested adding the above to your .rc so you don't forget to always use sudo with mtr.

ilovezfs mentioned this issue Jun 17, 2017

mtr doesn't work Homebrew/homebrew-core#14669

Closed

5 tasks

rewolff closed this as completed in 860a39c Jun 18, 2017

holzschu mentioned this issue Jan 7, 2022

Feature Request: mtr network utility holzschu/a-shell#284

Closed

holzschu mentioned this issue Mar 8, 2023

How to run nmap? holzschu/a-shell#579

Closed

powersj mentioned this issue Apr 12, 2023

A plugin to monitor websites the way traceroute does. influxdata/telegraf#12921

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

0.92 mtr: Failure to start mtr-packet: Invalid argument on macOS 10.12 #204

0.92 mtr: Failure to start mtr-packet: Invalid argument on macOS 10.12 #204

ilovezfs commented Jun 17, 2017 •

edited

Loading

matt-kimball commented Jun 17, 2017

JCount commented Jun 18, 2017

rewolff commented Jun 18, 2017

ilovezfs commented Jun 18, 2017

matt-kimball commented Jun 18, 2017

aquerubin commented Jul 15, 2017 via email

jmosmap commented Aug 29, 2017

jnjeG commented Sep 21, 2017 •

edited

Loading

mhutter commented Sep 21, 2017

7rakesh commented May 14, 2018

rewolff commented May 15, 2018

Chr0213 commented May 20, 2018

slmingol commented Sep 14, 2018

RuyProserv commented Feb 27, 2019

carlnc commented Apr 18, 2019 •

edited

Loading

rewolff commented Apr 18, 2019

carlnc commented Apr 27, 2019 •

edited

Loading

moovs commented Nov 9, 2020

rewolff commented Nov 9, 2020

moovs commented Nov 9, 2020

jkldgoefgkljefogeg commented Oct 21, 2021 •

edited

Loading

aakashvarma commented Aug 23, 2022 •

edited

Loading

gaurav9822 commented Jul 28, 2023

Olshansk commented Nov 20, 2023

0.92 mtr: Failure to start mtr-packet: Invalid argument on macOS 10.12 #204

0.92 mtr: Failure to start mtr-packet: Invalid argument on macOS 10.12 #204

Comments

ilovezfs commented Jun 17, 2017 • edited Loading

matt-kimball commented Jun 17, 2017

JCount commented Jun 18, 2017

rewolff commented Jun 18, 2017

ilovezfs commented Jun 18, 2017

matt-kimball commented Jun 18, 2017

aquerubin commented Jul 15, 2017 via email

jmosmap commented Aug 29, 2017

jnjeG commented Sep 21, 2017 • edited Loading

mhutter commented Sep 21, 2017

7rakesh commented May 14, 2018

rewolff commented May 15, 2018

Chr0213 commented May 20, 2018

slmingol commented Sep 14, 2018

RuyProserv commented Feb 27, 2019

carlnc commented Apr 18, 2019 • edited Loading

rewolff commented Apr 18, 2019

carlnc commented Apr 27, 2019 • edited Loading

tl;dr

Details

moovs commented Nov 9, 2020

rewolff commented Nov 9, 2020

moovs commented Nov 9, 2020

jkldgoefgkljefogeg commented Oct 21, 2021 • edited Loading

aakashvarma commented Aug 23, 2022 • edited Loading

gaurav9822 commented Jul 28, 2023

Olshansk commented Nov 20, 2023

ilovezfs commented Jun 17, 2017 •

edited

Loading

jnjeG commented Sep 21, 2017 •

edited

Loading

carlnc commented Apr 18, 2019 •

edited

Loading

carlnc commented Apr 27, 2019 •

edited

Loading

jkldgoefgkljefogeg commented Oct 21, 2021 •

edited

Loading

aakashvarma commented Aug 23, 2022 •

edited

Loading