| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do it with a bunch of ifs rather than with a translation table; that
lets the logic work differently for DLT_ -> LINKTYPE_ mapping and
LINKTYPE_ -> DLT_ mapping.
Have two "matching" ranges, so that the linktypes that preceded the BSDs
all going off in their own directions can be handled as a matching
range.
Avoid doing mapping if the corresponding LINKTYPE_ and DLT_ codes have
the same numerical value.
For LINKTYPE_ -> DLT_ mapping, don't map link-layer type values outside
either of the matching ranges if we don't have a specific mapping set up
for them, just treat the LINKTYPE_ value as if it's a DLT_ value. That
makes us handle some DLT_ codes outside the high mapping range to which
we assigned matching LINKTYPE_ codes, as well as attempting, as best we
can, files written with platform-dependent DLT_ codes (such as DLT_RAW)
as link-layer type codes (programs *on that platform* will handle them
correctly; programs will not do so on other platforms, but that's better
than not handling them correctly anywhere).
Update various comments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* amount
* anymore
* authentication
* availability
* bracket
* captured
* casted
* communications
* compliant
* configurable
* cumulate
* deinitialize
* descriptors
* didn't
* disassembler
* disassociate
* distributions
* divvy
* doing
* entries
* everything
* explicitly
* explosion
* expression
* extracting
* failed
* family
* find
* github
* global
* implementations
* incorrectly
* intel
* interlocked
* justifying
* know
* launched
* libraries
* malloced
* mask
* maximum
* network
* nonexistent
* number
* occurred
* optimizer
* overflow
* overwrite lower
* packet
* packetfilter
* packets
* parse hosts
* payload
* phase
* programmers
* promiscuous
* protocol
* receiving
* redefinition
* sampling
* savefile
* schwartz
* should
* snapshot
* something
* specifies
* straightforward
* stream
* subdir
* support
* surrogate
* suse
* system is
* test with
* than
* those
* unmaintained
* valid
* way
* western
* wireshark
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
| |
|
| |
|
|
|
|
| |
See tcpdump-htdocs pull request 27.
|
|
|
|
| |
As discussed on tcpdump-workers@.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
1) EXP_PDU_TAG_LINKTYPE isn't used any more.
2) EXP_PDU_TAG_HEUR_DISSECTOR_NAME is used.
3) EXP_PDU_TAG_PROTO_NAME was renamed to EXP_PDU_TAG_DISSECTOR_NAME to
reflect that it is (and always has been) a Wireshark internal dissector
name, not the name of a protocol.
|
|
|
|
| |
Signed-off-by: gorgas-waller <frank.gorgas-waller@auerswald.de>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
USB 2.0/1.1/1.0 devices (or 3.x and newer when connected to hosts that
are not Super-Speed capable) operate at one of three speeds:
* Low-Speed (1.5 Mbps)
* Full-Speed (12 Mbps)
* High-Speed (480 Mbps)
While the packets are generally common to all three speeds, there are
some differences that span across different layers. The capture speed
should be available to analyzer and it makes sense to expose it via
speed specific linktypes. Existing USB 2.0/1.1/1.0 captures can be
manually, retroactively updated to speed specific linktype.
Low-Speed device will always operate at Low-Speed, regardless of what
host it is connected to. USB cable connected to Low-Speed device only
ever carries packets sent at Low-Speed.
High-Speed device will operate at High-Speed when connected to High-Speed
capable host. If High-Speed Detection Handshake succeeds, the cable will
only carry High-Speed packets.
Full-Speed device will always operate at Full-Speed, regardless of what
host it is connected to. High-Speed device connected to Full-Speed host
or hub, will operate at Full-Speed. The cable connected to device
operating at Full-Speed can only carry Full-Speed or Low-Speed packets
preceded by Low-Speed preamble (PRE packet) sent at Full-Speed. Non-hub
device operating at Full-Speed always ignores Low-Speed packets. The hub
forwards the Low-Speed packets to downstream ports but does not act upon
the actual Low-Speed packet contents. The packets intended for device
operating at Full-Speed are always sent at Full-Speed.
|
|
|
|
|
|
|
|
| |
There's a reserved field that was originally intended to handle
alternate link-layer type values; it would contain a "class" value
indicating what the lower 16 bits of the field indicate. We currently
only support a "class" value of 0, meaning "it's a LINKTYPE_ value".
Reject files where it's non-zero.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
We'd reserved LINKTYPE_HDLC for it; we rename that to
LINKTYPE_NETBSD_HDLC, define DLT_HDLC as 16 on NetBSD (that's the value
they use) and as the same value as LINKTYPE_NETBSD_HDLC on others, so
it's at least defined everywhere, map between DLT_HDLC and
LINKTYPE_NETBSD_HDLC in capture files, and make sure we treat DLT_C_HDLC
and DLT_HDLC the same (as NetBSD appears to use DLT_HDLC for Cisco
HDLC).
Also, expand some comments.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
The description file was merged into the Web site repository, and
Wireshark's already treating 290 as mening LINKTYPE_ETW, so make it more
official.
|
| |
|
|
|
|
|
|
|
|
| |
DLT_PPP_WITH_DIR and DLT_PPP_PPPD are sufficiently different that
they're unlikely to be confused with one another;
DLT_PPP_WITH_DIRECTION, which is an old name for what is now called
DLT_PPP_PPPD, is enough like DLT_PPP_WITH_DIR that somebody might
confuse them.
|
|
|
|
| |
DLT_PPP_WITH_DIRECTION was renamed to DLT_PPP_PPPD.
|
| |
|
| |
|
|
|
|
| |
[skip ci]
|
|
|
|
| |
Also, add some missing values to dlt_choices.
|
| |
|
|
|
|
|
| |
In addition to the support for DSA data link types added by 993db38,
this commit adds support for the Marvell DSA and EDSA tagging formats.
|
|
|
|
|
|
|
|
|
|
| |
Apparently the Kontron person who said that the packets begin with the
I2C slave address didn't understand the question, because the Kontron
code adds a 2-byte pseudo-header before the I2C slave address. Rename
the DLT_ and LINKTYPE_ values to reflect this, and update the comments.
Add support for the Linux/Pigeon Point pseudo-header in some places
where it was missing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Linux kernel 4.20 and greater can report what type of Distributed Switch
Architecture tagging protocol is used on the DSA master/management
interface. We need to map the protocol to a specific DLT and linktype
value in the pcap file because these protocols typically cannot be
decoded simply by making use of heuristics. The sysfs attribute that is
being checked and parsed is documented in this commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a3d7e01da06013dc580641a1da57c3b482d58157
For now, the description of the Broadcom 4 byte Ethernet switch tagging
protocol is provided and more tags can be added in the future using the
same infrastructure.
|
|
|
|
|
|
|
| |
Specifically: DLT_VPP_DISPATCH and LINKTYPE_VPP_DISPATCH; update
DLT_MATCHING_MAX and LINKTYPE_MATCHING_MAX
Signed-off-by: Dave Barach <dave@barachs.net>
|
| |
|
|
|
|
|
|
|
|
| |
The original request just spoke of "sent by this host" and "received by
this host"; for X.25 LAPB and Frame Relay LAPF, "this host" is probably
a piece of Data Terminal Equipment rather than Data Communications
Equipment, so we treat "sent by this host" as DTE->DCE and "received by
this host" as DCE->DTE.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
with linktype value 276.
This is a preparation for implementing Linux "cooked" capture
encapsulation v2.
See: GH the-tcpdump-group/libpcap#127
Signed-off-by: Petr Vorel <pvorel@suse.cz>
|
|
|
|
| |
[skip ci]
|
| |
|
|
|
|
|
|
|
|
| |
That should emphasize that this should only be used for captures where
the FCS is part of the payload; if you're not supplying the FCS, use
DLT_IEEE802_15_4_NOFCS.
Keep the old name around for source compatibility.
|
|
|
|
|
|
|
|
| |
Use "macOS" except when referring to versions that came out when it was
still called "Mac OS X" or "OS X". Rename README.macosx to
README.macos.
Update some comments while we're at it.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can get them on any sufficiently modern UN*X, as they provide
<inttypes.h>. We can get them with MSVC, by including <inttypes.h> on
newer versions or defining them ourselves in older versions. We can get
them with various development environments on MS-DOS.
Add a pcap/pcap-inttypes.h header file that does what's necessary to get
them defined, and include that in the pcap/*.h headers that use those
types.
Have pcap-types.h only include what's necessary to get u_int defined.
|
| |
|