On Apr 4, 2011, at 12:15 PM, Rick Jones wrote:
> The former is easy enough - attached is a compressed pcap file with 30
> captured PDUs which can be used for testing. They are all just counter
> samples, there are no flow samples. Also attached is a compressed
> "cooked" file with the correct o
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.
The tradeoffs:
With LINKTYPE_PPI+LINKTYPE_TEXT, with no ch
On Apr 5, 2011, at 11:41 AM, Darren Reed wrote:
> My reading of your list of tradeoffs is that even for pcap-NG, LINKTYPE_TEXT
> is required as it has no other way to record text (no comment fields, for
> example, attached to packet blocks.)
Actually, yes, it does - just about every block can
On Apr 13, 2011, at 1:02 PM, Rick Jones wrote:
> To enable printing of non-expanded samples I've shuffled a bunch of code
> around and created a bunch of smaller routines to more easily support
> printing of both expanded and non-expanded counter and flow samples.
> I've done simple testing of no
On Apr 14, 2011, at 11:45 AM, Rick Jones wrote:
> Cool. BTW, I just found a bug in the print_counters routines - i was
> manipulating based on the size of the pointer rather than the struct to
> which it pointed. in 64-bit (where I'm running) the two were the same,
> but in 32 bit they were not
On Apr 14, 2011, at 2:59 PM, Rick Jones wrote:
> Thanks to some traces sent my way by Gavin McCullagh, and a comparison
> against the output of inMon's sflowtool, I can confidently say "Yes
> Virginia, there is an enterprise other than zero." Which means lest we
> start trying to decode somethin
On Apr 15, 2011, at 10:43 AM, Rick Jones wrote:
> So, does anyone know what sFlow enterprise ID 8800 might be all about?
http://www.iana.org/assignments/enterprise-numbers
"8800
YH Consulting
Robert Ellis
r.ellis&snet.net"
Google turns up nothing obvious.
-
This is the tcp
On Apr 25, 2011, at 3:08 AM, Laurent Debricon wrote:
> Hello,
>
> I am a bit confused and missing some knowledge about the kernel & libc :
>
> - I am trying to compile the latest libpcap 1.1.1 from github (
> https://github.com/mcr/libpcap/tree/libpcap_1.1 ) (I am trying to build
> because I ne
On Apr 26, 2011, at 3:45 AM, Ankith Agarwal wrote:
> I am trying to capture incoming packets in all the interfaces using
> pcap. I just wanted to know if there is a way of finding the interface(mac
> address or name) from which the packet has arrived??
>
>(As I am using the "any" interf
On Apr 26, 2011, at 8:48 PM, Ankith Agarwal wrote:
> Thanks for the reply. One more thing, if I am particular in getting the
> destination mac address, then is it better to run a pcap instance for each
> of the interfaces of the system??
For each of the *LAN* interfaces of the system. Not all
On Apr 27, 2011, at 12:07 PM, Michael Richardson wrote:
> I wrote some code C++, which I have placed under a do-anything license,
> which disguishes between EN10B and LINKTYPE_LINUX_SLL/DLT_LINUX_SLL.
I think there's another libpcap-based program out there that includes code to
distinguish betw
Checked into the trunk and 4.2 branches.
(Michael, do you want some regression tests, i.e. a sample capture or captures
and the corresponding tcpdump output?)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Apr 19, 2011, at 9:15 AM, Sam Roberts wrote:
> Does anybody here know what causes this? Am I calling libpcap
> incorrectly?
Yes:
>int snaplen = 0;
...
>pcap_t* cap = pcap_open_live(source, snaplen, promisc, to_ms, errbuf);
A snapshot length of 0, in libpcap, doesn't mean "
On Apr 28, 2011, at 6:42 PM, Andrej van der Zee wrote:
> Yes it does. Makes me wonder though why BPF was not extended with an "offset"
> keyword.
Why would an "offset" keyword be better in the filtering language than, say,
the "vlan" keyword it already has? You'd still have to do the same sor
On Apr 28, 2011, at 3:31 PM, Michael Richardson wrote:
> Unless someone says that there is something else out there, I'm going to
> write an (IPv4) pcap file anonymizer. I won't make the first version
> efficient.
The Internet Traffic Archive has some anonymizing software:
http://ita.
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 is one of the things wrong with PPI. pcap-ng makes th
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 pcap-ng
file" (pcap-ng isn't a link type, it's a file format).
> an
On May 5, 2011, at 8:29 AM, Jeff Garrett wrote:
> I want to be able to return from Step 2 and say "yes, sniffing was started
> successfully" or "no there was an error". I also want the sniffing to occur
> infinitely, or until I say stop (via pcap_breakloop() function).
> In addition, I want to b
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 pcap-ng?
> "The pcapng file format specification is still
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 the IDB which
> has a 16bit link type.
We could add an "enhanced IDB" with a 32-bit LinkType field.
> On
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 the IDB which
>> h
On May 5, 2011, at 5:20 PM, Darren Reed wrote:
> In the breakup where you were suggesting 10 bits that could be an
> organization ID, reserve "0" for the publicly recognised set
That's already done (implicitly, by virtue of those bits being 0 in existing
LINKTYPE_ values, and explicitly as wel
On May 8, 2011, at 8:26 AM, Zvika Meiseles wrote:
> I'm writing a program that uses packet capture via libpcap. It is built on
> multiple platforms and OS's, and runs fine on most of them. However, the
> combination of 32 bit binaries on a PPC64 Linux is failing (kernel
> 2.6.18-194.el5). 64 bit
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-63 dlt (DLT_*)
> 64-79 eth
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 general thrust
> of that is towards IP, t
On May 19, 2011, at 3:33 PM, Tim Sammut wrote:
> 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 May 19, 2011, at 7:43 PM, Guy Harris wrote:
> Ultimately, libpcap depends on the OS to provide raw packet capture and
> injection capabilities. If the Solaris networking stack allows a DLPI device
> bound to a VLAN interface to have packets handed to it with a full Ethernet
>
On Sep 6, 2010, at 11:45 AM, Doktor Bernd wrote:
> If I recompile with the HAVE_PACKET_RING stuff *not* commented out I get the
> bad performance as with the packaged versions from Ubuntu. So the performance
> drop is caused by that part of libpcap.
The packet-ring stuff has fixed-length slots
On Feb 8, 2011, at 12:53 AM, M. V. wrote:
> (this result is with libpcap-0.9.8. i got much worse
> results with libpcap-1.0+).
What snapshot length are you using? If, for example, this is on Ethernet, and
you're capturing with a snapshot length of 65535 (that's the default for newer
versions
On May 21, 2011, at 9:09 AM, barcaroller wrote:
> This may not be the right group, but I have a few BPF questions that I hope
> you can answer:
>
> * What is the maximum size of a BPF expression that can be passed to tcpdump
> and pcap_compile()?
pcap_compile() has no inherent limit; the only
On May 23, 2011, at 12:31 AM, ri...@happyleptic.org wrote:
> Which brings the question: how one could find out the MTU of a
> pcap_handle in order no to set caplen to 65535 ?
See pcap-linux.c in the top of the trunk or of the 1.2 branch. (Short answer:
SIOCGIFMTU, as in the iface_get_mtu() rou
On May 23, 2011, at 9:58 AM, Rick Jones wrote:
> Are there alignment differences for the different buffer sizes? For
> example, when one would use 1518, would one be better-off using 1520 to
> end on a 4 byte boundary and so begin on a 4 byte boundary if these
> buffers are carved one after the
On May 27, 2011, at 10:16 AM, Rick Jones wrote:
> Is this new libpcap going to be guaranteed that the underlying NIC HW
> isn't doing Large Receive Offload, or that the tracepoint in the stack
> is below any stack's attempt to do Generic Receive Offload?
If
1) your kernel supports the e
On May 27, 2011, at 5:20 AM, ri...@happyleptic.org wrote:
> If I understand this code correctly, in the next release of the libpcap
> if a client program ask for a capture length bigger than the MTU then
> the size allocated for each frame in the ring buffer will be sized down
> to avoid wasting
On May 27, 2011, at 10:54 AM, Rick Jones wrote:
> Excellent! And that makes me wonder if I should add similar offload
> checking (and reporting) code to netperf for its omni tests...
It's modeled after what ethtool does, so if your tests are wrapped in a shell
script, you could run ethtool on
On May 27, 2011, at 12:04 PM, Ben Greear wrote:
> Might want to add an extra 4 bytes for a possible VLAN header too.
prepare_tpacket_socket() sets the "reserve" for VLAN tag reconstruction to 4;
the "reserve", along with the maximum packet size, is involved in calculating
the frame slot size.
On May 31, 2011, at 7:36 AM, mold2010 wrote:
> I have a problem about libpcap ring buffer. The problem is the packets
> captured by libpcap1.1.1 which uses ring
> buffer are truncated.
Does this happen with the current top-of-tree libpcap (regardless of the
version of tcpdump with which it wa
On Jun 1, 2011, at 5:58 AM, mold2010 wrote:
> I tried libpcap1.1.1 release libpcap_1_1rel0 from
> https://github.com/mcr/libpcap. But found the same issue. Where can I get the
> 1.2 branch? Is it git hub: libpcap?
Both the 1.2 branch and the trunk can be found on bpf.tcpdump.org, and probably
On May 27, 2011, at 5:59 PM, Rick Jones wrote:
> The ifSpeed field of a generic interface counter in sFlow is 64 bits.
> The "overlay" definition in print-sflow.c is correct, but the actual
> extract for printing is using EXTRACT_32BITS rather than EXTRACT_64BITS,
> which leads to an incorrect re
On Jun 2, 2011, at 11:10 AM, Rick Jones wrote:
> Oops - I keep forgetting that all my compiles are 64 bit and so don't
> remember to check for such things.
You need an OS and build tools that make it easier to build stuff both ways
(and on which recent versions of libpcap and tcpdump default to
On Jun 2, 2011, at 11:48 PM, rajath kumara wrote:
> I am currently facing problems with understanding how port numbering
> occurs, with pcap_findalldevs().
What do you mean by "port numbering"? To what sort of ports, and what numbers
for them, are you referring here?
-
This is the tcpdump-work
On Jun 3, 2011, at 4:18 PM, Flavio Truzzi wrote:
>handle = pcap_open_offline(".cap",errbuff);
You're missing a
if (handle == NULL) {
report whatever error is in errbuff;
stop;
}
there. What happens after you add it?
-
This is the tcpdump
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)
seek(2)
write(2)
in pcap_dump_append(), and th
On Jun 1, 2011, at 12:43 PM, Michael Richardson wrote:
> So, you'd like to have pcap_reopen() then?
What would pcap_reopen() do? Mark's new API has a reasonable name given what
it does:
1) it returns a pcap_dumper_t, not a pcap_t, so it should have "dump"
in its name;
2) it
On Jun 3, 2011, at 4:18 PM, Flavio Truzzi wrote:
>pcap_compile(handle,&filtro,filtroexp.c_str(),0,0);
Where is filtro defined?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Checked into the trunk and 1.2 branches, with a change - ifrname points to a
location to which we copy an interface name, so it must be "char *", not "const
char *".-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Checked into the trunk and 1.2 branches.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Jun 4, 2011, at 11:23 AM, Flavio Truzzi wrote:
> In the class header
How is it defined? I.e., what is the statement that defines it?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Jun 6, 2011, at 10:39 AM, Flavio Truzzi wrote:
> Anyone?
As Darren Reed asked:
stack trace?
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Jun 6, 2011, at 11:23 AM, Raman Muthukrishnan wrote:
> We are using natty (linux 2.6.38) release, and we are facing the issue
> with pcap/bpf.h. You have addressed the issue in Jan 2011.
> But I am unable to find a release package with that fix. Do you know if
> one is available?
None are av
On Jun 6, 2011, at 3:02 PM, Martin T wrote:
> As you can see, every second I sent and received one frame. The
> question is, why is the frame, which I receive, 18 bytes longer than
> the one I sent? I mean what are those 144 0-bits at the end of the
> each frame back from the hardware loop?
Padd
On Jun 9, 2011, at 10:22 PM, rajath kumara wrote:
> I am working with ostinato for past 1 week, and found it great.
By "ostinato" do you mean
http://code.google.com/p/ostinato/
?
> currently i'm facing problems with port numbering, right now i have 6
> ports( 4 D-link ethernet adapter
On Jun 15, 2011, at 2:11 PM, Jeff Dean wrote:
> I tried installing the current tcpdump (because I needed the recent libpcap),
> and the configure step failed. The message was on checking the pcap_loop.
> My system has libpcap0.8 and libpcap0.8-dev installed.
...but you're not trying to build
On Jun 20, 2011, at 3:21 AM, Jakub Zawadzki wrote:
> After which follow any numbers of TLVs.
>
> (Structure From header)
>
> struct nfattr {
> uint16_t nfa_len; /** length, including 4 bytes of header, host-order
> **/
> uint16_t nfa_type; /* we use 15 bits for the type, and the highe
On Jun 20, 2011, at 3:21 AM, Jakub Zawadzki wrote:
> DLT_NFLOG starts with struct nfgenmsg header defined in
> ,
> which looks like (changed to stdint.h types + my comments in /** **/):
...
> Known types are defined in enum nfulnl_attr_type
> ()
Are these structures likely to remain
On Jun 22, 2011, at 10:48 AM, Alokat wrote:
> I have to save some pcap packets into a file for later analyzing.
>
> But I have some problems with creating the pcap file for it.
> Do I have to call first functions like fopen() to create a dump file?
No.
> Cause pcap_open_offline crashes if ther
On Jun 22, 2011, at 12:02 PM, Sanjay Sundaresan wrote:
> I am trying to evaluate how tcpdump performs with different libpcap versions
> and other packet capture libraries.
"Other packet capture libraries"? Meaning "alternative implementations of the
libpcap API" (the developers of which are en
On Jun 25, 2011, at 7:26 AM, alokat wrote:
> Is there a link-layer header type for ethernet and wlan available?
A *single* link-layer header type that can handle Ethernet frames and 802.11
frames in the *same* file, or separate link-layer header types for Ethernet and
802.11?-
This is the tcpd
On Jun 30, 2011, at 10:30 AM, V K wrote:
> And once packet is read using pcap_next(), I want to check that packet
> against all filters and mark the filter that matches the packet
>
> Is there a way one could compile multiple filters,
Have separate "struct bpf_program" structures for each filte
On Jul 6, 2011, at 10:38 AM, Scott, Keith L. wrote:
> The tcp.h file defines option 20 as 'Enhanced AUTH option' when I think it
> should be 'SCPS Capabilities'. I'd like to prepare and present a patch that
> processes at least the initial option 20 correctly. Does anyone know why 20
> was chos
On Jul 6, 2011, at 8:02 PM, Guy Harris wrote:
> According to
>
> http://www.iana.org/assignments/tcp-parameters/tcp-parameters.xml
>
> option 20 is, in fact, "SCPS Capabilities", which is presumably for the CCSDS
> Space Communications Protocol Specif
On Jul 8, 2011, at 12:46 AM, Folkert van Heusden wrote:
> Found the problem: I selected to not only not using yacc but not using
> bison as well. That gives weird results.
There's no "don't use yacc" configure option. Did you mean "flex" rather than
"yacc", or did you mean you specified not to
On Jul 9, 2011, at 4:41 PM, Alokat wrote:
> I'm wondering what is in the pcap_data (pcap file format) and what is not?
> Especially the timestamp ... is it just in the packet_header or in the
> packet_data too?
A pcap file starts with a header. Following the header are zero or more packet
reco
On Jul 9, 2011, at 7:01 PM, Alokat wrote:
> I'm wondering whats the difference between the pcap_packet and the payload?
What do you mean by "the payload"?
> I have seen that you can extract the payload like this:
>
> payload = (u_char *)(packet + SIZE_ETHERNET + size_ip + size_tcp);
That's th
On Jul 9, 2011, at 7:50 PM, Alokat wrote:
> Just for sure:
>
> *Ethernet packet*
>
> means a layer 2 (OSI / ISO model) packet right?
Yes.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Jul 9, 2011, at 6:52 PM, Sanjay Sundaresan wrote:
> Is the approximation because of the fact that NIC card generarates interrupt
> only after some number of packets arrive ?
Yes, that's one of the reasons. There's also the delay between the arrival of
the packet and the delivery of the inte
On Jul 10, 2011, at 9:16 AM, Jakub Zawadzki wrote:
> On Sat, Jul 09, 2011 at 10:37:55PM -0400, Michael Richardson wrote:
>> Just a general comment about patches:
>> - try not to include "configure" in your patch. From a developer
>>point of view, this is a generated file, and any patch it g
On Jul 10, 2011, at 11:07 AM, Geoffrey Sisson wrote:
> Is there any way to use BPF filters directly from tcpdump, i.e., supply
> tcpdump with a filter in BPF psuedo-machine format?
No, there isn't.
What are you trying to do? If it's a type of test that the filter language
doesn't support, the
On Jul 10, 2011, at 12:11 PM, Geoffrey Sisson wrote:
> It's for walking through some variable-length fields, and involves
> iteratively using values in the packet as offsets for successive loads.
...
> I don't think the filter language supports it,
The filter language is generally fair
On Jul 9, 2011, at 7:43 PM, Michael Richardson wrote:
> Up until somewhat recently, pcap methods were basically decided at
> compile time based upon the OS that one was on. There was little in the
> way of decisions in the code as to what was going to go on.
>
> We now have half-dozen methods o
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.
If the queries you're can be expressed in a syntax that could be added to the
libpcap filt
On Jul 12, 2011, at 8:26 PM, Flavio Truzzi wrote:
> Program received signal SIGABRT, Aborted.
> 0x75c57795 in raise () from /lib/libc.so.6
> (gdb) backtrace
> #0 0x75c57795 in raise () from /lib/libc.so.6
> #1 0x75c58c0b in abort () from /lib/libc.so.6
> #2 0x75
On Jun 28, 2011, at 10:05 AM, Gianluca Varenni wrote:
> A comment on this. In the last couple of years I've been actually thinking of
> dumping the rpcap support out of WinPcap. The reason is that such code is
> pretty much unmaintained, I struggle to have the patch compile on Windows
> every
On Jun 20, 2011, at 2:17 PM, Jakub Zawadzki wrote:
> On Mon, Jun 20, 2011 at 01:54:43PM -0700, Guy Harris wrote:
>> Are these structures likely to remain unchanged (other than new TLV types
>> being added,
>> and perhaps some TLVs changing length in a backwards-compatible
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 address is
On Jul 19, 2011, at 11:48 AM, nicolas roche wrote:
> I wondering if the number of packets loosed by the kernel may be added
> to the .pcap file header.
Not without assigning a new magic number for the new file format.
The pcap file header is of a fixed length, and if you add a new field without
On Jul 20, 2011, at 9:36 AM, Guy Harris wrote:
> The pcap file header is of a fixed length, and if you add a new field
> without, in effect, defining a new pcap format with a new magic number, you
> will end up with files that cannot be read by *any* programs that know the
> old
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 layer header for IPoIB on
> Linux is 12 b
On Jul 31, 2011, at 4:26 PM, ramkumar.parana...@gmail.com wrote:
> I have smtp traffic over ipv6 tunneled in ipv4. .ip->ipv6->tcp->smtp
> How can we set bpf to filter smtp in ipv6 in ipv4 tunnel traffic? I have
> tried with ip protochain 0x06 it is not working.
"ip protochain" doesn't suppor
On Jul 30, 2011, at 8:13 PM, Shmulik Bezalel wrote:
> Can you provide me New DLT_ for support Dialgic SIU M3UA trace (RFC 3332) ?
In that example, what's the lowest-layer protocol information in the packet?
M3UA (with SCTP, etc. not being in the trace)? If this is just regular
M3UA-over-SCTP
On Aug 4, 2011, at 2:11 AM, ． 嫒〆j々 wrote:
>First I use tcpdump to wirite the information to a file . like
> this,'tcpdump host 192.168.1.198 -w a.txt'.
"a.txt" is a bad name for the file, because it's *not* a text file!
> Arter about three seconds,I press the 'CTRL+C".
>Second, I use t
On Aug 2, 2011, at 4:42 PM, ramkumar p wrote:
> I am receiving warning that kernel filter failed: invalid argument when I
> enable ip6 protochain 6 to filter tcp traffic.
That warning means that the filter code generated for "ip6 protochain 6" was
rejected by the Linux kernel socket filter
On Aug 4, 2011, at 9:42 PM, ramkumar p wrote:
> If we specify "ip6 tcp port 25 " does this also filter the traffic with IPv6
> and extension headers like Routing, Fragment,hop and destination options
> etc... and tcp port 25
No.
> or it filters only ipv6 traffic without extension
> headers and
On Aug 4, 2011, at 10:46 PM, ramkumar.parana...@gmail.com wrote:
> Is there any way other than ip6 protochain 6 to filter ipv6 traffic with
> extension headers and tcp ?
Other than constructing your own BPF program (which would probably look like
what "ip6 protochain 6" generated, complete wit
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
>>
>
> How much
On Aug 8, 2011, at 6:22 PM, ramkumar.parana...@gmail.com wrote:
> Can we expect any packet drop by the kernel due to this warning?
If a lot of the traffic on your network isn't TCP, so that a lot of traffic
would've been discarded by the filter if it could've been run in the kernel,
more traff
On Aug 8, 2011, at 10:56 PM, ramkumar.parana...@gmail.com wrote:
> How much percentage of traffic in real world scenarios would these kind
> (ipv6 chain)of packets consist?
It depends on the scenario. If 50% of the traffic on your network is
TCP-over-IPv6 traffic, then 50%. :-)
Or, to put i
On Aug 14, 2011, at 11:15 AM, George Liang wrote:
> With below tcpdump command (in Ubuntu), I want to get multicast traffic, non
> udp, ..., but the filter "! udp" doesn't work. It gives output of UDP packets.
>
> sudo tcpdump -r tw 'ether[0] & 0xFF == 1' && ! udp && host 192.168.1.1 &&
> grea
On Aug 14, 2011, at 2:19 AM, Romain Francoise wrote:
> The 4.2.0rc1 beta tarball of tcpdump is missing the ppi.h file, so
> print-ppi.c doesn't build.
Checked into the trunk and 4.2 branches, along with a bunch of other fixes for
builds on other platforms, and a build fix for libpcap (trunk and
On Aug 16, 2011, at 5:10 AM, Doktor Bernd wrote:
> Two questions:
> - Do the two pcap_open_live() calls influence the hardware in anyway and have
> side effects on each other or are they bound to the handle and I can rely on
> the parameters I give to be set?
For LAN hardware, the "promisc" ar
On Aug 17, 2011, at 2:57 PM, Fabrizio Giordano wrote:
> Do you guys know where packets are timestamped in the kernel?
> I'm using a 2.6.32-131.4.1.el6.x86_64 kernel
I.e., Linux, of somewhat recent vintage.
The time stamp would be in the skb->tstamp field for the packet in question.
If the ada
On Aug 18, 2011, at 2:04 PM, Fabrizio Giordano wrote:
> Disabling net_timestamp() in net/core/dev.c was one of the first things I
> tried, among with disabling other "get_timestamp"-like functions. But
> apparently that's not where packes get timestamped.
It is, but it's not the *only* place w
On Aug 19, 2011, at 9:32 AM, Luca Deri wrote:
> This said, like Guy said I don't see why you want to disable them. You can
> use different/imprecise timestamp such as Linux epoch, but if you need pcap I
> believe you will also need timestamps.
If nothing he wants to do, and, if he's creating c
On Aug 21, 2011, at 12:40 PM, Martin T wrote:
> I would like to capture only the value of 108'th and 110'th bit in
> ICMP echo request packet. Those bits should reside in ICMP payload
> area. Is there a possibility in tcpdump to capture only specific bit?
What do you mean by "capture only specif
On Aug 30, 2011, at 7:29 AM, wrote:
> for our analysis product netANALYZER I would like to request a new
> link-layer header type value:
>
> LINKTYPE_NETANALYZER
>
> DLT_NETANALYZER
>
> Description: "Hilscher netANALYZER link-layer type to provide additional
> information for encapsulated Eth
On Aug 30, 2011, at 7:33 AM, wrote:
> for our analysis product netANALYZER I would like to request a new
> link-layer header type value:
>
> LINKTYPE_NETANALYZER
>
> DLT_NETANALYZER
>
> Description: "Hilscher netANALYZER link-layer type to provide additional
> information for encapsulated Eth
On Jul 13, 2011, at 7:40 PM, Guy Harris wrote:
>
> On Jun 20, 2011, at 2:17 PM, Jakub Zawadzki wrote:
>
>> On Mon, Jun 20, 2011 at 01:54:43PM -0700, Guy Harris wrote:
>>> Are these structures likely to remain unchanged (other than new TLV types
>>> being
On Aug 27, 2011, at 1:55 PM, Michael Richardson wrote:
> Patch applied.
...and propagated to the 4.2 branch.
(BTW, Michael and I are both members of tcpdump-workers, so there's no need to
CC us on mail to tcpdump-workers.)-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to u
On Jun 20, 2011, at 3:21 AM, Jakub Zawadzki wrote:
> DLT_NFLOG starts with struct nfgenmsg header defined in
> ,
> which looks like (changed to stdint.h types + my comments in /** **/):
>
> struct nfgenmsg {
> uint8_t nfgen_family; /* AF_xxx */
>/** Linux AF-VALUES, AF_
On Aug 31, 2011, at 4:03 AM,
wrote:
> Unfortunately there is no document online, but the structure is quite simple,
> it's just a 32-bit value containing some bit fields:
So a packet has a 32-bit value, followed by the Ethernet header, starting with
the destination MAC address?
> uiGpio:
>
1501 - 1600 of 2521 matches
Mail list logo
