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 ( (
On Jul 22, 2004, at 10:29 AM, Rick Jones wrote:
cc: "pcap-dlpi.c", line 376: LP64 migration warning 720: Argument #3
may overflow integer.
}
ret = dlrawdatareq(p->send_fd, buf, size);
I guess that one depends on how large size is likely to get.
...and changing the third argument t
On Jul 22, 2004, at 1:13 PM, Hu Thomas Pan wrote:
Still not work. No data comes into my callback function.
But tcpdump, with the same filter, shows packets?
We'd have to see the source to your program to figure out what the
problem is.
-
This is the tcpdump-workers list.
Visit https://lists.sande
On Jul 22, 2004, at 1:47 PM, Aaron Mitchell wrote:
I've noticed a peculiar behavior. Given the same hand-crafted
dump file (with an intended time of 5:36 on Jan 1, 1970), tcpdump
reports a time of 6:36 for default output, and a time of 10:36 when
run with the - option ("supposedly" same time w
On Jul 22, 2004, at 9:10 AM, César Cárdenas wrote:
I am trying:
windump -i 2 'tcp[13]&2==2'
It recognizes the interface but still there doing nothing...
I assume from the "-i 2" that you have more than one interface on your
machine. What happens if you try to connect from the machine running
Win
On Thu, Jul 22, 2004 at 09:21:36PM -0400, Michael Richardson wrote:
> >>>>> "Guy" == Guy Harris <[EMAIL PROTECTED]> writes:
> Guy> If that's still valid, we should probably have it set
> Guy> "thiszone" to "gmt2local
On Fri, Jul 23, 2004 at 06:09:39PM -0800, Tejas Kokje wrote:
> In /usr/include/linux/802_11.h 802.11 header is given as
>
> struct ieee_802_11_header {
> u16 frame_control;// needs to be subtyped
> u16 duration;
> u8 mac1[6];
> u8 mac2[6];
> u8
On Jul 23, 2004, at 11:57 AM, Gianluca Varenni wrote:
If the file is transfered from win to unix in ASCII mode, the file
should
become
\n\n\r .. In this case we recognize the first three characters
"\n\n\r", try to convert the first 12 bytes from unix-ascii to
win-ascii,
and check the by
On Jul 28, 2004, at 12:59 AM, SUZUKI Shinsuke wrote:
Here's a patch to properly check buffer boundary in MLDv2 packet
parsing.
Checked into the main and x.8 branches.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Jul 29, 2004, at 1:11 PM, Lowrie, Tom wrote:
Adding -lcfg along with -lodm solves my problem. Thanks for the
push in the right direction.
Next step will be to figure how to compile the libpcap source so
that these libraries are included.
The standard libpcap build procedure in the main CVS branc
On Jul 30, 2004, at 10:14 AM, Greg Weiss wrote:
Is there a way to command-line filter tcpdump so that only packets with
bad TCP checksums are dumped?
No.
The BPF filtering mechanism can't handle it, as there's no way for it
to compute a checksum, and the filtering mechanism is BPF-based.
A separa
On Mon, Aug 09, 2004 at 01:08:49AM +1000, Darren Reed wrote:
> In some email I received from Fulvio Risso, sie wrote:
> > Darren, could you please give us some numbers?
> > If you take a look at this paper:
> >
> > F. Risso, L. Degioanni
> > An architecture for high performance network analysi
On Sun, Aug 08, 2004 at 08:29:33AM +0200, Fulvio Risso wrote:
> If you take a look at this paper:
>
> F. Risso, L. Degioanni
> An architecture for high performance network analysis
>
> http://ieeexplore.ieee.org/iel5/7446/20240/00935450.pdf?tp=&arnumber=935450&;
> isnumber=20240&arSt=686&ared
Also, speaking of capture speed and memory-mapped devices, there was a
freebsd-hackers thread discussing a netgraph module providing
memory-mapped access to captured packets:
http://docs.FreeBSD.org/cgi/mid.cgi?20040614124708.A22679
and other messages with the subject "memory mapped packe
On Mon, Aug 09, 2004 at 12:21:18PM +1000, Darren Reed wrote:
> I did some similar work for bpf & mmap with NetBSD.
Yes, I saw those. The guy doing the FreeBSD work appears to be claiming
that he dropped fewer packets with his mapped access, but that might
just be a result of not time-s
On Aug 7, 2004, at 12:41 PM, Carter Bullard wrote:
On mac os x 10.3.4, using libpcap-0.8.3, opening pcap with
pcap_open_live(dev, 96, 1, 1000, errbuf) and reading packets with
pcap_loop (pd, 1, callback, user), packets are queued until some
magic number (looks to be 200) of packets is reached, a
On Aug 12, 2004, at 2:10 AM, Francisco Mesquita wrote:
Can you please assign me a new magic number so this format will be
recognized by libpcap?
Merely assigning a new magic number doesn't mean it'll be recognized by
libpcap - we'd have to modify libpcap to handle that, which means that
current
(How I want a drink, alcoholic of course, after the heavy lectures
involving quantum mechanics.
The above was inserted in the hopes that the duplicate message detector
won't flag this as a duplicate; it was originally sent from an address
of mine not on the tcpdump-workers list, and rejected fo
Francisco Mesquita wrote:
> I understand that, I will send you the necessary changes to the file
> savefile.c as soon as I have the magic number (at least to have reading
> compatibility).
OK, I've assigned you 0xa1b234cd.
> When do you expect the new format will be available?
I don't think we have
Hannes Gredler wrote:
i have checked in support for the new DLT_PPP_WITH_DIRECTION (166) and
LINKTYPE_PPP_WITH_DIRECTION (166)
Hmm. From what Karsten says, it's a bit special, with the 0xff in the
HDLC-like header replaced by a direction flag, rather than wit
ury segal wrote:
OK... Assuming I insist on enabling localhost
sniffing on Solaris to the benerfit of all:
You might want to rephrase that as "insist on *attempting* to enable..."
- there's no guarantee that you'll succeed, no matter how beneficial
it'd be, as the Solaris networking code might no
On Aug 24, 2004, at 6:37 PM, Ed Sawicki wrote:
There appears to be a parser error with compound
expressions like this:
tcpdump -i eth0 '(tcp[0:2]>=1024) && (tcp[0:2] <=6)'
You probably mean "compiler error" - it's probably a problem with the
optimizer, not the parser:
http://sourceforge.ne
David Front wrote:
I notice that 'tcpdump -s0' truncates packets with payloads longer than
(~1400 or) ~1500 bytes.
Is there a way to get full long payloads (or is this due to a (Ethernet MTU)
limit, or a tcpdump limitation/bug)?
Is this on Ethernet? If so, why are there packets with payloads longe
On Aug 25, 2004, at 11:05 AM, David Front wrote:
11:33:55.601653 IP lxfs5623.cern.ch.32962 > lcgmon002d.cern.ch.12509:
UDP, length: 1637
"UDP, length: 1637" means that the *UDP* packet length is 1637 bytes.
That doesn't mean that the *Ethernet* packet is 1637 bytes, as you note
later:
IP message
On Aug 25, 2004, at 11:09 AM, Guy Harris wrote:
Note, however, that the reassembly is *NOT* done at the low-layer
capture level, so a capture filter of "port 12509" will only capture
the first fragment of a fragmented datagram, and Ethereal and
Tethereal will *NOT* be able to reas
On Aug 26, 2004, at 3:43 PM, Chris Reining wrote:
I am running into an interesting promiscuous mode issue on Redhat
Enterprise WS 3, kernel version 2.4.21, libpcap version 0.7.2 and
tcpdump 3.7.2. The issue is unanticipated toggling of promisc state. I
am running Snort version 2.1.2 which itself se
(Crap added to avoid this retransmission, with the right "From:" address
this time, being seen as a duplicate.
Now is the time for all good parties to come to the aid of man.)
Eric St.John wrote:
I'm trying to use libpcap in Darwin (uses bpf). In order to capture the
packets, I must have read ac
On Sep 3, 2004, at 3:48 AM, Sebastien Vincent wrote:
So I made changes into ./tcpdump.c and it now works fine.
Checked in.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Sep 8, 2004, at 2:26 AM, Bruce M Simpson wrote:
Here's a patch against 5.3 to add a per-instance switch which allows
the user to specify if captured packets should be timestamped (and,
if so, whether microtime() or the faster but less accurate
getmicrotime() call should be used).
This is probabl
(Noise to defeat the duplicate-message detector for
[EMAIL PROTECTED])
Guy Harris wrote:
This is probably a pointless optimization,
"This" referring not to Bruce's proposed change, but to my proposed
change to have one time stamp call per packet.
-
This is the tcpdump-workers li
fullc0de wrote:
I want to use libpcap with non-promiscous mode. But I don't know
how to do.
"How" in what sense?
In the simple sense of "how do I make my program capture in
non-promiscuous mode", the answer is "pass 0 as the value of the
'promisc' flag when you call 'pcap_open_log()'".
-
This is
On Sep 9, 2004, at 1:10 AM, fullc0de wrote:
When I searched, I've not been able to find a function
"pcap_open_log()" in pcap.h.
Sorry, that should have been "pcap_open_live()".
The following code is used in my program.
pcap_open(d->name, 65536, 0, 1000, NULL, errbuf)
I Thought I am using the non
(Noise to trick the duplicate post recognize. Noise to trick the
duplicate post recognizer. Pack my bag with five dozen liquor jugs.)
Shaun wrote:
> Or get a DAG card? Not sure if they support FreeBSD though.
http://www.endace.com/faq.htm#linux
"Q: Do you support any other operating systems
On Sep 13, 2004, at 4:24 PM, Rick Jones wrote:
For other nefarious porpoises I downloaded libpcap and tcpudmp
"currents" on 2004-09-13 and did straight-up ./configure;make on HP-UX
11.11 (aka 11i v1) using the HP compiler. This system did not have
the "TOUR" installed to get IPv6 functionality.
On Sep 13, 2004, at 7:24 PM, rick jones wrote:
thanks. the end goal is to look at NFS over TCP traffic where the
traffic may have nfs messages split across segments, several in a
segment, that sort of thing.
If "look at" implies "dissect as NFS", Ethereal or Tethereal might be
the way to go (th
Shaun wrote:
Or get a DAG card? Not sure if they support FreeBSD though.
http://www.endace.com/faq.htm#linux
"Q: Do you support any other operating systems than Linux? Do you
support BSD or Solaris?
A: Linux is the primary platform for the DAG product range, with robust
support. A device dr
On Sep 14, 2004, at 10:33 AM, Rick Jones wrote:
well, with the link in place, i did the make dist clean then the
configure then the make and did get the duplicate symbols. so, here
is the config.log
...
configure:8312: checking for local pcap library
configure:8420: result: ./../libpcap/libp
On Sep 14, 2004, at 4:38 PM, Rick Jones wrote:
no datalinks.o:
LOCALSRC = print-smb.c smbutil.c
GENSRC = version.c
LIBOBJS = strlcat$U.o strlcpy$U.o strsep$U.o
But you got duplicate symbol errors?
What's the output of "make"?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to
On Sep 15, 2004, at 12:37 AM, Matthew Luckie wrote:
There is code in pcap-bpf.c to set the selectable fd to -1 if it is
detected the OS is FreeBSD 4.3 or 4.4
I don't think the check actually successfully detects 4.3 or 4.4, as
the osinfo.release parameter will have something like 4.3-RELEASE or
On Sep 17, 2004, at 12:55 PM, Paul Berube wrote:
Ok. I have a couple traces in tcpdump format. What I actually need is
just a list of destination addresses for the trace. I might be able to
use a timestamp if I got really fancy, but it's not required. So,
precisely, for each packet in the trace,
On Sep 17, 2004, at 3:20 PM, Paul Berube wrote:
One question, though. I see "h.m.s:ms, a.b.c.d.x:", and I'm wondering
what the 'x' is? By the frequent occurences of 80, I'm guessing these
are
port numbers, but I'd like to be sure :)
Yes.
this won't work with icmp though...
That's fine, I'm only
(Blah blah blah work around duplicate message detector blah blah blah
someday I'll figure out if I can configure Thunderbird to know that all
tcpdump-workers mail should come from my alum.mit.edu address blah blah
blah.)
David Young wrote:
Here is support for radiotap, an extensible radio captu
(blah blah blah duplicate posts blah blah blah thunderbird blah blah
blah multiple accounts blah blah blah)
Guy Harris wrote:
Looks good to me, at least for the top-of-tree (where we require that
the platform support 64-bit integers, and where we define u_int64_t to
be an unsigned 64-bit integer
Claudio Lavecchia wrote:
3. How do you calculate size_ip?
int size_ip = sizeof(struct sniff_ip);
Do any of the packets have IP options? If so, then that's *not* the
size of the IP header.
You should get the IP header length from the header length/version field
from the IP header (and should che
(blah blah blah another message sent from the wrong address blah blah
blah duplicate message detector blah blah blah)
Michael Richardson wrote:
Okay, so can it get integrated into CVS HEAD, and I will
arrange to do a 3.9, 0.9.
HEAD, or HEAD and x.8 branch?
-
This is the tcpdump-workers list.
Vi
(blah blah blah the other brain fart was sending it from sonic.net again
blah blah blah duplicate message dissector blah blah blah)
Michael Richardson wrote:
You tell me.
We didn't do a 0.8.4 yet, but this sounds like significant enough to
warrant 0.9, but maybe I'm wrong.
Sorry, brain fart,
(blah blah blah *surely* Thunderbird must have some way of arranging
that a particular mailbox have a preferred From address blah blah blah
duplicate post blah blah blah)
David Young wrote:
"Oh." Have we got the stomach for radiotap v2? If big-endian kernels
no longer have to convert fields to
Matthew Luckie wrote:
The motivation for this patch was to obtain something resembling the
timestamp closest to when a packet I generated and transmitted hit the
wire, to infer a more accurate RTT with an associated response packet.
That's certainly a worthy goal, but the patch might not help muc
On Sep 24, 2004, at 6:02 AM, Hannes Gredler wrote:
any suggestion for a x.9 branch date ? what about 31-oct-04 ?
Speaking of "x.9 branch", should the VERSION files in libpcap and
tcpdump change to "0.9-PRE-CVS" and "3.9-PRE-CVS", respectively?
-
This is the tcpdump-workers list.
Visit https://lis
(Blah blah blah defeat duplicate detector blah blah blah once again I
forgot to send with my alum.mit.edu address in the from line blah blah
blah Thunderbird blah blah blah time to pester Bugzilla.)
Travis wrote:
Is it not correct that pcap_compile takes in a filter program with
tcpdump syntax?
Ed Maste wrote:
1) Add a new pcap API function pcap_set_bufsize that can be used
to set the size used for following pcap_open_live calls (by setting
a libpcap global variable).
The global variable is a bit ugly. If you're going to have API changes...
2) Add a new function like pcap_open_live that
Gianluca Varenni wrote:
...like pcap_setbuff(), as implemented in WinPcap...
...and which I already know about.
Unfortunately, given that, on systems with BPF, you cannot change the
buffer size after a BPF device has been bound to a network interface,
"pcap_setbuff()" is unimplementable on those
On Oct 15, 2004, at 6:19 AM, Hannes Gredler wrote:
shouldn't we have upper/lower boundary checks for
such a buffer ?
i.e. minbuffer 1.5K
maxbuffer 128K
I think the BPF kernel code in most of the BSDs already impose upper
and lower bounds; are you suggesting that libpcap impose its own
bounds
(blah blah blah wrong from address blah blah blah duplicate message
dissector blah blah blah time to see whether I can configure Thunderbird
to automatically set the from address for tcpdump-workers messages blah
blah blah)
KEVIN ZEMBOWER wrote:
www:~# tcpdump src host centernet.jhuccp.org and
KEVIN ZEMBOWER wrote:
As you can see, I'm still getting packets from ns1.jhmi.edu on the DNS port.
What does the command
tcpdump -d src host centernet.jhuccp.org and \( ip proto \\tcp or \\udp \)
print?
If it helps, I'm using bash 2.05 on a Debian woody (stable, 3.0) distro
running kernal 2
On Sep 27, 2004, at 12:37 PM, KEVIN ZEMBOWER wrote:
Output is:
[EMAIL PROTECTED]:~$ su -
Password:
www:~# tcpdump -d src host centernet.jhuccp.org and \( ip proto \\tcp
or \\udp \)
(000) ldh [12]
(001) jeq #0x800 jt 2jf 8
(002) ld [26]
(003) jeq #0xa281e1c0
On Sep 27, 2004, at 5:17 PM, Joshua Blanton wrote:
One could also check to see if the file handle is
stdin.
That's what "sf_close()" does, so I checked in a fix to do that in
"pcap_open_offline()".
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Michael Mueller wrote:
Are there any positive or negative reactions to this? Will somebody fix it?
I'd check in the patch if somebody resolved the issue
Tcpdump -E doesn't work for 3des-cbc encryption with hmac-md5
authentication (tested with tcpdump-2004.09.22 on Linux 2.6). The
reason is that i
Sorry I didn't get around to this until now, but
On Jul 30, 2004, at 1:09 PM, Gianluca Varenni wrote:
There is another issue related to these block types.
Fulvio's proposal:
a shb (even corrupted by the ftp transfer) can begin with the following
strings:
\r\n\r\x1A -> 1 reserved block type
\r\
On Oct 18, 2004, at 3:04 PM, Alexander Dupuy wrote:
Guy Harris writes:
Unfortunately, given that, on systems with BPF, you cannot change the
buffer size after a BPF device has been bound to a network interface,
"pcap_setbuff()" is unimplementable on those systems, so it's not a
akshar SNIFFER wrote:
I am writing a sniffer in C++ ,
Then this is a question that belongs in the tcpdump-workers list, not
the ethereal-dev list, so I'm redirecting it there.
I have included the pcap.h header file .While compiling i get the following error
/**
Gerard Beekmans wrote:
tcpdump.o(.text+0x947): In function `main':
: undefined reference to `pcap_debug'
collect2: ld returned 1 exit status
What does
nm -o ../libpcap-0.8.3/libpcap.a | egrep pcap_dump
print, and...
Configure did check for, and found, pcap_debug:
checking whether pcap_debug
Gerard Beekmans wrote:
What does
nm -o ../libpcap-0.8.3/libpcap.a | egrep pcap_dump
print, and...
../libpcap-0.8.3/libpcap.a:savefile.o:0940 T pcap_dump
Sorry, brain fart. I meant to say "What does
nm -o ../libpcap-0.8.3/libpcap.a | egrep pcap_debug
print?"
-
This is the tcpdum
On Oct 22, 2004, at 3:50 PM, Gerard Beekmans wrote:
On Fri, 2004-10-22 at 12:21, Guy Harris wrote:
nm -o ../libpcap-0.8.3/libpcap.a | egrep pcap_debug
print?"
Nothing as a matter of fact. Thanks for the clue though, I got it
working now. To get that pcap_debug symbol compiled in I h
On Oct 25, 2004, at 1:27 PM, Ying Li wrote:
Sometimes select() times out way too
fast, like 0.0001 seconds while my timevar is set to
0.001 sec.
"Times out" in the sense that "retval" is 0?
On what OS are you doing this?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsub
Pete Wilson wrote:
I'm a new user of tcpdump, so please forgive these few amateur
questions.
1. I need to look at SNMP traffic, so I issue:
node2:/root#tcpdump udp host node1 or node2 or node3
tcpdump: 'udp' modifier applied to host
UDP doesn't know about "hosts" - that's IP's responsibility.
Matt Van Mater wrote:
Recently I've been investigating why tcpdump on my IDS shows quite a few
packets as being dropped.
Probably because it's receiving so many packets that it can't keep up.
Drops, as reported by tcpdump, are drops due to the buffer in the packet
capture mechanism overflowing d
On Oct 31, 2004, at 6:15 PM, Pete Wilson wrote:
although do you want to exclude TCP or exclude everything but UDP
(or exclude everything but port-161 and port-162 UDP traffic)?
Well, since you ask :-) Yes, sure.
Then that's where the
If you want to see all UDP traffic to and from particular hosts
101 - 200 of 2513 matches
Mail list logo
