FatRiSha wrote:
I would like to know the correlation between 'libpcap', 'linux' & bpf.
Linux is, depending on whom you ask, either an operating system kernel
or an operating system.
BPF is, depending on whom you ask, either
1) a mechanism, provided in various BSDs and in AIX, for capturing and
ashok kumar wrote:
In tcpdump we logged on through root access.
In that, we entered the command tcpdump -w
We are getting the specified format but we cant capture
any packets.
how to get a packet captured?
http://www.tcpdump.org/faq.html#q4
-
This is the tcpdump-workers l
alexander medvedev wrote:
i am trying to minimize the dropped packet count, which maybe due to a too
small buffer in the BPF driver.
are there any bad implications of setting the BPF buffer size to 1meg and
hardcoding pcap-bpf.c to use the buffer size of 1meg?
[wasting kernel memory does not count.
FatRiSha wrote:
So,.. Linux kernel 2.2 and above already used kernel filtering, right?
They already supported kernel filtering.
and there's no BPF in Linux at all, right?
There's no BPF in the sense of a raw packet capture and sending metod
that behaves the way BPF behaves on BSD.
There *is*, how
Langesh Dharmalingam wrote:
[EMAIL PROTECTED] libpcap-0.6.2]# ./configure
loading cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking build system type... i686-pc-linux-gnu
...
ln: creating symbolic link `net' to `./bpf/n
On Mar 31, 2005, at 7:20 AM, Gabriel wrote:
Hello, I tried using tcpdump -xs 1500 -i eth0
"tcp[2:2]>=1000 and tcp[2:2]<=2000" but it doesn't
capture anything. When I tried tcpdump -xs 1500 -i
eth0 tcp[2:2]=1500 it worked out fine (it captured
everything with the dst port 1500). I'm using linux
with
On Apr 1, 2005, at 2:56 AM, Gabriel wrote:
Yes, it works when I use the -O option. Thanks.
So it's probably an optimizer bug, and...
The output of the first one is:
-
[EMAIL PROTECTED]:~> sudo tcpdump -d -i eth0
"tcp[2:2]>=1000 and tcp[2:2]<=2000"
(000) ldh [12]
(001) jeq #0x800
gilbert HOYEK wrote:
hi i would like to request a new DLT_SEPTEL for Intel/Septel cards used
in ss7 messages transfer .
DLT_SEPTEL, or DLT_MTP2/DLT_MTP3/whatever?
Unless there's some extra header on the packet that includes information
from the Septel cards, the DLT_ name probably shouldn't m
nswer from
Mr . Guy Harris (thanks 2 him).
so it helped me a lot but still the part about the pcap-dag.c , idid not
get it well .so if you can explain it to me i would be gratefu:
There isn't anything about pcap-dag.c in my message; pcap-dag.c is an
example of a way to add support for
Alex Narinsky wrote:
How can I test STAP if all G-machines have new PacketData with longer
fields?
The only one is old but Nir does not allow me to test STAP on this
computer?
Was this supposed to be sent somewhere other than tcpdump-workers? It
sounds as if you wanted to send it to a co-worker o
On Apr 5, 2005, at 10:36 AM, Shyam Kumar wrote:
I am working on utilizing tcpdump for the way it presents data. As per
my Switch/Router I have my own implementation of ACL (Access Control
List) / Filter rule set & want to enhance its data representation
part.
For that very purpose I need to utili
gilbert HOYEK wrote:
2-in pcap-linux.c only pcap-open-live and pcap-platform-finddevs contains
#ifdef HAVE_DAG_API . so do i have to make similar code (#if def
HAVE_SEPTEL_API ...) to only these two funtions in pcap-linux.c ?
Yes.
3- pcap-linux.c contains #include pcap-int.h with contains at
Michael Richardson wrote:
I'd like to make sure that libpcap 0.9.1-096 compiles on NetBSD 1.6.
It appears that the test for fddipad says defined(__NetBSD__),
but that member must have been introduced in a post-1.6 version of
NetBSD.
Actually, the problem appears to be that PCAP_FDDIPAD is defined i
Brown, Mark C (GSE GCSM) wrote:
I'm finalizing a small patch to pcap-dlpi.c for HP-UX systems and I have
two questions:
1) What is the preferred format for patches?
Context or unified diff, probably.
2) The main website says 0.9.0 went alpha today (the link to the source
is broken btw). What is th
Michael Richardson wrote:
I would like to plan a 3.9 branch and release for April.
I would propose branching on April 10, with the release around April 25.
How does that sound?
It sounds reasonable.
(It turns out I might be able to get gencode.c to handle radiotap -
*all* filter expressions other
David Young wrote:
Radiotap is designed to be a variable-length header. When you say that
gencode will handle it, you mean that it will skip based on the length
field to the end of the radiotap header? If so, that sounds great!
That's the goal. There are a number of places that need to be change
Daniele Orlandi wrote:
I would like to request a DLT_ number for raw LAPD (q.921) frames captured
thru vISDN, an ISDN architecture I'm developing for Linux. Some draft
documentation may be found at http://www.orlandi.com/visdn/
So this is D-channel only, i.e. a DLT_{whatever} capture wouldn't hav
On Apr 7, 2005, at 3:01 PM, Daniele Orlandi wrote:
It depends on what you mean with "no extra stuff". The payload is
raw-LAPD but
the capture includes the sockaddr_ll header because the dissector
needs to
know the interface's role in order to correctly interpret the C/R
flag.
Specifically, b
On Apr 7, 2005, at 6:19 PM, Felipe Kellermann wrote:
b) Couldn't parse.
"tarceing" is probably a typo for "traceing"; I don't know whether
"pots" is a typo for "ports" or not. He might be referring to
support for passive network taps.
-
This is the tcpdump-workers list.
Visit https://lists.san
On Apr 7, 2005, at 7:33 AM, Brown, Mark C (GSE GCSM) wrote:
Here's a patch to allow the user to override the DLSAP in the
DL_BIND_REQ via environment variable PCAP_SAP when running on HP-UX.
There have been issues with other applications binding to 22
I.e., other applications trying to read raw pac
Automatic cvs log generator /tcpdump/bin/makelog wrote:
Description:
-add support for llc based protocols (iso, etc..) for ethernet
by checking the proto against the ethermtu and bumping
the link-layer offset by two.
-add support for vlan and mpls hierarchies by not absolute
setting offsets but
Mike Kershaw wrote:
I have code which does this already for wireless (sending a modified
pcap stream basically).
Wrapping it in SSL would be trivial (already on the list of stuff to
support).
Moving this to pure pcap would also be trivial. This seems more
application layer than pcap layer -- by th
Daniele Orlandi wrote:
Yes, I agree, in facts I forgot that I was already using DLT_LINUX_LAPD.
I would go with DLT_LINUX_LAPD,
OK, I've checked in a change to make it DLT_LINUX_LAPD. Presumably the
theory is that either
1) vISDN will be the only ISDN-for-Linux that supports D-channel packet
c
branch has been made, so stuff checked in won't be in
0.9/3.9 unless the code is pulled up.)
Guy> I'll ask Albert Chin of The Written Word to try that on the
Guy> platforms they use (they don't offer libpcap or tcpdump as
perfect, since libpcap is really the
Hannes Gredler wrote:
if you want to do live capturing and decode using ethereal/tethereal then you'd
simply do:
ssh [EMAIL PROTECTED] "sudo tcpdump -ni eth0 -s 0 -w -" | tethereal -nli -
That works for Tethereal. For Ethereal, it's a bit more complicated -
on UN*X, you'd create a named pipe fil
On Apr 12, 2005, at 3:32 PM, Michael Richardson wrote:
Since libpcap doesn't have sending packets as a goal, I'd say that
libdnet supports sending on an infinite more than libpcap.
...except for libpcap 0.9, which *does* support sending packets.
-
This is the tcpdump-workers list.
Visit https://l
gilbert HOYEK wrote:
[EMAIL PROTECTED] make install
[ -d /usr/local/lib ] || \
(mkdir -p /usr/local/lib; chmod 755 /usr/local/lib)
/usr/bin/install -c -m 644 libpcap.a /usr/local/lib/libpcap.a
/usr/bin/install: cannot stat `libpcap.a': No such file or directory
So there's no "libpcap.a" in the "
eving revision 1.110
diff -c -r1.110 pcap-dlpi.c
*** pcap-dlpi.c 8 Apr 2005 03:08:00 - 1.110
--- pcap-dlpi.c 13 Apr 2005 08:42:50 -
***
*** 20,27
*
* This code contributed by Atanu Ghosh ([EMAIL PROTECTED]),
* University College London, and subsequently modified
Oolan Zimmer wrote:
In Gcom's T1/E1 driver, a DL_ATTACH_REQ chooses the physical port and a
DL_BIND_REQ chooses the logical channel on that port. A logical channel is
a collection of one or more timeslots, and its associated SAP is
configurable (usually just starts at 1 for the configurations we d
Maxime Josset wrote:
I used WinDump and it captures files but i need your help to format them.
How can i decode the capture files XXX.dmp with TCPDump on a Windows XT in
order to render them as text?
"TCPDump on a Windows XT" (did you mean "Windows XP"?) is called
"WinDump"; WinDump is a port of t
Jeff Terrell wrote:
Is there a FAQ for either this list or for tcpdump development in general?
There is a tcpdump/libpcap FAQ:
http://www.tcpdump.org/faq.html
but it's not a FAQ for people doing development of tcpdump itself.
Is the sourceforge page really out of date, or are there really p
On Apr 15, 2005, at 1:10 PM, ury segal wrote:
I have pcap_dispatch sometimes returning value <0 and
pcap_geterr printing "Resource temporarily
unavailable".
The pcap handler is non blocking
(pcap_setnonblock was called with 1), the fd was
found with pcap_get_selectable_fd, it was select()ed
on and
Brown, Mark C (GSE GCSM) wrote:
I pulled the latest source from the CVS with your changes checked in
this morning:
Yeah, I decided not to do the "cleans up a bit of the DL_HP_RAWDLS
stuff", as the configure script treats HP-UX other than 9.0, 10.0x, and
10.1x as 10.20 or 11.x, so presumably it's
gilbert HOYEK wrote:
hi again , after i made the necessary changes to libpcap api and wrote a
pcap-septel.c using the septel library files , i need to know now ,if
you dont mind , what changes do i have to make to ethereal so that it
will support it .
as i think it should be something like captu
On Apr 18, 2005, at 12:00 AM, Tien Quang Huynh wrote:
At present, I need to know the structure of libpcap files to write
software.
Because I need to analyze Ethereal results.
If you just want to read a libpcap file, you can do that with libpcap
- pcap_open_offline() and pcap_loop() (or pcap_dis
ury segal wrote:
The code runs on Solaris 8. Sorry for misinforming
you before.
The code that produces the message is:
if ( (packet_from_pcap= pcap_dispatch(pcpaph,
1,
_pcap_reader,
(u_ch
ury segal wrote:
Any idea what is wrong with my sample program ?
What's wrong with your sample program is that
1) it's using non-blocking I/O and select() with a timeout, and calling
"pcap_dispatch()" regardless of "select()" says input is available on
the pcap_t or not;
2) it's running
ury segal wrote:
After fixing the program to save the value of the
pcap_dispatch correctly, I found it to be -1.
After expanding the if block of FD_ISSET to include
the pcap_dispatch call :-) , I don't see this message
any more.
Yes - but, as I noted, there's a problem with select() on BPF in some
K. Anantha Kiran wrote:
When i try to read each packet from "xx.dump" by using pcap_next, i
am always finding pcap header having "len" member value as "60" when i
read a packet which actually doesnot contain any data (For example ack,
fin packets) . What can be the reason for this.
As Aaron
v9 wrote:
3 infinite loop dos bugs... the bgp and ldp one SEEM to be fixed in the
cvs versions...the isis one isn't.
I've checked in a change that *should* fix the ISIS loop, but I haven't
tested it directly.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
soumya r wrote:
I am a newbie doing packet capturing using 'libpcap'. I want to know
whether the output given by pcap is fragmented packets or defragmented
packets. Please help.
The output will, if you're capturing on a network interface, be the
low-level packets from that interface. Packets can
On Apr 26, 2005, at 3:47 PM, Alexander Dupuy wrote:
The problem is that __ntohl et al. are already #defined as special
asm functions:
...
but this is easily fixed:
Checked in. Are there any *other* x86 UN*Xes that might have this
problem?
Another problem is that print-sunrpc.c doesn't com
Alexander Dupuy wrote:
I sent a report on this previously, but it didn't seem to go through on
the list.
Perhaps you're not getting stuff on the list delivered; I saw it, and
responded.
This is with the 2005-04-26 snapshot:
One problem occurs because of FreeBSD's #define of __ntohl as an inline
Gali Diamant wrote:
I expected pcap_dispatch to return since we have set
the handle to be non blocking. Instead, it doesn't and
blocks waiting. Is this the correct behavior or is
that an AIX issue? It doesn't happen on Linux or
Solaris.
It's probably an AIX issue; perhaps non-blocking mode doesn't
On Apr 27, 2005, at 12:22 PM, Guy Harris wrote:
Why is this occurring at all? I.e., why are we even including the
OS's pmap_prot.h file to *cause* problems?
Perhaps, on some UN*Xes, we get that because we include some system
RPC header files in print-sunrpc.c.
If that's unavoidable
On Apr 28, 2005, at 8:21 PM, alexander medvedev wrote:
I would like to compile a list of AIX's bpf flaws and lacking
features.
1. non-blocking read does not work;
2.
2. It's not documented.
3. It appears that, sometimes, when you read from a BPF device, you
get EFAULT for no good reason. (Se
Siva Ramagopal wrote:
I'm interested in knowing how tcpdump identifies the application or
service to which a packet belongs to. Is the /etc/services file used in
this operation or is there a list of mappings between well-known ports
to their corresponding applications that is used instead?
"iden
Sivakumar Ramagopal wrote:
When it dissects the packets for a particular protocol, it uses its
built-in notion of which port numbers are used on which ports.
Did you mean notion of which *protocols* are used on which ports?
Yes.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/
Pawel Pokrywka wrote:
Hello,
I need to specify packet direction for my sniffing application, but
current libpcap doesn't offer this functionality. I've found a patch[1],
which adds ability to set direction of packet capture.
The patch works good, but it modifies pcap_pkthdr struct from pcap.h,
whic
Alexander Dupuy wrote:
If that's unavoidable (i.e., if some system header file we're including
drags in pmap_prot.h), perhaps we should modify our pmap_prot.h so
that it
uses different names for what it defines, so we don't get the name
collisions that I'm assuming are causing the compile problems
Pawel Pokrywka wrote:
For me, only D_IN is required, so I would be happy with this direction
only :)
I don't know other platforms, but are you sure that there is no way to
implement for example D_IN, when there is D_OUT and D_INOUT? Maybe there
are other problems, but substracting D_OUT from D_INO
Pawel Pokrywka wrote:
Back to pcap_direction() function. I think I better like idea, that
pcap_direction() should return error when given direction is not
supported on users platform.
If there are no better ways, enclosing pcap_direction() body and
direction checks in pcap_read_packet() with #ifdef
Pawel Pokrywka wrote:
Here comes my latest patch.
Checked in, with some changes to handle old-style SOCK_PACKET sockets on
Linux (pcap_setdirection() isn't supported there, as the direction isn't
available), and to use the standard tab-based indentation.
On unsupported capture mechanisms setdire
Which e-mail address should I use in the CREDITS file? I used your
GMail address.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On May 4, 2005, at 7:21 AM, Wilmar Sulaiman wrote:
I am new to libpcap library, I was wondering how to get the payload
length and to print the payload content. I've look the tutorial at
http://www.tcpdump.org/pcap.htm. However my concern is they using
size of ethernet + ip + tcp, while it is
(Blah blah blah wrong From: address blah blah blah work around duplicate
detection blah blah blah.)
soumya r wrote:
I am doing packet sniffing and i found the "sniffer.c" program of
pcap web site extremely helpful. But i have got one problem. I am not able to
display the packet payload properly.
J.O. Leger wrote:
Is the timestamp in pcap_pkthdr from the hardware clock or the software clock?
The timestamp is from whatever it's from. :-)
If you're capturing on an interface on a UN*X or Windows (with WinPcap)
machine, the time stamp is from the capture mechanism that libpcap uses.
Those ca
Per Engelbrecht wrote:
Hi all
I'm having a peculiar problem with tcpdump (tcpdump version 3.4.0 /
libpcap version 0.5)
Those are very old versions - the current versions are 3.8.3 and 0.8.3.
Are those the versions that came with OpenBSD?
tcpdump with 0-2 flags = output.
tcpdump with 3-x flags =
prabhakaran amith wrote:
I have got knoppix installed in my system.the package
manager shows that libpcap is already installed .But
when i write a program using that i get errors saying
pcap.h not found.when i try searching for the file i
dont find anything apart from libpcap.s0.8 and
libpcap.s0.8.
Per Engelbrecht wrote:
This is a pre-release snapshot, don't know what stable will be shipped
with, but I expect no major changes in forthcoming 3.7 release (may 19).
OK, so some issues with it might be the result of stuff the OpenBSD
people have done.
What happens if you do
sudo tcpdump -n
prabhakaran amith wrote:
are u aware of any site where i can download those(the
developer package)
Presumably you'd get the developer package from the same place you get
other packages for Knoppix. I don't use Knoppix, so I can't offer any
more advice than that.
-
This is the tcpdump-workers lis
alexander medvedev wrote:
Which of the two (BPF or DLPI) will generally give you better performance?
Particularly, i am looking to reduce the number of dropped packets.
Will DLPI capture even report captured/dropped packet count?
On most OSes, one of them won't capture any packets whatsoever, as mo
J.O. Leger wrote:
The application that is using libpcap sometimes displays "unusual"
timestamps.
"Unusual" in what sense?
I believe this is caused by the hardware clock and the
software clock being set to different times.
To which hardware clock are you referring?
Note that, as far as I know, the t
Plantier, Spencer wrote:
I get this error when I try to install libpcap. I have downloaded and
installed the most current version of flex.
configure: error: Your operating system's lex is insufficient to compile
libpcap. flex is a lex replacement that has many advantages, including
being able t
Sanjay Patnaik (sanpatna) wrote:
I downloaded the libpcap-0.8.3.tar.gz and made a build.
It created the libpcap.a in the /usr/local/lib direcotry. But there is
no libpcap.so.0.8.3. I need the libpcap.so file as it is required
by the ethereal installation.
How should I do it.
*IF* you're using Lin
rupesh gautam wrote:
i have to do analysis for packet drop by changing buffer length on
fedorais it possible in libpcap to change buffer length...
It is possible to *change* libpcap to set the buffer length
and where is the code for buffer length
There isn't any. You'd have to add it.
On L
rupesh gautam wrote:
why changing buffer size is unimplementable on systems with bpf.
It's not *completely* unimplementable.
It can, however, not be done after the BPF device has been bound to a
network interface, which means that it cannot be done after
"pcap_open_live()".
I don't know why the
Gianluca Varenni wrote:
Is there any new plan for the release of libpcap 0.9?
At this point, I don't have anything additional planned for tcpdump
(other than perhaps grabbing some more capture files from the Ethereal
Web site and from mail to the Ethereal list, and running tcpdump against
those
Gcom, Inc. wrote:
We are considering adding support in libpcap to use a windows named pipe
as a capture interface. The other end of the windows named pipe would
present a libpcap file-format stream of data, so relatively little would
need to be done in libpcap to make this work. If we were to
On May 18, 2005, at 4:33 PM, mcr wrote:
I will cut a new beta, with a full pullup from HEAD of libpcap on
May
23. How is that?
Sounds good (although, at this point, the x.9 branches and HEAD are
the same for libpcap and tcpdump except for a couple of things in the
"tests" directory and the
On May 18, 2005, at 4:24 PM, Manu Pathak wrote:
I just finished adding support for LMP Service Discovery extensions
(defined in the UNI 1.0 spec) to tcpdump and would like to have these
changes integrated with the mainline tcpdump code. Could somebody on
this list tell me how to go about it (I a
Manu Pathak wrote:
Thanks for the information! The diffs are attached. Regards,
OK, checked in. It should be in 3.9.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
[EMAIL PROTECTED] wrote:
Here is a simple question I had, and just wonder whether you guys run into
the same situation or not.
When I do a tcpdump like this:
->/usr/sbin/tcpdump -n -s 54 -c 200 -w 54-200.bin
which means I need 54 bytes of the packet content. But when I check the
file size, I
On May 25, 2005, at 10:19 AM, mcr wrote:
Hi, I haven't cut the branch yet. Tonight, I think.
Cool.
I have a good excuse --- a child process was spawned, and it doesn't
take well to resource limits yet :-)
Congratulations are due, I assume
The impression I get is that RLIMIT_CPU isn't
Burton Strauss wrote:
Near real-time scenario - suppose I need to process packets as quickly as
they arrive. The per-packet processing time can exceed the inter-arrival
time and so I want to create a bunch of worker threads to process packets
in parallel.
I.e., you're running on an MP machine
Loris Degioanni wrote:
Trying to understand why the -C tcpdump option doesn't work under
Windows, I realized that a file pointer created in a dll can only be
used inside that dll. This is a documented Windows limitation.
Gak. That sux. Ethereal's capture file library is also done as a dll
on
On Jun 2, 2005, at 11:42 AM, Loris Degioanni wrote:
Trying to understand why the -C tcpdump option doesn't work under
Windows, I realized that a file pointer created in a dll can only
be used inside that dll. This is a documented Windows limitation.
So where is this documented?
-
This is t
On Jun 2, 2005, at 1:35 PM, mcr wrote:
Seems reasonable, but it certainly seems like a Windows.dll silly
to me.
Yes, but, as per my mail, there are arguably other reasons why
pcap_dump_ftell() should exist, namely that applications should have
the idea that a "pcap_dumper_t" is just a
On Jun 2, 2005, at 3:42 PM, Gianluca Varenni wrote:
Here is a KB documenting it
http://support.microsoft.com/default.aspx?scid=kb;en-us;94248
That's a bit nastier - not only can't a C runtime file handle (the
file descriptors returned by the UNIX-like _open() call and used by
the UNIX-li
Loris Degioanni wrote:
When were pcap_fopen_offline(), pcap_dump_fopen() and the other FILE
related functions introduced?
November 2004:
https://sourceforge.net/tracker/index.php?func=detail&aid=1051449&group_id=53067&atid=469577
We still don't export them in WinPcap, and
I don't s
On Jun 3, 2005, at 10:40 AM, Guy Harris wrote:
As happens all too often, patches that add new APIs don't include a
patch to pcap.3.
Either that patch did, or I added it, as those routines *are*
documented in pcap.3.
-
This is the tcpdump-workers list.
Visit https://lists.sandelm
On Jun 3, 2005, at 2:29 PM, Loris Degioanni wrote:
Consistency of the API across different platforms, taking into
consideration that some of them could have serious rerstrictions,
is an advantage for everybody, developer's and maintainers. Not
only Chris Lightfoot. And has always been the
Loris Degioanni wrote:
I've removed pcap_fopen_offline() and pcap_dump_fopen() from the WinPcap
exports and manual.
OK - should we #ifdef them out on Win32, so that they're not even
compiled into the library? (And then update the man page to say "not
available on Windows".)
Just a small no
Mark Pizzolato wrote:
In the MS CRTL, a fpos_t
is a 64bit integer, while on other platforms it may be a structure of
some sort.
Does Microsoft explicitly promise that an fpos_t is a 64-bit integer on
Windows? (It doesn't matter about UN*X, as ftello() can be used there,
and, as I understand
Loris Degioanni wrote:
So no all Unix systems have types.h?
Not all UN*X systems necessarily have a types.h that define u_int64_t or
uint64_t.
What about using something like the
bittypes.h in the missing folder of tcpdump?
That might be one way.
Can the MSVC++ I/O routines handle files
Fulvio Risso wrote:
Personally, I never use CRTDLL.LIB/MSVCRT.LIB, because in this case I'm
forced to distribute my application with tons of DLL (MSVC*.DLL), which are
far bigger than the application itself.
Therefore, I'm always using the standard C library.
The difference here, for the benef
On Jun 7, 2005, at 3:49 AM, Bruce M Simpson wrote:
1) Compatibility of WinPcap vs libpcap -- it would be nice if we
could build both Win32 and UNIX versions from the same libpcap
tree,
but this is something we can work around at XORP makefile level;
Build Win32 and UNIX versions o
Robert Lowe wrote:
Set the to_ms parameter in your pcap_open_live() call to a short[er]
interval.
Yes, there's nothing special about a value of -1 for the timeout; the
timeout value is, on systems using BPF (such as BSDs), just converted to
seconds and microseconds and passed to the BPF devi
Sam Pierson wrote:
On a hopefully final note,
It came back quickly when I passed a 1 in as the to_ms parameter, but is there
something I can define so that when it picks a packet off the wire, it reads it
_immediately_.
Not at present. There's an ioctl needed to enable immediate mode on
BPF,
Gerald Combs wrote:
We recently added fuzz testing to Ethereal's automated build system. I
tried out the script we're using on tcpdump and it turned up a bug in
util.c.
Yes, I've fixed some bugs that it turned up with my capture menagerie.
(Yes, I need to run the fuzz testing with those captu
On Jun 15, 2005, at 10:55 AM, Gerald Combs wrote:
It's attached to this message
It doesn't appear to have gotten attached.
and is also available at
http://www.ethereal.com/~gerald/lcp-crash.pcap .
OK, got it. I've checked in a fix for the underlying problem, and
audited the calls to "p
On Jun 15, 2005, at 6:10 PM, Guy Harris wrote:
OK, got it. I've checked in a fix for the underlying problem, and
audited the calls to "print_unknown_data()" and checked in other
fixes.
BTW, whenever you're dealing with TLVs and, especially, TLVs whose
data is made
Joshua Blanton wrote:
It does appear that printf doesn't set errno, at least on linux and
OSX,
It probably will set errno if
1) it gets an error writing to the standard output (e.g., if it's
redirected to a file, and the file system is full or you're over quota)
or
2) it calls "isatty()
Andy Chittenden wrote:
Rather than using OS specific #defines, wouldn't it be better to use
HAVE_SYS_FILE_H and set that appropriately for MSDOS (and our embedded
OS)?
One problem with doing that is that pcap.h includes other header files,
so if it did that, either
1) HAVE_SYS_FILE_H would
On Jun 23, 2005, at 12:39 PM, gilbert HOYEK wrote:
hi all , i have added two days ago a support for libpcap to be
able to capture mtp2 low level protocol ss7 messages over INTEL/Net
Structure cards (or Septel cards).
...with Intel's software for those cards on Linux.
-
This is the tcpdum
Phil Wood wrote:
It works, but I think args 2 and 3 (of 4) to fread are swapped.
Unless it forces the kernel to read a character at a time?
Line 1048: amt_read = fread((char *)&hdr, 1, sizeof(hdr), fp);
That call says "read 'sizeof(hdr)' 1-byte entities, and return the
number of 1-byte ent
xiaolei zhang wrote:
why the original buf_size == 8192 ?
We have to pick *some* size. I guess 65536 will probably be big enough
on most if not all systems, and probably small enough, but it's
ultimately arbitrary.
in my system, sizeof(struct ifreq) is 40, if the buf_size is 44, then
ioc
On Jun 27, 2005, at 12:50 AM, Olivier Godineau wrote:
I try to read captured packets on my machine with
pcap. with no difficulty, i achieve this.
TCPDUMP is able to capture some packets dropped by
iptables.
But with pcap i'm not successful with.
How it is possible to capture iptables dropped pa
Guy Harris wrote:
This means that, unless I've missed something, the *only* ways to ensure
you have the entire list are either to loop, increasing the size of the
buffer, until the difference between the buffer size and the number of
bytes of interface information returned is less tha
On Jun 29, 2005, at 12:11 PM, Nathan Jennings wrote:
There's one issue I've run into: after displaying certain packets
(see function print_payload), my xterm/bash shell loses the ability
to display newlines (i.e scroll lines). I suppose this is due to
the display of a certain sequence of c
301 - 400 of 2513 matches
Mail list logo
