> I have written a packet sniffer under C++ using libpcap.
> Now I have noticed that about every 3 minutes and 15 seconds the Program
> uses 100 % of the CPU.
> After about 45 sec the program works normal again and uses only 10% of the
> CPU time.
Sure sounds like a problem with your program - as
> > > Now I have noticed that about every 3 minutes and 15 seconds the Program
> > > uses 100 % of the CPU.
> > > After about 45 sec the program works normal again and uses only 10% of
> > the
> > > CPU time.
> > > The program is running on a 300 MHz Celeron with 128 MB RAM under
> > Slackware
> >
> Is there a limit on how big the string can be for specifying the filter to
> pcap in pcap_compile. My filter needs to exclude a bunch of ip addresses
> (eg: tcpdump host not 1.1.1.1 and host not 2.2.2.2 ...upto 50 addresses)
There are definitely limits for the operating systems which do in-kerne
gcc, at least on my FreeBSD 4.9 box, doesn't like an active statement
before the first declaration (compiling tcpdump-2004.05.20):
./print-ipx.c: In function `ipx_print':
./print-ipx.c:60: syntax error before `const'
I fixed it as shown below.
Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Below are patches to perform significantly more complete LDP decoding.
Synposis:
- Minor diff to print-tcp.c (actually call the LDP decoder)
- Minor diff to print-bgp.c (unstaticize routines used by print-ldp.c)
- Major diff to print-ldp.c
Hannes: I'd be happy to decode even more if you can get m
> Despite all my whining, it is great that tcpdump is being worked on again, and I
> appreciate the effort that you've put into it. I just wish there was an option
> that would preserve the old behavior. (Or, even better, an option that would
> *give* the new behavior.) I think a lot of peopl
> Is it possible to write a program using libpcap that doesnt need to be run in super
> user mode, and if there is how would that be done. Everything that i have seen that
> uses libpcap has to be in su mode
At least on BSD based systems, it depends on readability of the /dev/bpf*
devices and n
> > You could write a BPF expression to match a particular packet id#.
> >
>
> How should I do this? I don`t know a specific packet id. What I would have
> to do is to compare each packet id with the ones received earlier and I must
> store it to compare with ones received later. With that whole
> Recently I've been investigating why tcpdump on my IDS shows quite a few
> packets as being dropped. I think this is because my traffic to the IDS is
> fed through a hub where I know there are many collisions (there may be too
> many packets per second for the little soho 10/100 hub to handle
> >A collision on half duplex media (such as a hub) is a *normal* and
> >*expected* occurence, and does *not* cause a packet to be dropped.
>
> >Note that this does not apply to "late collisions" which are quite
> >different - late collisions are signs of *error* (for instance a
> >duplex mismatch
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. Example:
Vendor Specific Attribute (26), len
The original message was received at Fri, 9 Dec 2005 09:37:22 +0500
from nethelp.no [190.38.169.16]
- The following addresses had permanent fatal errors -
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
The original message was received at Tue, 18 Jul 2006 09:46:25 +0100 from
[27.102.129.216]
- The following addresses had permanent fatal errors -
tcpdump-workers@lists.tcpdump.org
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Very minor patch to print basic info about a few more Cisco LAN
protocols. See documentation of the PID values at for instance
http://www.cisco.com/en/US/products/hw/switches/ps700/products_white_paper09186a00801b49a4.shtml#pre4
Steinar Haug, Nethelp consulting, [EMAIL PROTECTED]
Does anybody know of a good tool for stripping parts of the packets in
a pcap file? Say I have a pcap file containing GRE encapsulated info,
and I want to strip the outer IP + GRE headers and leave the rest,
writing out the result to another (valid) pcap file - which should of
course be readable b
> Well, you can open your pcap file with Wireshark (ethereal), select
> the packets you want using the filter and saving them using the
> standard "save as" option.
>
> Is it enough or you need something more "scriptable" that can be done
> from the command-line?
Command line would be preferred.
> It's 2008. Should we enable IPv6 support by default in libpcap and
> tcpdump (as long as the OS supports IPv6 to a sufficient extent that we
> can compile the support in), and let users do "--disable-ipv6" if, for
> whatever reason, they don't want it?
Yes please.
Steinar Haug, Nethelp cons
> I'm currently doing packet capturing on a FreeBSD 7.0 system. I was actually
> running my own pcap based
> program but found the performance was very bad when I added a simple filter
> as "ip". So I tested tcpdump
> on the same machine. It turned out that the performance of tcpdump without a
> f
> Thanks alot Alex, that's exactly the problem since the university uses VLAN
> based on packet tags.
> Actually I'm using pcap to do some packet payload processing on FreeBSD. It
> seems right now that
> if I use the filter "ip or (vlan and ip)", the packet returned from pcap
> contains the VLAN t
> > As I'm developping on libpcap to provide a metrology plateform, I was
> > wondering if there is a manner to enable a specific user (or a specific
> > group) to capture from a network interfaces (even in promiscuous mode),
> > without using sudo.
> > I'm trying to do this with udev, but I'm not
> I've spent some time playing with tcpdump and pcap with regard
> to vlans. Using libpcap 1.0.0 + tcpdump 4.0.0, I can able to
> correctly dump packets including (reconstructed) vlan headers.
> But it seems that using the vlan filter keyword does not work.
Can't answer for Linux, but VLAN filt
> Well, it gets in the way of all types of things, for example:
>
> tcpdump-v -i foo.cap | egrep pattern | wc -l
>
> I think the behaviour should be the reverse of the -g in Mac OS X
> and that is it should be necessary to use some new command line
> option to force tcpdump to insert new lines be
> Darren> I'm curious about what the motivation is for splitting the
> Darren> timestamp and packet data onto separate lines is.
>
> I think it just kinda happened.
> I would have to go back and look at who did what... I think that it
> does not occur in IP/TCP, but it does in IP/SCTP
> > I want to filter TCp syn packet which is coming using IPv6 addresses. I am
> > not able to find the bpf filter for that can somebody help me to find the
> > right BPF filter
> >
> >
> > I have already tried" tcp[tcpflags] & (tcp-syn) != 0" which doesn't work
> > for IPv6 traffic.
> >
>
>
Having started to play with DHCPv6, I found the tcpdump printout of
DHCPv6 options,
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2
could be improved. Below are my suggested improvements, relative to
tcpdump-4.1.1.
The change to the "NTP-server" opti
> Do newer version of tcpdump no longer show TCP sequence numbers without the
> -vv
> flag? Or is this some kind of FreeBSD bug?
Known problem, nothing to do with FreeBSD. See the thread "forces (and
sctp) patch starting at 10. Jan 2010 at
http://news.gmane.org/gmane.network.tcpdump.devel
Not
> I want to filter packets having VLAN id 7 or VLAN ID 10. Those are not Q-n-Q
> VLAN ID. So what should be perfect BPF syntax for it.
>
>
>
> When I tried using below syntax, it results only those packets having VALN ID
> as 7 and src host 10.21.22.2.
>
> ""( ( vlan 7 and src host 10.21.22.
> I'm experiencing a problem with tcpdump, and I hope you guys can point
> me in a good direction.
>
> Here's the short version: Running "tcpdump -r 10Gig.pcap host 1.1.1.1"
> returns zero frames. Running the same thing without the filter shows tcp
> packets from that IP.
You may have VLAN tagged
> The final 3 digits of the timestamp are bogus and always the same
> throughout the run. Since the timestamps are stored in microsecond
> precision, shouldn't the last 3 digits be 0's?
Which OS are you on? Tried this on FreeBSD 8-STABLE, both 32 and 64
bit. Only 6 digits are printed, not 9 - and
29 matches
Mail list logo