majek04 wrote:
> Diman Todorov wrote:
>> I personally think that modifying nsock is preferable to introducing
>> a thread library dependence into nmap.
>>
>
> In summary we can add pcap support to nsock or
> use some ugly and not portable hack.
>
Hi again.
I have next question.
I'm not pcap expert yet.
As far as I understand Fyodor's patch http://seclists.org/nmap-dev/2006/q4/att-0128/nmap-osx-fix_diff
means that on some architectures we must use blocking pcap_next.
Integrating some pcap/dnet features into nsock makes sense only if pcap descriptors
could be used in the same 'select()' as nsock descriptors.
If I'm not wrong we're left with only two options
- running pcap_next in other thread than nsock_loop or
- running pcap_next after nsock_loop with very short timeouts.
The problem here is that pcap timeouts are broken. The alternative
would be to set pcap descriptor in nonblocking mode. But I don't
know if it's portable.
So what do you guys think about it?
Cheers,
Marek Majkowski
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org
Received on Dec 15 2006
Intro
