On Nov 6, 2007 2:03 PM, Rick Jones <[EMAIL PROTECTED]> wrote:
> Any thoughts as to how to deal with false checksum failure reports for
> outbound
> traffic being sniffed on a system with ChecKsum Offload (CKO)? It seems that
> linux has a flag they can set when capturing the packet that would tel
On 9/24/07, Amine Mustapha Smaali <[EMAIL PROTECTED]> wrote:
> Hi Harley,
>
> I'm trying to use internal stack functions. I found that the function
> netisr_queue() is delivering packets to IP layer. When I'm calling this
> function in my C program the compiler does not know this function even I
>
On 9/24/07, Amine Mustapha Smaali <[EMAIL PROTECTED]> wrote:
> Hi All,
>
> I'm a new member in this maling list and I'm pleased to join this list.
>
> So, I have one question concerning the libpcap. I wrote a C code to wait for
> specific ethernet frames. The frames received contains TCP/IP packets
On 12/4/06, Gerald Combs <[EMAIL PROTECTED]> wrote:
Harley Stenzel wrote:
> Looking forward, however, it would be helpful if the libpcap file
> format provided a way to tag the source of the captured packet, so
> that merged files do not loose information.
NTAR support
On 12/4/06, Jefferson Ogata <[EMAIL PROTECTED]> wrote:
Not sure I follow your response. It's not a proposal--mergecap exists as
part of wireshark ne ethereal. There are other tools for doing this as
well. Yes, something is lost, but something is gained. I use tools of
this ilk to merge together m
On 12/1/06, Jefferson Ogata <[EMAIL PROTECTED]> wrote:
Is it possible they were the result of combining multiple pcaps via
something like mergecap?
It would seem that for something like this to be generally usefull, a
capture station identifier would be needed. I suppose a source-file
identif
[Attempting to confuse dup message detection]
On 10/6/06, Gianluca Varenni <[EMAIL PROTECTED]> wrote:
Uhm, what's the purpose of some amount of memory put in front of the pcap_t
structure?
Maybe I don't understand your proposal completely...
I don't want the data in front of the pcap_t struct
On 10/6/06, Gianluca Varenni <[EMAIL PROTECTED]> wrote:
Uhm, what's the purpose of some amount of memory put in front of the pcap_t
structure?
Maybe I don't understand your proposal completely...
I don't want the data in front of the pcap_t structure, I want it in
front of the body of the pack
Greetings--
Has the idea of headroom for libpcap-based stack applications been
discussed before? The idea is to have a known amount of empty/usable
space in front of the buffer given to the application by the
pcap_dispatch callback, pcap_next(), or pcap_next_ex().
It looks like it'd be a ((pcap
On 7/31/06, Rick Jones <[EMAIL PROTECTED]> wrote:
I thought that one thread was send/recv and the other was send. The "send only"
thread ostensibly would not need to be in promiscuous mode right?
Sort of. Promiscous mode on the NIC and promiscous on the STREAM are
two different things. Libp
On 7/28/06, Guy Harris <[EMAIL PROTECTED]> wrote:
On Jul 28, 2006, at 12:51 PM, Harley Stenzel wrote:
> Show that this happens when 2 threads use pcap_t at the same time:
libpcap is, for better or worse, not thread-safe,
Good to know, thanks.
Using *different* pcap_t's
Greetings--
I'm seeing something quite strange.
I have a libpcap stack application. One thread may send while another
thread both receives and sends. (Sends in response to a packet, and
send in response to a timeout).
This works fine on Solaris, which also uses DLPI.
On HP-UX, transmission f
On 6/8/06, Justin E <[EMAIL PROTECTED]> wrote:
Hello,
I've been trying to get libpcap 0.9.4 to work on several HP-UX boxes,
and am unfortunately having some trouble when I try to open an
interface using pcap_open_live. The error I receive is:
recv_ack: promisc_phys: UNIX error - Device busy
On 6/4/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi guys,
I havent heard from anyone and I really need solution to this problem.
I was able to successfully create makefile.
When I tried to run the 'make' command with this option in the makefile
#CCOPT = -O2
CCOPT = -g
I get th
Greetings-
I'm seeing an odd behavior in my 64-bit libpcap application on HP-UX
11.23 ia64. It crashes in pcap_inject, even though the input appears
good. gdb information follows.
The same application works on Solaris, both 32-bit on sparc and 64-bit
on x86_64.
Additionally, my testcase appl
Greetings--
Is tcpdump-workers alive? The archives are unavailable,
https://lists.sandelman.ca/cgi-bin/mj_wwwusr/domain=lists.tcpdump.org
returns with 500/Internal Server Error, and a post I made does not
appear to have gone through.
Thanks.
--Harley
-
This is the tcpdump-workers list.
Visit h
[ I really can't seem to set the proper account for these
responses Here's to fooling the duplicate message detector ]
On 4/4/06, Guy Harris <[EMAIL PROTECTED]> wrote:
> Harley Stenzel wrote:
> > 2) It's not clear under what circumstances a rc 0 could ever be
On 4/3/06, Rick Jones <[EMAIL PROTECTED]> wrote:
> > 4) What is the expected interaction of multiple libpcap instances on
> > HP-UX? I can't use my program and tcpdump at the same time; something
> > I can do on other OSes.
>
> I believe this is a long-standing limitation of promiscuous mode suppo
Greetings--
[ obligatory new content because I messed up the content the first
time around. ]
I opened a bug report on sourceforge about this, but now have some
additional observations, and I would like some guidance about how to
best further debug the problem. I've included that bug report here
19 matches
Mail list logo
