Re: Help wanted on port scanner

[Guy Harris <guy () alum mit edu>]

On Oct 31, 2003, at 8:19 PM, Ronald F. Guilmette wrote:

> This is extremely perplexing to me.  It seems as if the underlying
> sendto() call being used within the implementation of `libnet_write_ip'
> is failing to block in cases where the packet to be sent cannot either
> be (a) immediately sent or else (b) buffered in kernel memory for the
> socket.

A quick look at fairly recent FreeBSD 5.x code suggests that it doesn't 
- it's like UDP, where an attempt to send a packet either succeeds 
immediately (modulo queueing on the *driver's* output queue) or fails 
(perhaps returning -1 and setting "errno" to ENOBUFS).  There's no 
buffering other than driver queue buffering.

I suspect that's the case with most BSD networking stacks, and probably 
even the case with non-BSD ones.

> #2)  If sendto() does not block when writing to RAW sockets, then is 
> there
> any other way for me to match the rate at which my little program calls
> sendto() to the actual rate that packets can be sent out of my ethernet
> card?  (I would prefer it if packets didn't just get discarded 
> willy-nilly,
> as that makes the results of the port scan dramatically less complete.)

None that I know of - I don't know any way to get that rate from the 
system (other than perhaps getting the raw rate of the network device, 
but that doesn't tell you the rate at which you can get packets to the 
receiving machines).

> #3)  I read that there is another way of sending out packets, i.e. just
> simply writing them to the fd of the device file that is opened in some
> call to `pcap_open_live'.  Would this be a better way to send packets
> out of my port scanner, i.e. better than trying to use the kernel's
> apparently unreliable `sendto' function to send them?

The same underlying problem will probably bite you - no flow control at 
the Ethernet driver level other than "I can't handle any more packets, 
so I'll drop the one I've been given on the floor".

> P.S.  One idea that occured to me was that maybe I should use libpcap 
> to
> _listen_ for my own outgoing packets, and then only send the next one
> when/if the last one has actually gotten sent out the interface.  Is
> this a totally brilliant idea or (as I suspect) a totally dumb idea?

That might work, although

	1) it probably underestimates the rate at which you can send packets 
in most cases

and

	2) *if* your machine is busy sending other stuff on the same network 
interface, the fact that you saw one attempt succeed doesn't mean your 
next attempt will succeed.

-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-request () tcpdump org?body=unsubscribe