Jim Lloyd writes:
These duplicate packets cannot be unique packets that were retransmitted
between the two machines on the layer 1 GigE link, because if there was a
significant increase in retransmission duplicates on the link, they would
have competed for the fixed 1Gbps channel capacity. But th
Hi Paul,
I wrote:
Also, looking at the source code, there appears to be an omission in
the error() function call in the pcap_dump_open failure case - the
third parameter (pcap_geterr call) seems not to be used
(This is a pre-existing bug that just happens to be in the vicinity of
your change).
I wrote:
If you ever think that SocketCAN/libpcap will be used on big-endian
systems, you might want to "canonicalize" the layout in the big-endian
format
Guy Harris replied:
Linux USB leaves the pseudo-header in host byte order - and, in the
code that reads the savefile, libpcap byte-swaps t
table
code has to use #ifdefs to determine byte-order and then call a swap()
function/macro on big-endian systems).
@alex
--
Alexander Dupuy
Senior Secure Systems Engineer
Trusted Computer Solutions
2350 Corporate Park Drive, Suite 500
Herndon, VA 20171-4848
mailto:adu...@trustedcs.com
-
This
Guy Harris writes:
> s for non-Ethernet networks using 802.2, RFC 1042, "Standard for the
> transmission of IP datagrams over IEEE 802 networks" replaced that
> scheme with a scheme using SNAP headers with the standard Ethertype
> for IP.
>
> So I don't know who actually *used* an 802.2 head
Guy Harris wrote:
Arguably, a library for writing link-layer protocols in userland,
separate from libpcap, would be useful. For example:
on a number of platforms, the former library would bind to the
low-level networking stack with a particular SAP rather than
"promiscuously" for all SAP
Lei Wei writes:
if I use the filter "ip or (vlan and ip)", the packet returned from
pcap contains the VLAN tag. I wonder
if there's a way to let the OS to strip off the tag before deliverying?
It really depends on the OS - I can't say anything about FreeBSD. While
it is possible to have Linu
You wrote:
...matched by the filter expression, so with a filter, tcpdump can
only process
3984 out of 1091656 ip packets And also, the port I'm monitoring
on is a mirror of the
department building uplink, it should have a major component of ip
packets.
As Guy Harris pointed out, , the f
Andy Howell wrote:
In my application I
needed to detect the duplicate packets that some Cisco Cat6000 (?)
switches send on a spanning port. I tried various hashes like SHA1,
MD4/5, but they were too cpu intensive. I ended up using a simple
checksum. I only look at the last 4 packets in determinin
Gianluca Varenni wrote:
Having a function that
returns success but then spits out a human only readable warning string in a
parameter called "errbuf" and not "warnbuf" (also considering that there's
an errbuf in the pcap_t structure that can be retrieved with pcap_geterror()
or similar) is not th
Guy Harris asked:
How does pcap_setbufsize() differ from pcap_setbuff()?
The WinPcap pcap_setbuff function is defined as:
int pcap_setbuff(pcap_t *p, int dim);
I declared it as follows:
extern int pcap_setbufsize(pcap_t *p, int bufsize, char *errbuf);
extern int pcap_getbufsize(pcap_t *p, ch
[I sent this from my other account but it seems not to have gone through;
resending and apologies if you receive it twice.]
Paolo Abeni writes:
It does not use environment variables to control the memory mapped ring
parameters; instead the requested snap len is used: the low order bytes
are used
Paolo Abeni writes:
It does not use environment variables to control the memory mapped ring
parameters; instead the requested snap len is used: the low order bytes
are used to select the ring frame size and the high order bytes are used
to select the ring frame number. If the high order bytes is
Paolo Abeni writes:
I tried to dig this in the ML archive, without any luck. It look like
there is a certain interested for the memory map patch by Phil Wood
(http://public.lanl.gov/cpw/), but it have never been merged, why ?!?
I can't say for sure, but I suspect that Phil Woods' changes, wh
ELF versioning is handled by ONAME tag in the library .so which specifies an
exact library name for linking. This is typically something like libx.so.6
which is a symlink to libx.so.6.1.2. So unless libpcap.so was built with an
ONAME of libpcap.so.0 the default is an exact version match, i.e.
l
Petr Novák wrote:
I sent You cut off my damaged cap file. Do not post this file to the
internet please. Could You have a look, why this whole file is not
succesfully passed? But it is better than nonpatched tcpdump.
OK I add one thing. I do not know why my cap file is damaged. It was
generat
Petr Novák wrote:
Please tcpdump, do not end, but run over damaged packets (move from
current position in cap file byte by byte) from cap file until You find
good header and packet,
Guy Harris replied
The code *could* skip forward until it finds something that appears to
have a caplen <=
There's a minor bug in the tcp_print() function introduced in Hannes'
rewrite in version 1.127 of print-tcp.c. A NUL ('\0') character is
printed after the open bracket '[' and before other options. If you're
just printing to a TTY, you probably won't see the NUL, but it's
definitely there, e.
rh wrote:
After playing around with this for a while, the solution I've used is
to open two pcap_t * handles, set them non-blocking, and then call
pcap_dispatch() on each of them within a while(1) loop.
You really want to use select() (or poll() if your operating system
doesn't support sele
David Moron asked:
I want to monitor a Gigabit Multimode(SX) Fiber link. If use a Network
Tap then:
- Using one SX NIC: Can Libpcap capture packets from TX and RX NIC's
connector?
- Have I to use 2 different NICs to connect the fibers to the RX
connectors and don't use the TX one
>> when given a rule consisting of a set of sub rules to pcap, if a packet
>> matches the rule, how do I know which sub rule it matches?
> libpcap will not tell you that. As far as it's concerned - and as far
> as the kernel is concerned, on those platforms where the packet
> filtering is done
[I tried sending this back on February 4 and 6, but there were problems
with the list, and I don't believe it ever made it through. My
apologies if this is a duplicate.]
The recent changes to pcap-linux.c to prevent double-counting of
received packets have an unfortunate bug that causes the ke
The current libpcap optimization functions rely heavily on recursive functions;
when optimizing very large filters, this can cause core dumps due to excessive
stack usage in some worst-case scenarios.
The attached patch replaces a few of the "deepest" recursive functions with
implementations t
The configure.in code that checks for SSLeay stuff can end up putting multiple
copies of -I include directives in the compiler flags (once in CPPFLAGS, and
again in V_INCLS) - it can also add -I/usr//include or -I/usr/include if the
SSLeay libraries are installed there, which is unnecessary, may
Is there a compelling reason why this returns a long, rather than an off_t
(ftello style)?
Given that libpcap dump files are very likely to be > 2 GB, it seems sensible
to return a type that supports the largest file offset possible on a given system.
Although, given that this is already in a
Guy Harris writes:
tcp && (ip[2:2] > (((ip[0]&0xF) + (tcp[12] >> 4)) << 2))
Extending this to check for TCP or UDP with non-empty payload, I got the
following:
# tcpdump -d 'ip && ((tcp && (ip[2:2] > ((ip[0]&0xF) + (tcp[12] >> 4))
<< 2)) || (udp && udp[4:2] > 8))'
(000) ldh [12]
(001
I added the -P flag, which takes a positive number, and has tcpdump
exit after capturing that many packets.
How, exactly, is this different from the existing -c "Exit after receiving
count packets" option? I suppose that one of them might count packets on the
interface before filtering, and
I sent a report on this previously, but it didn't seem to go through on
the list.
Perhaps you're not getting stuff on the list delivered; I saw it, and
responded.
I did see it eventually, but I get the digest, and it only showed up in the
digest I got after a > 24 hour delay.
One problem occurs
So what's the problem that requires the include protection?
Should we, instead, remove from our pmap_prot.h anything that causes a problem with the system's portmapper includes? We don't seem to need "struct pmap", for example.
It was getting an error on duplicate struct definitions, so yes, re
I sent a report on this previously, but it didn't seem to go through on
the list.
This is with the 2005-04-26 snapshot:
One problem occurs because of FreeBSD's #define of __ntohl as an inline
asm function conflicts with the one in tcpdump-stdinc.h. Patch to fix
this follows:
--- tcpdump-stdin
The problem is that __ntohl et al. are already #defined as special asm
functions:
gcc -O2 -DHAVE_CONFIG_H -I./../libpcap -I/usr//include -I./missing
-D_U_="__attribute__((unused))" -I. -I./../libpcap -I/usr//include -I./missing
-c ./addrtoname.c
In file included from addrtoname.c:33:
tcpdump-
Erik Corell wrote:
I am using a pcap filter to catch 90 bytes long packets on port 123 (NTP
packets). I am only interested in the packets to and from the computer I am
running pcap on. It is usually not a problem because I am running PCAP in
non-promiscuous mode. However, when I run for example tcp
Gert Doering wrote:
since quite a while, I can't do CVS pserver operations anymore (at
least half a year, but since I had no need to actually do anything
to the sources, I never bothered enough to send mail).
I have also had the same problem, for quite some time, and reported it to this
list (an
> ... the CPUs are Intel Pentium III, and the OS is Redhat Linux 8. For the
> network card, I am sorry I don't have much information. When I ran the
> program, I didn't check the CPU utilization, but I tried Tcpdump, and got
> the same problem.
> I was wondering if this kind of configuration is eno
Guy Harris wrote:
I don't know whether any of the mechanisms used for packet capture will
deliver packets in an order other than the order in which they are
received by the network interface device or processed by the driver.
On a multiprocessor RedHat 9 Linux box with an SMP kernel, packet capt
aman Reddy wrote:
Well I have gone through the man page. I didn`t get the clear point. U mean
the length of the header is the sum of the lengths of the fields in the
header.
Then it should be 16 bytes(2,2,2,8,2) but when I captured the packet using
ethereal it is showing me 6 in the link-layer add
...the time stamps you get out of libpcap might have
nanosecond *precision* but they might not have nanosecond *accuracy*) -
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.
If
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 promiscuous as the flag is ignored, b
Guy Harris wrote:
Try it with the top-of-tree CVS version; I've made some optimizer fixes that
will, I think, fix this.
I saw the commit messages. However, I'm unable to update my CVS version; as
noted before, I get an abrupt server abort, and don't have other ideas on how
to solve this:
$ cvs -d
Jefferson Ogata wrote:
Or you can do something more utilitarian, such as:
tcpdump [options] '( ip[12:4] >= 0xc0a8020f ) and ( ip[12:4] <= 0xc0a80228 )'
For some reason (subscription e-mail vs. sending e-mail) my previous messages
on this topic seem not to have gone out to the list, so I'll re-summ
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
candidate for libpcap.
I didn't realize it was possible to set the bu
41 matches
Mail list logo