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
201413384691
201312715755107
20121768453144
2011177235187215
201021713185141
2009220182186145
2008233140139269
2007154118251226
200620014871162
2004392374377208
2003315283259304
2002319

Latest Posts

bpf.tcpdump.org going down for migration Michael Richardson (Oct 01)
bpf.tcpdump.org will go down at 9am EDT until around 11am EDT so that
it can be moved to a location (a host, it's a VM) with more stable power.

Re: tcpdump and libpcap releases,     and future thoughts Denis Ovsienko (Sep 13)
> How about:
> sudo pktcap - | pktdump -

Although architecturally cleaner and SMP-friendlier than now, to survive busy everyday end-users this approach would
greatly benefit from a single front-end process that would launch the other binaries, connect them together and
properly distribute command-line options.

Re: tcpdump and libpcap releases, and future thoughts Guy Harris (Sep 12)
"dumpcap" is already taken. :-)

Some have argued in favor of running dissection in a context with *reduced* privileges, so that it can't, for example,
do file system I/O, create processes, etc., at least not after it's ready any configuration etc. files it might have,
with address-to-name resolution done in another process with sufficient privileges to read hosts files, talk to DNS
servers, etc.. The intent is to protect...

Re: tcpdump and libpcap releases, and future thoughts Michael Richardson (Sep 12)
Michal Sekletar <msekleta () redhat com> wrote:
> In the future I'd like to see pktdump to implement an architecture
> which would allow a user to run a packet dissector completely
> unprivileged. Meaning, that *all* privileged operations are done by a
> very tiny server program running on the side. We could then not
> implement equivalent of -Z option and possibly hook up the pktdump with
> an...

Re: DLTs for Z-Wave Michael Richardson (Sep 10)
Guy Harris <guy () alum mit edu> wrote:
>> It would be reasonable to anticipate additional characteristics that
>> could make their way into a capture file for received traffic, such as
>> RSSI and noise levels, antenna selection, etc. For the requested link
>> types, the packet will start with the MAC Layer data (the 4-byte
>> HomeID comes first), including an FCS, with no additional data....

Re: DLTs for Z-Wave Guy Harris (Sep 10)
So presumably new LINKTYPE_/DLT_ values will be requested for the captures with metadata, once the format for the
metadata is specified?

(PPI is *not* an ideal solution here; it's preferable to have the LINKTYPE_/DLT_ value directly specify the link-layer
header type, rather than having the link-layer metadata header itself include a LINKTYPE_ value.)

Re: DLTs for Z-Wave Joshua Wright (Sep 10)
Yes, notably R3 uses an 8-bit sequence number, where R1 and R2 use a 4-bit sequence number in the Frame Control field.
The R3 header is one byte larger than the R1/R2 header to accommodate the larger sequence number field. Also, the
frame control bit mask is different in R3 and R1/R2.

Yes, all packets in a capture will be of the same profile.

It would be reasonable to anticipate additional characteristics that could make their way into a...

Re: DLTs for Z-Wave Guy Harris (Sep 10)
So there are differences other than the FCS length?

Will all packets in a capture use the same profile?

If so, then, yes, two DLT_/LINKTYPE_ values will suffice.

Will the packet data be in the form specified by the "MAC Layer" part of Figure A.3 "General frame structure", with
nothing added, removed, or transformed? Or, for example, will it have radio metadata, along the lines of what radiotap:...

Re: DLTs for Z-Wave Joshua Wright (Sep 10)
Hearing no questions, is there anything more I can do to get this request authorized?

Thank you,

-Josh

Re: buggy getaddrinfo() Guy Harris (Sep 08)
As far as I can tell from grepping through the CVS files on bpf.tcpdump.org, we *never* needed it in tcpdump.

My guess is that, as part of IPv6 support, the same, or very similar, configure-script changes and replacement
getaddrinfo.c/getnameinfo.c were done for both libpcap and tcpdump, even though libpcap only uses getaddrinfo() (e.g.,
to map host names in filter expressions to addresses) and tcpdump only uses getnameinfo() (to map addresses...

buggy getaddrinfo() Michael Richardson (Sep 08)
Since a long time ago, we test to see if the getaddrinfo() function
is buggy. It appears that if we are cross-compiling, that we always
forceably fail the test.

But, since 2014-0-25, we don't even include getaddrinfo.c, is that because
we never need it anymore, (grep seems to agree), or because???

If we don't need it, can we remove the test in configure for it?

Re: tcpdump and libpcap releases, and future thoughts Michal Sekletar (Sep 08)
Hi,

this request is a bit unrelated to your proposal, but I think it better be
considered sooner than later.

In the future I'd like to see pktdump to implement an architecture which would
allow a user to run a packet dissector completely unprivileged. Meaning, that
*all* privileged operations are done by a very tiny server program running on
the side. We could then not implement equivalent of -Z option and possibly hook
up the pktdump...

Re: tcpdump and libpcap releases, and future thoughts Denis Ovsienko (Sep 06)
I don't fully understand the primary pro et contra of this change, but a positive side effect of this would be that the
new subdir would make it easier to apply uniform updates specifically to printers' source code. Right now it is easy to
miss a few .c/.h files when trying to do a uniform update.

DLTs for Z-Wave Joshua Wright (Sep 06)
I request two DLTs for Z-Wave packet captures based on the ITU-T
Recommendation G.9959 (http://www.itu.int/rec/T-REC-G.9959).

My packet capture tool has support for three Z-Wave RF profiles
(sometimes called "channel configurations"):

R1 - 9.6 Kbps (908.42 North America, 868.42 Europe)
R2 - 40 Kbps (908.4, 868.4)
R3 - 100 Kbps (916, 869.85)

The MAC format for R1 and R2 Z-Wave networks is identical, but the R3
MAC is different with...

buildbot failure in tcpdump+libpcap on Solaris-10-SPARC buildbot-no-reply (Sep 06)
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/116

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

Buildslave for this Build: solaris-10-sparc

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

BUILD...

More Lists

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


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