I was using pthreads for two interfaces, but I am trying to optimize now. I
have 15% memory usage.
I am trying to use select, as it seems the most basic. Junkie uses threads
to do this, so can't really use it.
I want to sniff only beacons in the network, so I am attaching a bpf filter
on the handle
Hi!
> I was using pthreads for two interfaces, but I am trying to optimize now. I
> have 15% memory usage.
So you were capturing traffic on two threads with two distinct pcap handlers?
Looks fine to me. What's eating 15% of your RAM, exactly?
> I am trying to use select, as it seems the most bas
On Sat, Dec 10, 2011 at 3:18 PM, wrote:
> Hi!
>
> > I was using pthreads for two interfaces, but I am trying to optimize
> now. I
> > have 15% memory usage.
>
> So you were capturing traffic on two threads with two distinct pcap
> handlers?
>
yes
> Looks fine to me. What's eating 15% of your RAM
On Dec 10, 2011, at 7:39 AM, abhinav narain wrote:
> Can I use pcap_loop when using select,
No.
You can, however, use pcap_dispatch(). pcap_loop() loops either indefinitely
or until it sees the specified number of packets; it will try to read more
packets from the underlying descriptor, and
So, I can do select + pcap_dispatch to read on two interfaces without even
using threads.
I read select is slow for monitoring. But with only two interfaces, it
should not be a problem.
Abhinav
On Sat, Dec 10, 2011 at 3:50 PM, Guy Harris wrote:
>
> On Dec 10, 2011, at 7:39 AM, abhinav narain
On Dec 10, 2011, at 12:18 PM, ri...@happyleptic.org wrote:
>> I am trying to use select, as it seems the most basic.
>
> If I understand correctly, you are replacing your threaded aproach by a singly
> threaded program using select. Unfortunately, I don't know any way to
> associate a file descr
On Dec 10, 2011, at 12:38 PM, abhinav narain wrote:
> On Sat, Dec 10, 2011 at 3:18 PM, wrote:
>
>> Looks fine to me. What's eating 15% of your RAM, exactly?
>
> I think pthread while keeping the states
Is that 15% of your machine's RAM? Unless the threads have really large
stacks, or you ha
On Dec 10, 2011, at 12:58 PM, abhinav narain wrote:
> So, I can do select + pcap_dispatch to read on two interfaces without even
> using threads.
>
> I read select is slow for monitoring.
Possibly. If you don't care about portability, you could use epoll():
http://kernel.org/doc/man-
-[ Sat, Dec 10, 2011 at 12:59:26PM -0800, Guy Harris ]
> > Unfortunately, I don't know any way to
> > associate a file descriptor with a pcap handle portably. :-(
>
> pcap_get_selectable_fd() if present in your libpcap, pcap_fileno() otherwise.
Thank you for the correction.
> > Yes junkie us
Two threads are too large on this.
I was unable to find how to set the set of interfaces to be restricted to 2
(the ones i want) and call the same callback on return from dispatch.
This code is not right, but I am clueless to proceed
Any direction will be good.
fd_set rfds;
char * device="p
Actually, I did better now ... but I don't know what should be done to call
the corresponding dispatch
If someone can give me a hint
char *device0="phy0";
char *device1="phy1";
pcap0 = pcap_open_live(device0, BUFSIZ, 1, -1, errbuf);
pcap1 = pcap_open_live(device1, BUFSIZ, 1, -1, errbuf)
I got it to work.
Thanks for replying on the thread
Abhinav
On Sat, Dec 10, 2011 at 8:15 PM, abhinav narain
wrote:
> Actually, I did better now ... but I don't know what should be done to
> call the corresponding dispatch
> If someone can give me a hint
>
>
> char *device0="phy0";
> char *
> I got it to work.
(...)
> > default: /* We got traffic */
> > pcap_dispatch(pcap0,-1, (void *) packet_callback, NULL);
> > pcap_dispatch(pcap1,-1, (void *) packet_callback2, NULL);
So that other may benefit from it in the future, I
guess your fixed version looks like:
default:
if (t
13 matches
Mail list logo
