On Wed, Oct 06, 2004 at 05:32:51PM -0700, Andy Lutomirski wrote:
>
> How 'bout just borrowing code from pcapsend.c -- we're already doing
> this anyway, and the logic shouldn't be different between Windows and
> other OS's.
That sounds like a good idea, though I don't know if the UNIX pcap
offers the same sort of packet sending on all platforms. And, of
course, there is the serious ARP issue you mentioned. Also, UNIX has
different ways to determine the host interface MAC address and such.
> Otherwise I'll code up an ARP reciever thread, hopefully in a
> non-Windows-specific manner, which I was planning to do anyway, and the
> whole mess could be transplanted into the core code.
That should be good, though I don't think it should be a separate
thread. Nmap always uses non-blocking I/O for its UNIX activities,
and pcap will queue received packets for you.
> FWIW, it could be handy to support MAC spoofing of scans. I would have
> had a good white-hat use for that a couple days ago. An interesting
> black-hat use comes to mind as well, but I'll leave that to everyone's
> imagination.
That might be handy. On Linux and may other systems, it is simple to
change the MAC on the command line, though I can think of cases where
having Nmap do the spoofing itself is preferable. Nmap would of
course have to then handle the other side of arp resolution.
> So long as I'm asking, is STL allowed in the core yet? I was planning
> on using it in the Windows code (where STL is "always" present), but
> I'll avoid it in pcapsend if that might cause problems later.
Portable STL is fine for the C++ parts of Nmap. Service scan uses it
and there have been hardly any problems with non-conformant compilers
and such.
Cheers,
-F
---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-help@insecure.org . List archive: http://seclists.org
Received on Oct 07 2004
Intro
