Turn the sequence of details to supply in an Npcap bug into a list, with
one element per line, and provide the interface name, Windows version
string, and Npcap version string. Put that into a common routine.
Give a whole bunch of details to put into the bug, in the (vain?) hope
that the user will put them in the bug, to try to help Daniel and
possibly Microsoft networking stack folk figure out what's happening.
(Remove an extra report_capture_error() left over from the previous
commit.)
dumpcap can capture on more than one interface at a time. If the
capture stops due to an error on an interface, report the name of the
interface on which the error occurred.
This adds support for handling SCS Descriptors and MSCS descriptors and add
more handling of TCLAS.
Change-Id: Ibe91a612c2dc8c325c3223633610b954ea2fda3d
Use the new stat_tap_find_table function during init to check if our
statistics table already exists.
If so, we can safely assume that its rows have already beend initialized.
All we have to do is clear the data that was collected by the tap.
If the init function is called and the statistics table already exists, it's
sufficient to clear the data that was collected when the tap parsed the
packets.
Fixes: a5207b541e ("mtp3: create the statistics table only once")
dot11decrypt.c:1775:27: error: ‘ptk_len’ may be used uninitialized in
this function [-Werror=maybe-uninitialized]
sa->wpa.ptk_len = (INT)ptk_len;
^
Change-Id: I705007a8b351c333dc1c8cb1d455ea2f0976c964
This change adds code to allow the selection of a configuration
profile during sharkd start by adding a -C command line option.
A new -a option has been added to specify the api service
endpoint e.g. tcp:127.0.0.1:4446
The change also adds version display (-v) and help display (-h) options.
These additions have been made in a way to ensure that the original
command line options still work correctly to maintain backward
compatibility.
The new options have been added using the getopt_long(...) function
that is used by tshark to simplify the addition of further command
line options.
Closes#17222
Commit f582c85623 ("netlink: use value retrieval with proper encoding")
changed the conversion of timestamp field and with it the field is
displayed incorrectly.
In the kernel the timestamp field is encoded in nanoseconds using 64 bits.
Change the code to the way it was written before which is compatible
with kernel coding.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
For "PacketReceivePacket error: The device has been removed. (1617)",
report the error in that fashion, indicate that the interface is no
longer attached, *and* suggest that this may be an Npcap bug and that
the user should report it as such; give the URL for the Npcap issue
list.
For "The other host terminated the connection", report the error in that
fashion, and suggest that it might be a problem with the host on which
the capture is being done.
Hopefully this will mean fewer bugs filed as *Wireshark* bugs for those
issues.
(And, with any new capture API in libpcap, these should all turn into
specific PCAP_ERROR_ codes, to make it easier to detect them in callers
of libpcap.)
Use the new stat_tap_find_table function during init to check if our
statistics table already exists.
If so, we can safely assume that its rows have already beend initialized.
All we have to do is clear the data that was collected by the tap.
Use the new stat_tap_find_table function during init to check if our
statistics table already exists.
If so, we can safely assume that its rows have already beend initialized.
All we have to do is clear the data that was collected by the tap.
Use the new stat_tap_find_table function during init to check if our
statistics table already exists.
If so, we can safely assume that its rows have already beend initialized.
All we have to do is clear the data that was collected by the tap.
Use the new stat_tap_find_table function during init to check if our
statistics table already exists.
If so, we can safely assume that its rows have already beend initialized.
All we have to do is clear the data that was collected by the tap.
Sip uses two different statistics tables. We check for each one if it
already exists. If so, we don't populate the rows again, we just clear
the data that was collected when the tap parsed the packets.
Fixes: b00c3bd742 ("sip: create the statistics tables only once")
If the init function is called and the statistics table already exists, it's
sufficient to clear the data that was collected when the tap parsed the
packets.
Fixes: b49b95af65 ("rpc: create the statistics table only once")
If the init function is called and the statistics table already exists, it's
sufficient to clear the data that was collected when the tap parsed the
packets.
Fixes: f21f1c292a ("dhcp: create the statistics table only once")
If the init function is called and the statistics table already exists, it's
sufficient to clear the data that was collected when the tap parsed the
packets.
Fix a typo in a comment while at it.
Fixes: 8963dff518 ("ansi_a: dtap statistics: create the table only once")
Commit f4ac70818a updated the init function to use stat_tap_find_table and
create the statistics table only when it doesn't already exist.
However, if the table does already exist, its rows are still populated
again. If the table rows contain data that is allocated dynamically by
g_malloc or g_strdup, populating the table again (without freeing its rows
before) causes a memory leak.
If the init function is called and the statistics table already exists, all
we have to do is clear the data that was gathered when the tap parsed the
packets. This is what the stat_tap_reset_table_cb function does.
Fixes: f4ac70818a ("stat_tap_table_ui: create tables only once during init")
In answer to the question "How do we support multiple backends?", this
is the answer - what they mean is "how do we support multiple
encapsulation types for the *same* file format", and the answer is "you
have one dump open routine that writes the appropriate encapsulation
type in the header, depending on the encapulation type, and you have one
dump write routine that generates the appropriate packet header and
writes out the packet, depending on the encapsulation type".
Fix the generation of the packet header when writing H1 and H4 packets,
and *don't* strip off the first octet of the packet data when writing H1
packets - that octet isn't generated when reading H1 packets, it's read
from the file.
Tested by running several H1 and H4 captures through "editcap -F
btsnoop" and making sure that the files are identical.
'wlan.s1g.twt_information.next_twt' exists multiple times with incompatible types: FT_UINT48 and FT_UINT32
'wlan.s1g.twt_information.next_twt' exists multiple times with incompatible types: FT_UINT64 and FT_UINT48
packet-smc.c:595:4: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-smc.c:664:4: warning: Value stored to 'offset' is never read [deadcode.DeadStores]
packet-opa-mad.c:2816:12: warning: Although the value stored to 'local_offset' is used in the enclosing expression, the value is never actually read from 'local_offset'
Guy Harris