This patch changes the #ifdef for knowing about the path to "if_packet.h"
to being the result of work done by configure. Rerunning autoconf to
regenerate configure from configure.in is required after applying this
patch.
There might be some appropriate use of #else here as it seems that
glibc shi
Scott,
Is it just the 82580 or others too?
If I look in the source code for OpenSolaris, I see:
igb_82575.h:#defineE1000_SRRCTL_TIMESTAMP 0x4000
igb_82575.h:#defineE1000_RXDADV_STAT_TS 0x1 /* Pkt was
time stamped */
igb_82575.h:#defineE1000_RXDADV_STAT_TSIP 0x
Scott,
How does "-j raw" generate different output to "-j nic"?
Looking through your code below, the code which constructs
the data to pass through with the SIOCHWSTAMP ioctl ignores
the "timesource" member completely (except to check if it is
zero or not and thus turn it on.) This is the chang
t docs.
In the Linux driver, the PTP hw timestamping and general purpose packet
timestamping paths have much in common. (see IGB_PER_PKT_TIMESTAMP in the Linux
igb stable driver, http://sourceforge.net/projects/e1000/files/).
Scott
-Original Message-----
From: Darren Reed [mailto:darren.
Linux has defined a large number of values for dummy ARP
header types () that are not present in the
official IANA listing. See the hardware type table here:
http://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml
and compare it with the list found in pcap-linux.c.
One of my current
On 20/08/10 01:56 PM, Guy Harris wrote:
On Jun 30, 2010, at 3:10 PM, Darren Reed wrote:
Linux has defined a large number of values for dummy ARP
header types () that are not present in the
official IANA listing. See the hardware type table here:
http://www.iana.org/assignments/arp
I've been looking through all of the DLT decoders looking for one that has
just the DLT number in the header but I couldn't find one. Is there an
existing
DLT that matches this description?
Otherwise, I'd like to request DLT_DLT (or something like that) be allocated
to represent a 4 byte (netwo
When BPF was ported to Solaris, all of the ioctl operations
that use "struct ifreq" had a clone made that uses "struct lifreq".
So far as I know, "struct lifreq" is a Solaris-ism. One of the
main differences between "struct ifreq" and "struct lifreq" is
that the interface name can be 32 bytes long
roy hills wrote:
I maintain an application that uses libpcap to receive frames, and uses its own
link-specific functions to obtain interface details and send frames. I
currently support packet socket (Linux), BPF (BSD) and DLPI (Solaris).
I'd like to use libpcap to send as well as receive fra
On 5/02/11 11:20 PM, M. V. wrote:
hi,
as i mentioned in my previous mail, (with the title: "HUGE packet-drop") i'm
having problem trying to dump gigabit traffic on harddisk with tcpdump on
Debian5.0. i tried almost everything but got no success. so, i decided to
start-over:
*) if anyone has ex
Benimaur Gao wrote:
Dear all,
I tried to capture http traffic by the following command:
# tcpdump -Ani eth1 'host 10.20.156.9 and tcp port 9003 and
(((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'
(the web application didn't not serve at the conventional 80 port)
but different result
Is there a DLT type for "plain text"?
That is, can I record or insert text based comments or other data to a
pcap file?
Why could or would this be significant?
Well, if I was using DLT_PPI that allows multiple types of packets to be
recorded in a single file, why can't one of those DLT's be
Guy Harris wrote:
On Apr 4, 2011, at 10:09 PM, Darren Reed wrote:
Is there a DLT type for "plain text"?
No.
That is, can I record or insert text based comments or other data to a pcap
file?
No, but you can record them in a pcap-NG file.
My reading of yo
Printing PPI packets with tcpdump does not turn out
to be that hard.
My simple tests have produced the output as below.
It would be worthwhile having some changes made into
the tcpdump code base that were similar to the attached
that print them out.
Darren
19:20:51.470264 , DLT IPV4 (228) len
chael Richardson wrote:
"Darren" == Darren Reed writes:
Darren> Printing PPI packets with tcpdump does not turn out to be
Darren> that hard.
Darren> My simple tests have produced the output as below.
Super!
Do you have some PPI pcap files we can i
On 5/05/11 11:16 AM, Guy Harris wrote:
On May 5, 2011, at 11:07 AM, Darren Reed wrote:
There are also libpcap issues here that need to be resolved. At present, using
any filter with a PPI device fails to match any packet that doesn't have a DLT
of DLT_IEEE802_11.
...which i
On 5/05/11 11:35 AM, Guy Harris wrote:
On May 5, 2011, at 11:28 AM, Darren Reed wrote:
I see - you're concerned about how do you make "tcpdump icmp" work when the
link type is PPI (or pcap-ng)
Presumably meaning "when the link type is PPI or when the file is a
On 5/05/11 01:42 PM, Guy Harris wrote:
On May 5, 2011, at 1:38 PM, Darren Reed wrote:
In terms of pcap, I'm becoming more and more of the opinion that DLT_PPI should
not be used for anything other than DLT_IEEE802_11.
Sounds good to me.
Why am I not very interested in
On 5/05/11 05:09 PM, Guy Harris wrote:
On May 5, 2011, at 4:54 PM, Guy Harris wrote:
On May 5, 2011, at 2:45 PM, Darren Reed wrote:
Looking through it, the first observation I'd make is that there should not
have been any 16 bit fields. The one that concerns me most is th
To pursue this a little further, experimenting has
determined that the best layout thus far would be
something similar to this:
bits field
00-07 version (1)
08-15 pad (0)
16-31 pre-mac payload length
32-63 dlt (DLT_*)
64-79 ethernet protocol number
80-95 pad (0)
The pads are to ensure that fiel
To follow this on, looking at the output of "tcpdump -d",
it became obvious that the opcodes could be optimised.
The optimised would need to be seriously smarter than
it currently is to detect that it has a repeating group of
six statements, of which the second can be eliminated.
That's completely
It occurs to me that BPF needs a similar "special" instruction to chase
down a particular header. At present, BPF filters will fail to match any
TCP packet that has any extension header present. Thus a "chase" or
"find" instruction is needed.
An example of such an instruction might be:
ldxbf [8
On 12/05/11 04:27 AM, Guy Harris wrote:
On May 10, 2011, at 1:40 PM, Darren Reed wrote:
To pursue this a little further, experimenting has
determined that the best layout thus far would be
something similar to this:
bits field
00-07 version (1)
08-15 pad (0)
16-31 pre-mac payload length
32
On 13/05/11 01:02 AM, Guy Harris wrote:
On May 13, 2011, at 12:52 AM, Darren Reed wrote:
The goal of this is quite specific: to allow packets on a network device
to have mixed link-layer headers present and be able to use tcpdump and
friends to push meaningful filters into the kernel. The
On 19/05/11 03:33 PM, Tim Sammut wrote:
Hi, everyone.
I have a small tool that uses pcap_inject to send ethernet frames on
specific host interfaces. When injecting on a 802.1q virtual interface
on Solaris the frame is ultimately transmitted without the 802.1q header
that should have been add by
On 23/05/11 10:16 AM, Tim Sammut wrote:
On 05/20/2011 04:08 PM, Darren Reed wrote:
Hi, Darren, thanks for the note.
Are you using a virtual interface such as vnic0?
Or does it have another name?
The virtual interfaces appear as ce101002 and ce102002; the physical
Hi Mark,
I must admit that I don't see the point of this patch.
A pcap data file, with packets in it, is something that
I would create using tcpdump over a specific period
of time. The data file is thus associated with a very
specific set of actions. To then append data to that
file without that
On 1/06/11 12:43 PM, Michael Richardson wrote:
"Sam" == Sam Roberts writes:
>> Yeah, I'd rather that we have a good set of pcap manipulation
>> tools. Maybe we just need better pointers to mergecap and
>> editcap?
Sam> I don't see extensions to libpcap a
On 1/06/11 08:10 AM, Mark Johnston wrote:
Hi Darren,
On Tue, May 31, 2011 at 03:53:22PM -0700, Darren Reed wrote:
Hi Mark,
I must admit that I don't see the point of this patch.
A pcap data file, with packets in it, is something that
I would create using tcpdump over a specific p
On 3/06/11 05:24 PM, Guy Harris wrote:
On Jun 3, 2011, at 3:13 PM, Darren Reed wrote:
Because for every packet that is appended you need to do:
1. open(2)
2. read(2)
3. seek(2)
4. write(2)
5. close(2)
Really?
Why can't you do
open(2)
read(2)
s
On 3/06/11 04:18 PM, Flavio Truzzi wrote:
Hi, I am trying to compile a filter but I am getting a segmentation fault,
anyone can help me out?
Code:
"
...
handle = pcap_open_offline(".cap",errbuff);
string filtroexp;
filtroexp = "tcp port 80";
pcap_compile(handle,&filtr
Solaris 11 will support the ioctl BIOCSETLIF.
This operates on "struct lifname".
Whilst there are other *LIF ioctls, only this one
is important for libpcap.
For most consumers, the primary difference is the
length of the name allowed. The traditional ifname
structure only allowed for 16 characte
This set of diffs is required to correct a problem when compiling
libpcap on Solaris 11 due to the assumption that the presence of
AF_PACKET implies certain header files are in certain positions.
The failure (without the patch) is demonstrated as follows:
gcc -O2 -fpic -I. -DHAVE_CONFIG_H -D_U_=
On 13/05/11 12:52 AM, Darren Reed wrote:
On 12/05/11 04:27 AM, Guy Harris wrote:
On May 10, 2011, at 1:40 PM, Darren Reed wrote:
To pursue this a little further, experimenting has
determined that the best layout thus far would be
something similar to this:
bits field
00-07 version (1)
08-15
On 22/06/11 12:02 PM, Sanjay Sundaresan wrote:
Hi
I am trying to evaluate how tcpdump performs with different libpcap versions
and other packet capture libraries. How do I re-compile TCPDUMP to work with
a different libpacp ?
Depend on the version changes, if tcpdump is dynamically linked
Jakub Zawadzki wrote:
On Mon, Jun 20, 2011 at 11:17:20PM +0200, Jakub Zawadzki wrote:
If DLT_* registration process can be only done by someone who maintains
given protocol/interface than I'm not such person :)
Ping?
Jakub,
In your last email, you said that you couldn't answer so
Geoffrey Sisson wrote:
Guy Harris wrote:
On Jul 10, 2011, at 6:57 PM, Geoffrey Sisson wrote:
The catch is that domain names comprise a variable number of
variable-length fields.
...and include pointers back to other labels, for compression.
It's unlikely this would be
Some time ago I requested a DLT value for the IP over IB format of IB
frames.
The interfaces that I'm using on Solaris appear to be compliant with
RFCs 4391
and 4392.
Currently we're using DLT_USER15 internally but given the alignment with the
RFCs, I feel that this should be changed before I
# symbols seems like the only
reasonable solution.
Darren
Darren Reed wrote:
Some time ago I requested a DLT value for the IP over IB format of IB
frames.
The interfaces that I'm using on Solaris appear to be compliant with
RFCs 4391
and 4392.
Currently we're using DLT_USER15 intern
This is a trivial patch to update print-arp.c to know about the mapping
between hardware type having a value of 32 and the name Infiniband. The
value of 32 is as according to RFC 4391.
Darren
--- print-arp.c.distThu Mar 11 17:56:44 2010
+++ print-arp.c Thu Jul 14 08:56:12 2011
@@ -62,6 +62
Guy Harris wrote:
On Jul 14, 2011, at 5:23 AM, Darren Reed wrote:
Some more follow up on this...
Looks are deceiving - there is no RFC 4391/4392 header being prepended to the
IP packet:
/*
* In order to transmit the datagram to correct destination, an extra
* header including destination
Guy Harris wrote:
On Jul 14, 2011, at 5:23 AM, Darren Reed wrote:
Some more follow up on this...
Looks are deceiving - there is no RFC 4391/4392 header being prepended to the
IP packet:
/*
* In order to transmit the datagram to correct destination, an extra
* header including destination
alue for IP over IB (Infiniband)
From:
Darren Reed
Date:
Tue, 02 Aug 2011 08:57:40 -0700
To:
Guy Harris
CC:
tcpdump-workers@lists.tcpdump.org
On 07/29/11 09:49, Guy Harris wrote:
On Jul 27, 2011, at 3:02 AM, Darren Reed wrote:
With Solaris, the interfaces available from the driver and
On 07/29/11 09:49, Guy Harris wrote:
On Jul 27, 2011, at 3:02 AM, Darren Reed wrote:
With Solaris, the interfaces available from the driver and protocol stack
prohibit access to actual packets at the link layer. I don't know if this is or
will be possible with Linux, but if the link
On 5/08/11 01:46 AM, Guy Harris wrote:
...
That could, in theory, be fixed - for example, BSD/OS's BPF interpreter had an
instruction that would do IPv6 extension header parsing
How much interest is there in that?
And what would the functional requirements be?
I've written a prototype BP
On 6/08/11 11:22 PM, Guy Harris wrote:
...
For "ip4 protochain", the only protocol type that needs special treatment is
AH; can there be AH-within-AH? If so, that'd need a different instruction, otherwise,
unless I'm missing something, there's no need for a loop.
There's IP in IP (proto #4)
On 6/08/11 11:22 PM, Guy Harris wrote:
On Aug 5, 2011, at 6:59 AM, Darren Reed wrote:
On 5/08/11 01:46 AM, Guy Harris wrote:
...
That could, in theory, be fixed - for example, BSD/OS's BPF interpreter had an
instruction that would do IPv6 extension header parsing
On 13/11/2013 7:15 PM, Guy Harris wrote:
> ...
> Or write your own filter expression that looks at the link-layer header to
> detect IPv6 packets, skips past the IPv6 header (you won't be able to handle
> extension headers, as that involves looping, and the libpcap filter language
> doesn't supp
On 15/11/2013 6:26 AM, Michael Richardson wrote:
> Darren Reed wrote:
> >> Or write your own filter expression that looks at the link-layer
> >header to detect IPv6 packets, skips past the IPv6 header (you won't be
> >able to handle extension headers, as t
On 18/05/2015 9:31 AM, Mindaugas Rasiukevicius wrote:
Michael Richardson wrote:
Mindaugas Rasiukevicius wrote:
> A while ago NetBSD gained support for BPF_COP instruction, see [1]
> for more details. However, now there are use cases of it outside
> the NetBSD kernel, e.g. stand
On 10/06/2015 5:42 AM, Michael Richardson wrote:
re: https://github.com/the-tcpdump-group/tcpdump/pull/464 Guy writes:
We have the -C option, giving a file size in megabytes (real
megabytes, i.e. 1,000,000 bytes, not 1,048,576 bytes); once the file
gets that big, tcpdump switches to a new file.
Extending BPF
=
Introduction
BPF was originally designed to provide very fast packet matching
capabilities for IPv4 but as a result of its generic nature, is
capable of being used for just about any protocol. With IPv6 the
limitations of BPF became apparent.
BPF & IPv6
-
On 11/06/2015 1:08 AM, Paul "LeoNerd" Evans wrote:
On Wed, 10 Jun 2015 23:17:20 +1000
Darren Reed wrote:
BPF & IPv6
--
The problem with IPv6 and BPF is that the transport header (TCP,
UDP, etc) can have a number of extension headers between it and
the network header t
On 11/06/2015 9:31 AM, Mindaugas Rasiukevicius wrote:
Darren Reed wrote:
Extending BPF
=
Introduction
BPF was originally designed to provide very fast packet matching
capabilities for IPv4 but as a result of its generic nature, is
capable of being used for just about
101 - 154 of 154 matches
Mail list logo
