invalid-argument

[patatetom]

hi,

you're Getting started code example ends with invalid-argument :

ProbeResult(success=False, result='invalid-argument', time_ms=None, responder=None, mpls=[])

do I need privileges (root) to use mtrpacket ?

regards, lacsaP.

[matt-kimball]

Normally you will not need to run as root. The mtr-packet executable from mtr usually has the capabilities bit set to allow raw network access. (On Linux sytems.)

What operating system are you using? Did you build the mtr tool yourself?

If you run the following command from the commandline, does it also say invalid-argument ?

echo 1 send-probe ip-4 8.8.8.8 | mtr-packet

[patatetom]

I'm using archlinux and mtr (0.93) is provided by pacman (eg. archlinux).

$ echo 1 send-probe ip-4 8.8.8.8 | mtr-packet
1 invalid-argument

[matt-kimball]

That is very unusual. This is not a problem with mtrpacket (the Python module) but with mtr-packet the binary. However, I wrote much of the code in mtr-packet too, so I am responsible either way.

Perhaps we can use strace to find the problem. Please run this:

echo 1 send-probe ip-4 8.8.8.8 | sudo strace mtr-packet

You will likely see something returning EINVAL near the end of the output. If you can quote that full line, and some of the lines around it for context, that will be helpful in figuring out what is happening.

[matt-kimball]

Also, I see this issue in the mtr github repository. Maybe this is related: https://github.com/traviscross/mtr/issues/329

[patatetom]

$ echo 1 send-probe ip-4 xx.x.xxx.xxx | sudo strace mtr-packet
...
close(8)                                = 0
fcntl(0, F_GETFL)                       = 0 (flags O_RDONLY)
fcntl(0, F_SETFL, O_RDONLY|O_NONBLOCK)  = 0
select(8, [0 4 7], [], NULL, NULL)      = 1 (in [0])
recvmsg(4, {msg_namelen=128}, 0)        = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, {msg_namelen=128}, 0)        = -1 EAGAIN (Resource temporarily unavailable)
read(0, "1 send-probe ip-4 xx.x.xxx.xxx\n", 4095) = 31
brk(NULL)                               = 0x557a01edc000
brk(0x557a01efd000)                     = 0x557a01efd000
socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP) = 8
connect(8, {sa_family=AF_INET, sa_data="\0\1"}, 4) = -1 EINVAL (Invalid argument)
close(8)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x4), ...}) = 0
write(1, "1 invalid-argument\n", 191 invalid-argument
)    = 19
select(8, [0 4 7], [], NULL, NULL)      = 1 (in [0])
recvmsg(4, {msg_namelen=128}, 0)        = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, {msg_namelen=128}, 0)        = -1 EAGAIN (Resource temporarily unavailable)
read(0, "", 4095)                       = 0
exit_group(0)                           = ?
+++ exited with 0 +++

note that mtr works perfectly, without any special privileges needed.

[matt-kimball]

I am able to reproduce this issue when running Arch Linux in a docker container. Something about the specific version of mtr provided by Arch is causing the issue. I don't see this problem with either the version of mtr installed with Debian 10, or when building from the latest mtr source from github.

It appears that there is a problem with that version of mtr-packet determining it's local IP address.

You can see this because this command fails:

echo 1 send-probe ip-4 127.0.0.1 | mtr-packet

and this command succeeds:

echo 1 send-probe ip-4 127.0.0.1 local-ip-4 127.0.0.1 | mtr-packet

A good way to work around this would be to provide a local IP to the mtrpacket.probe arguments. Except, it looks like local IP parameters are broken in the currently published version of the mtrpacket python package.

I will try to get a new version of mtrpacket (the python package) out this weekend which fixes the local IP parameters.

If this is an urgent issue for you, building mtr-packet from the latest mtr github source should fix this.

[patatetom]

there's no emergency on my end. did you contact the archlinux package maintainer ?

https://www.archlinux.org/packages/extra/x86_64/mtr/ https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/mtr&id=a6d2745b9c13e0f370481236a18a37d55360069a

[matt-kimball]

I published a new version of the mtrpacket Python module. You can upgrade with:

pip3 install mtrpacket --upgrade

With this version, you can specify a local IP address when sending a probe, to work around this issue:

import socket

local_addr = socket.gethostbyname(socket.gethostname())
result = await mtr.probe('example.com', local_ip=local_addr)

This does appear to be an issue caused by the 0.93 release of mtr, specifically. When the next version of mtr releases, it will no longer be a problem requiring a work-around.

[patatetom]

👍