non-blocking packet pacture (libpcap)

non-blocking packet pacture (libpcap)

Post by Marko Mlaka » Fri, 05 Mar 1999 04:00:00



Hey folks.

I was wondering if someone here knows if there's function/parameter or
technique of making pcap_next (or whatever) non-blocking. I'd like something
to return -1 if the packet is invalid/isn't received. Changing libpcap
would be the easiest right now, But that's now what i want. I dont want
my program to be dependable only on my patched version of pcap.

                                        Marko Mlakar

 
 
 

non-blocking packet pacture (libpcap)

Post by shado » Mon, 08 Mar 1999 04:00:00



>I was wondering if someone here knows if there's function/parameter or
>technique of making pcap_next (or whatever) non-blocking. I'd like something
>to return -1 if the packet is invalid/isn't received. Changing libpcap
>would be the easiest right now, But that's now what i want. I dont want
>my program to be dependable only on my patched version of pcap.

The easiest way you can do this is to have a child process do the
sniffing, and a parent process communicate with it via a socket.
Make the parent process not block on the reading from the socket.

This is probably the most portable way. Patching libpcap is
something I'd feel very wary about.

--
Thamer Al-Herbish                          <URL http://www.whitefang.com/>
[    The Raw IP Networking FAQ <URL http://www.whitefang.com/rin/ >      ]

 
 
 

1. Blocking connect() fails, non-blocking succeeds?

Hi folks.

        I'm experiencing an odd problem using a non-blocking connect() call. Our
code is vanilla in this respect - it uses fcntl() to set the non-blocking
bit, etc., and the code works fine. However, during testing, we tried
running the code against machines on the net which are not listening at the
standard ports for our application. We expected that this would cause our
background connection attempts to fail, which we would detect by periodic
select() calls to see if the socket is writable. However, this non-blocking
connect() call _always_ seems to succeed when run against a valid host
which does not have our server running. To further confuse the issue, when
we vary the port number, it seems that the non-blocking connect() _always_
succeeds. Also, when we use a _blocking_ connect call to the same address
and port, we get (again, as expected), a -1 returned from connect, with
errno = ECONNREFUSED.

        The problem is, our code sends a message to the server when the connection
is "established", i.e. when select() indicates the socket is writable.
However, such a socket isn't writable, really - there is no server at the
other end. As you might expect, when we send the message, we get a SIGPIPE,
which we catch, so our program doesn't crash.

        Am I missing something here? I thought the point of using a non-blocking
connect() was to put it in the background. Is there some other step that
must be taken in order to ensure that the connection has been established?

        Any help or ideas appreciated.

Eric Winter
Hughes STX

2. DHCP oddities with Cable Modem

3. Blocking and Non-Blocking socket

4. I need help with my modem installation

5. [2.2] pipe_write can block even with non-blocking fd

6. aix printing to win95/98

7. how to get blocking i/o after non-blocking???

8. Multicast recvfrom not working??????

9. [2.5] Non-blocking write can block

10. Blocking & Non-Blocking

11. Non-blocking socket reads block! (Bug?)

12. Problem with blocking opens preventing non-blocking opens in AIX 5.2

13. Difference between blocking and non-blocking socket ?