Skip to content

GitLab

Switch branch/tag
  1. 19 Oct, 2021 2 commits
    • Pascal Quantin's avatar
      BSSMAP LE: fix dissection of APDU in 2 messages · 84da7c37
      Pascal Quantin authored 
      The APDU information element in Perform Location Request and Perform
Location Information messages is optional and not mandatory, as seen in
3GPP 49.031. This commit fixes a regression introduced in ga6ed603f.

Closes #17667


(cherry picked from commit 017eb216)
      84da7c37
    • Guy Harris's avatar
      socketcan: support the CANFD_FDF flag for identifying CAN FD frames. · b26fce1f
      Guy Harris authored 
      The Linux SocketCAN header now uses the formerly-reserved byte in the
SocketCAN header after the "payload length" field as an "FD flags"
field, with a flag bit reserved to indicate whether the frame is a
classic CAN frame or a CAN FD frame, with two other bits giving frame
information for FD frames.

For LINKTYPE_CAN_SOCKETCAN, use that flag bit to determine whether the
frame is classic CAN or CAN FD.  As some older LINKTYPE_CAN_SOCKETCAN
captures have SocketCAN headers in which the fields after the "payload
length" field were uninitialized, so trust that thge "FD flags" was
filled in, rather than possibly randomly uninitialized, only if the only
bits set in that field are the bits defined to be in that field and the
two reserved bytes after it are zero.

This will be needed when the current main-branch libpcap is released, as
it uses LINKTYPE_CAN_SOCKETCAN rather than LINKTYPE_LINUX_SLL for
ARPHRD_CAN devices; we add it now to future-proof the Wireshark releases
to which this is being committed.  It also handles what existing CAN FD
captures using LINKTYPE_CAN_SOCKETCAN exist.

For LINKTYPE_LINUX_SLL frames, we have the protocol field to distinguish
between classic CAN and CAN FD, so we use that to determine the frame
type, rather than looking at the CANFD_FDF flag.

dissect_socketcan_common() now handles both classic CAN and CAN FD
frames.

(backported from commit 39604740)
      b26fce1f
  3. 17 Oct, 2021 1 commit
  5. 14 Oct, 2021 2 commits
    • Guy Harris's avatar
      dumpcap: do all packet counting in capture_loop_wrote_one_packet(). · 5f4dbf17
      Guy Harris authored 
      We need to update global_ld.inpkts_to_sync_pipe as soon as we've written
a packet to the current capture file.  If we're writing to multiple
files, then, if we delay counting until after we switch to another file,
the packet-count message we send to the parent before switching won't
include the packet, and the first packet-count message we send to the
parent *after* switching *will* include the packet, which could mean the
parent will try to read more packets than there are in the new file, in
which case it'll get an EOF and, at least in the case of TShark, treat
that as an error and stop capturing.

This should fix issue #17654.

While we're at it, don't send a "we have no packets" packet-count
message even for the packet-count message we send just before switching
files.


(cherry picked from commit 79920cbc)
      5f4dbf17
    • Chuck Craft's avatar
      dumpcap: double received count when using threads · 0e6cefc8
      Chuck Craft authored and Guy Harris's avatar Guy Harris committed 
      Closes #17089


(cherry picked from commit fefad2e7)
      0e6cefc8
  7. 13 Oct, 2021 1 commit
  9. 10 Oct, 2021 2 commits
  11. 09 Oct, 2021 1 commit
  13. 08 Oct, 2021 1 commit
    • João Valverde's avatar
      dfilter: Fix parsing of octal character escape sequences · 81f71afc
      João Valverde authored and João Valverde's avatar João Valverde committed 
      Octal escape sequences \NNN can have between 1 and 3 digits. If
the sequence had less than 3 digits the parser got out of sync
with an incorrect double increment of the pointer and errors out
parsing sequences like \0, \2 or \33.

Before:
  Filter: ip.proto == '\33'
  dftest: "'\33'" is too long to be a valid character constant.

After:
  Filter: ip.proto == '\33'

  Constants:
  00000 PUT_FVALUE	27 <FT_UINT8> -> reg#1

  Instructions:
  00000 READ_TREE		ip.proto -> reg#0
  00001 IF-FALSE-GOTO	3
  00002 ANY_EQ		reg#0 == reg#1
  00003 RETURN

Fixes #16525.


(cherry picked from commit 9dab2280)
      81f71afc
  15. 07 Oct, 2021 1 commit
  17. 06 Oct, 2021 3 commits
  19. 05 Oct, 2021 3 commits
    • Gerald Combs's avatar
      GitLab CI: Restrict our merges to release-3.4. · eb2642f4
      Gerald Combs authored
      eb2642f4
    • John Thacker's avatar
      BT-DHT: Test packets even if the dissector is set · 64b66b6e
      John Thacker authored and Wireshark GitLab Utility's avatar Wireshark GitLab Utility committed 
      BitTorrent clients use the same UDP conversation for both DHT and
uTP, switching back and forth between the two at connection start.
So even if the dissector has been set for the conversation or
ports to BT-DHT, test the packet and reject it if not DHT in order
to give the uTP dissector a chance. Fix #17626


(cherry picked from commit 5c185238)
      64b66b6e
    • John Thacker's avatar
      wiretap: camins, vwr: Stop heuristics after 1GiB · 8b2fda62
      John Thacker authored and Jaap Keuter's avatar Jaap Keuter committed 
      Very large 64 bit files are supported, so the CAM Inspector and
Ixia Veriwave heuristics, which are fairly weak and either always
(CAM Inspector) or possibly (Veriwave) try to read the entire file
should stop their heuristics and make a decision after some reasonable
length.

Without this, the GUI freezes for seconds, minutes, or even hours
by merely clicking on a large file in the file chooser, as
wtap_open_offline attempts to determine the file type. The same issue
occurs in capinfos, captype, tshark, editcap, etc.

In addition, previously the CAM Inspector heuristics could give the wrong
result on very large files, because 10 * invalid_pairs could overflow
its guint32 and then end up comparing as less than valid_pairs.

Fix #17620


(cherry picked from commit e05f7046)
      8b2fda62
  21. 04 Oct, 2021 23 commits