On Thu, Apr 01, 2004 at 02:12:35PM +0200, Hans Klute wrote:
> Now I have noticed that about every 3 minutes and 15 seconds the Program
> uses 100 % of the CPU.
> After about 45 sec the program works normal again and uses only 10% of the
> CPU time.
> The program is running on a 300 MHz Celeron with
On Thu, Apr 01, 2004 at 02:11:24PM -0800, Rick Jones wrote:
> Seems that some of the "DL_HP_mumble_OBS" defines being looked for in
> pcap-dlpi.c are no longer present in 11.23. This leaves a routine
> undefined in the libpcap.c and that makes tcpdump grumpy. The following
> are some diffs agains
On Mar 27, 2004, at 9:15 PM, Michael Richardson wrote:
Do these need to be in every packet? Maybe it is just meta-data that
needs to be added at the beginning, perhaps along with the filter code.
The packet direction and, for received packets, an indication of how it
was received, would be per
On Sun, Apr 04, 2004 at 11:53:18PM -0400, Michael Richardson wrote:
>
> Itojun changed print-esp.c to look up crypto routines using
> EVP_get_byname() instead of having a table.
>
> The problem with that is that the ivlen differs for different
> algorithms. This is easily solved by calling EVP_CI
On Sat, Apr 03, 2004 at 05:44:55PM -0500, Michael Richardson wrote:
> It appears that we don't really do the right with:
>
>./configure --with-crypto=/path
>./configure --with-openssl=/path
>./configure --with-ssleay=/path
>
> (I'm uncertain which of these is right)
"--with-openssl"
On Apr 5, 2004, at 10:39 PM, Ryan Mooney wrote:
What about adding the concept of arbitrary meta-packets that can
sit anywhere in the capture stream. These could be used to encode
comments, and other meta-data.
In Michael Richardson's proposal, a capture file is a sequence of
records, each of whi
On Tue, Mar 23, 2004 at 04:56:43PM -0800, Mark Pizzolato wrote:
> I wonder where the sendto() stuff is really necessary. The simple send()
> worked for us on RH 7.3-Fedora Core1 on Intel. And RH 6.2 on Sparc, and
> numerous other linux environments. We've never gotten a complaint
"send()" a
On Apr 8, 2004, at 6:52 AM, Fabio Duarte wrote:
Hi, some weeks ago I asked about how I could know if a pcap captured
packet was tranmitted to or received from the network. Well, I found a
patch that solves this problem and it might help some people. It only
works for linux 2.4.x and later, but
On Fri, Apr 09, 2004 at 06:29:42PM +1000, Ronnie Sahlberg wrote:
> A capture application could then initially write length==0 when it first
> writes out the SHB and then not seek() back and write the real length until
> it closes the SHB.
...unless it's writing to a pipe; I think people sometimes
On Fri, Apr 09, 2004 at 05:06:59PM +0200, Francis Dupont wrote:
> ESP decryption should not be performed on the authentication trailer...
...
> PS: here is the fix (for tcpdump 3.8.3 release):
Checked into the main and 3.8 branches.
-
This is the tcpdump-workers list.
Visit https://lists
On Sat, Apr 10, 2004 at 04:39:41AM +1000, Darren Reed wrote:
> I'll agree that this, as part of the per-packet header, would be a useful
> addition to the pcap format. No need for chained hashing, just per-record.
Part of the packet block header, or an option in the packet block? I'd
vote for th
On Apr 12, 2004, at 2:25 AM, Darren Reed wrote:
In some email I received from Guy Harris, sie wrote:
On Sun, Apr 11, 2004 at 03:15:30AM +1000, Darren Reed wrote:
And there's also BPF_MAXBUFFERSIZE. I see pcap_getbuff() as being
essential to getting code to work without trial and error by pa
On Apr 12, 2004, at 4:43 PM, Darren Reed wrote:
The problem with pcap_next_ex() is the man page description:
"reads the next packet and returns a success/failure indication"
Well, it says more than that - it indicates what the values of the
success/failure indication mean, and says what is suppli
On Apr 12, 2004, at 5:07 PM, Guy Harris wrote:
...which would require that "pcap_pkthdr" be changed to begin with a
"struct pcap_timeval". If it's OK to, on platforms where, for
example, "ts_sec" is 64 bits, break binary compatibility with
applications
On Mon, Apr 12, 2004 at 05:07:35PM -0700, Guy Harris wrote:
> The mail archives with the mail in question are at home, but I think
> I've exchanged mail with some IBM person and not seen anything come of
> it.
Yes, nothing appears to have ever came of it (you were CCed on th
On Apr 13, 2004, at 6:58 AM, Darren Reed wrote:
What I'd like to see hashed, by the kernel, is the data it provides
to the user application. Depending on the purpose, this has better
trustworthiness, I feel. libpcap may decide to throw away that hash
and include its own in the dump file.
I'm not
On Apr 13, 2004, at 3:18 PM, Darren Reed wrote:
Ok, now that I read it, I find it tries to do too much (in my
opinion.) The part that makes it go off and read more data is
of questionable value ?
I.e., the fact that it - like "pcap_next()" - will fill the packet
buffer if it's empty?
As for non-
On Apr 13, 2004, at 3:38 PM, Darren Reed wrote:
In each case the specification defines support for a number of
different
hashes, of varying strengths and the choice is left to the end user to
decide on what they wish to use. I don't see why libpcap should be any
different.
If the hash value is g
(Noise inserted in the hopes that that the mailing list software doesn't
think that this is a duplicate of my previous message, which I sent from
my sonic.net address and which thus didn't get through, and thus prevent
it from getting to the list.)
On Wed, Apr 14, 2004 at 12:30:45PM +1000, Darren
On Wed, Apr 14, 2004 at 09:23:52AM +0200, Fulvio Risso wrote:
> If everything is "optional", two compliant implementations cannot exchange
> data.
If the hash is an option (which it should be!), compliant
implementations should handle hash values they know about and just
ignore those that they don
On Wed, Apr 14, 2004 at 02:13:54PM -0400, Jefferson Ogata wrote:
> - Is the list still being archived?
Yes.
> If so, where?
The same place as always - the postings for year , month MM are
archived under
http://www.tcpdump.org/lists/workers//MM/maillist.html
However, the page at
On Wed, Apr 14, 2004 at 02:13:54PM -0400, Jefferson Ogata wrote:
> So now I have these questions:
One more issue:
At least at one point, postings with more than 2048 bytes of mail
headers were rejected - but that includes "Received:" headers,
which means that if you have t
On Apr 14, 2004, at 11:23 AM, Guy Harris wrote:
One more issue:
At least at one point, postings with more than 2048 bytes of mail
headers were rejected - but that includes "Received:" headers,
which means that if you have too many mail routers you might be
On Apr 14, 2004, at 12:06 AM, Jefferson Ogata wrote:
Additional protocol dissectors for protocols unknown to
tcpdump/tethereal could be written in any language with XML support
(preferably event-based). In fact, many protocol analyzers could be
written directly in XSLT/XPath and processed using
On Wed, Apr 14, 2004 at 04:56:49PM -0400, Norman Elton wrote:
> We've got a system running RedHat Enterprise WS 3.1, kernel
> 2.4.21-9.0.1, running tcpdump 3.7.2 and libpcap 0.7.2. When I run a
> tcpdump (tcpdump -i eth2 -nne), things run fine for about two minutes,
> then the dump mysterious st
On Fri, Apr 16, 2004 at 12:17:54AM +0200, Jacky Buyck wrote:
> This last one, if I've correctly understand handle all the addresses
> that can be use on an interface.
Yes, but note that they aren't all necessarily IPv4 addresses - you have
to check the "sa_family" member of the address before prin
On Apr 16, 2004, at 3:01 AM, Chen Hsia Lee wrote:
I have just started using libpcap and am still unfamiliar with it.
What is the filter expression to pick up only wireless 802.11 packets?
If you're capturing on an 802.11 interface, by definition all the
packets you will get are wireless 8
On Tue, Apr 20, 2004 at 06:16:48PM -0700, Michael Richardson wrote:
> Darren> btw, is it at all easily possible to get the 802.3 checksum
> Darren> into captured data ?
>
> On some OSes you ask for that. Not on BSD AFAIK, yes, with PF_PACKET
> on Linux.
Some BSDs give it to you, at lea
On Fri, Apr 23, 2004 at 11:05:23AM +1000, Darren Reed wrote:
> The only part that wasn't thread safe (last time I checked)
> was pcap_compile().
On Linux 2.0[.x] kernels, opening and closing a device isn't
thread-safe, either, as, if the device is opened in promiscuous mode,
it's added to a global
On Sat, Apr 24, 2004 at 07:21:59PM +0530, Chen Hsia Lee wrote:
> I tried to set the wireless card into monitor mode using:
> iwconfig eth1 mode Monitor
> The error it gave was:
> Error for wireless request "Set Mode" (8B06):
> SET failed on device eth1: Invalid argument
The Airon
On Wed, Apr 28, 2004 at 04:22:38PM +0200, César Cárdenas wrote:
> It works now!!!
Note that newer versions of libpcap/WinPcap have "pcap_findalldevs()",
which returns information about all interfaces libpcap/WinPcap knows
about and can open; the interface names are always in ASCII.
> ps by the wa
On Apr 28, 2004, at 7:03 PM, Michael Richardson wrote:
Hannes,
ipproto.c has IPPROTO_IGRP, but ipproto.h doens't define it.
Is this supposed to be protocol=9 ("IGP"), which you have as
IPPROTO_PIGP, or???
Actually, I made it IPPROTO_PIGP, not Hannes - that one's not his fault.
We used to have IPP
On Apr 29, 2004, at 11:00 AM, Michael Richardson wrote:
Your patch means that one can not decode v6 packets in a v4-only
environment.
I think that's already the case.
We have strived to provide replacement headers whenever possible such
that the dissectors are fully features on all platforms.
T
On Apr 29, 2004, at 4:05 PM, Michael Richardson wrote:
Okay, it has been years since I was on a v6-crippled system, so I
didn't
know that we weren't OS independant.
Can we extract some in6_addr code from one of the BSDs and include
that if we need it?
That might work - one concern would be a coll
On Sun, May 16, 2004 at 06:26:40PM -0400, Michael Richardson wrote:
> LINKTYPE enumeration. - metadata about linktype in file.
> MUST put a meta-data packet about a particular link type before you
> use that LINKTYPE.
>
> - - string saying name.
Is the name one thing assigned to it when a new
On Wed, May 19, 2004 at 03:54:48PM -0400, [EMAIL PROTECTED] wrote:
> I recently compiled snort 2.1.3rc1 with libpcap 0.8.3 on Solaris 8 which
> uses libpcap to report statistics among other things.
> Before that I was running snort 2.1.1 with libpcap 0.7.2.
> Whereas before I used to see 0% pack
On Fri, May 21, 2004 at 02:06:57AM -0700, Guy Harris wrote:
> The DLPI code should *probably* add the dropped-packet count to the
> packets-received count, so as to reduce the differences between
> statistics (although it doesn't eliminate them - the right long-term fix
> is prob
On May 21, 2004, at 7:26 AM, [EMAIL PROTECTED] wrote:
The way I see it in snort's implementation of the statistics it's doing
ps_drop/(ps_recv + ps_drop). So I believe that part is accurate.
As far as I can tell, that'd be *wrong* on BSDs and Linux 2.4 and later.
The BPF in the BSDs I've looked at
On May 17, 2004, at 11:31 AM, Lance Uyehara wrote:
Is there a thread safe version of libpcap around?
I have pcap programs which include hostnames, i.e "dst host
blahblah.com"
and if multiple pcap programs fail to resolve the hostname then I
sometimes
get a core. I've looked at the source and I be
On May 23, 2004, at 6:37 PM, Brandon Stafford wrote:
I'm writing a server that captures UDP packets and, after some
manipulation, sends the data out the serial port. Right now, I'm using
recvfrom(), but it takes 20 ms to execute for each packet captured. I
know that tcpdump can capture packe
On May 26, 2004, at 1:55 AM, Gisle Vanem wrote:
I feel it's high time we cleanup some of the sources. I'd start
with savefile.c. Currently it doesn't work for offline data from stdin.
--gv
--- libpcap-2004.05.20/savefile.c Tue Mar 23 21:18:08 2004
+++ savefile.c Wed Mar 24 16:29:06 2004
@@ -
On May 26, 2004, at 3:24 AM, [EMAIL PROTECTED] wrote:
gcc, at least on my FreeBSD 4.9 box, doesn't like an active statement
before the first declaration (compiling tcpdump-2004.05.20):
./print-ipx.c: In function `ipx_print':
./print-ipx.c:60: syntax error before `const'
I fixed it as shown below.
C
On May 26, 2004, at 2:16 PM, Gisle Vanem wrote:
I wasn't sure why either. Maybe reducing the chance of a file with
truncated packets. I just moved setbuf() further up.
Actually, you moved the "if (f == NULL)" check down, leaving the
"setbuf()" where it was, and also removed the "#ifdef WIN32"/"#en
On May 26, 2004, at 2:35 PM, Guy Harris wrote:
Also, that means that if it's writing to the standard output it won't
do a "setbuf()" even on Windows.
...which, of course, it isn't doing now, either - but now writing to
the standard output won't work right on Windows
On Thu, May 27, 2004 at 02:38:57PM +0800, Bassam A. Al-Khaffaf wrote:
> But for other ether frame protocols such as arp, rarp and ip there is no
> problem and they work.
Try just
tcpdump netbeui
"ether proto" expects a protocol with an Ethernet type value - but
NetBEUI doesn't have an Et
On May 27, 2004, at 11:04 AM, [EMAIL PROTECTED] wrote:
Below are patches to perform significantly more complete LDP decoding.
Checked in, with an unused variable removed, and with declarations of
"decode_prefix{4,6}()" put into a "decode_prefix.h" header included by
"print-bgp.c" and "print-ldp.c
On May 27, 2004, at 5:22 AM, Gisle Vanem wrote:
Since pcap_dump_close() doesn't have a pcap_t argument, where should
the oldmode come from? Can we have two module globals; oldmode_stdin,
oldmode_stdout, assuming stdin/stdout won't be opened for capture more
than once?
If it's opened for capture or
On May 27, 2004, at 11:56 PM, Jun-ichiro itojun Hagino wrote:
Yes I am doing live capturing, but all what I interested about is the
16
byte "Source Name" field (Name to Add). I want to include the tcpdump
command in my perl program so that I can make further processing on
the data
of that field
On Fri, May 28, 2004 at 11:55:53AM -0700, Guy Harris wrote:
> Or that he modify an existing program using libpcap, namely tcpdump, to
> understand more NBF command types (such as ADD_NAME_QUERY, which his
> packet appears to be), and then send us the patches so we can add that
>
On Mon, May 31, 2004 at 03:45:04PM +0800, Bassam A. Al-Khaffaf wrote:
> As introduction for me to learn the network programming, anyone can tell me
> what is the difference between the "pcap" and "libpcap"?
THe letters "l", "i", and "b". :-)
The name of the library is "libpcap"; sometimes people
On Jun 4, 2004, at 9:32 AM, ice ice wrote:
Yes, I should say that the trace file is in pcap format.
20020814-09-0-anon.pcap.gz: tcpdump capture file (little-endian) -
version 2.4 (BSD/OS Cisco HDLC, capture length 48)
So I couldn't assume the 48byte header is the normal IP+whatever
header ev
On Jun 4, 2004, at 1:09 PM, ice ice wrote:
here is more information about tcpdump's output:
% tcpdump -c 5 -n tcp -r 20020814-09-0-anon.pcap.gz
11:00:00.58 69.245.49.10.2082 > 143.173.237.247.1214: .
2133229289:2133230749(1460) ack 6821225 win 17188 (DF)
11:00:00.69 236.179.225.218.473
Martin Angler said:
> my name is Martin Angler and I am developing a BACnet MS/TP - enabled
netdevice-driver
> under GNU/Debian Linux. Now I've seen, that there is no linktype that
specifies BACnet
> MS/TP. So I wanted to ask whether you could define/implement a
corresponding linktype.
I infer fro
On Jun 7, 2004, at 3:28 AM, Martin Angler wrote:
Yes, our driver will supply "raw" packets with the header specified by
the BACnet specification. Therefore we would appreciate your first
suggestion, which would be naming the linktype DLT_BACNET_MS_TP.
OK, I've added DLT_BACNET_MS_TP, with the val
On Jun 9, 2004, at 1:27 PM, Rick Jones wrote:
Does it always happen or just sometimes? A DL_UNITDATA_IND is
basically saying "Hi there, here is a packet" in DLPI speak. It looks
like the stream is sending one of those up to the application when
libpcap isn't expecting it.
In fact, it's sending
On Jun 9, 2004, at 1:58 PM, Rick Jones wrote:
On the surface I wouldn't think so - simply attaching to a PPA I don't
think means traffic could arrive - however, if one has attached, and
then binds to a SAP, then traffic could indeed start arriving.
(Il-informed guesstimation, and hopefully I'm
On Jun 9, 2004, at 2:55 PM, Rick Jones wrote:
Guy Harris wrote:
Well, we *are* doing an info request after binding, so perhaps it
might happen then.
I'm not sure why we're doing that; it dates back to libpcap 0.4. Do
you know of any reason why the "dl_mac_type" from an
On Jun 11, 2004, at 9:03 AM, Gordon Tyler wrote:
So, the rough summary of all this is that it was unlucky timing that
libpcap received a packet which it wasn't expecting?
The rough summary is that it's unlucky timing, but libpcap is *perhaps*
doing something it doesn't need to do and, if it didn't
On Jun 14, 2004, at 7:11 AM, fcarone wrote:
Hello! Im new in programming with libpcap and im using the
libpcap0.8.3, and i´d like to know if the timeout works in linux RH9
kernel 2.4.20.
No, it does not. The timeout is passed on to the underlying OS's
packet capture mechanism, if it supports a
On Jun 14, 2004, at 1:38 AM, Raphael Raimbault wrote:
There is a patch for 3.8.3 version:
--- tcpdump.c.orig Sun Jun 13 15:50:49 2004
+++ tcpdump.c Sun Jun 13 16:05:34 2004
@@ -615,7 +615,7 @@
/* NOTREACHED */
}
- if (tflag > 0)
+ if ((tfla
On Jun 15, 2004, at 2:49 PM, John Heffner wrote:
I've found that on my linux machines, setting the rcvbuf on the packet
socket bigger helps to reduce drops at high rates.
I implemented the following, though I'm not sure how this works on BSD
and
other UNIXes.
It *doesn't* work on BSD, unfortunatel
On Thu, Jun 17, 2004 at 03:19:40PM +1000, Ben Low wrote:
> I attempted to use the following expression to filter netbios stuff:
>
> udp[2:2] >= 137 && udp[2:2] <= 139
>
> However this expression only captures port 137 packets on my two Power
> PC machines:
> - linux 2.4.18 ppc (debian)
> t
(I'm on tcpdump-workers, so there's no need to send mail to me *and*
tcpdump-workers; if you have a question, it's better to ask
tcpdump-workers than to ask only me.)
On Sat, Jun 19, 2004 at 10:07:17PM -0400, Ernest L. Williams Jr. wrote:
> Could you tell me a tcpdump filter that only gives multic
On Sat, Jun 19, 2004 at 10:35:54PM -0400, Ernest L. Williams Jr. wrote:
> Do I have to join the list? Looks like there is a post block on me at
> the moment.
You might have to join the list in order to be able to mail to it. It's
not very high-volume
> However, I am only getting address star
On Jun 21, 2004, at 3:39 AM, [EMAIL PROTECTED] wrote:
I am working on a project that involves sniffing 802.11 traffic.
I am using an Orinoco-based WLAN card.
I read that libpcap are not suitable as they are to sniff 802.11.
Libpcap 0.7 and later should be able to handle 802.11 on Linux *IF* the
Li
On Jun 22, 2004, at 8:45 AM, Bowser Jason S Contr AFRL/IFTA wrote:
I am writing some software that forks multiple process on a unix
macine(IRIX) however when i have each child start the pcap_loop when i
get to the 4th child and beyond i get the following error
pcap_open_live snoop bind: Cant ass
On Jun 22, 2004, at 8:48 AM, Eddie Kohler wrote:
The www.tcpdump.org section on mailing lists needs updating -- sending
mail to '[EMAIL PROTECTED]' results in an error; it looks like the
address has changed to '[EMAIL PROTECTED]'.
I've checked in a change to replace "@tcpdump.org" with
"@lists.t
On Jun 25, 2004, at 2:21 PM, Christian Kreibich wrote:
an XML based tcpdump output would
be great in the long term -- it would certainly eliminate a lot of
parsing ambiguity.
Yes - the problem with the traditional UNIX "the output of one program
should be usable as input to another program" idea i
On Jun 25, 2004, at 4:34 PM, Xavier Brouckaert wrote:
Could it happen because there are several applications using libpcap
at the same time ?
Not if they're writing to different files. There's no data that would
be shared by all libpcap-using processes on a given machine.
If multiple applicatio
On Jun 28, 2004, at 1:21 PM, [EMAIL PROTECTED] wrote:
We would like to include WinPcap and WinDump on the Windows Toolbox
compilation of
software but your licencing restrictions present a problem. The clause
we have difficulty with in
particular is this:
"all advertising materials mentioning fea
On Jun 28, 2004, at 12:10 PM, four wrote:
Here is the situation: I am trying to build a simple bridging program.
If I use pcap_set_nonblock() the function call returns fine, but the
program ends up using 100% cpu utilization, presumably because it is
simply looping and returning with no packets c
On Jun 30, 2004, at 10:00 AM, Jefferson Ogata wrote:
More specifically, you can use libpcap as any user. On most systems,
you have to be root, however, to monitor traffic on a network
interface.
I.e., you can use libpcap to read a capture file as any user (if that
user has permission to read the
On Jun 30, 2004, at 12:58 PM, Michael Richardson wrote:
How widespread is PDML?
Tethereal and Ethereal can generate it; I presume the intent is to have
Analyzer 3.0 generate it as well, given that it was invented by the
Politecnico di Torino folks. (I don't see anything immediately obvious
on
On Thu, Jul 01, 2004 at 07:34:44AM +0200, Fulvio Risso wrote:
> Ethereal is able to prodice PDML output (altough it uses a slightly modified
> dialectn of PDML).
What are the modifications? (Note that one problem is that PDML's field
names come from the NetPDL specification for the protocol - thi
On Jul 1, 2004, at 2:50 AM, [EMAIL PROTECTED] wrote:
tcpdump doesn't have any specific facility to handle fragmented
packets,
as far as I know (it cannot reassemble the fragments).
That capability could be added (Ethereal supports it), although, if
provided, it should be an option (as reassembly
On Jul 1, 2004, at 12:18 PM, alex medvedev wrote:
this, however, does not work well with relative seq numbers in tcp
packets [maybe smth else too?].
Anything that maintains and uses state information between packets
wouldn't work.
However, what could be done would be something that still runs the
On Jul 2, 2004, at 11:07 AM, Hannes Gredler wrote:
could you maybe also provide a pointer to a spec where the escaping
routines and or the 0x7e escape hack is described ?
http://www.ietf.org/rfc/rfc1662.txt
"This document describes the use of HDLC-like framing for PPP
encapsulated packets.
On Mon, Jul 05, 2004 at 06:27:24PM +1000, Darren Reed wrote:
> The frame format here is something like this:
>
> ethernet{ip{l2tp{hdlc{ppp{ip{gre{ppp{...
...i.e., as opposed to
ethernet{ip{l2tp{ppp{ip{gre{ppp{...}}}
-
This is the tcpdump-workers list.
Visit https://lists.sand
On Jul 2, 2004, at 8:29 PM, J.R. Lillard wrote:
Is it possible to filter packets by the DNS query?
For example, how could I dump all packets trying to resolve
google.com?
The filtering engine in libpcap isn't powerful enough to do that
easily, if at all (it's intended to be simple enough to be
On Jul 5, 2004, at 3:13 AM, Darren Reed wrote:
Looks better if its "compressed PPP data" :)
Checked in, with "compressed PPP data" - and with another change to use
"ppptype2str[]" in the default case.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Jul 5, 2004, at 4:51 AM, Darren Reed wrote:
If ppp_hdlc() is called with length < 2, bad things happen.
Should it be called *at all* from "handle_ppp()"?
Or, if this is really just HDLC-over-L2TP, in which case it should be
called directly from t
http://www.ietf.org/internet-drafts/dra
On Wed, Jul 07, 2004 at 04:21:39PM +1000, Darren Reed wrote:
> IP 1.1.1.1.1701 > 2.2.2.2.1701: l2tp:[TLS](24460/3222)Ns=23239,Nr=647
>*MSGTYPE(ICCN) *TX_CONN_SPEED(156000) *FRAMING_TYPE(A)
>*VENDOR0c7f:ATTR0066(00) RX_CONN_SPEED(156000)
I'm not sure what the "framin
On Jul 7, 2004, at 10:44 AM, Claudio Lavecchia wrote:
Writing a packet dissector based on pcap libraries on Linux and using
it to sniff traffic going through a WLAN (dell truemobile 1150 with
orinoco driver) card I noticed a really strange behaviour. The card is
set in promiscous mode, and I use
On Thu, Jul 08, 2004 at 11:38:33AM +0200, rmkml wrote:
> Possible add detect tcp header len pb in tcpdump ?
I've added those checks to the x.8 and main branches in the tcpdump CVS
tree.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Mon, Jul 12, 2004 at 03:13:33PM +0200, Klaus Schrod wrote:
> Does anybody have any idea why we still get this error?
Because, for whatever reason, the dissector for the protocol atop which
the purported IP traffic is running thinks it's IP even though it isn't?
(The version field has 11, not 4
On Jul 13, 2004, at 9:52 AM, Andersen, Kevin J. wrote:
However, that shows me all the traffic. I am specifically looking for
each
original request.
tcp dst port 80
should catch all traffic going *to* port 80 but not all traffic coming
*from* port 80 (although if the client port is also 80, i
On Jul 13, 2004, at 7:56 AM, Klaus Schrod wrote:
Again our situation: Two computers connected to the net, one (lion)
with a fixed ip address and one (styx) with pppoe. We established an
ipsec tunnel between them successfully. tcpdump showed an error in the
ESP traffic between styx and lion. But
On Jul 13, 2004, at 11:51 AM, Guy Harris wrote:
whereas the traffic from 62.225.140.214 to 217.234.111.121 has
Linux cooked capture
IP with a protocol type of IP-inside-IP
IP (with a bogus version number of 3 and a bogus header length of 8)
The second capture is similar
On Jul 13, 2004, at 12:44 PM, César Cárdenas wrote:
It is possible to write raw packets in a *.txt file?
That depends on what you mean by "raw packets".
Packet data is binary, so that wouldn't go into a .txt file.
The packet data can be dumped in hex and/or ASCII, and that could be
put into a text
On Jul 19, 2004, at 6:57 AM, Alex Narinsky wrote:
I need to change the filter condition dynamically. So I have another
thread that changes filter expression.
This code works fine on Windows changing the filter condition. On
LINUX
if I change a filter condition no packages come anymore through
pc
On Tue, Jul 20, 2004 at 09:50:01PM +1000, [EMAIL PROTECTED] wrote:
> I have had a problem building tcpdump 3.8.3 under Solaris 2.9.
>
> Unable to build inet_aton.o.o
>
> I changed configure and removed .o from the inet_anon.o${ac} line
> nad was able to perform a compile. I was not able
On Jul 20, 2004, at 1:32 AM, Li Ruzhen wrote:
hi, whether i can use libpcap to optimize some
complicate expressions and then conver the optimized
result back to the expression format?
If by "expressions" you mean filter expressions, no, you can't -
there's no code that takes a BPF program (which i
On Jul 20, 2004, at 10:40 AM, [EMAIL PROTECTED] wrote:
gcc -O2 -I. -DHAVE_CONFIG_H -D_U_="__attribute__((unused))"
-c ./gencode.c
In file included from gencode.c:73:
pf.h:66: syntax error before "sa_family_t"
Which version of libpcap is this? 0.8.3?
And what are the contents of the "con
On Jul 20, 2004, at 1:46 PM, Rick Jones wrote:
cc -O -I. -I/usr/local/include -DHAVE_CONFIG_H -D_U_="" -c
scanner.c
cc: "pcap-int.h", line 217: warning 573: Parameter list is
inconsistent for "yylex".
What is the argument list that "yylex()" takes?
here is the diff for pcap-dlpi.c:
I've
I have some changes to support that.
The main change is to add a "union h6addr" to "tcpdump-stdinc.h", along
with defintions of IN6_IS_ADDR_UNSPECIFIED, AF_INET6, and NI_MAXHOST if
they're not defined.
Some side-effects of this:
1) it defines DEFAULT_SNAPLEN as 96 unconditionally, rather
On Tue, Jul 20, 2004 at 03:25:03PM -0400, Michael Richardson wrote:
> >>>>> "Guy" == Guy Harris <[EMAIL PROTECTED]> writes:
> Guy> Michael, should we put out a libpcap 0.8.4/tcpdump 3.8.4
> Guy> release with the fixes that have been added sin
On Jul 21, 2004, at 4:39 AM, John Hawkinson wrote:
Won't this have unfortunate effects on performance (and possibly
storage,
but that's less concerning) for some people in borderline situations?
Only if they're running a version of tcpdump built without IPv6
support. The change wouldn't affect v
On Jul 21, 2004, at 2:16 PM, Rick Jones wrote:
First was print-esp.c - it was warning in three places about an
integer being converted to a pointer with the return value of strsep.
There is no strsep in HP-UX, and it seems that interface.h deals with
that, but print-esp.c was not including inte
On Jul 21, 2004, at 3:03 PM, Guy Harris wrote:
Cool. Sun C and your Alpha C compiler would probably pick up other
issues; I don't have access to them any more, though.
Actually, as tcpdump and libpcap have SourceForge sites, we might be
able to build on Solaris 9:
On Jul 22, 2004, at 12:25 PM, Hu Thomas Pan wrote:
I have a pcap filter string: udp and \( \( host host1 and port port1
\) or
\( host host2 and port port2 \) \)
Things are working through command line for tcpdump. But, it doesn't
work
for pcap lib in the code.
Try using the string
"udp and ( (
1 - 100 of 2496 matches
Mail list logo
