| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
If we can't allocate the list of DLT_ values, format a message; if
PCAP_ERROR is returned, the caller will expect pcap_geterr() to return a
pointer to an appropriate error message.
|
| |
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some read routines don't read a single bufferful of packets and process
just those packets; if packets continue to be made available, they could
conceivably process an arbitrary number of packets.
That would mean that the packet count overflows; either that makes it
look like a negative number, making it look as if an error occurred, or
makes it look like a too-small positive number.
This can't be fixed by making the count 64-bit, as it ultimately gets
returned by pcap_dispatch(), which is defined to return an int.
Instead, if the maximum packet count argument to those routines is a
value that means "no maximum", we set the maximum to INT_MAX. Those
routines are *not* defined to loop forever, so this isn't an issue.
This should fix issue #1087.
|
| |
|
|
|
| |
Most users probably won't have it installed, so treat its absence as an
indication that they don't have an AirPcap device.
|
| |
|
|
|
|
|
|
| |
Always heck wehther the allocation succeeds, and fail if it doesn't.
Set the count of elements of the list only if the list was successfully
allocated. For stylistic consistency, also seet it after we've set all
the elements of the list.
|
| |
|
|
| |
Treat AIRPCAP_LT_UNKNOWN as meaning the link-layer type is unknown.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
The argument to the format should be airpcap_errbuf, which is where the
call to AirpcapGetDeviceList() put the raw error string.
Found by cppcheck as run by fxlb.
|
| |
|
|
|
|
| |
Moreover:
Remove some spaces before tabs.
Remove an extra blank line.
|
| |
|
|
|
|
|
|
| |
struct pcap_stat has a ps_capt member iff _WIN32 is defined, so fill in
our structure's ps_capt member iff _WIN32 is defined. (We *never* fill
it in for pcap_stat(), as we cannot guarantee, *even on Windows*, that a
structure passed to us will have them; we fill in a structure that *we*
set up for pcap_next_ex(), so we don't have to worry about that.)
|
| |
|
|
|
| |
device_is_airpcap() doesn't return -1, so there's no need to check for
it.
|
| |
|
|
|
| |
Have it set the read event, just as the NPF code does, so that, if we're
blocking on a read, pcap_breakloop will wake us up.
|
| |
|
|
|
| |
It's not guaranteed to be 802.11+radiotap; it can be configured with the
AirPcap configuration tool.
|
| |
|
|
|
| |
Some Sun code ay impose a minimum snapshot length of 96, but AirPcap
doesn't.
|
| |
|
|
| |
Found, like the previous ones, by @gvanem.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We load the AirPcap DLL at run time, rather than statically linking with
it, so we must make all calls to AirPcap routines through function
pointers set when we first load the DLL.
Call AirPcapClose() and AirpcapFreeDeviceList() through the existing
pointers.
Add a new pointer for AirpcapSetDeviceMacFlags(), set it at DLL load
time, and call through that pointer.
|
| |
|
|
|
| |
The argument in question is of type PBYTE, whatever that might be, not
char *.
|
|
|
This allows us to update the support for newer APIs in the future - and
in the present, with pcap_set_datalink() - and would allow Npcap to
remove its AirPcap support.
Add another test program, while we're at it.
|
