[Winpcap-users] Using too many pcap_t handles causes

[Hakan Uluoz]

Hi, 

Gianluca thanks for all again. Having a 64 bit winpcap driver allready answers my questions. By the time I started this project I did not realize the beta x64 components.And looking forward to hearing news about the 4.1beta :).

By the way I did run a test with pcap_setbuff, but a very limitied non-functional test where I opened more and more applications thus handles manually and set the buffer size to 64K. Obviously there seems a neglectable total memory usage, but it seems I can open much more handles now ( up to the physical limit ). Yes, it seems working too at least structurely but hance there is no traffic on the test I did not test the functionality. So the function is so called to alter the interface driver kernel buffer allocation size ( and I believe it should alter only for the pcap_t handle given). I will run a functional test with parametric buffer sizes ( starting from 64 K and doubling it each time on a failure ) next monday. But if I know what this buffer is used for, I will be able to do the math.

So, is this buffer a temporary storage area of the captured packets, till you get them with any pcap function or use callback ( I use callback ) ? If so, is this buffer contains the packets according to your filter or all? If there should be only filtered packets stored on this buffer than 64K will be far away from sufficient, cause RTP packets I am collecting are merely 60-70 Bytes size including protocol headers. If the buffer is used for some internal purposes also and 1/4th is assigned to packets storage than it should buffer nearly 256 packets and seems to be quite enough again. But if I misunderstood the function of this buffer my math shall be  invalid. So,  if there are functionalities of this buffer that I am not considering please let me know.

My best regards, and wish having nice days to all,

HKN 

Message: 2
Date: Fri, 12 Dec 2008 08:29:21 -0800
From: "Gianluca Varenni" <gianluca.varenni at cacetech.com>
Subject: Re: [Winpcap-users] Using too many pcap_t handles causes
    errors?
To: <winpcap-users at winpcap.org>
Message-ID: <6FEDFCD68B444E7992944813E95AB5CD at nelson2>
Content-Type: text/plain; charset="iso-8859-3"


  ----- Original Message ----- 
  From: Hakan Uluoz 
  To: winpcap-users at winpcap.org 
  Sent: Thursday, December 11, 2008 11:12 PM
  Subject: [Winpcap-users] Using too many pcap_t handles causes errors?


  Hi ,

  Gianluca thanks for the info and suggestions, as far as I understand the non-paged kernel pool is the source of my problems. Yes, at first stage I thought a master thread for capturing and workers for processing, but hence this application is realtime ( or let's say near-realtime ) the results ( at least on win systems ) were worse ( though I did not make a complete protocol etc analysis on the packets ) as analysis results were much sooner than the events. As I said I have no trouble with the processor power so running all analysis threads paralely gives me the results as the expected events occur.

  Tried decreasing the mem usage with pcap_setbuff but I did not see any +/- ( honestly I did not test this issue completely , I prom¹se I'll test it by lowering to 256 KB which I think will be more then enough since RTP packets I am collecting is around 60-70 bytes including protocol overhead). 

  Finally, as you suggested I decided to swap to a 64 bit OS, paralelly porting the applications to linux. Natively 64 bit Win OSes do not have the strange 256 MB kernel pool limit, AFAIK the limit is far beyond GBs. One point I need to know is results of using an 32bit dll or application on a 64 bit os( I cannot find the wpcap.dll or libs 64 bit version ). If you are experienced on this topic, will "using 64 bit os and running same applications on it ( or converting the applications to 64 bit but the wpcap.dll  will be still 32 bit )" be enough to avoid the kernel limitation, or still the WoW64 emulation limits you to 256 MB pool? If second is the reality, then compiling a 64 bit version of the pcap lib and/or dlls will be the only solution.  

When you work on a 64bit OS (I mean x64/EM64T), all the kernel components must be 64bit. But the user level components can be 32- or 64bit. Even if the application is 32bit, the WinPcap driver is 64bit, so there is no 256MB limitation on the nonpaged pool.

Regarding a 64bit version of the user level components, there's an experimental build of them here

http://www.winpcap.org/install/x64.htm

and I plan to release a new 4.1beta version by the end of the year that includes both 32- and 64- user level components (and associated lib files).

Have a nice day
GV


  My best regards and again thanks for the suggestions.

  Hakan.


  Hi,

    I am building a Win 32 application pair to monitor the SIP flow on a gateway. Basically the machine running the monitor applications is connected to a hub with the gateway. Main application monitors the SIP flow and runs sub-applications according to the SIP informations. Sub-applications monitor the RTP flows on forward and reverse directions. So all sub-applications have 2 pcap_t handles plus the main has 1. All have unique filters on the same adapter. Yes, the sub-applications are better be threads but there are some other restrictions irrelevant to wpcap that forces me to make them as applications.

    The machine runs on Win XP 32 bit with 2 GB of ram, with all unnecessary services removed. Applications run smooth on around 60 channels ( that makes 60*2 + 1 => 121 handles ). But when the channel count exceeds this boundry, findalldevs and open_live starts to fail. The errors are generally :

    Error in pcap_findalldevs: PacketGetAdapterNames: ERROR_INSUFFICIENT_BUFFER(122)

    Unable to open the adapter. <adapter> is not supported by WinPcap - errbuf :(NULL)

    Unable to open the adapter. <adapter> is not supported by WinPcap - errbuf : Cannot determine the network type(0)

    And mostly :
    Unable to open the adapter. <adapter> is not supported by WinPcap - errbuf : driver error: not enough memory to allocate the kernel buffer  
    
    First observations showed that when the total memory consumptions exceed 1GB errors start. Thought to be a paging issue and disabled paging but did not give a cure. As there is around 1 GB free physical ram available, I focussed on the kernel memory usage, and found that the errors start as soon as the non-paged kernel memory usage reaches around 256 MB ( which is the limit for all Win 32 versions AFAIK ). Besides the CPU usage is very acceptable under all circumstances.
    
    Can anyone clarify the reason for these errors I am getting? Is it memory, handle limitations? And I'd be thankful on suggestions on a solution. I already admit that everything has a limit but a way to tripple or double the channel count ( e.g. monitoring 180-120 channels ) would be quite useful.

  The problem is non paged pool exaustion: every capture instance by default uses a 1MB kernel buffer that is allocated from the non paged pool, plus some kB for the internal structures (I don't remember exactly how many). 
  Several solutions come to my mind:
  - after you open the adapter with pcap_open_live, set the kernel buffer size to a smaller one (with pcap_setbuff).
  - redesign your application so that you open less pcap_t handles and then dispatch the packets to different threads
  - use a 64bit machine.

  Have a nice day
  GV

    
    As a note I am using the WinPcap 4.0.2. 
    
    My best regards,
    
    Hakan.


      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20081213/3f2e4c59/attachment.htm