In some email I received from Christian Kreibich, sie wrote:
> [I've tried to get this to the list about four times now and it always
> came back with a different reason -- I hope this one will make it to
> the new list. Thanks.]
What's the _real_ list address? The web page still has:
[EMAIL PROT
In some email I received from Ronnie Sahlberg, sie wrote:
> Oh, I forgot.
>
> Another useful thing to have is an option for the packet block where one
> would store
> a reasonably collission-safe 8-byte hash of the packet data.
>
> This would make it much easier to compare two different capture f
In some email I received from Guy Harris, sie wrote:
> On Sat, Apr 10, 2004 at 04:39:41AM +1000, Darren Reed wrote:
> > I'll agree that this, as part of the per-packet header, would be a useful
> > addition to the pcap format. No need for chained hashing, just per-record.
>
In some email I received from Loris Degioanni, sie wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> Ok, I'm going to add a 8-byte hash option for the packet block. Can anybody
> suggest the hashing algorithm?
You obviously sent this before reading another email I sent on this.
Today, so
In some email I received from Brian Ginsbach, sie wrote:
> The following in netdissect.h seems like a bad thing to do.
>
> #define ND_PRINT(fmt, args...) (*ndo->ndo_printf)(ndo, fmt, ##args)
>
> Not all compilers/preprocessors support variable argument macros
> like GCC. Compiling tcpdump shou
In some email I received from Guy Harris, sie wrote:
>
> On Apr 12, 2004, at 2:25 AM, Darren Reed wrote:
>
> > In some email I received from Guy Harris, sie wrote:
> >> On Sun, Apr 11, 2004 at 03:15:30AM +1000, Darren Reed wrote:
> >>> And there's also BP
In some email I received from Michael Richardson, sie wrote:
-- Start of PGP signed section.
>
> >>>>> "Darren" == Darren Reed <[EMAIL PROTECTED]> writes:
> Darren> Today, some people might want MD-5, others SHA-1 and in the
> Darren> futur
In some email I received from Guy Harris, sie wrote:
>
> On Apr 12, 2004, at 4:43 PM, Darren Reed wrote:
>
> > The problem with pcap_next_ex() is the man page description:
> > "reads the next packet and returns a success/failure indication"
>
> Well, it sa
In some email I received from Loris Degioanni, sie wrote:
> > Today, some people might want MD-5, others SHA-1 and in the future,
> > there may be other hashing algorithms that are better to use. And
> > there are times when we might want it off (algorithm 0, for example.)
> >
> > As such, I belie
In some email I received from Michael Richardson, sie wrote:
> {Darren, you are sending to tcpdump-workers-owner, from the SMTP
> envelope. I think my MTA is canonicalizing something in a way I don't
> want it to. It isn't the lists' fault}
Thanks, fixed my alias.
&g
In some email I received from Jefferson Ogata, sie wrote:
> Darren Reed wrote:
> > In some email I received from Michael Richardson, sie wrote:
> >> Prooving what? that you aren't being lied to? By whom?
> >> What is the thread model for this? What does having t
In some email I received from Andreas Rieke, sie wrote:
> Hi there,
>
> is pcap really thread-safe, especially under linux? Did anybody really
> try to run it on multiple interfaces, one per thread?
The only part that wasn't thread safe (last time I checked)
was pcap_compile(). And yes, I've us
Firstly, still hitting "reply" puts this in the To line:
To: [EMAIL PROTECTED]
In some email I received from Automatic cvs log generator /tcpdump/bin/makelog, sie
wrote:
> CVS log entries from 22.04.2004 (Thu) 09:05:47 - 23.04.2004 (Fri) 09:06:03 GMT
> ===
In some email I received from Brandon Stafford, sie wrote:
[ Charset windows-1252 unsupported, converting... ]
> Hello,
>
> I'm writing a server that captures UDP packets and, after some
> manipulation, sends the data out the serial port. Right now, I'm using
> recvfrom(), but it takes 20 ms t
In some email I received from Hans Klute, sie wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> Hi!
>
> I just realized a bug/feature of pcap that I didn?t think of.
> I wrote a sniffer based on pcap. This sniffer can handle fragmented IP
> packets. Now I realized that if you set up a fil
I've been using this patch to print IP packets inside PPP HDLC
frames found in raw 1xRTT traffic. I've been able to find few
details on the actual PPP header format apart from what "0x7eff"
means and observing traffic for 0x7e21. The end result is extra
output of the form "{ PPP HDLC IP 1.2.3.4 >
In some email I received from Hannes Gredler, sie wrote:
> darren,
>
> can we have a .pcap sample showing such a frame for
> the /tests directory ?
I've semi-hand constructed this file because of privacy
concerns about the real data.
I've also included a new version of the patch (moved the
unesc
In some email I received from alex medvedev, sie wrote:
> hi,
>
> i think print-gre.c needs a #ifdef INET6 around
>
> case ETHERTYPE_IPV6:
> ip6_print(bp, len);
> break;
>
> otherwise tcpdump does not build if compiled without ipv6 support.
> but who does
In some email I received from alex medvedev, sie wrote:
> hallo,
>
> any interest in having a -j flag in tcpdump?
>
> the flag would simply jump over the specified number of packets.
> it may be useful when reading dumps with -r flag.
> it may also be useful in conjuction with -c flag to isolate
In some email I received from Hannes Gredler, sie wrote:
> i have some questions wrt to the format based on the .pcap
> file that you supplied;
>
> the 1st byte 0x7e seems to introduce a HDLC frame;
>
> after that i can see 4 different frame formats:
Yes. I thought it might be useful to provide
hope the white space is ok, it's a cut-n-paste.
*** print-gre.c.origSun Jun 13 02:32:56 2004
--- print-gre.c Sun Jul 4 03:30:00 2004
***
*** 195,203
--- 195,205
case ETHERTYPE_IP:
ip_print(bp, len);
break;
+ #ifdef INET6
ca
Seems frozen on 2004.06.28 ?
Darren
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
> Normally a NIC or interface providing access to an HDLC link/network would
> perform de-bytestuffing internally before the packets ever get to libpcap.
> Obviously de-bytestuffing a packet twice can corrupt data. Do we really
> want to have de-bytestuffing code in libpcap?
This isn't in libpc
Rather than just hexdump the PPP data and say "unknown PPP proto (0x00fb)",
I thought it might be better to print out a nicer message...
--- print-ppp.c.orig2004-07-05 18:30:38.0 +1000
+++ print-ppp.c 2004-07-05 18:30:47.0 +1000
@@ -1170,6 +1170,9 @@
case PPP_MPLS_MCAST
> Rather than just hexdump the PPP data and say "unknown PPP proto (0x00fb)",
> I thought it might be better to print out a nicer message...
>
> --- print-ppp.c.orig2004-07-05 18:30:38.0 +1000
> +++ print-ppp.c 2004-07-05 18:30:47.0 +1000
> @@ -1170,6 +1170,9 @@
> case PP
If ppp_hdlc() is called with length < 2, bad things happen.
Notably, if length == 1, handle_ppp() will be called with "length < 0".
At this point, things get ugly and print_unknown_data() tries to print
way too much data.
If ppp_hdlc() is being called with "p - 1", shouldn't the next parameter
I believe the sessions I am seeing start out with a conversation like this:
IP 1.1.1.1.1701 > 2.2.2.2.1701: l2tp:[TLS](24460/0)Ns=23236,Nr=646 *MSGTYPE(HELLO)
IP 2.2.2.2.1701 > 1.1.1.1.1701: l2tp:[TLS](4/0)Ns=646,Nr=23237 ZLB
IP 1.1.1.1.1701 > 2.2.2.2.1701: l2tp:[TLS](24460/0)Ns=23237,Nr=646 *M
> 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(1
I've come across a packet that causes me to get a stack trace something
like this:
#0 0x in ?? ()
#1 0x0807a0bd in handle_ctrl_proto (proto=32855, pptr=0x8195c82 "\001", length=14) at
print-ppp.c:450
#2 0x0807be24 in handle_ppp (proto=32855, p=0x8195c82 "\001", length=14) at
print-ppp.
A new RFC (3828) documents a slightly modified UDP protocol,
#136, called "UDP-Lite". For the true geeks, 136 is 10001000
and UDP (17) is 00010001 :)
The main difference is the length field bcomes a checksum length
field with valid values 0,[8,65535]. This indicates the amount
of data in the 'U
One of the big problems I have with tcpdump and libpcap, today,
is the limitations in the filter language. As a quick example,
while it understands IP header bits and port numbers, I can't
do 'tcpdump gre_v 1' in the same way I can do 'tcpdump port 2',
etc.
Taking it out to what I'd like to see
In some email I received from Guy Harris, sie wrote:
> 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:
>
In some email I received from John Hawkinson, sie wrote:
> Guy Harris <[EMAIL PROTECTED]> wrote on Tue, 20 Jul 2004
> at 23:21:17 -0700 in <[EMAIL PROTECTED]>:
>
> > 1) it defines DEFAULT_SNAPLEN as 96 unconditionally, rather
> >than, as is done now, as 68 if INET6 isn't defined and as
> This looks like Debian bug #255179, I fixed it differently by not trying
> to analyze IPV6CP, a comment in print-ppp.c says that it's not supported
> (yet).
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255179&archive=yes
>
> Corresponding fix currently in the Debian package (notice ho
In some email I received from Motonori Shindo, sie wrote:
> Hi,
>
> I'm involved in a project to do some network traffic analysis. One of
> the goals of this project is to identify an equipment that is
> supposedly dropping packets. My idea to achieve this goal is to
> capture traffic by tcpdump a
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 analysis
>
> http://ieeexplore.ieee.org/iel5/7446/20240/00935450.pdf?tp=&arnumb
In some email I received from Guy Harris, sie wrote:
> 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:
I did some similar work for bpf & mmap with NetBSD. See:
http:
[ Charset ISO-8859-1 unsupported, converting... ]
> http://netgroup.polito.it/fulvio.risso/pubs/iscc01-wpcap.pdf
When was it published? There is no date...
Winpcap appears, by design, to be the same as BPF. If you reduced the
number of buffers in the ring used with NPF to 2 buffers, I suspect
Hi Fulvio,
> Fulvio Risso, Loris Degioanni, An Architecture for High Performance Network
> Analysis, Proceedings of the 6th IEEE Symposium on Computers and
> Communications (ISCC 2001), pg. 686-693, Hammamet, Tunisia, July 2001.
Is there any way you can get this (and the other date info.) into th
In some email I received from Loris Degioanni, sie wrote:
> Other things:
> - modern network cards don't almost do buffering. The memory inside the
> board is usually few KB, and its purpose is providing the space for a packet
> or two. The actual buffering is done in the RAM of the PC. What determ
Hi Fulvio,
> > What have you found that makes you say this ?
> > The simplicity in cpu cycle cost ?
>
> 1. simplicity
> 2. swappable buffers are very helpful if you plan to make statistics, not
> only packet capture.
> For instance, let's think about a system (like a NetFlow probe or something
>
Hi Fulvio,
> Yes, it is harder.
> For instance, let's imagine you collected statistics based on the IP source
> address (e.g. byte count). You need something like a 10MB buffer (uhmmm,
> probably much more) to store data.
> Now, let's imagine you want to plot a snapshot of your stats every minute.
> Hi !
>
> I understand there is no solution to sniffing
> for local traffic on Solaris since the
> kernel always used the loopback interface for
> that.
>
> I suggest to write a STREAMS module to sit on top
> of the loopback driver.
>
> Does anyone know if the loopback driver is a
> STREAMS dr
In some email I received from Guy Harris, sie wrote:
> 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
In some email I received from Guy Harris, sie wrote:
>
> 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?
gethrtime
-
This i
In some email I received from rick jones, sie wrote:
> >> BTW, where are you getting the nanosecond-resolution time stamps in
> >> Solaris?
> >
> > gethrtime
>
> there is such a thing in some of the other OSes as well - netperf will
> use it for -DHISTOGRAM because it typically is lower overhead.
In some email I received from Guy Harris, sie wrote:
>
> 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?
> >
>
Hi,
I'm trying to work out how to correctly map the DLPI data link
types that are used to each of the relevant DLT's that are
supplied in bpf.h. Some of them are easy, some are repeats,
some not so...
I'm not completely sure if I should assume DLT_NULL for the
likes of IPv4/6 tunnels or pretend
On 26/03/09 05:23 PM, Guy Harris wrote:
On Mar 26, 2009, at 11:58 AM, Darren Reed wrote:
I'm trying to work out how to correctly map the DLPI data link
types that are used to each of the relevant DLT's that are
supplied in bpf.h. Some of them are easy, some are repeats,
s
On 27/03/09 03:01 AM, Guy Harris wrote:
On Mar 26, 2009, at 6:47 PM, Darren Reed wrote:
On 26/03/09 05:23 PM, Guy Harris wrote:
On Mar 26, 2009, at 11:58 AM, Darren Reed wrote:
{ DL_HDLC, DLT_HDLC }, /* ISO HDLC protocol support */
"HDLC" is a catch-all term f
On 27/03/09 11:27 AM, Guy Harris wrote:
On Mar 27, 2009, at 10:58 AM, Darren Reed wrote:
Seriously, for my purposes, it is "Cisco HDLC".
So it should be mapped to DLT_C_HDLC.
For the purposes of my table, I'd like to map the mediums that have
passed (or are passing) fro
On 27/03/09 05:03 PM, Guy Harris wrote:
On Mar 27, 2009, at 1:45 PM, Darren Reed wrote:
On 27/03/09 11:27 AM, Guy Harris wrote:
On Mar 27, 2009, at 10:58 AM, Darren Reed wrote:
Seriously, for my purposes, it is "Cisco HDLC".
So it should be mapped to DLT_C_HDLC.
For the purp
On 27/03/09 07:01 PM, Sebastien Roy wrote:
Hi Darren,
On Fri, 2009-03-27 at 10:58 -0700, Darren Reed wrote:
Additionally, I'm considering creating a new datalink type for loopback
packets on OpenSolaris. The contents would be something like:
version (16 bits: 1)
protocol family (16
On 27/03/09 07:42 PM, Guy Harris wrote:
...
2) returning some new DLT_ value.
The only thing that would break would be applications that don't
understand that new DLT_ value, but that happens with *any* new DLT_
value.
Alternatively, libpcap could have DL_IPNET devices offer *two* new
l
On 29/03/09 11:11 PM, Guy Harris wrote:
On Mar 29, 2009, at 10:59 PM, Darren Reed wrote:
What I am considering is:
And what Sebastien is suggesting is, I think:
using the DL_IPNET link-layer header for loopback devices, as
documented in the loopback device man page, in your Solaris
Sebastien Roy wrote:
...
It might also be simplest for BPF to hook into the ipnet driver anyway,
as the driver implements all kinds of heuristics to ensure that the
observer doesn't see packets that shouldn't be seen (as related to
zones). Some code sharing would be beneficial, and the header co
What you might be able to do is construct a filter that only matches
Ipv4 packets that have an ipid field that is 0 in base 4.
i.e. this
tcpdump 'ip[2:4] & 3 = 0'
should get you approximately 25% of the packets.
On 6/04/09 04:11 PM, Diego Valverde wrote:
Hi,
I am using linux on my device.
I d
Guy,
The URL below contains the necessary changes for BPF on Solaris to
"just work". To summarise, Solaris needs a few extra includes and for
BPF to be checked before DLPI.
http://www.opensolaris.org/os/community/networking/files/libpcap.diff.gz
Cheers,
Darren
-
This is the tcpdump-workers lis
On 13/04/09 10:58 AM, Guy Harris wrote:
On Apr 10, 2009, at 8:23 PM, Darren Reed wrote:
The URL below contains the necessary changes for BPF on Solaris to
"just work". To summarise, Solaris needs a few extra includes
@ -37,6 +37,12 @@ static const char rcsid[] _U_ =
#include
There's another change that I think should be made that I'd like to
discuss and that's the change from using "test -r" to "test -a" or
"test -c". With the device as rwx--, "test -r" will fail for doing
"configure" as non-root. I don't consider that to be ideal. At least
I like to build softwar
I'd like to request a DLT type for the "ipnet device" on OpenSolaris.
A description of the packet header can be found here:
http://arc.opensolaris.org/caselog/PSARC/2009/232/commitment.materials/bpf-psarc.txt
and the relevant structure name is "dl_ipnetinfo".
This structure will be prepended t
On 18/04/09 01:07 PM, Guy Harris wrote:
On Apr 10, 2009, at 8:23 PM, Darren Reed wrote:
The URL below contains the necessary changes for BPF on Solaris to
"just work". To summarise, Solaris needs a few extra includes and for
BPF to be checked before DLPI.
http://www.opensola
On 21/07/09 02:40 PM, Guy Harris wrote:
On Jul 21, 2009, at 1:35 PM, Guy Harris wrote:
struct dl_ipnetinfo {
uint8_tdli_version;
uint8_tdli_family;
uint16_tdli_htype;
uint32_tdli_pktlen;
uint32_tdli_ifindex;
uint32_tdli_grifindex;
uin
On 21/07/09 01:35 PM, Guy Harris wrote:
On Jul 14, 2009, at 5:53 PM, Darren Reed wrote:
I'd like to request a DLT type for the "ipnet device" on OpenSolaris.
A description of the packet header can be found here:
http://arc.opensolaris.org/caselog/PSARC/2009/232/commitmen
As well as porting BPF to Solaris, I've been working on developing an
implementation of PF_PACKET. I went to try this out with libpcap and
it failed badly. pcap-linux.c is a combination of PF_PACKET bits plus
all of the code required to deal with Linux's ARP implementation.
Is there any interest
On 27/07/09 12:48 PM, Guy Harris wrote:
On Jul 27, 2009, at 11:40 AM, Guy Harris wrote:
The code to use PF_PACKET and PF_INET/SOCK_PACKET sockets *does* have
to translate the ARPHRD_ values Linux returns to DLT_ values; that's
not a lot of code, and is only minimally involved with Linux's ARP
On 27/07/09 11:47 AM, Guy Harris wrote:
On Jul 26, 2009, at 6:48 PM, Darren Reed wrote:
On 21/07/09 01:35 PM, Guy Harris wrote:
dli_htype - hook type (in, out, local)
Presumably there are specific values for those (0, 1, and 2, or
whatever).
Yes, 0 for inbound, 1 for outbound, 2
On 27/07/09 12:03 PM, Guy Harris wrote:
On Jul 14, 2009, at 5:53 PM, Darren Reed wrote:
I'd like to request that the assigned name is DLT_IPNET.
I've assigned 226 to DLT_IPNET.
Thanks,
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
I'm seeing this
Not Found
The requested URL / was not found on this server.
Apache/2.2.9 (Debian) Server at www.tcpdump.org Port 80
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscrib
After around 17 years of being out in the cold, BPF is now integrated into
the SunOS kernel. At long last it is no longer necessary to use binary
patches on a SunOS kernel or do the filtering in userland. BPF can be
found in Solaris Express Community Edition build 125 onwards and in
upcoming relea
To compile libpcap on OpenSolaris (or Solaris Express Community Edition)
build 125 and later to use the native BPF with both IPNET and traditional
MAC (ethernet, etc) packet sniffing, the attached patches are required.
The attached patches represent what's in our internal build tree for
libpcap.
The patches attached to this email are required to get a fully working
tcpdump
on OpenSolaris, or Solaris Express Community Edition, build 125 and later.
The attached patch introduces support for printing out the IPNET headers
used
for packet capture inside of zones that share their networking
On 11/24/09 18:41, Michael Richardson wrote:
I applied the patches.
The Makefile.in patch has changed, I think the command is now derived by
configure. Also the DLT_CHOICE macro was already there, I think maybe
Guy did that, but the rest was not.
Pushed into libpcap, passed tcpdump make check.
On 11/24/09 18:31, Michael Richardson wrote:
Darren, thanks!
Please pull from the git tree, and run "./configure; make check"
I would appreciate it if you have any pcap files of formats:
DOCSIS (DOCSIS) (printing not supported)
This seems to be an inherent part of libpcap?
BPF on Solaris
Guy Harris wrote:
On Nov 24, 2009, at 3:55 PM, Darren Reed wrote:
--- Makefile.in.distMon Oct 27 18:26:13 2008
+++ Makefile.inWed Oct 21 21:36:27 2009
@@ -44,6 +44,7 @@
# You shouldn't need to edit anything below.
#
+LD = /usr/bin/ld
CC = @CC@
CCOPT = @V_CCOPT@
INCLS = -I. @V_
Guy Harris wrote:
On Nov 25, 2009, at 11:42 AM, Guy Harris wrote:
Can I plug a Cisco cable modem head-end device into an IPNET device
and have it put DOCSIS frames inside IPNET layer-1 framing, so that
you get packets with *no* IPNET header? I suspect the answer is
"no", in which case you s
Doing some further testing of DLT lists, get_dlt_list() needs
some further work. On an OpenSolaris host with ethernet
and a tunnel created, they're visible here:
# dladm show-link
LINKCLASS MTUSTATEBRIDGE OVER
igb0phys 1500 up -- --
e1000g0
Guy Harris wrote:
On Nov 29, 2009, at 11:43 PM, Darren Reed wrote:
...
When there is no network interface specified with
-i, what I expect from "tcpdump -L" is for tcpdump to
list all of the DLTs that are available for selection
with -y.
What you *should* expect is all the DLTs
Sebastien Roy wrote:
On Tue, 2009-12-01 at 00:47 -0800, Guy Harris wrote:
On Nov 30, 2009, at 5:30 AM, Darren Reed wrote:
# dladm show-link
LINKCLASS MTUSTATEBRIDGE OVER
igb0phys 1500 up -- --
e1000g0 phys 1500 up
Guy Harris wrote:
On Dec 1, 2009, at 4:10 PM, Darren Reed wrote:
Use of libdladm is going to be required.
Required for what? Enumerating capture interfaces?
On Solaris, yes. This is a [Open]Solaris problem because libdladm is
not yet in a state suitable for use by tcpdump.
libpcap
In some further development, I've updated print-ipnet.c
to output which hook was used to record the packet.
The output has been modified to look like this:
$ ./tcpdump -c 3 -en -r ~/a
reading from file /home/dr146992/a, link-type IPNET (Solaris ipnet)
20:52:54.829738 0 > -1, hook observe-out (1)
Mark Bednarczyk wrote:
Hello,
We are running into some performance issues with libpcap when running
under VMWare products such as VMWworkstation or VMServer. These are guest
OSes (running as a VM process on a host operating system.)
Does the performance change if you compare capturing pa
Looking at the BPF code that gets generated for links such as
the IP tunnels in Solaris, there appears to be an inefficiency
in the opcodes generated. Let me explain.
The links that support the IP tunnels are a fixed type, be
it IPv4 or IPv6, and are reported as being DLT_RAW because
there is no
On 23/12/09 06:09 PM, Guy Harris wrote:
On Dec 23, 2009, at 2:01 AM, Darren Reed wrote:
The links that support the IP tunnels are a fixed type, be
it IPv4 or IPv6, and are reported as being DLT_RAW because
there is no real layer 2 header present.
...
In the face of
On 23/12/09 06:09 PM, Guy Harris wrote:
On Dec 23, 2009, at 2:01 AM, Darren Reed wrote:
The links that support the IP tunnels are a fixed type, be
it IPv4 or IPv6, and are reported as being DLT_RAW because
there is no real layer 2 header present.
...
In the face of
On 11/01/2010 1:29 AM, Michael Richardson wrote:
...
I was initially concerned about the output with -v, as it is multiline,
and I think that without -v, one packet should occupy one line.
This makes postprocessing easier, and certainly makes grep easier.
Maybe we need another option, "--human"..
Since you're looking for one-liners...
On 15/01/2010 9:47 PM, Mark Bednarczyk wrote:
bpf_filter- ???
Applies the BPF program (filter) to a packet and returns if the packet
should be captured or not.
bpf_validate - ???
Verifies that a BPF program is valid and
On 12/01/2010 6:57 PM, Michael Richardson wrote:
"sthaug" == sthaug writes:
>> 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
On 18/01/2010 9:27 PM, Michael Richardson wrote:
"Darren" == Darren Reed writes:
Darren> This kind of change to the defaul behaviour warrants bumping
Darren> the version number from 4.x to 5.x because this is a
Darren> significant chan
A question that I'm sure that everyone who's responsible for bringing
libpcap and tcpdump into a distro would like to know is, what are the
plans for the release schedule of libpcap and tcpdump, if there are any?
Does a release of libpcap mean that there will be a new one for tcpdump?
And/or vice
Michael Richardson wrote:
"Darren" == Darren Reed writes:
Darren> A question that I'm sure that everyone who's responsible for
Darren> bringing libpcap and tcpdump into a distro would like to
Darren> know is, what are the plans for the r
Michael Richardson wrote:
"Darren" == Darren Reed writes:
Darren> A question that I'm sure that everyone who's responsible for
Darren> bringing libpcap and tcpdump into a distro would like to
Darren> know is, what are the plans for the r
Michael Richardson wrote:
"Darren" == Darren Reed writes:
>> We were planning a release for earlier this month, and the
>> question of newline behaviour came up. I gave it an extra week
>> to let people catch up and express an opinion.
Ritesh Rekhi wrote:
Hi all,
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.
W
Is there a target date for the delivery of tcpdump 4.1 and libpcap 1.1?
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On 19/02/10 10:56 AM, Michael Richardson wrote:
"Darren" == Darren Reed writes:
Darren> Is there a target date for the delivery of tcpdump 4.1 and
Darren> libpcap 1.1?
Ken is working on it as I type, I think.
There's still no sig
Michael Richardson wrote:
"Darren" == Darren Reed writes:
Darren> There's still no sign of a new release on www.tcpdump.org...
http://www.tcpdump.org/beta/
I will sign "4.0.1rc3" as "4.1" on Monday evening.
I don't know if thi
On 16/03/10 04:40 PM, Jim Lloyd wrote:
I have a working application using libpcap that doesn't always filter as I
expect. The application is designed to sniff http traffic, so the filter can
be as simple as "tcp port 80". However, we allow sniffing multiple http
servers running on different ports
On 03/31/10 11:39, Michael Richardson wrote:
"Guy" == Guy Harris writes:
Guy> On Mar 30, 2010, at 1:55 PM, Wesley Shields wrote:
>> The links on http://www.tcpdump.org are broken.
Guy> The tarballs are libpcap-1.1.tar.gz and tcpdump-4.1.tar.gz,
Guy> rather than li
the current libpcap record format has no way to record this information.
you might like to play around with pcap-ng.
Darren
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
1 - 100 of 154 matches
Mail list logo
