On Sep 2, 2011, at 12:53 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?
>
On Sep 5, 2011, at 1:37 AM,
wrote:
> Our device does not use the snapshot length feature. So I think this
> would only be a theoretical problem.
Wireshark's editcap program can be used to impose an *ex post facto* snapshot
on packets; arguably, tcpdump should do so as well, if you do somethi
On Sep 2, 2011, at 12:53 AM,
wrote:
>>> uiTransparent:
>>> 0: normal Ethernet mode
>>> 1: transparent capture mode
>>
>> Is there any difference between the packets in those two modes?
>
> Yes, this will include the preamble/SFD as supplied by the Ethernet-PHY.
> This is used as low-level an
On Aug 14, 2011, at 6:51 AM, Tek Bahadur Limbu wrote:
> I need to run TCPDUMP on a Linux bridge with multiple network interfaces.
> However, instead of using a shell, I need to run it over a web interface.
Tcpdump can do a number of things - it can capture traffic and dissect and
print it, or i
On Sep 13, 2011, at 12:47 PM, Erik Hjelmvik wrote:
> What do you guys think? Would it be relevant to implement a
> Pcap-over-IP client in tcpdump?
It sounds as if you mean "pcap-over-IP server" here, in that tcpdump would send
network traffic over the wire to a client, such as {tcpdump, Wiresha
On Sep 6, 2011, at 11:01 PM,
wrote:
>
>> Will there ever be both "normal mode" and "transparent mode" packets
> in
>> the same capture file? If not, perhaps transparent mode should have
> its
>> own link-layer type value.
>
> The two modes will never be mixed up in one file. Having a second
On Sep 13, 2011, at 11:16 PM, Erik Hjelmvik wrote:
> The reason for why it would be great to have in tcpdump is because
> tcpdump is an ubiquitous tool that is available practically everywere.
tcpdump-with-pcap-over-IP-support is a non-existent tool that is available
nowhere. :-)
If the tcpdum
On Sep 13, 2011, at 8:47 PM, Jon Schipp wrote:
> I have a few questions, hopefully someone can set me straight.
> Info: *I'm on FreeBSD 8.2* *out of a couple million packets, in a few hours
> time, I drop around 4000*
> First off are all packets stored in mbufs?
With most network drivers, I thin
On Sep 14, 2011, at 12:31 AM, wrote:
> Yes, that's right, these are the sequences described in sections 3.2.1 and
> 3.2.2. Even though, in hexadecimal notation this would be 0x55 0x55 0x55 0x55
> 0x55 0x55 0x55 and 0xd5, respectively (as denoted in section 3.3)
Sigh. I guess the bottommost b
On Sep 15, 2011, at 9:54 AM, Jon Schipp wrote:
> I'm trying to use the -B option this time but it's not working
> for me, tcpdump just prints the help menu.
> tcpdump -B 200 -nni em0 -s0 -w test.txt
> I've tried other values as well e.g. 524288, 1048576. It doesn't like any of
> them. *I'm o
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:
>
> typedef struct
> {
> uint32_tuiErrorCode : 8;
> uint32_tuiGpio: 1;
> uint
On Sep 14, 2011, at 1:16 AM, Guy Harris wrote:
> In any case, I've assigned 240 as
> DLT_ETHERNET_HILSCHER/LINKTYPE_ETHERNET_HILSCHER, for non-transparent packets
> (with the 4-byte pseudo-header before the Ethernet header, but without the
> preamble or
On Sep 17, 2011, at 1:54 AM, Tek Bahadur Limbu wrote:
> Can you provide further information about how we can go about
> implementing this setup?
No, I can't, because this is more about setting up a Web server than it is
about tcpdump, and I'm not at all familiar with how to set up any particula
On Sep 27, 2011, at 7:32 PM, Jon Schipp wrote:
> Is this specific to Linux, because I haven't experienced this on FreeBSD?
It's specific to the platforms on which libpcap implements it; currently, Linux
is one such platform, as is Tru64 UNIX, but FreeBSD (and other *BSDs and Mac OS
X) aren't.
On Sep 28, 2011, at 2:28 AM, Srikanth Raju wrote:
> In one of my tcpdump logs, I have the following two lines which is the same
> packet.
>
> 00:43:44.896482 P 00:00:ac:12:80:01 ethertype IPv4 (0x0800), length 76:
> 172.18.128.1.ssh > 155.xx.xx.xx.56365: S 1308033114:1308033114(0) ack
> 131
On Oct 5, 2011, at 8:51 AM, Petr Sumbera wrote:
> I'm trying to add support for IP over Infiniband (IPoIB) as defined in
> rfc4391 for Wireshark and I have realized that I need new DLT_ value for that.
>
> For more info you can see:
> http://tools.ietf.org/html/rfc4391
>
> Where you can see in
On Nov 17, 2011, at 2:22 AM, Fernando Gont wrote:
> Basically, I have a program that does this:
>
> 1. Captures and sends some packets
> 2. Does something else
> 3. Captures and sends some packets
>
> I'd like to use the same libpcap descriptor (pcap_t *) for both Step 1
> and step 2 above, but
On Oct 10, 2011, at 7:36 PM, Jon Schipp wrote:
> Are there any plans for a shared memory libpcap version from you guys?
> I know that there are some other that have modified libpcap to use mmap()
> such as Phil's: public.lanl.gov/cpw
>
> I was just curious to whether you guys have anything
Yes,
On Nov 17, 2011, at 3:43 AM, Fernando Gont wrote:
> Is it possible to call pcap_compile() more than once on the same libpcap
> descriptor (pcap_t *)?
If it doesn't work, that's a bug. pcap_compile() should
1) use the pcap_t only to get information such as the link-layer header
type an
On Oct 17, 2011, at 1:02 AM, Anders Broman wrote:
> What would be required to request a DLT for a proprietary format?
If "proprietary" means "to be kept private to your organization", and you can't
just use one of the DLT_USERn values for it, just ask for it and give a name.
That's one of the
On Oct 10, 2011, at 8:28 PM, Jon Schipp wrote:
> I'm going through some past mailing lists posts and I found this, which may
> have answered my question on where libpcap on Linux gets its drop count:
> http://seclists.org/tcpdump/2010/q3/46
>
> "You have a recent version of libpcap, and a recent
On Oct 17, 2011, at 8:44 AM, Magnus Gille wrote:
> I came across an issue with tcpdump where the linux kernel couldn't allocate
> memory properly when we ran tcpdump -s 0 on one of our boxes. Tcpdump sets
> snaplen to 65535 if -s 0 is provided and this became a problem for us, to
> get around thi
On Nov 13, 2011, at 1:00 PM, Ibrahim wrote:
> According to the IEEE Std 802.11-2007
> it's :
>- 2 bits version
>- 2 bits type
>- 4 bits sub type
>- 8 bits for 8 flags
> when I was comparing my result to wireshark , I noticed the following problem
> fc is 0x0080 as unsigned short
On Oct 19, 2011, at 4:17 AM, Tom Carly wrote:
> i'm trying to compile tcpdump with libpcap-pfring. The libpcap compilation
> went fine. With tcpdump compilation (./configure and make) i get this error:
What are the complete contents of the "config.log" file in the tcpdump source
directory?
-
On Nov 29, 2011, at 7:48 PM, Gianluca Varenni wrote:
> Is there a specific reason why shared memory is implemented in such a way
> that frame buffers are allocated based on the maximum frame supported frame
> size (+junk, see 802.11)?
I didn't see any of the discussions about it, but my guess
On Nov 20, 2011, at 8:41 AM, Lazarev Dmitry wrote:
> Can I offer binary version of tcpdump for my on needs? To trace
> traffic on my own notebook?
I'm not sure what you mean by "offer". If you want to install a binary version
of tcpdump on your own machine, there are no licensing issues; you'd
On Nov 28, 2011, at 6:58 AM, Michael Richardson wrote:
> I think that this belongs in libpcap, in pcap-linux.c.
Yes, it does, and, in fact, it *is* there in the trunk and 1.2 branches (and
the 1.2.0 release), as per my response to the previous copy of Magnus's message
(presumably he resent it
On Nov 30, 2011, at 2:40 AM, Fernando Gont wrote:
> Could you suggest a good reference for BPF syntax? -- So far I've only
> used pcap_compile() and hence didn't really get into BPF.
Well, for reference purposes, there's the original BPF paper:
http://www.tcpdump.org/papers/bpf-usenix93
On Nov 30, 2011, at 9:55 AM, David Laight wrote:
> That doesn't preclude the use of variable sized buffers.
> There are several schemes that could have been used that
> have much the same logic, but allow variable sized buffers.
At least with the Linux design, there's a fixed ring buffer of desc
On Nov 30, 2011, at 2:18 PM, Michael Richardson wrote:
> I was under the impression that some of hte ring-buffer mechanisms need
> packets to be aligned on MMU-sized boundaries so that the kernel can
> play page-swapping games, rather than copying data.
I don't think it does page-flipping - it j
On Nov 27, 2011, at 10:51 PM, Max Filippov wrote:
> Looks like your mail has been delayed a bit.
Yes, there was apparently a glitch in the mailing list.
> Usually beacons are not sent as ordinary packets, so you cannot see
> them on their egress interface.
> Wireless driver is notified about be
On Nov 30, 2011, at 4:17 AM, Shalom Kramer wrote:
> This will show you how the packet looks when tcpdump doesn't try to apply
> any filters.
*The* packet?
Those are two different packets; the filter "tcp" is, for some reason, failing
to match the first packet, but it's matching a subsequent pa
On Nov 30, 2011, at 6:11 PM, Guy Harris wrote:
> However, even with the filter that *does* handle extension headers - "ip6
> protochain \tcp" (which has to be quoted so that the shell passes the
> backslash on to tcpdump) - it *still* isn't matching the first packet
On Dec 6, 2011, at 5:47 PM, Gianluca Varenni wrote:
> It looks like there is a bug in the optimizer of the BPF compiler, both in
> 1.0 and trunk on git. If you try to compile the following filter,
> pcap_compile goes into some endless loop in bpf_optimize and never exits. If
> optimization is
On Dec 9, 2011, at 11:41 AM, Rick Jones wrote:
> I have some packet captures which were taken with a snaplen of 128 bytes, but
> I would like to convert that to one with a snaplen of say 66 bytes. The
> existing tcpdump/libpcap does not *seem* to do that - is there already a
> utility out the
On Dec 10, 2011, at 7:39 AM, abhinav narain wrote:
> Can I use pcap_loop when using select,
No.
You can, however, use pcap_dispatch(). pcap_loop() loops either indefinitely
or until it sees the specified number of packets; it will try to read more
packets from the underlying descriptor, and
On Dec 10, 2011, at 12:18 PM, ri...@happyleptic.org wrote:
>> I am trying to use select, as it seems the most basic.
>
> If I understand correctly, you are replacing your threaded aproach by a singly
> threaded program using select. Unfortunately, I don't know any way to
> associate a file descr
On Dec 10, 2011, at 12:38 PM, abhinav narain wrote:
> On Sat, Dec 10, 2011 at 3:18 PM, wrote:
>
>> Looks fine to me. What's eating 15% of your RAM, exactly?
>
> I think pthread while keeping the states
Is that 15% of your machine's RAM? Unless the threads have really large
stacks, or you ha
On Dec 10, 2011, at 12:58 PM, abhinav narain wrote:
> So, I can do select + pcap_dispatch to read on two interfaces without even
> using threads.
>
> I read select is slow for monitoring.
Possibly. If you don't care about portability, you could use epoll():
http://kernel.org/doc/man-
On Dec 10, 2011, at 11:58 PM, Cedric Cellier wrote:
>> I got it to work.
> (...)
>>> default: /* We got traffic */
>>> pcap_dispatch(pcap0,-1, (void *) packet_callback, NULL);
>>> pcap_dispatch(pcap1,-1, (void *) packet_callback2, NULL);
>
> So that other may benefit from it in the fut
On Dec 11, 2011, at 8:36 AM, abhinav narain wrote:
> the return value of error is -1,
> EINTR is 4.
For many UN*X APIs, "the return value" and "the error" are not the same; "the
return value" on an error is -1, and "the error" is in the variable "errno".
The select() man page on my system (not
On Dec 11, 2011, at 11:17 AM, abhinav narain wrote:
>> What is "it"? Your program? Or just *some* program?
>>
> Its the return statement of perror.
Presumably you were calling perror() because some call returned -1; what call
was that? If something keeps returning -1 because, for example, i
On Oct 14, 2011, at 2:51 PM, Magnus Gille wrote:
> I came across an issue with tcpdump where the linux kernel couldn't allocate
> memory properly when we ran tcpdump -s 0 on one of our boxes. Tcpdump sets
> snaplen to 65535 if -s 0 is provided and this became a problem for us, to
> get around thi
On Dec 11, 2011, at 2:42 PM, abhinav narain wrote:
> It sniffs for beacons by using bpf filter and keeps a per AP record of
> packet count etc in a table.
So if that's all you're doing, you presumably don't have your own buffer for
packets; when you say "I already have 15% RAM being eaten by th
On Dec 11, 2011, at 4:10 PM, abhinav narain wrote:
>> It sniffs for beacons by using bpf filter and keeps a per AP record of
>>> packet count etc in a table.
>>
>> So if that's all you're doing, you presumably don't have your own buffer
>> for packets; when you say "I already have 15% RAM being
On Dec 12, 2011, at 12:31 AM, abhinav narain wrote:
> I see this usage by top command.
> VSZ reports 9304 Bytes.I think this must be virtual address space.
9394 *bytes*? That's 15% of about 62KB; if that's 15% of your RAM, you're
probably running on a machine with 64K, which I doubt.
Did you
On Dec 12, 2011, at 1:36 AM, abhinav narain wrote:
> I can't find any default buffer size in pcap,
The default size is platform-dependent. On Linux systems that support
memory-mapped capture (in both the kernel, which your kernel does, and in
libpcap, which libpcap 1.0 and later do), the defa
ink that interface could defer freeing the last
> rx buffer until the request to read another packet.
> That would avoid the necessity of a buffer copy
> for applications that don't want to use callbacks.
That strategy was attempted by
commit 54ef309e921c11a4e80cd7a26d9e25d30c833
On Dec 12, 2011, at 1:10 PM, drag...@durandal.kismetwireless.net wrote:
> About the only time you'll see beacons on non-basic rates is a
> greenfield deployment, of which I've *never* found one in the wild
> despite all the manufacturers caring about it.
Will we see any greenfield deployments an
On Dec 12, 2011, at 1:18 PM, abhinav narain wrote:
> Its KB then, because the router has 64MB RAM
> So, it means, I am filling the buffer almost always.
No, what it means is "the process running your application has a 9.3MB virtual
address space", which says nothing about how much RAM it's usin
On Dec 12, 2011, at 1:41 PM, Guy Harris wrote:
> On Dec 12, 2011, at 3:59 AM, David Laight wrote:
>
>> I also think that interface could defer freeing the last
>> rx buffer until the request to read another packet.
>> That would avoid the necessity of a buffer copy
On Dec 15, 2011, at 2:39 PM, Rick Jones wrote:
>> This may be of help.
>> http://www.tcptrace.org/faq_ans.html#FAQ%2021
>
> Given the behaviour seems to be (at least for the foreseeable future) a
> "feature" is there someplace in tcptrace/tcpdump to mention this? The
> tcptrace FAQ seems to h
On Dec 16, 2011, at 1:51 PM, Jon Schipp wrote:
> Do the recent tcpdump releases use the shared memory functionality of
> the newer libpcap libraries?
> Basically, if I download the latest tcpdump and the latest libpcap and
> compile them on FreeBSD and on Linux, and then run the binary, will I
>
On Nov 29, 2011, at 11:38 AM, Sam Roberts wrote:
> DLT_USER0 is available for internal use, and pcap_open_dead() will
> accept it, but pcap_dump_open() is complaining that it doesn't know
> the corresponding link type.
>
> I assume this is intentional, but why is it a feature? It seems
> prefera
On Dec 17, 2011, at 12:37 PM, Nikola Ciprich wrote:
> When starting tcpdump (using either -i any or -i xxx) on system with
> higher disk load, it sometimes happens that system seems to hang almost
> immediately and
> loadavg value shoots to really bad numbers (almost 200 for example).
So that
On Dec 18, 2011, at 3:54 AM, Nikola Ciprich wrote:
> here's the strace:
> 09:48:15.982305 setsockopt(3, SOL_PACKET, PACKET_RX_RING,
> "\0\0\2\0\37\0\0\0@\0\1\0\37\0\0\0", 16) = 0 <15.531056>
> ^^^ here it hangs
> 09:48:32.050796 mmap(NULL, 4063232, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) =
> 0x
On Dec 21, 2011, at 9:02 AM, David Laight wrote:
> I thought Berkley had made a general statement that
> some of those clauses (esp. the advertising one) could
> be removed??
The statement made by the Directory of Technology Licensing at UCB was:
ftp://ftp.cs.berkeley.edu/pub/4bsd/READM
On Dec 21, 2011, at 8:46 AM, Michael Richardson wrote:
>
>> "David" == David Ward
>>
>> writes:
>David> I'm sending a couple of fixes to the 'inbound' and 'outbound'
>David> filters in libpcap affecting Linux. I have compiled and
>David> tested under Linux as well as F
On Dec 20, 2011, at 4:37 PM, Akos Vandra wrote:
> When building wireshark based on the new libpcap with my module using
> libusb-1.0, it didn't build, because it was missing symbols
> (naturally, as wireshark didn't know it has to link libusb-1.0 as
> well). So insted of digging into where I have
On Dec 20, 2011, at 1:01 AM, Akos Vandra wrote:
> So my questions are:
> - What are the steps needed to 'nicely' add support to a new device?
If your new device requires a new link-layer header type (which this one does,
as per the discussion on the wireshark-dev list), you need to get one ass
On Nov 28, 2011, at 2:02 PM, Andy Fingerhut wrote:
> libpcap has had support for pcap ng files since early 2010. Such
> files can contain timestamps with resolutions more precise than
> microseconds. From my reading of the code, it appears that when
> libpcap reads from such a file, it converts
On Dec 22, 2011, at 11:32 AM, Chris Maynard wrote:
> For what it's worth, I e-mailed him. Thanks again.
I hope your e-mail didn't use any masculine pronouns when referring to Petra:
http://www.linkedin.com/in/petrasoderling
:-)
Not that it matters, as the Nokia unit whose appliances
On Dec 22, 2011, at 5:51 PM, Akos Vandra wrote:
> This is another project, that adds support for a canusb adapter,
So this adapter doesn't just show up as a regular SocketCAN network adapter
when you plug it in?-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
On Dec 23, 2011, at 5:36 AM, 赵彤 wrote:
> checking for local pcap library... ./../libpcap-1.2.0/libpcap.a
> checking for pcap-config... ./../libpcap-1.2.0/pcap-config
> checking for pcap_loop... no
> configure: error: Report this to tcpdump-workers@lists.tcpdump.org, and
> include the
> config.lo
On Dec 23, 2011, at 7:54 AM, Keith Roberts wrote:
> Are you running Linux
As the config.log file he was told to include, and that he did include, says:
hostname = zt-ThinkCentre-
uname -m = i686
uname -r = 2.6.38-13-generic
uname -s = Linux
uname -v =
On Dec 23, 2011, at 9:02 PM, ri...@happyleptic.org wrote:
> The "any" device is not an ethernet device, but a virtual thing
> that will bring you (at least on Linux) a "Linux Cooked" header
> instead of an ethernet header.
The "any" device currently only exists on Linux, so there's nothing other
On Dec 27, 2011, at 12:58 PM, Michael Richardson wrote:
>> "Akos" == Akos Vandra writes:
>
>Akos> P.S. Why are configure and config.h.in tracked? Shouldn't
>Akos> these be generated by autoconf and autoheader?
>
> In theory, yes. In practice, end users never have the exact *right*
On Dec 27, 2011, at 12:53 PM, Michael Richardson wrote:
> I plan to let a 4.1.2 (perhaps a 4.2) out tomorrow.
Do you mean "4.1.2" or "4.2.1"? 4.2.0, and libpcap 1.2.0, are the current
release, according to the Web site. Both of them have significant bugs that
are fixed in the current 4.2 and
On Dec 29, 2011, at 1:58 PM, Fernando Gont wrote:
> I was trying to check for specific errors in libpcap I/O functions such
> as pcap_next_ex() and pcap_inject().
>
> However, the relevant manpages indicate that these functions return -1
> on error, and don't mention the setting of any "errno-li
On Dec 30, 2011, at 6:21 AM, Fernando Gont wrote:
> After taking a look at the libpcap code, it seems that a straightforward
> way to incorporate the functionality I was mentioning would be to add to
> pcap_t a "status" member, and add right before every sentence that
> writes to handle->errbuf a
On Jan 1, 2012, at 6:12 PM, Michael Richardson wrote:
> libpcap 1.2.1 and tcpdump 4.2.1 were tar.gz and signed tonight.
tcpdump-announce is still listed under
http://www.tcpdump.org/#mailing-lists
Should announcements of new releases be sent there as well?
The Web site still lists 1.2
On Jan 2, 2012, at 11:14 AM, Guy Harris wrote:
> The Web site still lists 1.2.0 and 4.2.0 as the current release.
It looks as if the home page in the Git repository lists 1.2.1 and 4.2.1. I'd
noticed in the past that CVS repository changes don't immediately show up on
the
On Jan 3, 2012, at 1:23 AM, David Laight wrote:
>
>> On all modern UN*Xes, as far as I know, a dynamic library can
>> be linked with another dynamic library, and if a program is
>> explicitly linked with the first of those libraries, but
>> *not* explicitly linked with the second of those lib
On Jan 4, 2012, at 4:10 PM, Akos Vandra wrote:
> When opening a capture device, is it possible to hand off some
> initialization data to the libpcap handler?
Yes.
The ways to do that would either be to
1) have the device name include parameters such as that
or
2) add new APIs
On Jan 5, 2012, at 1:40 AM, Akos Vandra wrote:
> I browsed through the code of pcap_open_live, and pcap_set_promisc,
> and related stuff, and I think that now I understand how this works.
>
> However in my opinion, the way parameter passing is implemented breaks
> the principle of modularity.
>
On Jan 6, 2012, at 8:16 AM, Jakub Zawadzki wrote:
> On Fri, Jan 06, 2012 at 04:47:09PM +0100, Akos Vandra wrote:
>> Another reason why this is not a good approach: Let's get wireshark in
>> the picture. Let's say the user selected a canusb device. The only way
>> for wireshark to know what parame
On Jan 9, 2012, at 8:49 PM, Fernando Gont wrote:
> I'm doing I/O multiplexing with the pcap descriptor, and it turns out
> that on OpenBSD the underlying descriptor for a pcap_t is never writeable.
I presume from "I'm doing I/O multiplexing" that by "writeable" you're
referring to "writeable" a
On Jan 10, 2012, at 3:15 PM, Fernando Gont wrote:
> I would expect that if there are no buffers available, pcap_inject() or
> blocks, rather than silently fail.
"Blocks" and "silently fails" aren't the only alternatives; "returns -1 and
sets errno to an error such as ENOBUFS" is a third alterna
On Jan 6, 2012, at 2:16 PM, Akos Vandra wrote:
> On 6 January 2012 17:16, Jakub Zawadzki wrote:
>
>> Let's have just:
>> int pcap_setparam(pcap_t *p, const char *param, const char *value)
>>
>> If param is not understand, or value is invalid for given param (like: not
>> integer)
>> it shoul
On Jan 12, 2012, at 1:06 AM, Akos Vandra wrote:
> We could put a limit - say 32 or 64 chars - to the max length of the
> param, and then allocate in on the stack, but it would still require
> printf.
Where would that be done? It's a little more convenient than using routines
such as asprintf()
On Jan 15, 2012, at 9:36 AM, Fernando Gont wrote:
> I'd like a call to pcap_next_ex() to block, waiting for a single packet,
> with no timeout.
>
> So far, the only portable way to do it I've found is to select() on the
> underlying descriptor.
>
> The reason is that if I pcap_open_live() with
On Jan 15, 2012, at 3:11 PM, Fernando Gont wrote:
> For my current app, it's probably just "annoying" (although no big
> deal). However, I was mostly concern about performance problems in other
> applications. Put another way, if there's nothing that an app can do
> without a packet being read, t
On Jan 15, 2012, at 6:44 PM, Gianluca Varenni wrote:
> Hi all.
>
> It looks like there is a bug in handling a snaplen of 1500 on linux (with
> mmap on). If I set a snaplen of 1500 and receive packets > 1500 (e.g. 1514),
> libpcap returns only 1498 as caplen, and not 1500.
>
> Libpcap latest o
On Jan 16, 2012, at 5:55 AM, Shalom Kramer wrote:
> But I seem not to be able to filter by the underlying tcp properties. For
> instance:
>
> *tcpdump ** -r http_over_ipv6_with_options.pcap* *"ip6 protochain \tcp and
> port 80"
>
> *Will return only the packets without the optional IPv6 headers
On Jan 16, 2012, at 6:58 AM, Fernando Gont wrote:
> On 01/15/2012 08:56 PM, Guy Harris wrote:
>>> For my current app, it's probably just "annoying" (although no big
>>> deal). However, I was mostly concern about performance problems in
>>> other appl
On Jan 16, 2012, at 2:20 PM, Fernando Gont wrote:
> Both on Linux and on BSDs, each time a packet is received, select()
> returns readable (without waiting for the entire buffer to fill up). --
> my understanding is that you were expecting select() to block till the
> buffer filled up, or when th
On Jan 16, 2012, at 11:11 PM, rehaf drar wrote:
> my project name is “creating network attack dataset to aid security and
> network researchers “ this dataset must be include specific type of network
> attack
> I will use pcap format to save dataset file and bit twist network
> generator t
On Jan 22, 2012, at 11:16 PM, narmada wrote:
> I am using wpcap.lib for packet capturing in my application. my application
> is written in delphi. i can able to getting packets. But when i am applying
> filter to the device it is not able to apply filter to that.. The
> pcap_compile function r
On Jan 25, 2012, at 7:20 AM, Chris Maynard wrote:
> If you visit http://blog.gmane.org/gmane.network.tcpdump.devel, it indicates
> at
> the top of the page that tcpdump-workers@lists.tcpdump.org is a, "list about
> the
> developpement of tcpdump".
In addition to misspelling "development", the
On Jan 29, 2012, at 1:34 AM, dyn...@lavabit.com wrote:
> I've trying to build from source libpcap-1.2.1 but have been getting into
> trouble when building other software, lft-3.33, that errors on build.
What are the errors you're getting?
> I think I may have missed something in building libpca
On Jan 29, 2012, at 9:21 AM, Guy Martin wrote:
> I've been working with protocols encapsulated into MPEG2-TS but
> I can't save the raw stream straight into a pcap file.
> Those protocols include DOCSIS (cable modem) and DSM-CC (IP packets
> into DVB streams).
>
> Unless I'm mistaken, there is c
On Jan 29, 2012, at 1:19 PM, Guy Martin wrote:
> Correct. It's most commonly refered as ISO 13818-1.
Yes, but I usually go to the ITU-T standard first, in the hopes that I won't
have to drag out my credit card to get access to the standard. Alas, my hopes
were dashed in this case (but CHF 77
On Jan 29, 2012, at 9:11 PM, Yohannes Affandy Siregar wrote:
> I'm curios about the BPF. Is there any BPF to filter probe request or
> management frame of 802.11 packet over a wireless network.
Yes.
> If yes, what is the filter expression?
As you asked about two types of filters, there's no "t
On Jan 31, 2012, at 1:13 AM, tom h wrote:
>
> hello there
> i tried to install tcp dump and get this message during ./configure
>
> checking for pcap_loop... no
>
> it says to report that so here we are
Something didn't build correctly in libpcap. Could you send us both the
config.log file
On Jan 31, 2012, at 7:18 AM, 苏少飞 wrote:
> I try to install the tcpdump to my Ubuntu 11.10, but it installed failed
> after I run the ./configure script and there is a log file generated. Can
> you help me ?
Could you send us the config.log file from the tcpdump source directory and the
log from
On Jan 31, 2012, at 11:31 PM, Graeme Sheppard wrote:
> I have a problem capturing in a 32 bit guest on a 64 bit VZ/OpenVZ host.
> It worked in a 64 bit guest but I had to change to 32 (another story.)
So the host on which you're capturing is running a 32-bit Linux kernel and a
32-bit version of
On Feb 1, 2012, at 12:26 AM, Guy Harris wrote:
> On Jan 31, 2012, at 11:31 PM, Graeme Sheppard wrote:
>
>> I have a problem capturing in a 32 bit guest on a 64 bit VZ/OpenVZ host.
>> It worked in a 64 bit guest but I had to change to 32 (another story.)
>
> So
On Jan 29, 2012, at 2:17 PM, Guy Harris wrote:
> At this point, no. (I need to be able to push changes to pcap-common.c and
> pcap/bpf.h, but that's not under your control. :-))
OK, I've assigned LINKTYPE_MPEG_2_TS/DLT_MPEG_2_TS, with a value of 243.-
This is the tcpdump-wor
On Oct 10, 2011, at 11:07 PM, Jens Grimmer wrote:
> I just work on libpcap enhancements to monitor ATM- and Iub over IP protocol
> data, generated/received by our ng40 protocol tester. Therefore I ask you to
> get a new DLT_value.
>
> I use a pseudo header to transmit ATM path information and
On Feb 1, 2012, at 5:32 AM, Michael Richardson wrote:
> No, openvz is a container, not a virtualization.
As I suspected.
> So the kernel is 64-bit, the userland in a chroot/jail+++ is 32-bit.
> The kernel would be doing 32-bit emulation of many calls, but I'll bet
> things like the mmap() inter
1601 - 1700 of 2521 matches
Mail list logo
