Hello All. First of all, thanks for all the answers. I've been looking in to this matter, at first thinking that filtering at the kernel level would not be much faster than my own filtering... I was very, very wrong !
I made a test application and this time i used wpcap.dll instead of talking directly to packet.dll. I also build in both my old filter and added the compile/setfilter code to try and compare the two filters. On my workstation here (amd barton xp2500 with 1 gig memory) it messured like this at 60% load on a 100MBit link: cpuload old filter : 98 - 100 % all the time. cpuload bpf filter: 0 - 1 % all the time. This is offcause messured while adapter runs in promiscuous mode. This completely solves my problem, thank you all for the tips!. Regarding this matter I do have some additional questions: Who/how does the old filter get freed when you set a new one ? Does pcap_setfilter free any previous used filter when it applies a new one ? I ask because i want to make the bpf filter a learning filter like the old one was. This means that each time a new local mac address is found, it should get added to the filter like : "not ether dst 112233445566", and the get compilet and set. I might even end up with something like 100 of these statemens. Can the bpf filter handle this? "not ether dst 112233445566 and not ether dst 778899AABBCC"... Also, could one write "not ether dst mac1 mac2 mac3 mac4 mac5......." ? Best regards, J. Thomsen ----- Original Message ----- From: "rujipun" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, August 21, 2003 4:08 AM Subject: RE: [WinPcap-users] speed + re-capturing packets. > Hello J. Thomsen > > Precisely, when an adapter is not put in promiscuous mode, it will not > capture any packet that don't have the same destination MAC address > as the MAC address of the adapter. > > If the tunnel forwards a packet from compA1 to compB (as seen in the > figure below), the destination MAC address of the packet when it arrive > at > the tunnel will normally be the MAC address of the tunnel (if compA1 did > > not send a raw socket in which the destination MAC address is the MAC > address of compB). No matter it is promiscuous mode or not, the packet > will be captured. So you can avoid to capture the packets sent from > tunnel > by put the promiscuous mode off. > > compA1 compA2 > | | > ------------------ > | > Tunnel > | > compB > > Another benefit of non-promiscuous mode is any packets sent between > compA1 > and compA2 will not be captured. > > Rujipun > > -----Original Message----- > From: winpcap [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 21, 2003 12:10 AM > To: [EMAIL PROTECTED] > Subject: Re: [WinPcap-users] speed + re-capturing packets. > > > Hello Gisle. > > My tunnel simulates a level 2 switch quite precisly, > and i was told that if i didnt put it in promiscous mode > it would not be able to capture any packets not directed > to itself. If this was the case, then the tunnel would not work as it > would not capture packets for the computers on the other end of the > tunnel, or am i wrong ? > > / J. Thomsen > > > > ================================================================== > 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] ==================================================================
