Bug#508432: fwknop patched

[Sébastien Aperghis-Tramoni]

Hello,


Franck Joncourt wrote:

> Hi Sébastien,
>
> We have been without news since about 2 weeks.

Sorry for being slow to answer. From time to time, even I can be  
catch back by real life things.

> What about this bug?

I didn't forget about this bug, your mails are the last ones in my  
inbox (I'm using an inbox-zero process).

> Have you been able to reproduce the problem?

I also tried without success on my machine at work, an x86-64 running  
an old Mandriva system, with Net::Pcap 0.16, libpcap 0.9.1. This bug  
seems to be either very tied to the x86 or to a recent version  
version of the libpcap.

I've also tried and failed to link Net::Pcap with libpcap 1.0.0,  
which is problematic.

> Do you intend to update libnet-pcap-perl?

I intend to update Net::Pcap.

> Should we patch libnet-pcap-perl in order to remove the ability to be
> interrupted by a signal for this release?

I've answered Martín's concerns in the CPAN-RT ticket:

> I'd say many Perl users don't know how signals are actually  
> handled. In fact, more than a few are surprised that signals are  
> not immediately delivered. IIRC, I added this code to Net::Pcap  
> because I had a couple of requests (by private mail, not on CPAN- 
> RT) to modify Net::Pcap so it behaves this way.
>
> I also remember explaining this to a couple of colleagues, and how  
> to enable "unsafe" signals.

So, as you already suggested..

> I think maybe that could be nice to have a way to enable/disable the
> current behavior of the pcap_loop function against interrupts.

.. I'll add a new function, pcap_perl_settings() to address this  
particular issue.

> Having a note about the possible problem would also be good as Martin
> pointed out.


I'll add a note about signals, pointing to the pcap_perl_settings()  
function.
I'll also have to fix the problems with libpcap 1.0.0


-- 
Sébastien Aperghis-Tramoni

Close the world, txEn eht nepO.