[tcpdump-workers] Latency Impact and How to Minimize?

2017-11-12 Thread Hei Chan
Hi, I am curious on a x86_64 machine, if I run a tcpdump, how much latency will tcpudmp add (assuming that I can dedicate a core to tcpdump and OS won't reschedule it to another core)? And what's the best way/setup (besides avoiding using promiscuous mode) to minimize the latency impact to the p

Re: [tcpdump-workers] Coredump Without Much Info?

2015-07-10 Thread Hei Chan
  0x7715a07c <+60>: retq   End of assembler dump.(gdb)  On Saturday, July 11, 2015 5:32 AM, Guy Harris wrote: On Jul 10, 2015, at 7:53 AM, Hei Chan wrote: > I am using libpcap 1.4.0 to read in pcap. > And my application crashed at pcap_next() when it rea

Re: [tcpdump-workers] Coredump Without Much Info?

2015-07-10 Thread Hei Chan
bove hasn't been changed for like a year.  It used to work long time back with other pcap files. So I suspect that it has something to do with my pcap file. On Saturday, July 11, 2015 1:32 AM, Guy Harris wrote: On Jul 10, 2015, at 7:53 AM, Hei Chan wrote: > I am using libp

[tcpdump-workers] Coredump Without Much Info?

2015-07-10 Thread Hei Chan
Hi, I am using libpcap 1.4.0 to read in pcap. And my application crashed at pcap_next() when it read the first packet from my pcap file:(gdb) bt#0  0x7715a044 in pcap_next () from /usr/lib64/libpcap.so.1 I used wireshark to open the pcap and wireshark doesn't show any error (e.g. no hig

Re: [tcpdump-workers] Handling Corrupted Packets Inside Pcap Files?

2014-10-23 Thread Hei Chan
18, 2014, at 4:12 AM, Hei Chan wrote: > Hi, > The first 3 packets are corrupted according to wireshark. What is the exact message Wireshark reports? Can you send us the pcap file or make it available for downloading? > As soon as I read the first packet with pcap_next(), my applicati

[tcpdump-workers] Handling Corrupted Packets Inside Pcap Files?

2014-10-22 Thread Hei Chan
Hi, The first 3 packets are corrupted according to wireshark. As soon as I read the first packet with pcap_next(), my application gets a coredump. Is it an expected behavior? If not, what's the correct/better usage to get around it? Thanks in advance. Cheers, Hei P.S. I am using libpcap 1.4

Re: [tcpdump-workers] Setting the Buffer Size Without Restarting the NIC?

2014-02-06 Thread Hei Chan
s enabled in the OS but could be "not activated" before those pcap_*() calls? Thanks in advance. On Thursday, February 6, 2014 6:24 PM, Guy Harris wrote: On Feb 6, 2014, at 12:19 AM, Hei Chan wrote: > When I call pcap_set_buffer_size() on an actively using/running NIC, it give

[tcpdump-workers] Setting the Buffer Size Without Restarting the NIC?

2014-02-06 Thread Hei Chan
Hi, When I call pcap_set_buffer_size() on an actively using/running NIC, it gives me an error: can't perform  operation on activated capture Is there a way to change the pcap capture buffer size without deactivating it? How does this buffer different from SO_RCVBUF?  It seems like SO_RCVBUF do

[tcpdump-workers] pcap_findalldevs

2014-02-05 Thread Hei Chan
Hi, I am new to libpcap, and I am trying to use the following to get the list of network devices available to libpcap by calling pcap_findalldevs(). Manpage mentions, "there may be network devices that cannot be  opened  by  the  process  calling pcap_findalldevs(3), because, for example, that p