On Feb 1, 2012, at 11:12 AM, Guy Harris wrote:
> so the mmap interface should work between a 64-bit kernel and 32-bit userland
> *if* the kernel supports TPACKET_V2, as libpcap should choose TPACKET_V2
> rather than TPACKET_V1 if TPACKET_V2 is supported.
I tried building 32-bit ve
On Feb 1, 2012, at 3:00 PM, Graeme Sheppard wrote:
> Yes my remote system shares the same kernel as the other customers.
> Calling it a 32 bit guest isn't accurate. Sorry about that. Subject title
> changed.
>
> The kernel I've been told is Red Hat derived,
>
> 2.6.18-194.17.1.el5.028stab070.7
On Feb 1, 2012, at 7:12 PM, Firdaus Tahir wrote:
> Hye there... i'm having a trouble to configure tcpdump on Ubuntu 11. Any
> help would be appreciated.
There's something wrong with your libpcap.
If you built libpcap from source, I would have to see
1) the config.log for libpcap
and
On Feb 2, 2012, at 9:41 AM, Guy Martin wrote:
> Do you have an ETA as of when the next release with this addition will
> be available ?
No, but note that the link-layer type value is available for use outside of
libpcap already.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.c
On Feb 4, 2012, at 12:02 PM, Prashant Batra (prbatra) wrote:
> I want to use "pcap_compile" to get a bpf filter from a string. And then
> I want to use the filter in the form of sock_filter to set as a socket
> option to capture the packets specified by the filter. I want to receive
> the filter
On Feb 4, 2012, at 8:18 PM, Prashant Batra (prbatra) wrote:
> [Prashant] Thanks, but I used the same device to check this.
Then you must have disabled the optimizer, or used different versions of
libpcap, or something.
What was the exact tcpdump command you used with "-d" - just "tcpdump -d",
On Feb 8, 2012, at 3:26 AM, mike wakerly wrote:
> I'd like to request a new encapsulation type for NFC Logical Link
> Control Protocol (LLCP) [1].
...
> A new encapsulation type is needed for reasons similar to i2c and
> bluetooth.
No, it's needed because no existing link-layer header
On Feb 8, 2012, at 8:28 PM, Gianluca Varenni wrote:
> We've run some more tests, and it looks like the problem is (obviously) not
> just with a snaplen of 1500.
>
> Here is what we found (using packets bigger than the snaplen):
>
> Snaplen = 59+16n -> caplen=58+16n
> Snaplen = 60+16n -> capl
On Feb 9, 2012, at 5:05 AM, David Laight wrote:
> There is a report on one of the netbsd lists (might have
> been a developer-only list) that tcpdump (etc) aren't
> working on 64bit netbsd platforms.
>
> IIRC it had something to do with 'struct timeval' and friends.
>
> I'm not sure of the full
On Feb 9, 2012, at 7:04 PM, Guy Harris wrote:
> *However*, that's not the only place where structures involving times get
> passed between the kernel and userland. They *also* get passed in the
> BIOCGRTIMEOUT and BIOCSRTIMEOUT ioctls, the argument to which is a pointer to
>
On Feb 2, 2012, at 9:45 AM, Guy Harris wrote:
> On Feb 2, 2012, at 9:41 AM, Guy Martin wrote:
>
>> Do you have an ETA as of when the next release with this addition will
>> be available ?
>
> No, but note that the link-layer type value is available for use outsi
On Feb 14, 2012, at 6:09 AM, Moshe Matitya wrote:
> Yes, we built libpcap 1.2.1 from the distribution tarball.
...so it's presumably 64-bit.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Feb 15, 2012, at 7:13 PM, Dhenyz Shady wrote:
> There's the Config.log content:
If you configured and built libpcap from source, please send us the config.log
file and the build output from libpcap. There's something wrong with libpcap,
but, without that information, we can't determine wha
On Feb 23, 2012, at 5:58 PM, Michael Richardson wrote:
>
>> "Paul" == Paul Sheer writes:
>Paul> Actually I found the answer to this, as below.
>
>Paul> Would anyone consider adding this support to libpcap: i.e. a
>Paul> new member within pcap_opt ?
>
> I think that it should p
On Feb 23, 2012, at 7:58 PM, Paul Sheer wrote:
>>>
>>>Paul> Would anyone consider adding this support to libpcap: i.e. a
>>>Paul> new member within pcap_opt ?
>>>
>>> I think that it should probably just be on.
>>> Principal of least surprise.
>>
>> Here's why PACKET_MR_ALLMULTI is cur
On Feb 23, 2012, at 9:23 AM, Andriy Tylychko wrote:
> Yeah, seems you're right. After upgrading to libpcap 1.2.1 I see failed
> sends only on packets with size of 1518 bytes, before that (with default
> libpcap 0.8 from Debian repository) I saw packets of >2000 bytes.
>
> Why I cannot send such
On Feb 27, 2012, at 9:40 AM, Nuno Martins wrote:
> I'm having a trouble to find the purpose of pid identifier in grammar.y
> file. #line 398
>
> This identifier is related to what protocol ?
>
> I'm supposing that this pid is not related in any way with processes (like
> pid process identifier)
On Feb 13, 2012, at 12:58 PM, mike wakerly wrote:
> No problem. Let's go with more condensed version of my example:
> struct llcp_phdr {
>guint8 adapter; /* Adapter number, typically 0. */
>guint8 flags;/* Direction flag (TX/RX) and future use. */
> };
>
> The least significant b
On Feb 28, 2012, at 3:05 AM, Stefan Hajnoczi wrote:
> The QEMU system emulator now supports the virtio-scsi SCSI transport
> for efficient virtualized SCSI I/O. I would like to support
> virtio-scsi debugging and analysis with pcap.
>
> The pcap data will include the virtio buffers containing S
On Mar 1, 2012, at 3:39 PM, Mark W. Jeanmougin wrote:
> On Thu, Mar 1, 2012 at 11:55, Charles DeVoe wrote:
>> I have installed an X520 card with the latest driver ixgbe 3.8. The
>> operating systems is CentOS 5.7. When doing an ifconfig I see receive
>> packets. I also see packets when I do
On Mar 3, 2012, at 9:11 AM, MacPir wrote:
> I have some problem with install tcpdump latest version .
> I have installed libpcap 1.2.1 form tcpdump site and when I want install
> tcpdump , I can't go trough configure stage .
> I include config.log file
As in all these "pcap_parse not found" cas
On Mar 3, 2012, at 8:51 AM, Romain Francoise wrote:
> Simon Ruderich found that tcpdump's configure script
> loses the value of CPPFLAGS because the save/restore code has a typo.
> He provided the following patch to fix the problem:
Selecting and copying the patch and doing
pbpaste | p
On Mar 4, 2012, at 4:23 AM, Romain Francoise wrote:
> Guy Harris writes:
>
>> Checked into the trunk and 4.2 branches.
>
> Thanks, but I should have made it more explicit that the patch fixes *two*
> typos: 'savedppflags' vs. 'savedcppflags' and '
On Mar 6, 2012, at 3:18 AM, Yohannes Affandy Siregar wrote:
> Can I run program using libpcap (such as tcpdump) in Embedded Linux
> and Android to capture wireless packet?
If the Linux kernel on the machine in question has PF_PACKET socket support
compiled into it (I think it's configured in by
On Mar 3, 2012, at 3:38 AM, Stefan Hajnoczi wrote:
> There are SCSI commands and responses. Commands and responses are
> separate pcap packets because there can be multiple outstanding
> commands to multiple targets/LUNs.
>
> From the spec, commands have the following layout:
>
>u8 lun[8];
On Mar 3, 2012, at 3:38 AM, Stefan Hajnoczi wrote:
> Responses have the following layout:
>
>u32 sense_len;
>u32 residual;
>u16 status_qualifier;
>u8 status;
>u8 response;
>u8 sense[sense_size];
>char datain[];
Are "sense_len" and "sense_size" the same thing - i.e.,
On Mar 6, 2012, at 11:45 AM, Stefan Hajnoczi wrote:
> On Tue, Mar 6, 2012 at 7:28 PM, Guy Harris wrote:
>
>> Are "sense_len" and "sense_size" the same thing - i.e., is sense_len the
>> size of the sense data?
>
> No, sense_size is a fixed value
On Mar 8, 2012, at 4:47 PM, abhinav narain wrote:
> I have seen tcpdump,wireshark both just print packet contents till mac
> header in monitor mode.
> In case of normal wireless interfaces (wlan0), they follow a different
> execution path.
No, it's not based on the type of interface, or the mode
On Mar 8, 2012, at 6:34 PM, Guy Harris wrote:
>
> On Mar 8, 2012, at 4:47 PM, abhinav narain wrote:
>
>> Can someone tell me what should I expect in the the frame after
>> ieee80211_hdr (which comes after the radiotap header) ?
>
> Yes.
By the way, note that the
On Mar 8, 2012, at 6:53 PM, abhinav narain wrote:
> Since I am capturing every frame in monitor mode, I would like to see the
> packet type : arp/ip ... and is it tcp/udp type.
> But when I do the following, I don't get any output
You *won't* get any output if the packets are encrypted, and, if
On Mar 9, 2012, at 9:24 AM, António Richard Silva wrote:
> Hi, I am having problems capturing some packets using tcpdump.
> At the application level I am sending and receiving packets but tcpdump
> does not capture any data.
> There are no packets dropped by the kernel
> I have tried reducing the
On Mar 8, 2012, at 4:47 PM, abhinav narain wrote:
> hi,
> I have seen tcpdump,wireshark both just print packet contents till mac
> header in monitor mode.
> In case of normal wireless interfaces (wlan0), they follow a different
> execution path.
> Can someone tell me what should I expect in the t
On Mar 10, 2012, at 10:18 AM, abhinav narain wrote:
> I believe, the data packets destined for my AP, will be decrypted by the
> hardware itself
I *don't* believe that if the hardware is running in monitor mode.
> In any case, when I get them in userland, they should be unencrypted. right?
Wr
On Mar 10, 2012, at 6:18 AM, jedge wrote:
> When using the (-w) option in conjunction with the (-l) option,
Use it with the -U option instead:
$ man tcpdump
...
-U Make output saved via the -w option ``packet-buffered''; i.e.,
as each packet is saved, it wil
On Apr 18, 2012, at 3:05 PM, Sam Roberts wrote:
> For what its worth, the last message I saw was on Mar 13th, thought I
> have 2 or 3 more messages than I can see on
> http://news.gmane.org/gmane.network.tcpdump.devel
>
> I'm CCing tcpdump-workers, I'll see if I have the problem, too.
For what
On Apr 25, 2012, at 5:12 PM, Andrew Daviel wrote:
> I just built libpcap-1.2.1 and tcpdump-4.2.1 on Centos 6.2.
>
> If I read a pcap-ng capture file from the Hone project, or one written by
> Wireshark 1.7.2 on XP with the default filter, I get a message "snaplen of 0
> rejects all packets" an
On Mar 10, 2012, at 12:01 PM, jedge wrote:
> I suppose if you don't HAVE_PCAP_DUMP_FLUSH
If the libpcap with which tcpdump is built is a version released at the same
time, or after, the time that version of tcpdump is released, it'll have
pcap_dump_flush(). A version of tcpdump with -U su
On Mar 26, 2012, at 2:17 AM, Cong Meng wrote:
> I drafted some description. Should I make an HTML version?
Yes, matching the style of the other ones, once the issues that are raised are
resolved.
(Of course, for the diagrams, we just cheat and use .)
> LINKTYPE_VIRTIO_SCSI
>
> Packet structu
On May 10, 2012, at 7:43 AM, Wiener Schnitzel wrote:
> I need to perform packet sniffing on several interfaces at the same time.
Are you processing packets from each interface independently, so that a packet
on interface A is not looked at when processing packets from interface B, or
are you p
On May 27, 2012, at 7:40 PM, Ajith Adapa wrote:
> Now if I build tcpdump it is linked with shared libraries of libpcap and
> others as shown below. Is it possible for me to create tcpdump binary
> linking up with all static libraries ?
You would have to modify the Makefile by hand to statically
On May 27, 2012, at 11:31 PM, Artur Kielak wrote:
> I think than You run older version tcpdump:
You can't use ldd to find out the version of tcpdump; you have to run "tcpdump
-h" to get the version of tcpdump.
> This is the answer:
> libpcap.so.0.8 => /usr/lib/libpcap.so.0.8 (0x002c9000)
> Lin
On May 28, 2012, at 2:28 AM, Ajith Adapa wrote:
> I am currently building tcpdump on Ubuntu
Given the "libpcap.so.0.8", I suspected you were either using Debian or a
Debian derivative such as Ubuntu.
> $ ./tcpdump -h
> tcpdump version 4.4.0-PRE_GIT_2012_05_28
OK, that's a *VERY* recent versio
On May 28, 2012, at 8:01 AM, Ajith Adapa wrote:
> I getting following error. Seems directly using static flag wont solve
>
> /Ajith/LABS/submission/tcpdump/./addrtoname.c:728: warning: Using
> 'getservent' in statically linked applications requires at runtime the
> shared libraries from the glib
On Jun 7, 2012, at 6:36 AM, Michael Richardson wrote:
> This message never went out properly.
> I can either push 4.3 out this weekend, or wait until the end of July
> and roll a new release as there is lots of new code.
> (Is there a debian, ubuntu, fedora, *BSD code freeze that would care?)
(P
On Jun 25, 2012, at 9:49 PM, Mamatha wrote:
> I am implementing one application using libpcap but I am unble to
> use pcap_inject is failing it showing undefined reference to this
> function...I searched header file also The function is not avalible..
It *isn't* available in libpcap prior
On Jun 27, 2012, at 12:24 AM, ri...@happyleptic.org wrote:
> I'd like to be able to read a pcap in a loop.
>
> There are two options I know of:
>
> - either close the pcap_handle when the pcap_dispatch/pcap_next function
> returns the error-code for signaling end of file, and reopen it.
>
> -
On Jun 22, 2012, at 5:26 PM, Esteban Pellegrino wrote:
> Name of the proyect: libcrafter
>
> Libcrafter is a high level library for C++ designed to make easier the
> creation and decoding of network packets. It is able to craft or decode
> packets of most common network protocols, send them on t
On Jun 21, 2012, at 6:59 AM, Romain Francoise wrote:
> The LLDP printer doesn't show the packet protocol unless -v is used,
> which results in pretty useless output lines where only the timestamp is
> present. Make sure we include the default protocol+length output even in
> default mode.
Checke
On Jun 6, 2012, at 6:57 AM, manish nimse wrote:
> i want to create create tcp/ip packet . i want additional information
> about the creation of packet .
> so please send me the api's required .
libpcap has no APIs for that.
However, there are other libraries that do, such as
http://cod
On Jun 3, 2012, at 12:33 PM, Giovanni wrote:
> I tried to build libpcap with
>
> ./configure --without-flex --without-bison
> the problem is always the same.
Have you tried building with just
./configure
(so that it uses Flex and Bison) and if you build with
./configure --wi
On Jun 30, 2012, at 12:47 PM, Guy Harris wrote:
> On Jun 21, 2012, at 6:59 AM, Romain Francoise wrote:
>
>> The LLDP printer doesn't show the packet protocol unless -v is used,
>> which results in pretty useless output lines where only the timestamp is
>> pres
On Jul 11, 2012, at 4:36 AM, Geoffrey Bugniot wrote:
> I have a board with a PowerPC 8270 with an embedded Linux (2.6.39.4). On that
> platform, I use tcpdump and a program wich use libcap (4.1.1). Cross compiling
> is done with the ELDK 5.1 toolchain.
>
> When I launch tcpdump, it works fine. T
On Aug 7, 2012, at 7:53 AM, Joseph Freemaker wrote:
> Using libpcap 1.3.0.
>
> libpcap had a patch applied in October of 2011 for the Solaris Zone.
>
> However when libpcap is used with a C program (that is very similar to
> tcpdump - makes the same calls) that is run in a Solaris Zone (Solari
On Sep 3, 2012, at 2:35 PM, Michael Richardson wrote:
> okay, so as I understand it, basically you have keeping the name that
> was in the library in a structure in lib cap.
No, the name was never in a library; "struct canusb_t" is a structure in the
pcap-canusb-linux.c module. The field was r
On Sep 3, 2012, at 7:13 PM, Michael Richardson wrote:
> Wesley, is fopen("/dev/stdin") really the most portal
(Presumably "portable".)
> way to get a reference to stein?
Definitely not - it will probably work on most modern UN*Xes (Linux, *BSD/OS X,
and Solaris; I don't know about HP-UX or AI
On Sep 4, 2012, at 3:11 AM, David Laight wrote:
> On windows you can't pass 'FILE *' into shared libraries,
> they are likely to have their own copies of the stdio
> libraries - with different FILE structures.
> (eg if one part is compiled with debug enabled).
In this patch, the library into whi
On Sep 5, 2012, at 2:39 PM, George Bakos wrote:
> I don't see any discussion regarding adding modular operations to
> pcap, i.e. "header[offset:width] % 4 != 0". I've put together a patch
> that compiles & honors that (at least on the few systems I've tried),
Does it work if the right-hand side
On Sep 6, 2012, at 12:36 AM, George Bakos wrote:
> $ tcpdump -nvr /tmp/DG2-test2 '(ip[2:2] - 20) % 5 != 0 && ip[6] &
> 0x20 = 0x20'
>
> reading from file /tmp/DG2-test2, link-type EN10MB (Ethernet)
> 19:01:51.270202 IP (tos 0x0, ttl 64, id 1, offset 40, flags [+],
> proto ICMP (1), length 61)
On Sep 10, 2012, at 3:41 AM, "David Laight" wrote:
>>> What about the other OS - eg all the BSDs?
>>> I had a vague idea that BPF was supposed to be reasonable portable.
>>
>> Yes, does it mean BPF is frozen ?
>>
>> Or is BSD so hard to update these days ?
>
> Not really - but it some other p
On Oct 13, 2012, at 8:39 AM, Marc Abramowitz wrote:
> This actually smells like a problem in SmartOS's packaging, as I seem to have
> ended up with a mixture of 32-bit and 64-bit stuff and that seems like the
> problem,
Given that the error is
configure:5844: gcc -o conftest -g -O2 conftes
On Oct 14, 2012, at 1:15 AM, Marc Abramowitz wrote:
> This is strange, because the tests pass fine on my OS X 10.7.4 machine but I
> got one failure on my OS X 10.6.8 machine:
>
> https://gist.github.com/3887919
I presume that's the entire file, which would mean that the result produced for
On Oct 14, 2012, at 4:25 PM, Marc Abramowitz wrote:
> marc@hyperion:~/dev/testing/tcpdump/tests
> 16:02:52 $ tcpdump -t -r e1000g.pcap
> reading from file e1000g.pcap, link-type 226
> tcpdump: unknown data link type 226
That's LINKTYPE_IPNET, a/k/a Solaris ipnet (when I first saw "e1000g" I wa
On Oct 20, 2012, at 7:27 AM, David Smith wrote:
> I have successfully compiled and installed tcpdump using libcap_1.2.2 (1.3.0
> misbehaved in another application).
What sort of misbehavior did you see with 1.3.0?
> My purpose is to understand interaction with the wireless device. I am
> cu
On Oct 22, 2012, at 2:36 PM, Michael Downey wrote:
> I am having trouble fully understanding what exactly a '.' stands for when
> following another flag in the tcpdump output, for example [S.] The reason why
> I am having trouble with this, is due to separate versions of the man page
> explai
On Oct 31, 2012, at 2:50 PM, Ani Sinha wrote:
> pcap files that already have the tags reinsrted should work with
> current filter code. However for live traffic, one has to get the tags
> from CMSG() and then reinsert it back to the packet for the current
> filter to work.
*Somebody* has to do
On Oct 31, 2012, at 3:35 PM, Ani Sinha wrote:
> yes but if the packet is passed to the filter within libpcap (when we
> are not using the kernel filter) before the reinsertion,
...that would be a bug.
Currently, that bug doesn't exist in the recvfrom() code path, but *does*
appear to exist in
On Nov 5, 2012, at 11:03 AM, abhinav narain wrote:
> I just checked the two mechanism :
> (1) Using mmap to fetch packets from kernel to userspace
> (2) Using recvfrom() call to fetch packets
>
> I see top reports
> (1) 34% memory 20% cpu usage
> (2) 21% memory 7% cpu usage !
>
> I wanted
On Nov 11, 2012, at 4:53 AM, Oren Kladnitsky wrote:
> I'd like to request a new DLT/LINKTYPE value for Infiniband traffic
> (DLT_INFINIBAND).
> Infiniband spec is available at:
> http://members.infinibandta.org/kwspub/spec/V1r1_2_1.Release_12062007.zip
> (registration required).
> See "Chapter
On Nov 7, 2012, at 10:28 AM, abhinav narain wrote:
> I wanted to know why is MSG_PEEK used in the recv() call in mmap code
> and not recvfrom() with MSG_TRUNC flag.
> The reason i am asking is .. because I see my code takes a lot of CPU which
> is due to more looping, I suppose.
> The flag des
On Nov 11, 2012, at 2:55 PM, barcaroller wrote:
> The libpcap C API provides functions for writing (pcap_dump) and reading
> (pcap_next) a PCAP file. I have two questions:
>
> - How do I remove a packet from a PCAP file using the libpcap C API?
You can't remove a packet from an existing file
On Nov 5, 2012, at 11:03 AM, abhinav narain wrote:
> I just checked the two mechanism :
> (1) Using mmap to fetch packets from kernel to userspace
> (2) Using recvfrom() call to fetch packets
>
> I see top reports
> (1) 34% memory 20% cpu usage
> (2) 21% memory 7% cpu usage !
>
> I wanted a p
On Nov 11, 2012, at 5:44 PM, barcaroller wrote:
> On 2012-11-11 23:27:00 +0000, Guy Harris said:
>
>> They could, in principle, be appended to, but that can't be done with the
>> existing APIs - you'd need an "open for appending" call, which would, un
On Nov 24, 2012, at 6:09 AM, Michael Tuexen
wrote:
> could you register a DLT for SCTP? It would be similar to
> LINKTYPE_IPV4 / DLT_IPV4 or LINKTYPE_IPV6 / DLT_IPV6,
> just covering the SCTP packet without any lower layer.
No IPv4 or IPv6 headers, so no identification of the IP-layer endpoint
On Nov 24, 2012, at 9:50 PM, abhinav narain wrote:
> hi,
> I am looking for timestamp provided by pcap header and later used by
> tcpdump.
> Seems like some of wireless drivers do not provide the mac tsf timestamp.
> I can't figure out the timestamp meaning in pcap.
> Its surely not the time wh
On Nov 26, 2012, at 7:17 AM, Michael Richardson wrote:
>
>> "Jaylen" == Jaylen VanOrden writes:
>Jaylen> Attached config.log
>
> The list has to remove non-text attachments to keep things sane against
> trojans that are sending virii/trojans from legit email addresses.
> So, please i
On Nov 26, 2012, at 12:58 PM, abhinav narain wrote:
> @Guy,
> Basically, I was adding my own header (instead of radiotap) in kernel and
> processing it in userland with my own code. Basically I wrote my own pcap
> for that.
For your own radio header, what you'd need would be:
your own
On Nov 26, 2012, at 12:56 AM, Cheng Cheng wrote:
> In order to get the accurate receiving timestamp of a packet on the NIC
> device not supporting hardware timestamping, can I modify the NIC device
> driver code to update skb_shared_hwtstamp struct by using TSC in RX routine?
Well, that's arg
On Nov 24, 2012, at 12:49 PM, Michael Tuexen
wrote:
> This is what we want to dump to a file when running SCTP over DTLS over UDP,
> after DTLS has decrypted the packet. This stack will be using for RTCWeb
> between Web Browsers. For debugging purposes of SCTP related issues, we
> don't need lo
On Nov 27, 2012, at 1:10 PM, Sam Roberts wrote:
> We'd like to distinguish between ethernet frames received on an
> interface, and sent, and due to the nature of the traffic, we can't
> rely on the addressing information in the packets.
>
> Currently, we do this with an external tap, that gener
On Oct 31, 2012, at 1:59 PM, Paul Sheer wrote:
> I notice you guys have in scan_sys_class_net() -
>
> if (ent->d_type == DT_DIR) continue;
>
> I believe this should be -
>
> if (!strcmp(ent->d_name, ".") || !strcmp(ent->d_name, "..") ||
Yes.
> !strcmp(ent->d_name, "bonding_masters")) contin
On Dec 2, 2012, at 6:54 PM, Paul Sheer wrote:
>>> !strcmp(ent->d_name, "bonding_masters")) continue;
>>
>> No.
>>
>> That wires in a particular name, and when the *next* weird file gets added
>> by some future kernel revision, we won't handle it, and would end up wiring
>> in another name, l
On Dec 3, 2012, at 10:33 AM, Paul Sheer wrote:
> works for me
Ok, good.
Thanks for noting the "subsystem in older kernels" issue - looking for ifindex
is a better idea; in addition to dating back to 2.6.0, it's also more strongly
associated with being a network interface.
(What we really wa
On Dec 5, 2012, at 2:56 PM, Paul Sheer wrote:
> I would like to capture on all interfaces, but I would also like to know,
> with each packet, what interface it arrived on and left out of.
>
> This information is contained within the Linux kernel skbuff.
>
> But pcap does not see it.
What's r
On Dec 10, 2012, at 9:50 AM, Kaya Saman wrote:
> I'm trying to build libpcap 1.3.0 on my Sun Fire V210 running OpenBSD 5.2
> however, I keep getting errors??
>
> The configuration script doesn't come up with anything claiming to be an error
That's because there isn't anything on the system th
On Dec 17, 2012, at 1:50 AM, "David Laight" wrote:
> How are you going to tell whether a feature is present in a non-Linux
> kernel ?
The Linux memory-mapped capture mechanism is not present in a non-Linux kernel,
so all the libpcap work involved here would, if necessary on other platforms,
h
On Dec 19, 2012, at 1:27 PM, Stuart Werbner wrote:
> I am requesting a new LINKTYPE_ (LINKTYPE_IB) value for IP over Infiniband
> be reserved, in order to properly support this protocol within tcpdump and
> libpcap for upcoming AIX kernel releases.
So you're using LINKTYPE_ values, rather than
On Dec 28, 2012, at 1:15 PM, Maik Jäkel wrote:
> for 2 days I'm now searching for the appropriate position to insert 5 lines
> of code:
Insert into tcpdump or insert into some other program?
> I'm trying to print out a current timestamp with nanosecond accuracy between
> every printed packet
On Dec 28, 2012, at 3:14 PM, Maik Jäkel wrote:
> My target environment is android with a 2.6.35.14-kernel.
> I realize that the timestamp is taken "a long time" after the reception of
> the packet. I didn't know a better way, though and hoped that the execution
> time between the reception of
On Dec 28, 2012, at 3:53 PM, Guy Harris wrote:
> I would suggest, instead, that you:
>
> modify *libpcap*, so that it returns nanosecond-resolution time stamps;
I would also suggest that you modify it to write out pcap files with a
different magic number, so that, if you
On Jan 8, 2013, at 1:58 PM, Derek Cole wrote:
> I am not sure this is the right mailing list for this or not,
It is. "tcpdump-workers" is actually a combination of:
"tcpdump-users" - users of tcpdump;
"tcpdump-workers" - developers of tcpdump;
"libpcap-users" - "user
On Jan 8, 2013, at 7:08 PM, Derek Cole wrote:
> Thanks for the detailed response. You are correct that was my stack overflow
> post. At the time I posted that I didn't have as clear of an idea of the
> problem, so, casting a wide net.
>
>> Valgrind is complaining about several uninitialized
On Jan 9, 2013, at 1:29 PM, Derek Cole wrote:
> Well, after tracking down some of the structures being used in the ioctl
> arguments, and memset() them to zero, I think all of the errors went away
> without the need to write any additional wrappers other than the pselect()
> wrapper. Most of
On Jan 9, 2013, at 1:34 PM, Guy Harris wrote:
> On Jan 9, 2013, at 1:29 PM, Derek Cole wrote:
>
>> I am not sure whether that is a worthwhile check-in to make for pcap or not.
>
> I'd rather fix valgrind. I'll see if I can beat it into working on Mountain
>
On Jan 10, 2013, at 7:22 AM, Derek Cole wrote:
> Can you provide a link where I can see the changes you made?
The bug I filed against Valgrind:
https://bugs.kde.org/show_bug.cgi?id=312989
has a patch.
> I thought valgrind had a source code repo viewer for latest patches and stuff
>
On Jan 29, 2013, at 12:54 PM, Wenfei Wu wrote:
> When using tcpdump capture trace, we can add filter expressions ( in a
> form of primitive [and/or primitive] ).
> I want to know how the packets are parsed and matched to this filter
> expression. Is there some intermediate data structure for
On Jan 29, 2013, at 2:24 PM, Wenfei Wu wrote:
> Thanks, this is really helpful.
> On Tue, Jan 29, 2013 at 3:21 PM, Guy Harris wrote:
> er, so you can't check the TCP ports in tho
I'm not sure whether you intended to quote that part of my response, but, if
you did, because
On Feb 1, 2013, at 4:49 AM, Bill Fenner wrote:
> We have wanted to fix the vlan support ever since it was added.
The "vlan" keyword serves two purposes:
1) matching VLAN-encapsulated packets or VLAN-encapsulated packets on a
particular VLAN;
2) handling the extra MAC-layer he
On Jan 24, 2013, at 2:43 AM, ri...@happyleptic.org wrote:
> I have a set of pcap files which packets are not stricly ordered according to
> packet timestamp.
> I'd like a tool to reorder such packets according to timestamp (without
> altering packet timestamp
> by by swapping packets in the fil
On Feb 21, 2013, at 2:15 AM, Romain Francoise wrote:
> Michael Richardson writes:
>
>> DISTRO MANAGERS: I think that the libusb should be disabled in libpcap,
>> otherwise ELF shared library systems will break, as the application
>> won't know to link libusb in.
>
> Hmm. It seems to me that p
On Mar 15, 2013, at 9:07 AM, wen lui wrote:
> I used libpcap function pcap_next() to capture some tcp packets I checked
> the bytes of the captured packets and notice that the ethernet and ip
> header of packets are distorted, in a mess with a lot 0's but the TCP
> header is fine
>
> what are p
1701 - 1800 of 2521 matches
Mail list logo
