Skip to content
GitLab
    • GitLab: the DevOps platform
    • Explore GitLab
    • Install GitLab
    • How GitLab compares
    • Get started
    • GitLab docs
    • GitLab Learn
  • Pricing
  • Talk to an expert
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
    • Switch to GitLab Next
    Projects Groups Snippets
  • Sign up now
  • Login
  • Sign in / Register
  • wireshark wireshark
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 1,367
    • Issues 1,367
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 168
    • Merge requests 168
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • External wiki
    • External wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Wireshark FoundationWireshark Foundation
  • wiresharkwireshark
  • Issues
  • #18010
Closed
Open
Issue created Mar 25, 2022 by Dave Sclarsky@sclarsky

IPFIX/cflow dissector asserts when varlen field length is zero

Summary

(Summarize the bug encountered concisely) The IPFIX/cflow dissector is incorrectly asserting when a variable length field is present with a length of zero with: 'epan\tvbuff.c:4387: failed assertion "len > 0"'. This is a legal condition and should not assert.

Steps to reproduce

Must have an IPFIX/cflow capture with a template indicating a variable length field and a flow with the same ID as the template with that field's length == 0.

What is the current bug behavior?

The assert mentioned above is observed in the packet list and packet details views.

What is the expected correct behavior?

It is perfectly legal to have a zero length field. Per RFC 7011 paragraph 7, the one byte length field is < 255.

Sample capture file

The 1st packet in the attached .k12 file is a template (258) with 11 fields, the 1st 6 are fixed length, the last 5 are variable length. The 2nd packet is has a set based on template 258 with 20 flows, but flow 13's variable length fields are empty (have length==0). Wireshark 3.6.3 cannot decode this flow (or any remaining in the packet), but 3.2.2 decodes it fine.ipfix.txt

Relevant logs and/or screenshots

(Paste any relevant logs here)

image

Build information

3.6.3 (v3.6.3-0-g6d348e4611e2)

Compiled (64-bit) using Microsoft Visual Studio 2019 (VC++ 14.29, build 30139),
with Qt 5.15.2, with libpcap, with GLib 2.66.4, with zlib 1.2.11, with Lua
5.2.4, with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.8.3, with MIT
Kerberos, with MaxMind DB resolver, with nghttp2 1.44.0, with brotli, with LZ4,
with Zstandard, with Snappy, with libxml2 2.9.10, with libsmi 0.4.8, with
QtMultimedia, with automatic updates using WinSparkle 0.5.7, with AirPcap, with
SpeexDSP (using bundled resampler), with Minizip.

Running on 64-bit Windows 10 (21H1), build 19043, with Intel(R) Core(TM) i5-8400
CPU @ 2.80GHz (with SSE4.2), with 65343 MB of physical memory, with GLib 2.66.4,
with Qt 5.15.2, with Npcap version 1.55, based on libpcap version
1.10.2-PRE-GIT, with c-ares 1.17.0, with GnuTLS 3.6.3, with Gcrypt 1.8.3, with
nghttp2 1.44.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard 1.4.0, without
AirPcap, with light display mode, without HiDPI, with LC_TYPE=English_United
States.utf8, binary plugins supported (21 loaded).
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking