Pavan Mirla wrote:
After I use tcpdump to set my interface to promiscuous mode I se that
my mbufs are getting exhausted.I later get the errot "mlcpool reached
it's limit, increase NMBCLUSTERS size. "
netstat -m shows me multiple calls to protocol drain routines.I am
using netBSD version 1.6.
Ca
Thinh Ho wrote:
Is there a struct for the options field of tcp_header?
No. That field is variable in both length and contents, so there can't
be a C-language data structure for it (and I don't know whether any
language has a concept of "data structure", in the sense in which it's
used in la
Richard Huddleston wrote:
Freshly installed FreeBSD 5.4. New user of FreeBSD.
pcap_open_live() fails with a
BIOCSRTIMEOUT: Invalid argument
pcap_open_live( device, BUFSIZ, 1, -1, errbuf )
itimerfix() in the 5.4 kernel does
int
itimerfix(struct timeval *tv)
{
if (tv->tv_sec < 0
Michael Richardson wrote:
Any objection to 0.9.2 going out in the next 20 hours?
At this point, I don't see anything in the CVS tree that I think needs
any changes.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
On Jul 11, 2005, at 1:03 PM, Richard Huddleston wrote:
Just referencing Tim Carsten's pcap doc: "...to_ms is the read
time out...0
sniffs until an error occurs; -1 sniffs indefinitely)."
I *really* need to sit down and edit that document - and incorporate
Nathan Jennings' sniffex.c into
On Jul 12, 2005, at 3:42 AM, Thinh Ho wrote:
Thanks for your reply!
Extracting the data is where I am stuck...
The struck of option is below:
typedef struct option
{
byte byte1;
byte byte2;
byte byte3;
} option;
An option might have fewer than, or more than, three bytes.
For that reason, ne
Richard Huddleston wrote:
(gdb) where
#0 0x280ee6fb in read () from /lib/libc.so.5
#1 0x28090c57 in pcap_lookupnet () from /usr/lib/libpcap.so.3
#2 0x28091adb in pcap_loop () from /usr/lib/libpcap.so.3
GDB is buggy, it appears, and printed a bogus stack trace; pcap_loop()
doesn't call pcap
Sam Pierson wrote:
This is unavoidable, as the problem lies within FreeBSD, correct?
To what does "this" refer?
It's an intended feature that a zero timeout will wait until "enough"
packets arrive, so if you're not in non-blocking mode, it is, indeed,
"unavoidable" that a read will block un
Sam Pierson wrote:
What I meant was that in a situation where you send a single packet,
you can't pick it up as soon as it comes, you have to wait for some
other timeout value that you supply... the problem is that it only has
a time resolution of 1ms, so for applications that depend on a finer
Loris Degioanni wrote:
Some genius had the idea of adding a new file (print-slow.c) to the
repository few hours before the x.9.2 release, without at least trying
to recompile on all the platforms. Result: tcpdump 3.9.2 doesn't compile
under Windows (even if it used to compile the night before t
Costas Djouvas wrote:
I am trying to get a packet in hex. Though, I cannot
get the link layer
part of the packet in hex. I have read some previous
discutions in the
list but nothing helped. Can anyone send me the
command that I have to
use in order to do that.
Costas
P.S Failed attemps tcpdu
On Jul 13, 2005, at 9:50 AM, Loris Degioanni wrote:
Yes, in a genera way, we should a a pre-release building (and
possibly testing?) procedure, carried on by one person (or a
limited group of people) after the CVS has been locked.
Note that this procedure needs to include at least one pers
Phil Wood wrote:
I scanned through an ethereal-dev list of Auguest 1999 about 64-bit
pcap timestamp problems. It appears that the consensus was such that
pcap files written on 64 bit machines will not be readable on 32 bit
machines and arsy-varsy.
That was the consensus at the time in etherea
[EMAIL PROTECTED] wrote:
I found out the problem, for some reason it wasn't sniffing localhost traffic,
If by "localhost traffic" you mean traffic being sent from the machine
to itself, the reason is that, on most if not all OSes, that traffic
gets "wrapped around" internally to the machine b
Mike Kershaw wrote:
I've been working on bringing the radiotap headers to Linux so that
we'll finally have a kernel-level multi-platform consistent way to get
signal data on wireless cards.
Well, it'd also need to be brought to the Aironet driver on the BSDs as
well, to complete that process.
Martin Stransky wrote:
Hello,
there is a new bug, buffer overflow, it's in 3.9.3 too.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=164227
OK, I've checked in (a variant of) Ulrich's fix - but, as I noted in
that bug, I'm not sure how a string could've been long enough to
overflow t
Gert Doering wrote:
The effect is quite weird - with "-i", it will not dump, but exit
immediately, printing an empty message:
[EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ SU ./tcpdump -n -i gre0
tcpdump: WARNING: gre0: no IPv4 address assigned
tcpdump:
[EMAIL PROTECTED]:/home/gert/cdp/tcpdump$ SU
Mike Kershaw wrote:
Well, yes. :) I still have to get my patches accepted to the ieee80211
branch, merged into the kernel, and then all the driver patches done and
accepted. It's a step in the right direction tho.
If you're working on the FreeBSD Aironet driver, you might want to look
at th
Mike Kershaw wrote:
Sorry, I'm only messing with the linux stuff at the moment,
While you're doing that, could you beat up on the driver teams to get
them to adopt the same APIs for turning on monitor mode and setting the
channel? There's a whole bunch of different commands (and presumably
Mike Kershaw wrote:
I've been developing a database of cards based on the iwpriv
fingerprints. So far, the method seems to be sound. I hope to use that
to map sources automatically inside Kismet to the kismet 'specialty'
sources. As drivers evolve, I should only need one standard source
under
noc ops wrote:
I'm looking for any help in detecting (if possible)
*outgoing* client request (see below flow) header information for
transparent proxies via some sort of pattern match. Maybe proxy
connection tag? Is it doable? So far my search has turned up negative.
As noted in the Ethereal t
rmkml wrote:
x.9.2 or x.9.3 ?
It's 0.9.3/3.9.3 - the VERSION files weren't updated. They were updated
since then, so if subsequent 0.9.x/3.9.x releases are made, they'll
identify themselves as 0.9.4/3.9.4.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscri
27;
print-dccp.c:57:2: #error "Adjust your defines"
Unfortunately, the suggestion made by the errors doesn't help:
Guy-Harris-Computer.local$ ls -l /usr/include/asm/byteorder.h
ls: /usr/include/asm/byteorder.h: No such file or directory
Guy-Harris-Comp
cycl0ne dude wrote:
what i know is, filter only works in filtering traffic on interface
only, but how about on offline pcap file?
pcap_setfilter() works on a pcap_t that you've opened with
pcap_open_offline() the same way it works on a pcap_t you've opened with
pcap_open_live().
-
This is t
Jan C. Nordholz wrote:
init_linktype() sets off_linktype to -1 (not present),
and off_nl (and _nosnap) to 0 (packet starts immediately),
which is fine. But gen_proto() insists that for Q_IP,
regardless of the current DLT, the link level should be
inspected:
...which is also fine; "gen_linktype
Guy Harris wrote:
There should probably be another way of indicating "we're now parsing
MPLS-encapsulated stuff", e.g. a Boolean flag. I'll look at
implementing that (and put it into the x.9 branch).
I've checked into the main and x.9 branches a change to do t
Guy Harris wrote:
I've checked into the main and x.9 branches a change to do that (with a
Boolean flag).
...followed by a change that checks the label stack level, instead (the
Boolean wasn't necessary).
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Jan C. Nordholz wrote:
Which one do you mean - the one I took the gdb trace and the output from?
Sure, no problem, but as I said, it's basically a 10-liner, if you don't
count the #include statements in... ;-) I was even too lazy to include a
reverse translator numeric->symbolic instruction code
On Aug 8, 2005, at 10:40 AM, Black, Michael wrote:
What I want is for 10.4.4 to see ALL non-10.4.4 traffic (like a
honeypot).
Seems like a reasonable request to say "not net 10.4.4"
If by "10.4.4 traffic" you mean "traffic from an address on the
10.4.4 network to an address on the 10.4.4 ne
On Aug 8, 2005, at 3:43 PM, Albert Chin wrote:
I've built libpcap-0.9.3 and tcpdump-3.9.3 on HP-UX 11i:
# tcpdump
tcpdump: no suitable device found
libpcap-0.8.3/tcpdump-3.8.3 works fine. How can I help debug this?
What happens if you change "add_or_find_if()" in "inet.c" in libpcap
so
Albert Chin wrote:
With the patch below,
...which is exactly the change I intended.
I get:
# tcpdump
tcpdump:
Just "tcpdump:", and nothing else? Not even a message saying it's
starting a capture? That's weird. Is it dumping core, exiting
immediately, or continuing to run but not
On Aug 8, 2005, at 8:57 PM, Albert Chin wrote:
Nothing. Even if I specify the interface:
# tcpdump -i lan0
tcpdump:
# echo $?
1
OK, so it appears it's not a problem in the code to enumerate
interfaces.
What does "tcpdump -D" print?
# tcpdump
1.lan0
2.lo0
OK, so it's at least
Albert Chin wrote:
Nothing. Even if I specify the interface:
# tcpdump -i lan0
tcpdump:
# echo $?
1
Try applying the attached patch to "pcap-dlpi.c", rebuild, rebuild
tcpdump, and try again.
Index: pcap-dlpi.c
===
RCS f
Guy Harris wrote:
Albert Chin wrote:
Nothing. Even if I specify the interface:
# tcpdump -i lan0
tcpdump: # echo $?
1
Try applying the attached patch to "pcap-dlpi.c", rebuild, rebuild
tcpdump, and try again.
Don Ebright sent me mail noting another possible problem. He
Cian Masterson wrote:
Can
anyone tell me what changes/hooks tcpdump puts into the stack that might
lead to this behaviour?
Tcpdump (or other programs such as snort, Ethereal, etc.) just call
libpcap to do the capturing.
Libpcap doesn't make modifications to the networking code path (except
Mike Kershaw wrote:
Since I'm working more on pushing the radiotap patches into the kernel,
heres a super-tiny patch to libpcap to properly detect the link type.
This isn't yet an official arphrd, but madwifi also uses it for radiotap
output on linux and I expect we'll have it official soon. If
Speaking of radiotap, the current tcpdump snapshot length defaults of 68
(for tcpdump without IPv6 support) and 96 (for tcpdump with IPv6
support) don't correspond to the same amount of payload above the "link
layer" on all network types. For most network types, the difference is
small - if we
Mike Kershaw wrote:
No, it's the next in line, and madwifi uses it as well for radiotap on
linux.
OK, I've checked the patch into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Albert Chin wrote:
Missing a closing '}'?
Yes.
This patch works. Thanks!
I've checked it in.
Does it also fix the problems with Ethereal? If not, what happens if
you try to run more than one tcpdump at the same time?
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/
On Aug 16, 2005, at 4:29 PM, Ebright, Don wrote:
I have some information regarding your question to Albert Chin. If
I try to
run more than one tcpdump at the same time on HP-UX, it doesn't
work for me.
...
It appears that the second pcap_open_live() fails with one of two
errors
Cian Masterson wrote:
In case anyone else is experiencing similar behaviour with their driver
(or in case I'm trawling this list in a few years time wondering how I
fixed it) the problem was with skb->tail not being updated properly in
my code on the receive side. Six lashes with a wet cabbag
On Aug 17, 2005, at 2:24 PM, Albert Chin wrote:
To be more specific, "future release of the DLPI provider". So, I
think a LAN patch could correct the problem. In PHNE_25388, we find:
( SR:8606225662 CR:JAGad94736 )
HP-UX only allow one unbound promiscuous stream per
interface, when trying
On Aug 17, 2005, at 2:16 PM, Albert Chin wrote:
Capture->Interfaces->Capture (on lan0 interface) results in:
The capture session could not be initiated (recv_ack:
promisc_phys: UNIX error - Device busy).
Please check to make sure you have sufficient permissions, and
that
you
I've checked in some libpcap fixes for HP-UX and Mike Kershaw's
support for radiotap in Linux, and Hannes has checked in some changes
in both libpcap and tcpdump for additional Juniper link-layer types.
Unless there are some other fixes in the pipeline, or some tcpdump
vulnerabilities not y
On Aug 19, 2005, at 3:03 PM, Ronald SURAY wrote:
How can I resolve this problem?
Try building and installing the "Current tar files" versions of
libpcap and tcpdump; there are some HP-UX problems fixed in them.
(They will, at some point, be released as 0.9.4 and 3.9.4; earlier
0.9.x re
On Aug 22, 2005, at 2:30 PM, Ronald SURAY wrote:
Where can I find the releases of libpcap 0.9.4 and tcpdump 3.9.4 ?
When they are released, you will be able to find them on
www.tcpdump.org.
They have not been released yet, however, so you currently cannot
find them anywhere.
-
This is
Nathan Jennings wrote:
Thanks for the help and suggestions. They are implemented in the updated
attached "sniffex.c" source file, v0.1.1.
I've checked that in to the Web site, with some changes, and updated the
tutorial to refer to it (I changed both the tutorial code and sniffex.c
code to r
David Rosal wrote:
I'm trying to use an application that needs to be linked dinamically
against libpcap, so it needs libpacp.so to be installed.
I've downloaded libpcap-0.9.3 and installed it, but it only provides the
static library libpcap.a. I've tried also adding --enable-shared to
config
On Aug 29, 2005, at 3:18 AM, Ulf Lamping wrote:
Could you provide me with a magic number for the libpcap file
format I've outlined some time ago?
It will simply be the same format as the common libpcap format,
except that the lower 32bits of the timestamp field are nsec
resolution instea
On Sep 2, 2005, at 1:42 PM, Michael Richardson wrote:
"Romain" == Romain Francoise <[EMAIL PROTECTED]> writes:
Romain> Can we merge these spelling fixes (courtesy of Michael
Romain> Shields <[EMAIL PROTECTED]>) for 3.9.4?
Go ahead, pull up to branch.
They're not checked into the
Romain Francoise wrote:
Can we merge these spelling fixes (courtesy of Michael Shields
<[EMAIL PROTECTED]>) for 3.9.4?
Checked into the main and x.9 branches.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Ian McDonald wrote:
Please find attached a reworked patch which I believe addresses all of
Guy's original concerns and also adds options processing and other
enhancements.
"dh_end" still isn't being used, as per my original comment:
In addition, there are no TCHECK(), TCHECK2(), TTEST(), or
(Blah blah blah wrong From: address bounce blah blah blah fool the
duplicate message detector into not bouncing this retransmission from
the right address blah blah blah.)
On Sep 6, 2005, at 1:45 AM, fanci wrote:
So, libpcap is passing "0" for the "sap" parameter to invoke a
DLPI_BIND_REQ.
fanci wrote:
As for my workaround, I didn't really hardcoded 88-8e in libpcap;
instead I modified a bit in pcap_open_live() to let it parse the "char
*ebuf" parameter in "$SAP=%d" format. If the parse succeeds, then
libpcap would take the user-supplied number for SAP. Otherwise, it uses
0 for th
On Sep 7, 2005, at 5:27 AM, fanci wrote:
That's really complicated @_@
Yes, that's what happens if you have more than one e-mail address.
One thing to remind... actually you don't have to quote
"Broadcom"'s name in the manpage if you're to indicate the SAP-
overwriting problem...
I
Richard Stearn wrote:
Has there been any development effort in the past on any of the
above protocols?
The only thing I was able to find from a quick Google was a patch at
http://www.tux.org/pub/net/ip-routing/lbl-tools/tcpdump-tcpdump.org-ss991030.dif.gz
which appears to inc
Richard Stearn wrote:
A cursory look at the print-ax25 from that patch indicates that some
of the support is missing, e.g. ARP printing for ax25 is not in the
current tcpdump.org tcpdump. So somewhere between tcpdump 3.4 & 3.9
the ax.25 support was taken out.
That presumes that there *was* sup
Florian Weimer wrote:
Have these vulnerabilities been fixed in the main tcpdump code?
I can't answer about "etc." without knowing what's included in "etc."
(is it all CVE items for tcpdump?), but the two you mention are, as far
as I know, fixed in the top of the main and 0.9.x branches (I che
David Smith wrote:
A problem with cross-compiling tcpdump is that it isn't possible to
override the finding the location of the SSLeay libraries/headers. The
small attached patch fixes this.
So how do you override that? I don't see where Xprefix is getting set,
other than in that code.
-
Th
Ian McDonald wrote:
Please find attached a slightly revised patch to tidyup a bug with
seqno/ackno processing.
Checked into the main and x.9 branches. I got rid of the dh_end
variable, and added RCS IDs.
I gave you and Arnaldo credit in the CREDITS file; should I put
Yoshifumi Nishida in
(Noise inserted here to trick the duplicate-message dissector into
letting this message pass; the original was sent from the wrong address.)
Ian McDonald wrote:
Thanks for putting this in - please credit Nishida-san as well.
Done.
-
This is the tcpdump-workers list.
Visit https://lists.sand
David Smith wrote:
At first I tried to do this the "right" way of using a cached configure
variable, but the ac_cv_ssleay_path code is a bit too complicated for
that, since it actually sets two variables - ac_cv_ssleay_path and
incdir.
So, this Xprefix change is a bit of a hack, but not *too* g
On Sep 21, 2005, at 2:13 PM, David Smith wrote:
OK, here's a cleaner solution. It does this the "right" way using a
cached config variable.
So should that be applied to the configure.in *before* your previous
patch?
If so, does it mean that there's no need to have the user say where
th
On Sep 23, 2005, at 8:01 PM, Manish Jain wrote:
My question is regarding when does libpcap timestamp the packet -
when the
packet arrives in the kernel from NIC or when the packet is read by
application in user space?
Libpcap reads the time stamp when it reads the packet. However, the
ti
Sebastien Raveau wrote:
I could always make a separate capture just to be able to forward all traffic
while my first capture is filtered, but I am not comfortable with that
solution. This is why I am writing this feature proposal to this list:
* possibility of registering a separate callback fu
[EMAIL PROTECTED] wrote:
As far as I can see, print_vendor_attr() in print-radius.c doesn't
account for the fact that the length field includes itself (1 byte)
and type (1 byte), thus attempting to print 2 bytes too much when
printing the ASCII text form of the Value field.
Yes.
However, while
Vossie wrote:
My opinion is that libpcap are not able to send packets, it can only capture
it!!!
I think you will agree if you have a look at "man pcap"
Not if the output of "man pcap" mentions pcap_sendpacket() and
pcap_inject(); those were added in libpcap 0.9.x.
-
This is the tcpdump-wor
linjiangxiao wrote:
the website is a document about the libpcap-0.9.3,but i still cannot
use libcap-0.9.3 to send packets!-
On what OS are you using libpcap? HP-UX (as per the URL you sent), or
some other OS?
What happens when you try to send packets? Does pcap_sendpacket() or
pcap_injec
Albretch Mueller wrote:
1._ how do you log to a syslog client instead of a file?
If you mean "in tcpdump", the only way to do that would be to pipe the
output of tcpdump to the "logger" command (if the UN*X on which you're
running has that command); that would, of course, require that you're
Michal Kepien wrote:
I don't know whether this is the right place to post, but unfortunately nobody
on the usenet was able to help me with this issue. I came across this while
I was writing a simple libpcap-based program. The problem is, after I call any
packet capturing function (pcap_next(), p
rh wrote:
I'm using libnet 1.1.1 and pcaplib 0.8.3 (I believe).
Linux 2.4.20 / 2.6.11 (and later, FreeBSD 5.2).
GCC 3.3
Apologies if this is too off-topic an application for this list.
I'm attempting to use libnet and pcap together to write a client using raw
sockets so that I can gain explic
rh wrote:
Sounds like it's unavoidable. libnet and libpcap seem like they'd
complement each other so well.
libpcap is a low-level library, in that
1) it works at the link layer
and
2) it doesn't deal with dissecting or constructing packets.
As of 0.9.x, it *does* deal with
rh wrote:
If you're going to be sending stuff *that* strange, you shouldn't expect
a receiving machine to run an ordinary networking stack to handle them,
so it seems a bit odd that you're running ttcp on the remote machine,
unless you're trying to use that to test whether your code works if it'
Michal Kepien wrote:
$ tcpdump -h
tcpdump version 3.9.2
libpcap version 0.9.2
I've compiled both libpcap and tcpdump from sources version 3.9.3 (yes, that's
a "3" at the end :))
Could you try running that version of tcpdump, or your application,
under Valgrind, while capturing on a PPP link?
Michal Kepien wrote:
The whole `valgrind --leak-check=yes ./glibc_pcap_error' output can be found
here:
http://kempniu.no-ip.com/files/valgrind.log
Well, after seeing the Valgrind errors and asking why it was complaining
about a buffer of size 1, and then looking at the libpcap code to see
Vossie wrote:
I am using pcap_loop to capture a given amount of packets. That is
easy to implement but now I want to use pcap_loop BUT it must capture
packets for a given amount of time.
PS: According to man I must use pcap_breakloop. But how? Inside the callback
function?-
That depends on
Wilmar SULAIMAN wrote:
Suppose that I've set up a program using libpcap library to capture all
the packet that going to the ethernet card. I was wondering is it possible
that the program can't capture all the packets due to massive network packets.
What I mean by that is that suppose that my
Vossie wrote:
I wanted libpcap to do the following: It must distinguish between
packets that have been sent from its monitoring network card and between
packets that was received on its monitoring network card.
"Distinguish between" those packets in what sense? Do you mean you want
libpcap t
On Nov 2, 2005, at 4:16 PM, Luis Del Pino wrote:
Can i capture radio header 802.11 with promicuouos mode or only
monitor
mode?
I would like to get signal strength, noise strength, etc.
Could i capture this information with libpcap and promiscuous mode?
Not unless the driver supports that.
Mike Kershaw wrote:
Radio level data is only available in monitor mode.
On Linux, at least. From a quick look at the wi driver and 802.11
framework in NetBSD, you should be able to get radio data and 802.11
headers in non-promiscuous, promiscuous, and monitor mode; the 802.11
headers should
On Nov 7, 2005, at 1:08 PM, Rick Jones wrote:
The following change bumps a few limits in scanner.l so it will be
processed by the lex which ships with HP-UX. It is based on
libpcap-2005.10.09. While I was here, I went through to make sure
that utilization of these things was no more than ~
On Nov 7, 2005, at 1:23 PM, Rick Jones wrote:
It seems the compiler I have didn't like the + sizeof(*dh) in the
declaration.
Legitimately so. "void" objects have no size, so "(void *)dh" points
to an "object of unknown size", so advancing the pointer by "sizeof
(*dh)" objects is impossib
On Nov 4, 2005, at 3:11 AM, Karl-Johan Perntz wrote:
When I cross compiled libpcap and tcpdump for the CRIS architecture I
had to make libpcap aware of architecture dependent ar and ld. The
diff
below adds the option to specify which ar and ld to use. I think that
this could be useful for ot
On Nov 9, 2005, at 12:20 AM, Vossie wrote:
Ok in terms of the feature that I wanted to use... Is there a
command that
libpcap can use to detect lost packets?
To quote my earlier message:
"See packet lost" in what sense?
The only types of lost packet libpcap can report on - and it can on
On Nov 9, 2005, at 9:59 AM, Rick Jones wrote:
Vossie wrote:
Sorry guys. I was typing too fast. I mean HTTP packets (that
transfer the
data) and not the TCP ACK's :-)
Looking at a stream of HTTP carried in TCP segments without looking
at the ACKs seems a bit odd, but if you really don't w
On Nov 9, 2005, at 2:53 PM, Rick Jones wrote:
Shouldn't that have then appeared in the 11/09 "current" tar? I
just grabbed that and it doesn't seem to have been there. Operator
error on my part? Grabbing the wrong tar file or something?
It was checked in, but perhaps the tarball was crea
On Nov 9, 2005, at 3:17 PM, Rick Jones wrote:
For fun and excitement :) I tried compiling the 10.09 bits on an
IA64 HP-UX 11.23 system. I'm not _entirely_ certain of the lineage
of the compiler I'm using, having gotten it from an internal depot,
but it did emit some warnings that may or m
On Nov 10, 2005, at 11:05 AM, Rick Jones wrote:
Interesting - last time I looked, 10.09 was the latest. Ironic
coincidence that today happens to be the 10th of November - is the
machine's date off by a month?
Not now:
$ ssh cvs.tcpdump.org
...
% date
On Nov 11, 2005, at 1:48 PM, Evan Hughes wrote:
I'm building a library that indexes packets in libpcap files. In
order to create and use such an index, I'd like to be able to get the
file location that each packet starts at.
Would I be violating encapsulation if I just use pcap_file()
Vossie wrote:
The University of Pretoria uses a firewall to limit access to the
Internet but also a proxy server (for the students). According to
someone I have spoken about my problem the proxy server also uses the
firewall for outside access but it is a kind of a router for the
students. Thus
Vossie wrote:
This was the feature I wanted to implement. I would just mention in my
report that this kind of detection is not practical.
Direct *detection* isn't possible except at the point of packet loss
(although you might be able to get packet loss counts from the switch or
router), but
Albert Chin wrote:
From print-isoclns.c:
static int
isis_print_extd_ip_reach (const u_int8_t *tptr, const char *ident, u_int16_t
afi) {
char ident_buffer[20];
u_int8_t prefix[sizeof(struct in6_addr)]; /* shared copy buffer for IPv4
and IPv6 prefixes */
The prefix definition is
Ian McDonald wrote:
It uses the in6_addr structure because that would be bigger than IPv4
so could hold both. Saves having two different parts of code doing
basically the same thing.
...and breaks builds on systems that don't support IPv6.
As noted, a change was checked in to fix this; all it
Louis-Michel Gelinas wrote:
I ran into an issue using libpcap and tcpdump.
Whenever I enter a filter tcpdump segfaults:
i.e.:
works fine :
#tcpdump
segfault
#tcpdump port 80
That's a rather common filter, I suspect. :-)
I.e., if this were a libpcap bug, unless it's a very new one, it
Evan Hughes wrote:
If I submitted a patch with the change in it, what's the
likelihood that it would be accepted?
A patch with pcap_seek() and pcap_tell()? It'd probably be accepted...
I would, of course, wrap the
position into an opaque typedef, so that stuff like endian-ness could
be
Latha G wrote:
But on my system the link level header is not printd out. -xx option gives
the output same as the -x option.No change in the output.Both are the same.
Is this a bug in tcpdump???
Can anyone help me.
Thanks in advance.
my tcpdump version is: 3.8
...which means that, when it start
Latha G wrote:
In my system,
YYY is EN10MB and
ZZZ is Ethernet.
But for tcpdump -e option gives correct output only.
Means the link level headers are prited out.
Why it happens for -xx , that it is not printing header information.
I'm not seeing that on my system (OS X 10.4.3), which comes wit
Evan Hughes wrote:
Bah! That patch has cruft from an uninteresting file. A slimmer
patch is attached.
Some comments:
fgetpos() and fsetpos() don't return an error code, they returns 0 on
success or -1 on failure and, if they return -1, they set "errno" to the
error code.
If fgetpos() fai
Gianluca Varenni wrote:
Do you have any idea if performance is affected by these patches?
I'd probably expect almost no performance penalty in pcap_ftell() (apart
from the fact that you allocate memory with malloc),
...and might make a system call to get the file position, which could
signi
Evan Hughes wrote:
I haven't done any performance tests. The fgetpos() call is the
only function call I've added on the main path (although I do a little
stack manipulation during the read), but that's during
sf_next_packet(). I'm assuming that is already slow due to IO.
...although real I/
401 - 500 of 2521 matches
Mail list logo
