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
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
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 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.
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 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 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 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 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 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 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
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
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
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
# 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
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
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
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
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
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
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_=
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
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
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 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 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
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 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
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 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 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
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
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
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
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
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 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 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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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.
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
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
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 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
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.
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
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.
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
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
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
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
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 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"..
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
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
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
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)
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
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 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
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 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
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_
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
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.
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
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.
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
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
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.
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: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
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 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
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 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
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
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
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
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
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
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
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
1 - 100 of 154 matches
Mail list logo
