On Feb 14, 2012, at 6:09 AM, Moshe Matitya wrote:
> Yes, we built libpcap 1.2.1 from the distribution tarball.
...so it's presumably 64-bit.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
> "Moshe" == Moshe Matitya writes:
>> Whose libpcap 1.2.1 are you using?
>> I assume that it is one that you built. On RHEL 3.8 were you using
>> libpcap 1.2.1?
>>
>> Also can you tell us what kernels are in each, as RHEL 3.8 was a long
>> time ago.
Moshe> Yes,
Whose libpcap 1.2.1 are you using?
I assume that it is one that you built. On RHEL 3.8 were you using
libpcap 1.2.1?
Also can you tell us what kernels are in each, as RHEL 3.8 was a long
time ago.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Ri
On Tuesday, February 14, 2012 3:57 PM, m...@sandelman.ca wrote:
>
>Whose libpcap 1.2.1 are you using?
>I assume that it is one that you built. On RHEL 3.8 were you using
>libpcap 1.2.1?
>
>Also can you tell us what kernels are in each, as RHEL 3.8 was a long
>time ago.
Yes, we built libpcap 1.2.1
On Tuesday, February 14, 2012 3:40 PM, ri...@happyleptic.org wrote:
>
>Calling pcap_loop() after it returned something else than 0?
No, pcap_loop() is called only once.
Moshe
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
-[ Tue, Feb 14, 2012 at 03:26:21PM +0200, Moshe Matitya ]
> Any ideas as to what may be causing this would be much appreciated.
Calling pcap_loop() after it returned something else than 0 ?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
We are running an application using libpcap 1.2.1, on CentOS 5.6 (64-bit), on a
machine with a 10 gigabit NIC. We have been using this application for several
years, using previous versions of libpcap, previous versions of Linux, and
other NIC's, without any problems. Also, the current version
