Thanks for the very quick response. I have checked the kernel memory and it does jump by 40MB when I start the capture. So setbuff looks like it is allocating the memory ok.
With the timeout. I was assuming that, if the timeout response was genuine, it would occur after 1000 milliseconds, not 100 milliseconds. I have also tried changing the blocking state using pcap_nonblock and changing the pcap_mintocopy setting. But these did not seem to help. I have written a short test program to allow me to try out combinations of these settings. I can email this if you think that might help identify the problem. It is only about 200 lines long (compiled under Visual C++ 6.0 SP5). Is there any initialisation of the buffer that occurs when you use pcap_setbuff? If there is, then, is it possible that the initialisation fails to complete when there is a high level of network traffic, resulting in timeout responses being generated for pcap_next_ex? If this is the case, is there a way to stop packets being processed until this initialisation has been completed? Thanks again. Steve -----Original Message----- From: Gianluca Varenni [mailto:[EMAIL PROTECTED] Sent: 14 May 2004 14:48 To: [EMAIL PROTECTED] Subject: Re: [WinPcap-users] Timeout responses to pcap_getnext_ex with high network load and using pcap_setbuff ----- Original Message ----- From: "Steve Fernandes" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, May 14, 2004 3:33 PM Subject: [WinPcap-users] Timeout responses to pcap_getnext_ex with high network load and using pcap_setbuff > Hi, > > I have a problem using WinPCap to capture packet files on a busy network. > > I am using WinPCap 3.0 on a system running Windows 2000 Professional with > Service Pack 4. > > I open the adapter using pcap_open_live (timeout set to 1000), set the > buffer size to 40,960,000 using pcap_setbuff and then use pcap_next_ex to > get the packets. The setbuff command returns 0 (zero), so I presume it is > working ok. Yes. You can be sure that this buffer is really allocated in the driver by looking at the task manager, Tab performance, Panel "kernel memory", it's "nonpaged". This value should increase of about 40 MB after pcap_setbuff(). > > When I start my program running on a heavily loaded network (over 13,000 > packets per second) I keep getting timeout responses and no proper packets. Quite strange... > > But if I do not use setbuff it seems to work ok. > > Also, if I start the high network traffic after starting my program, it > seems to work ok. That's really odd. > > Even though I set the timeout value in pcap_open_live to 1000, the timeout > responses seem to be coming in much faster than 1 second intervals. This is normal: pcap_next_ex returns if either (whatever comes first) - the timeout has elapsed - at least mintocopy bytes are present in the kernel buffer. The default value for mintocopy is 16kB, you can change it with pcap_setmintocopy() > > My test program is a command prompt program, running under Windows 2000 Pro. > The timestamps for the packets (which I get using SYSTEMTIME and display) > show the timeout responses coming in approxiamtely 100 milliseconds apart. What do you mean? pcap_next_ex could return up to 1 second (the timeout you have set) after the packet has been captured, BUT the timestamp in the packet header tells you the actual capture time. Have a nice day GV > > Here is relevant code sections: > > > First the initialisation > > /* Open the adapter */ > if ( (adhandle= pcap_open_live(d->name, // name of the device > 65536, // portion of the packet > to capture. > // 65536 grants that the whole > packet will be > // captured on all the MACs. > 1, // promiscuous mode > 1000, // read timeout > errbuf // error buffer > ) ) == NULL) > { > fprintf(stderr,"\nUnable to open the adapter. %s is not supported by > WinPcap\n"); > /* Free the device list */ > pcap_freealldevs(alldevs); > return -1; > } > > printf("\nlistening on %s...\n", d->description); > > /* At this point, we don't need any more the device list. Free it */ > pcap_freealldevs(alldevs); > > // set the buffer size > sbresult = pcap_setbuff(adhandle, nSetBuff); > printf ("SetBuff returned : %d\n", sbresult); > > ... > > And the reading section. > > while (1) > { > retcode = pcap_next_ex(adhandle, &hdr, &data); > > switch (retcode) > { > case -2: // eof reached whilst reading packet > display_packet("Dried up", 0, 0); > break; > > case -1: // error occurred > display_packet("Error reading packet, trying again", 0, > 0); > break; > > case 0: // timeout > display_packet("Timeout reading packet", 0, 0); > break; > > case 1: // received packet ok > display_packet("Got Packet", hdr, data); > break; > } > } > > Am I doing something wrong? > > Thanks for the help > > Steve > > > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > ================================================================== > This is the WinPcap users list. It is archived at > http://www.mail-archive.com/[EMAIL PROTECTED]/ > > To unsubscribe use > mailto: [EMAIL PROTECTED] > ================================================================== ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe use mailto: [EMAIL PROTECTED] ================================================================== ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe use mailto: [EMAIL PROTECTED] ==================================================================
