Reproducer captures are essential for developers. Move the
request to the top of the template and be more forceful
stressing the importance of capture files to fix bugs
and implement feature requests.
Sort the model by Most Recently Used, instead of Most Recently
Added. This improves the usability of the combobox and prevents
the most used filters from being pushed out of the list by newer
entries.
Add a monotonic increasing timestamp to each row, set it
when each entry is created or updated, and use it to sort the model.
Fixes#18997.
Because existing code is dependant on the behavior that a null/empty
filter is a sort of valid input (presumably to avoid having to check
for that condition explicitly) add back that behavior to avoid a lot
of potential hidden cascading failures.
Fail compilation if error pointer is set. Remove other redundant
failure flags.
Remove lemon %parse_failure block. This should be unnecessary.
I think this is only useful if we are doing error recovery,
which we aren't.
Replace the Python repr() syntax and the overly-long standard output
markers.
This format should make it easier to read the logs and copy-paste the
commands.
Matter is an interoperable application-layer protocol to control IoT smart
home devices, maintained by the Connectivity Standards Alliance.
This dissector currently only parses the outer "message headers" and
"payload headers". The protocol also has encryption, a TLV encoding for
the payload, the application semantics of those TLVs, fragmented
payloads in UDP, support for TCP, etc. which is all missing from the
dissector for now, so there's still lots to do.
There is no defined port number (implementations pick an arbitrary port and
advertise it over mDNS), so I'm only making Matter available in "Decode As"
for now. In the future it would be nice to get the port from the mDNS
answers.
Some fields in the message header can be encrypted by "message privacy".
Since we don't support decryption yet, these currently show up as a
single "encrypted headers" field if the "message privacy" flag is set.
This patch adds basic parsing for audio out and clipboard redirection, only the
kind of message is parsed, not the complete body, but that already gives some
useful informations.
Warning: epan/dissectors/packet-ieee80211.c hf_ieee80211_ndp_annc_variant filter= wlan.ndp.token.variant - mask has odd number of digits 0x003 expected max for FT_UINT8 is 2
Warning: epan/dissectors/packet-ieee80211.c hf_ieee80211_ndp_annc_variant filter= wlan.ndp.token.variant 0x003 with len 3 but type FT_UINT8 indicates max of 2
Warning: epan/dissectors/packet-ieee80211.c hf_ieee80211_twt_individual_flow filter= wlan.twt.individual_flow - mask with non-contiguous bits 0x67 ( 0x67 )
Warning: epan/dissectors/packet-ieee80211.c hf_ieee80211_eht_tx_max_nss_20mhz_8_9 : - filter "wlan.eht.supported_eht_mcs_bss_non_sta.rx_max_nss_supports_eht_mcs_8_9" appears consecutively - labels are "RX Max NSS That Supports EHt-MCS 8-9" and "TX Max NSS That Supports EHt-MCS 8-9"
Warning: epan/dissectors/packet-ieee80211.c hf_ieee80211_eht_tx_max_nss_20mhz_10_11 : - filter "wlan.eht.supported_eht_mcs_bss_non_sta.rx_max_nss_supports_eht_mcs_10_11" appears consecutively - labels are "RX Max NSS That Supports EHt-MCS 10-11" and "TX Max NSS That Supports EHt-MCS 10-11"
Warning: epan/dissectors/packet-ieee80211.c hf_ieee80211_eht_tx_max_nss_20mhz_12_13 : - filter "wlan.eht.supported_eht_mcs_bss_non_sta.rx_max_nss_supports_eht_mcs_12_13" appears consecutively - labels are "RX Max NSS That Supports EHt-MCS 12-13" and "TX Max NSS That Supports EHt-MCS 12-13"
Warning: epan/dissectors/packet-ieee80211-radiotap.c hf_radiotap_eht_data1_ru_mru_index filter= radiotap.eht.data_1.ru_mru_index - mask has odd number of digits 0x0001FE0 expected max for FT_UINT32 is 8
Warning: epan/dissectors/packet-ieee80211-radiotap.c hf_radiotap_s1g_ndp_ps_poll_udi_2m filter= radiotap.s1g.ndp.ps_poll.udi - mask has odd number of digits 0x1FFE00000 expected max for FT_UINT40 is 10
On Linux, look for an error message of "socket: Address family not
supported by protocol"; if we see it, that's EAFNOTSUP, which means
either that 1) your kernel doesn't have PF_PACKET support configured in
or 2) this is a Flatpak package of Wireshark that's "helpfully" been
sandboxed. Display a secondary error message indicating one of those is
likely the problem; mention the Flatpak one first, as that's more likely
than the second (if you can still configure PF_PACKET sockets out, it's
not the default, so it's unlikely to be the case).
See issue #19008.
Expand the set of CAP_DEVICE_OPEN_ errors and warnings to include
specific errors for many of the errors and warnings libpcap returns.
(This doesn't include the errors that would definitely either be
Wireshark or libpcap bugs, such as PCAP_ERROR_NOT_ACTIVATED and
PCAP_ERROR_ACTIVATED.)
Don't give "make sure you have the right permissions" secondary error
messages if we know that the error isn't a permissions error.
For the PCAP_ERROR_ codes that we handle individually, don't bother with
the pcap_statustostr() string, as it would duplicate the error message
we're providing.
For the PCAP_ERROR_ codes we *don't* handle individually, give both the
pcap_statustostr() string and the pcap_geterr() string, to give the user
as much information as possible (even if that's just so that they can
give *us* as much information as possible to figure out what the problem
is).
This should remove the "how to support packet capturing on Debian"
message for "sorry, we don't support PF_PACKET sockets" error that shows
up if either 1) your kernel doesn't have PF_PACKET support configured in
or 2) this is a Flatpak package of Wireshark that's "helpfully" been
sandboxed. See issue #19008.
"Over TCP" dissectors are usable only over byte-stream protocols, as
they have to carve individual PDUs out of a byte stream, doing
reassembly if necessary; dissectors registered in the media_type
dissector table get a reassembled PDU handed to them, and all the
special reassembly stuff they do isn't necessary and may cause
dissection not to work.
Exposing the fvalue_t implementation is exposing internal
details of the implementation. Fix that by making the fvalue_t
internal to the ftypes implementation and using setters/getters
where necessary.
Fvalues are immutable objects. This isn't strictly true in
the case of FT_BYTES because of widespread use of
proto_item_set_len() but that can be worked around and using
GBytes should be more convenient for callers and make some
aspects of the implementation simplers (others not).
João Valverde