After the upgrade to libnet-arp-perl 1.0.8-1, Net::ARP::arp_lookup
always fails:

xvii:~> perl -MNet::ARP -e 'print "-> ".Net::ARP::arp_lookup(undef,"192.168.1.1")."\n"'
No valid device name found.
-> unknown

I can't seem to find any references to arp_lookup accepting undef as
device in the manual. I can reproduce your issue, but actually setting
device to something makes it work. I'm inclined to disagree on this
being grave. Imho.

$ perl -MNet::ARP -E 'say Net::ARP::arp_lookup("wlan0", "192.168.1.1")'

severity 719960 normal
thanks

The implementation changed between 1.0.4-1 and 1.0.8-1; whereas before,
it would just open /proc/net/arp and look for the IP address, matching
the device only when given, it now uses the SIOCGARP ioctl for which a
device name is mandatory.

So I think this "works as intended", but one could perhaps ask upstream
to provide an option to iterate over several / all available devices, or
amend the documentation to explain that undef values are not / no longer
supported.

Florian

I don't remember where I got this solution.

OK, but indeed this should be documented. I think it would be nice
if it could iterate over the devices (or get the device directly
from the IP address, if possible), as the user doesn't necessarily
know the device in question (even when the user knows the physical
device, as the device name may have a random value). Now, this may
not really be important as a workaround for the user seems to use
/proc/net/arp directly as libnet-arp-perl did before, unless there
are potential problems with this.

I came accross this bug report again the other day, and forwarded it
upstream to see what the Net-ARP author would say. His answer was:

    I am not actively developing in Perl anymore and only fix nasty bugs
    and security issues in that Perl module, but if you would provide a
    working patch I would integrate it.

    (https://rt.cpan.org/Public/Bug/Display.html?id=107677)

It is unlikely that I will find the time to develop such a patch myself
in the forseeable future, but I will certainly look at / forward any
contributions by other people (but by all means feel free to work with
upstream directly).

Florian