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-stamping pac
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
(Blah blah blah once again I forgot to set the from line yes I know I
should set up my sonic address as an alias but if I sent from my mit
address replies get to me at work and at home so I can respond from
either site blah blah blah.)
Kathy Chen wrote:
I want to know in what situations the mac
(Blah blah blah oops I did it again blah blah blah avoid duplicate
message detection blah blah blah.)
Kathy Chen wrote:
I want to know in what situations the machine's
network is set to "promiscuous" mode.
It's put into promiscuous mode if an application requests that the
interface be put into pr
(Blah blah blah another wrong from line blah blah blah avoid the
duplicate message detector blah blah blah.)
Kathy Chen wrote:
When I call
u_char *packet = pcap_next(handle, &header);
I can get the packet length value, but I can't really
get the "packet" data (Using printf(..., packet)).
The
Gisle Vanem wrote:
I've compiled tcpdump okay with these compilers and some
small changes.
Checked in.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Nov 3, 2004, at 11:34 PM, [EMAIL PROTECTED] wrote:
Um, I'm still not sure if you understand. A normal collision is
detected
during the first 512 bits of the packet. There is no retransmission of
the whole packet in case of collision (and thus no second copy of the
packet). One packet is sent, o
Robert Lowe wrote:
Beautiful! But wouldn't the bit-shift be for 4 bits?
The TCP header length field (data offset field) is in units of 4-byte
words, not in units of bytes, so it has to be multiplied by 4 to be in
units of bytes.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.c
On Nov 16, 2004, at 1:08 PM, jesk wrote:
in some auth-replies iam missing some attributes but instead of them i
can see at the end of a tcpdump line the following:
"[|radius]"
what does this exactly mean?
It probably means that either
1) the RADIUS packet didn't fit in a single link-layer packet (
Alexander Dupuy wrote:
Note also that there is a bug in the libpcap BPF optimizer (as of 0.8.3)
that breaks the hack described above,
Try it with the top-of-tree CVS version; I've made some optimizer fixes
that will, I think, fix this.
However, the libpcap 0.7 optimizer not only generates correc
On Nov 22, 2004, at 1:26 PM, Livio Ricciulli wrote:
The idea is to automatically translate the BPF expressions passed to
libpcap into MTP macrocode and load it into the card on the fly
___in_addition_to___ the normal BPF software matching.
By "BPF expressions" do you mean "BPF programs" or do you m
On Nov 22, 2004, at 4:01 PM, Livio Ricciulli wrote:
How far is the current implementation from this architecture?
None of it has been done - the only way to be further from that
architecture would be not to have come up with that architecture.
Any change to support generating anything other than
MAURICIOMANENTS wrote:
I'd like to store packets in a database format so I can see packets
using ethereal (with the needed changes to support database reading)
If you're talking about reading it using Ethereal, what you'll have to
store is raw packet data, not something like a database record with
Ed Maste wrote:
Your program wouldn't be processing old captured data. You have tcpdump
output libpcap format data to stdout, in realtime.
Note that there's currently no option in tcpdump to cause the standard
output to be flushed at the end of a packet (or a batch of packets) when
capturing wit
On Nov 27, 2004, at 10:31 PM, Dug Song wrote:
a program which changes the filter for its pcap handle at runtime with
pcap_compile/setfilter() will abort when operating on a savefile, due
to this dangling ptr reference in pcap_offline_read():
Checked in.
-
This is the tcpdump-workers list.
Visit htt
On Dec 1, 2004, at 7:53 AM, Claudio Lavecchia wrote:
I have two laptops (say A and B) that have 802.11 wireless cards. I am
developing some application that essentially perform sniffing
functions using wireless cards in promiscuous mode. To test my code, I
need those two laptops not to "see" eac
On Dec 1, 2004, at 3:31 PM, Robert Lowe wrote:
In testing a small app using libpcap, I noticed differences in
behaviour when
using the loopback interface vs. using a hardware interface. In
particular,
it seems the packets coming in over the loopback interface are still
in host
byte order (littl
Robert Lowe wrote:
Well, I was reporting this from memory. Let me back up a bit. When I first
looked at pcap, I went through Tim Carsten's tutorial, referenced from the
tcpdump.org website. Using that code (sniffer.c) on Linux with a downed eth0
i/f (forcing the dev to any) results in very weird
On Dec 2, 2004, at 6:25 PM, ~{Ir;*AV~} wrote:
what does the 10 bytes mean~{#?~}
The file header is 24 bytes long, not 10 bytes long.
The first 4 bytes are a 4-byte "magic number", with a value that's
either 0xa1b2c3d4 or 0xd4c3b2a1. If it's 0xa1b2c3d4, all the other
fields in the file header, an
æåæ wrote:
Can u tell me something about your new capture file format?
See
http://www.tcpdump.org/pcap/pcap.html
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Dec 6, 2004, at 2:07 AM, Peter Sandford wrote:
I need to capture from 2 interfaces on a machine in promiscuous mode.
This is because we are routing a copy of 2 load balanced streams onto a
box for monitoring.
I'm aware it isn't possible (?) to listen on "any" with a
pcap_open_live
in promiscuou
marc hermstein wrote:
I would like to request a DLT_ number for usage with
raw GPRS LLC frames (DLT_GPRS_LLC). On a mobile, this
is an output format that some loggers use. Having it
defined as a possible link-layer type would allow me
to have the GPRS_LLC dissector in ethereal register
with that en
On Dec 6, 2004, at 9:16 AM, marc hermstein wrote:
I would like to request a DLT_ number for usage with
raw GPRS LLC frames (DLT_GPRS_LLC). On a mobile, this
is an output format that some loggers use.
"Loggers" in what sense?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to u
marc hermstein wrote:
When developing a handset, some manufacturers dump
debugging data from the protocol stack out the serial
port on the bottom of the handset. This is what I
meant by a "logger".
So you'll be writing, or have written, a piece of code that reads from
the serial port and writes to
Dumas Hwang wrote:
I would like to request two new link layer types for Generic
Framing Procedure (DLT_GFP_T and DLT_GFP_F). Thank you.
OK, DLT_GPF_T is 170 and DLT_GPF_F is 171.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
aman Reddy wrote:
But when I assign either eth0 or eth1 is working fine , I am able to capture
correct
packets: But I fail to understand why I am getting corrupt packets if "any" or
NULL is set
You're *not* getting corrupt packets.
You're getting packets that don't have an Ethernet header on them
On Dec 9, 2004, at 12:48 PM, Dumas Hwang wrote:
I would like to get nanosecond resolution on Solaris in
libpcap. What's the best way to go about it? I suppose it's not a
good
idea to change struct timeval ts in pkthdr to timespec.
That would be an amazingly bad idea (and it was an am
On Dec 9, 2004, at 12:48 PM, Dumas Hwang wrote:
I would like to get nanosecond resolution on Solaris in
libpcap.
BTW, where are you getting the nanosecond-resolution time stamps in
Solaris?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Dec 9, 2004, at 1:09 PM, Robert Lowe wrote:
to_ms specifies the read timeout in milliseconds. The read timeout is
used to arrange that the read not necessarily return immediately when
a packet is seen, but that it wait for some amount of time to allow
more packets to arrive and to read multiple
On Dec 9, 2004, at 2:08 PM, Darren Reed wrote:
In some email I received from Guy Harris, sie wrote:
BTW, where are you getting the nanosecond-resolution time stamps in
Solaris?
gethrtime
That says what the high-resolution time counter's value is now, not
what the value was when bufmod sa
On Dec 9, 2004, at 3:23 PM, Darren Reed wrote:
So what am I trying to say here? Unless you have hardware timestamps
in captured packets, one software timestamp is as good as the next in
a well written application.
...or as bad as the next.
If you want absolute time stamps, nanosecond resolution wi
aman Reddy wrote:
I would like to know what is the length of the DLT_LINUX_SLL link layer header
and please also explain to me the different fields in it.
"man pcap", with modern versions of libpcap, describes the link-layer
headers; it describes DLT_LINUX_SLL in some detail, and gives the
leng
Ariel Burbaickij wrote:
The second one,
I.e., the answer to the question originally asked is "no, there are no
plans to add support for SCTP to capture filters, because libpcap
filters already supports SCTP", and the real question should've been
"are there any plans to support printing SCTP in t
On Dec 14, 2004, at 2:17 PM, Ariel Burbaickij wrote:
well, here I fear I will become slightly offtopic. I am not so much
concerned about tcpdump, I am concerned about [t]ethereal
as the application that uses libpcap (as tcpdump does), so far I have
failed trying to set any sctp filters there.
H
On Dec 16, 2004, at 10:02 AM, Paul Thomas wrote:
The configure script reports:
checking ifaddrs.h usability... yes
checking ifaddrs.h presence... no
checking for ifaddrs.h... no
What can I do about this? (The file does not exist.)
Ask QNX; at least according to this page:
http://www.qnx.com/devel
101 - 200 of 1280 matches
Mail list logo
