Thanks!

So this happens with radiusclient-ng specifically, but not with the FreeRADIUS Client library? Isn't radiusclient-ng dead for way over a decade?

i tried to replicate #1607 and radiusclient-ng was the library available for my system. i got the same issue and the behaviour detected was able to explain all described tests of the original poster.

i have no idea if "radiusclient-ng dead for way over a decade". this plugin works with 4 different radius libraries and i will not try to bring them all to work with my system while the issue ist replicated with the first tested library.

My question wasn't meant as a criticism of your work in any way, and it wasn't necessarily directed at you specifically. The question is whether we'd want to merge that change, which only affects radiusclient-ng users, as-is. In my book, the answer depends on whether that library is still in use. If it isn't, maybe we should rather remove radiusclient-ng support altogether. Because as you say:

this plugin works with 4 different radius libraries and i will not try to bring them all to work with my system

That's precisely my problem when reviewing patches such as this one.

In my book, the answer depends on whether that library is still in use.

And (as I said), the next question would be whether FreeRADIUS users are affected by #1607 as well. Maybe the answer is "yes", in which case this patch wouldn't actually fix that issue. So while I'm not saying that you should do the work of figuring out these things, I do think that someone should before we merge this.

how you will detect if a library is still used?

i checked the code for "-V". It doesn't contain a hint with which library the plugin was compiled. it could help, if this info is easier available. else we can only ask the issue reporter for ldd output, right?

waiting for "someone" to check any other library option will delay this PR probably forever. that will make my analysis and the fix finally useless. that's why i'm not happy with your annotation.

the PR fixes a real problem with this combination of software. and the fix will only change the code for that specific combination.

how you will detect if a library is still used?

Others might have some insight as to which of those libraries are still offered by the popular Linux/BSD distributions, for example.

waiting for "someone" to check any other library option will delay this PR probably forever.

Maybe "someone" could at least check FreeRADIUS, which, as far as I know, is the only supported library that's still maintained, and therefore probably the most important to address.

the PR fixes a real problem with this combination of software. and the fix will only change the code for that specific combination.

Yes, I understood as much. What I'm not sure about is:

1. Can check_radius: Multiple NAS-IP-Address attributes #1607 be closed if we merge this patch, and:
2. Do we still want to support this combination of software, or rather take the chance to remove it altogether to avoid the maintenance cost in the future?

Isn't radiusclient-ng dead for way over a decade?

From my POV, radiusclient-ng is dead: https://tracker.debian.org/pkg/radiusclient-ng

Maybe "someone" could at least check FreeRADIUS, which, as far as I know, is the only supported library that's still maintained, and therefore probably the most important to address.

In Debian we have (as far as I know) two radius library: radcli and freeradius.

The monitoring-plugins package supports both for building while radcli is the preferred one.