Home page logo
/
tcpdump Mailing List

Covers the classic tcpdump text-based network sniffer and its libpcap sniffer library component.

List Archives

Jan–MarApr–JunJul–SepOct–Dec
20141338434
201312715755107
20121768453144
2011177235187215
201021713185141
2009220182186145
2008233140139269
2007154118251226
200620014871162
2004392374377208
2003315283259304
2002319

Latest Posts

Re: ICMP echo reply Rick Jones (Jul 24)
Please keep the discussion on the list - I don't have a monopoly on
knowledge in this area.

If you have tcpdump traces from both the client and the server I would
expect to see a total of four lines of trace. Two from the trace on the
client and two from the trace on the server.

Exactly *how* are the VM's clocks synchronized? If you are going to
want to know the time it took to get from the server back to the client,
using...

Re: ICMP echo reply Rick Jones (Jul 23)
Questions, the answers to which will perhaps help lead you to the/an answer.

*) Do you have just the one tcpdump trace or do you have tcpdump traces
from both the client and the server?

*) Do the client and the server synchronize their clocks?

*) How large is the latency as reported by ping (I'm assuming ping is
the source of these ICMP Echo Requests and so triggers the ICMP echo
replies)?

*) What do you know about the network path...

[pcap-ng-format] opsarea presentation? Michael Richardson (Jul 23)
{resending, because my address book was confused}

So, was pcap-ng well receives by opsarea WG this morning?

and the reply was:

Michael Tuexen <Michael.Tuexen () lurchi franken de> said:

ICMP echo reply French_christ (Jul 23)
I just have a question and i am suppose to answer it.
The question is :ICMP echo request was sent by the client,then ICMP echo reply was recieved by the client,both have
timestamps on the tcpdump output
The question is how long took the ICMP echo reply to be sent from the server to the client.

Thanks a lot for your efforts
Hayder abdulabbas abdulameer
Iraq/karabala

Linux mmap support and nonblocking mode Aaron Lehmann (Jul 23)
Hi,

I just spent a few days debugging unexpected packet loss in my
application. The first packet that passed the filter would often be
missed, but the response that came immediately after would always make
it through, as well as subsequent packets. This failure was inconsistent
and difficult to reproduce.

After trying several other things, I upgraded from pcap 1.1.0 to pcap
1.6.1. This made the issue much worse. With the new version, the first...

Re: Packet identifier Guy Harris (Jul 22)
The trunk and 4.6 branch support the "-#"/"--number" command-line option to print an ordinal number at the beginning of
the first line of output for each packet.

Packet identifier Aravindhan Dhanasekaran (Jul 22)
Hello,

Is there a packet level ID support in current tcpdump code? A simple
non-decreasing integer for every packet (something similar to
Wireshark) would do.

Thanks,
Aravind

buildbot failure in tcpdump+libpcap on Solaris-10-SPARC buildbot-no-reply (Jul 17)
The Buildbot has detected a new failure on builder Solaris-10-SPARC while building tcpdump+libpcap.
Full details are available at:
http://buildbot.wireshark.org/tcpdump/builders/Solaris-10-SPARC/builds/63

Buildbot URL: http://buildbot.wireshark.org/tcpdump/

Buildslave for this Build: solaris-10-sparc

Build Reason: The web-page 'rebuild' button was pressed by '<unknown>':

Build Source Stamp: [branch master]...

buildbot failure in tcpdump+libpcap on Ubuntu-12.04-x64 buildbot-no-reply (Jul 16)
The Buildbot has detected a new failure on builder Ubuntu-12.04-x64 while building tcpdump+libpcap.
Full details are available at:
http://buildbot.wireshark.org/tcpdump/builders/Ubuntu-12.04-x64/builds/815

Buildbot URL: http://buildbot.wireshark.org/tcpdump/

Buildslave for this Build: ubuntu-12.04-x64

Build Reason: The Nightly scheduler named 'nightly' triggered this build
Build Source Stamp: [branch master] HEAD
Blamelist:

BUILD...

Re: FreeBSD sandboxing support via capsicum Loganaden Velvindron (Jul 11)
Thanks. I'll test it.

Please note that the code is adapted from code written by Pawel J Dawidek (pjd () freebsd org), and that I simply
rewrote it for tcpdump. I think that he also deserves credit in the CREDITS file.

Re: FreeBSD sandboxing support via capsicum Guy Harris (Jul 10)
Checked in (with some fixes to the configure script - there shouldn't be anything between AC_MSG_CHECKING and
AC_MSG_RESULT that would print any output, and capsicum should be enabled only if none of the functions were not found).

Michael, should this go into 4.6 or should we wait for the next tcpdump release?

Re: FreeBSD sandboxing support via capsicum Loganaden Velvindron (Jul 09)
Thank you for your feeeback.

Updated diff. Feedback welcomed.

diff --git a/configure.in b/configure.in
index c88f470..8488653 100644
--- a/configure.in
+++ b/configure.in
@@ -177,6 +177,16 @@ else
AC_MSG_RESULT(no)
fi

+AC_ARG_WITH(sandbox-capsicum, [ --with-sandbox-capsicum ])
+AC_MSG_CHECKING([whether to sandbox using capsicum])
+if test ! -z "$with_sandbox-capsicum" && test "$with_sandbox-capsicum" !=...

Re: building libpcap without usb support Guy Harris (Jul 08)
I've changed the configure script in the trunk and the 1.6 branch so that, instead of looking for the header, it checks
whether it can build, with -lusb-1.0, a program that calls libusb_init().

See if that fixes the problem.

Re: building libpcap without usb support Michael Richardson (Jul 06)
Romain Francoise <romain () orebokech com> wrote:
>> <linux/usbdevice_fs.h> is a kernel header; does USB sniffing require
>> libusb-dev at all?

> Nope. libusb is only required for canusb support.

Ah, that's a bit confusing.

There is a --disable-canusb, I think, so I'll try building libpcap
with that option, which ought to eliminate needing to link with -lusb.
I wonder if canusb sniffing is...

Re: building libpcap without usb support Michael Richardson (Jul 06)
Guy Harris <guy () alum mit edu> wrote:
>> Done. If that header isn't present, the USB probing code isn't built
>>or called, so you don't get information about attached USB devices as
>>the first items in the trace unless they happen for some other reason.

> I've cherry-picked that to the 1.6 branch.

> BTW, I don't see a 4.6 branch for tcpdump; will that be created soon...

More Lists

Dozens of other network security lists are archived at SecLists.Org.


[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]