| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Stick a byte-order magic number, in the host byte order of the server,
into the authentication reply.
If the authentication reply is large enough to contain that magic
number, extract it and, from it, determine whether the server's byte
order is the opposite of the client's byte order; if it's not present,
assume the server has the same byte order.
If the two byte orders are differen, do the same byte-order fixing of
the packet contents that we do when reading a pcap file or pcapng
section with the opposite byte order, so that host-byte-order fields are
converted from the byte order of the host that sent or wrote them to the
byte order of the host that received or read them.
This change will allow a client to work with all servers, regardless of
whether they provide the byte order or not, although if the server
doesn't provide the byte order, and it happens to be the opposite of the
client's byte order, packets with a link-layer header type that contains
host-byte-order fields will not be able to be processed correctly. It
also allows clients that don't handle the byte order magic number in the
authentication reply to work with all servers, as they will just discard
what they consider extra data at the end of the reply.
(Note: fixing the byte order in the server requires that the client send
a byte order indication to the server, so *either* fix works only
between an updated client and an updated server. We already have
optional data in the authentication reply, to allow updated servers and
clients to negotiate a protocol version while still allowing updated
clients to work with older servers and older clients to work with
updated servers, so this just continues that mechanism.)
|
| |
|
|
|
|
|
|
|
| |
When retroactively fixing up capture file on-the-network lengths for
memory-apped Linux USB captures, only fix up the on-the-network length
if it has the value that would be expected from the old capture code.
In the fixup code, make sure it's both >= the proper length, as best we
can calculate it, and the captured length.
|
| |
|
|
|
|
|
|
| |
Correctly compute the "real" length for isochronous transfers.
When reading memory-mapped Linux capture files, fix up the "real" length
field, in case the file was written by a program doing a capture with
the bug.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To quote C99 section 6.5.7 "Bitwise shift operators":
The result of E1 << E2 is E1 left-shifted E2 bit positions;
vacated bits are filled with zeros. ... If E1 has a signed
type and nonnegative value, and E1 x 2^E2 is representable in
the result type, then that is the resulting value; otherwise,
the behavior is undefined.
In practice, signed vs. unsigned shouldn't make a difference, as long
as we don't get a trap of some sort in the "isn't representable" case,
but we might as well do an unsigned shift, because we're just doing
bit-banging, so we *want* unsigned - yeah, it means the result may not
have the same signedness as the value we pass in, but, as the saying
goes, bits are bits. We end up stuffing the result back into the place
from which we extracted it, so it ultimately will get back the correct
signedness.
This should keep UBSAN quiet.
While we're at it, in SWAPSHORT(), do all the bit-banging on u_int
values, and cast the result to u_short.
|
| |
|
|
|
|
|
|
| |
At one point, I remember a discussion resulting in the official name of
the next-generation replacement for pcap format being changed to
"pcapng", with no hyphen.
Make libpcap reflect that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
D-Bus packets can be up to 128MB in size, but don't allocate 128MB for
every pcap_t, or even every D-Bus pcap_t. Start out with enough to
handle 2KB packets - that should be enough for most regular network
packets - and grow the buffer as necessary to handle packets up to the
snapshot length.
Treat packets bigger than the maximum snapshot length for the link-layer
type as errors; we continue to use MAXIMUM_SNAPLEN (256KB) for most
link-layer header types, but use 128MB for DLT_DBUS, as per the above.
If the snapshot length in the file header or IDB is 0, or is > 2^31-1,
use the maximum snapshot length for the link-layer header type as the
snapshot length. The check for 2^31-1 is there because the current API
for snapshot lengths returns an int, and thus can't handle snapshot
lengths > 2^31-1, even though the field is actually unsigned.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
That means that, when reading a LINKTYPE_NFLOG file, the type and length
values are in the byte order of the host *reading* the file, rather than
the host that *wrote* the file, just as they're in the byte order of the
host capturing the traffic if you're doing a live capture of NFLOG
messages.
That way, when reading a LINKTYPE_NFLOG file and writing another one
from those packets, the type and length in the output file will be in
the byte order of the host writing the file, rather than the byte order
of the host that wrote the input file.
Export the nflog.h file containing the declarations and definitions we
need, for use by tcpdump and other programs reading LINKTYPE_NFLOG
files.
Put the bulk of the byte-swapping code into a common routine, for use by
pcap and pcap-ng readers, while we're at it.
|
| | |
|
|
|
All sections of the file must have the same byte order, so that the
result of pcap_is_swapped() is the same throughout the file; all
interfaces in the file must have the same link-layer type and snapshot
length, so that pcap_datalink() and pcap_snapshot() can return a single
value for the entire file; and all interfaces must have the same time
resolution and offset.
|
