| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This avoids potential and, in one case (SIMH), actual collisions with
names in other libraries or in applications using libpcap.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change should avoid these cppcheck warnings:
pcap-hurd.c:77:18: warning: 'p->buffer' is of type 'void *'. When using
void pointers in calculations, the behaviour is undefined.
[arithOperationsOnVoidPointer]
pkt = p->buffer + offsetof(struct net_rcv_msg, packet)
^
pcap-hurd.c:78:8: warning: 'p->buffer+offsetof(struct net_rcv_msg,packet)'
is of type 'void *'. When using void pointers in calculations, the
behaviour is undefined. [arithOperationsOnVoidPointer]
+ sizeof(struct packet_header) - ETH_HLEN;
^
pcap-hurd.c:79:25: warning: 'p->buffer' is of type 'void *'. When using
void pointers in calculations, the behaviour is undefined.
[arithOperationsOnVoidPointer]
memmove(pkt, p->buffer + offsetof(struct net_rcv_msg, header),
^
Remove some '(u_char *)' casts accordingly.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
If it successfully read one or more packets and then got an EOF, it
would return 0 rather than the number of packets it processed.
While we're at it, change the next_packet_op routines to return 0 on EOF
and 1 on success, rather than vice versa, so that it's a bit clearer.
|
| |
|
|
| |
[skip ci]
|
| |
|
|
|
|
|
|
| |
Some programs wrote it, even though the only "difference" is that some
new sysdig block types were added. Any program that can read version
1.2 and its new block types should be able to read 1.0 files with the
same block types, so that wasn't a reason to bump the minor version
number.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The sizeof operator and alignof macro can be given a type "name" that's
anonymous, e.g. sizeof(struct { int a; char *b; }). Have
pcap_create_common() and pcap_open_offline_common() take, as arguments,
the total size of a structure containing both the pcap_t and the private
data as members, and the offset of the private data in that structure,
and define macros that calculate those given, as an argument, the data
type of the private data.
This avoids making assumptions about the alignment of those two items
within the structure; that *might* fix GitHub issue #940 if the issue is
that the ARM compiler being used does 16-byte alignment of the private
structure, rather than the 8-byte alignment we were wiring in.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We don't currently use it, but 1) we would do so in the future if we
ever fully support pcapng and 2) Apple will do so if they pick up the
patch I'll provide once I file the bug originally reported as
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16573
as an Apple bug, so this makes one less place where Apple's libpcap fork
would differ from our libpcap if they pick up 1.10 when it's released.
(This also keeps them from claiming that change is licensed under the
APSL, as we got it first, and none of *our* code is licensed under the
APSL.)
|
| |
|
|
| |
Probably a copy & paste error.
|
| | |
|
| | |
|
| |
|
|
| |
fault; but doing the check results in a more consistent error
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Require Visual Studio 2015 or later; fail if we don't have it, and
remove checks for older versions.
That means we have C99-compliant snprintf() and vsnprintf(); require
them when configuring for UN*X, and then use them directly, rather than
having wrappers for systems lacking them.
If we're using MSVC, skip the tests for options to request C99
compatibility - either we have VS 2015, which is sufficient, or we
don't, in which case we fail.
|
| |
|
|
|
|
| |
C99 support it and also Visual Studio VS 2015 and after.
No more need for PRIsize format.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the snapshot length is 0, or doesn't fit in an int, we adjust it. If
we see an IDB after the first IDB, perform the same adjustment on *its*
snapshot length before comparing it with the adjusted snapshot length
for the first IDB.
(Yes, this means that if the IDBs have different snapshot lengths, but
they both adjust to the same value, they will be treated as equal.
That's not a bug, that's a feature - the only reason we insist that they
be the same is so that the value that pcap_snapshot() returns, which,
for pcapng files, is the adjusted snapshot length for the first IDB,
applies to all IDBs, so the IDBs all just have to have the same adjusted
snapshot length.)
This should fix GitHub issue #832.
|
| |
|
|
|
|
|
|
|
|
| |
Assigning it to p->snapshot, and then checking whether the result is
negative, should work in practice, but it gets unsigned-behavior
warnings. Test beforehand whether it's valid, and only assign it to
p->snapshot if it is.
This should address the pcap.c part of GitHub issue
the-tcpdump-group/tcpdump#785.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently, in some C implementations, attempting to do an fread() into
a variable of a 32-bit unsigned integral type with a size of 1 and a
count of 4 returns 0 with an EOF indication; see GitHub pull request
We can make the size be the size of the variable and the count be 1, but
that means that the count returned by an fread() terminated by an EOF
will be 0, not the number of bytes successfully read, so the "truncated
dump file" message will give an invalid count:
tcpdump: truncated dump file; tried to read 4 file header bytes,
only got 0
If, instead, we read into an array of 4 bytes, with a size of 1 and a
count of 4, we'll get the right short count back.
Pass the byte array to the file-type-specific "is this a file of this
type?" routines, so that if we add support for files where the magic
number isn't byte-order dependent (e.g., Microsoft Network Monitor), we
can handle them more cleanly (check for the standard magic number as a
4-byte array, rather than as its numerical value in both the host's byte
order and the byte-swapped byte order).
|
| |
|
|
|
|
|
| |
I'm not sure what files, if any, required the Wireshark library to round
up the block length, but it was only for packet blocks, not all blocks.
We'll add it *if* there are files with which there are problems.
|
| |
|
|
|
|
|
|
| |
Handle the block total length not being a multiple of 4. Pad it to a
multiple of 4 if possible; fail if that would exceed 2^32-1.
Do the same for the total length in the trailer, and make sure the
(padded, if necessary) lengths in the header and trailer match.
|
| |
|
|
|
|
|
|
|
|
| |
Start out with the 16 MiB maximum block size, check against that when
trying to read the SHB at the beginning of the file, and then increase
the maximum block size if we see an IDB with a snaplen that would result
in a bigger maximum block size.
When reading a block, we don't need to check against the maximum block
size unless we need to increase the block size.
|
| |
|
|
|
|
|
|
|
|
| |
size_t may be bigger than unsigned long, so don't just cast to unsigned
long and print with %lu". (In practice, the value is unlikely to be
bigger, but this is cleaner.)
We could use %zu on UN*X, as we require C99 support and C99 requires
support for z as a size modifier, but MSVC doesn't support z as a size
modifier until Visual Studio 2017.
|
| |
|
|
| |
As a follow-up to comit 5f2a5c03e0f91bc2dc2ae33838db273dd6c7d8d9.
|
| |
|
|
|
| |
It's calculated as the quotient of two 64-bit values, and is used only
in 64-bit calculations, so it should be made 64-bit as well.
|
| |
|
|
|
| |
This allows higher-resolution time stamps; we now allow powers of 2 up
to 2^-63 seconds and powers of 10 up to 10^-19.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ISO C says that if a left shift is done that's the full bit width of the
operand being shifted, the behavior is undefined. In practice, it
probably just does a single shift instruction, which does whatever it
does with such a shift on the processor on which you're running; that is
likely either to be "all the bits are cleared" or "no shift is done",
but we can't rely on "all the bits are cleared".
So, instead, check the time stamp resolution exponent before using it,
and reject it if it'll result in a resolution that doesn't fit into a
32-bit quantity.
Use uint8_t for an 8-bit unsigned integral quantity while we're at it.
|
| |
|
