Re: libpcap change in nmap ?

[Lamont Granquist <lamontg () raven genome washington edu>]

On Fri, 29 Jan 1999, Fyodor wrote:
> On Thu, 28 Jan 1999, fzef fzef wrote:
> > I want to use the libpcap under linux , but i would
> > like to know what are the change with the libcap modified ?
> > thanks ....
>
> The only changes I have made are bugfixes in the Linux specific code.  For
> example, the timeout value passed to pcap_open_live is completely ignored
> with the stock libpcap (and nmap uses this timeout extensively).  Patches
> have been sent to the maintainers.

Actually, I don't think this is a bug.  I think its a mis-named feature.

The "timeout" is the buffering timeout which is passed to BPF or DLPI and
allows the kernel to spool packets without having to copy each one
individually over to userspace.  Linux's SOCK_PACKET doesn't do this at
all, and does copy each one individually over to userspace -- therefore,
no "timeout."

I think that programs are supposed to use that "timeout" value as a
suggested value to improve packet filter performance, but that they're
supposed to ultimately be responsible for making sure that they're calling
pcap for long enough, and doing their own timeouts.

So I doubt that libpcap will get fixed...

> Of course, I did not fix all the bugs.  Here is one that you can verify
> with normal tcpdump:
>
> In window 1 type: tcpdump -i lo "dst host 127.0.0.1"
> And in window 2: telnet 127.0.0.1 80
>
> You should see the TCP handshaking but instead you see nothing on most
> systems I have tried.  This problem seems specific to localhost (note that
> you may have to use a different name than lo). Nmap solves it with the
> ugly solution:
>
> if (target->source_ip.s_addr == htonl(0x7F000001))
>    filter[0] = '\0';

Note that 127.0.0.0/8 == 127.0.0.1 according to Stevens, although
127.0.0.1 is the convention (UNP1 pg 891).

On other fronts, all this TCP sequence number prediction information has
got me curious about blind spoofing attacks, and I'm making slow progress
on it -- but the standard theoretical rsh attack turns out to be a bit
more difficult than daemon9 makes it out to be in P48-14.  Might be
interesting to do something where nmap output could be piped into a
sequence number prediction attack engine...

-- 
Lamont Granquist                       lamontg () raven genome washington edu
Dept. of Molecular Biotechnology       (206)616-5735  fax: (206)685-7344
Box 352145 / University of Washington / Seattle, WA 98195
PGP pubkey: finger lamontg () raven genome washington edu | pgp -fka