On 3/17/20 4:02 AM, Marc Lehmann wrote:
> On Sun, Mar 15, 2020 at 03:43:09PM -0700, Robert Woodcock <r...@debian.org>
> wrote:
>> If you *do* need to differentiate, I would adjust the limit for the
>> number of outstanding probes in packet/probe.h, and then recompile:
>>
>> #define MAX_PROBES 1024
>>
>> However, that's not enough - I believe the intent of this limit is to
>> match the default Linux limit of 1024 open files per process, which you
>> will need to override in /etc/security/limits.conf to make effective use
>> of the new limit in your copy of mtr.
>>
>> Probably the best long-term fix would be to automatically free the
>> oldest probe when the newest one is requested, but I don't know how
>> practical that would be.
> Thanks a lot for this detailed analysis and tips. The strange thing,
> though, is that this is clearly a regression, i.e. these limits (other
> than the kernel limit) seem to either be new, or mtr silently handled this
> in the past.
>
> Anyway, if that's going to be it, I'll simply have to adapt, and this
> apparently works as designed and is not a bug.
>
MTR was pretty substantially redesigned about 3 years ago - the UI was
separated from the backend (which has to have special privileges to open
a raw socket - it used to need to be setuid, but now it uses setcap to
provide only the RAW socket privilege needed). That redesign made it
into the mtr 0.92 package in the current stable version of Debian -
Buster - released in 2019. This was done for security reasons, to limit
the possible attack surface for privilege escalation. I have not done a
similar analysis on the older versions (0.87 and below) but I suspect
that's what you were using before.
