[Wireshark-bugs] [Bug 16470] The IEEE 802.3br frame preemption dissector is confused by unrelated packets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16470

Jaap Keuter  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #16 from Jaap Keuter  ---
Although missing from the Release Notes, this bug fix was included in 3.2.3.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with a use-after-free

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

--- Comment #12 from Peter Wu  ---
While this is a bug, the problem does not seem to be very severe. It will only
crash when built with ASAN. It is a correctness issue.

Prior to the use-after-free, the file was already closed, so no data loss
should occur. The worst thing that can happen when ASAN crashes is that the
temporary file is not deleted in cf_close (which calls wtap_close first).

void
wtap_close(wtap *wth)
{
wtap_sequential_close(wth);

if (wth->subtype_close != NULL)
(*wth->subtype_close)(wth);

if (wth->random_fh != NULL)
file_close(wth->random_fh);
// at this point the file is closed and no data loss should occur.

g_free(wth->priv);

if (wth->fast_seek != NULL) {
g_ptr_array_foreach(wth->fast_seek, g_fast_seek_item_free, NULL);
g_ptr_array_free(wth->fast_seek, TRUE);
}

// use-after-free in the next line
wtap_block_array_free(wth->shb_hdrs);
wtap_block_array_free(wth->nrb_hdrs);
wtap_block_array_free(wth->interface_data);
wtap_block_array_free(wth->dsbs);

g_free(wth);
}

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with a use-after-free

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

Peter Wu  changed:

   What|Removed |Added

 Status|IN_PROGRESS |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with a use-after-free

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

--- Comment #11 from Peter Wu  ---
Fixed in
v3.3.0rc0-974-ga0600e02a9
v3.2.3-1-gf7537ea094
v3.0.10-1-geb0680d0b4

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with a use-after-free

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

--- Comment #10 from Gerrit Code Review  ---
Change 36757 merged by Peter Wu:
tshark: fix use-after-free while closing a live capture file

https://code.wireshark.org/review/36757

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with a use-after-free

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

--- Comment #9 from Gerrit Code Review  ---
Change 36757 had a related patch set uploaded by Peter Wu:
tshark: fix use-after-free while closing a live capture file

https://code.wireshark.org/review/36757

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with a use-after-free

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

--- Comment #7 from Gerrit Code Review  ---
Change 36756 had a related patch set uploaded by Peter Wu:
tshark: fix use-after-free while closing a live capture file

https://code.wireshark.org/review/36756

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with a use-after-free

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

--- Comment #6 from Gerrit Code Review  ---
Change 36755 merged by Peter Wu:
tshark: fix use-after-free while closing a live capture file

https://code.wireshark.org/review/36755

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with a use-after-free

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

--- Comment #8 from Gerrit Code Review  ---
Change 36756 merged by Peter Wu:
tshark: fix use-after-free while closing a live capture file

https://code.wireshark.org/review/36756

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16488] New: Decode and filter SIP Display Information uniquely for "To", "From", "Contact" and "PSID" headers

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16488

Bug ID: 16488
   Summary: Decode and filter SIP Display Information uniquely for
"To", "From", "Contact" and "PSID" headers
   Product: Wireshark
   Version: 3.2.2
  Hardware: x86-64
OS: Windows 10
Status: UNCONFIRMED
  Severity: Enhancement
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: khcoom...@hotmail.com
  Target Milestone: ---

Build Information:
3.2.2 (v3.2.2-0-ga3efece3d640)

Compiled (64-bit) with Qt 5.12.6, with WinPcap SDK (WpdPack) 4.1.2, with GLib
2.52.3, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, 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.39.2, with brotli, with LZ4, with
Zstandard, with Snappy, with libxml2 2.9.9, with QtMultimedia, with automatic
updates using WinSparkle 0.5.7, with AirPcap, with SpeexDSP (using bundled
resampler), with SBC, with SpanDSP, with bcg729.

Running on 64-bit Windows Server 2016 (1607), build 14393, withIntel(R)
Xeon(R) CPU E7- 8870  @ 2.40GHz (with SSE4.2), with 8191 MB of physical memory,
with locale English_United States.1252, with light display mode, without HiDPI,
with Npcap version 0.9986, based on libpcap version 1.9.1, with GnuTLS 3.6.3,
with Gcrypt 1.8.3, with brotli 1.0.2, without AirPcap, binary plugins supported
(19 loaded).

Built using Microsoft Visual Studio 2019 (VC++ 14.24, build 28316).

--
When decoding the From, To, Contact, and P-Asserted-Identity headers, the
display information for each of these headers has the same field name, that is
"SIP Display info" (or sip.display.info). If I wanted to filter for a certain
name, then filtering at a high level for sip.display.info might be useful.  But
it would be more useful yet to be able to drill down to filter SIP packets on
only certain headers such as the From or To header Display Information.

So, I'm asking for a unique field for each header's display info like these:

 sip.from.display.info
 sip.to.display.info
 sip.P-Asserted-Identity.display.info
 sip.contact.display.info

Where this would really come in handy is when applying these fields as columns.
 Today if I do this, I will see 3 or 4 names in a single "SIP Display info"
column when I'd really like to pick which fields to display in their own
columns, such as the From and/or PSID display name when I'm testing for proper
Caller ID name, which I often do.

Thanks!
Kenneth

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with a use-after-free

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

Guy Harris  changed:

   What|Removed |Added

 Status|CONFIRMED   |IN_PROGRESS

--- Comment #5 from Guy Harris  ---
(In reply to Gerrit Code Review from comment #4)
> Change 36755 had a related patch set uploaded by Peter Wu:
> tshark: fix use-after-free while closing a live capture file
> 
> https://code.wireshark.org/review/36755

Yes, that's the ticket; I was in the middle of doing a compile with ASAN to
test a similar fix, but I just moved cf_close() right above wtap_cleanup().
Moving it all the way to the top of the clean_exit block is probably the right
thing to do.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with a use-after-free

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

Peter Wu  changed:

   What|Removed |Added

Summary|tshark live capture |tshark live capture
   |finishes with an|finishes with a
   |out-of-bounds read  |use-after-free

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with an out-of-bounds read

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

--- Comment #4 from Gerrit Code Review  ---
Change 36755 had a related patch set uploaded by Peter Wu:
tshark: fix use-after-free while closing a live capture file

https://code.wireshark.org/review/36755

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with an out-of-bounds read

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

--- Comment #3 from Peter Wu  ---
Clarification: it is a use-after-free, not just an out-of-bounds read.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with an out-of-bounds read

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

--- Comment #2 from Guy Harris  ---
(In reply to Peter Wu from comment #1)
> I did reproduce this on v3.2.3 as well, reverting the offending commit
> avoids the issue.

And leaks file descriptors.

Let's try to do something better than that.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] tshark live capture finishes with an out-of-bounds read

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

--- Comment #1 from Peter Wu  ---
I did reproduce this on v3.2.3 as well, reverting the offending commit avoids
the issue.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16457] tshark logs: "...could not be opened: Too many open files."

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16457

Peter Wu  changed:

   What|Removed |Added

   See Also||https://bugs.wireshark.org/
   ||bugzilla/show_bug.cgi?id=16
   ||487

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16487] New: tshark live capture finishes with an out-of-bounds read

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16487

Bug ID: 16487
   Summary: tshark live capture finishes with an out-of-bounds
read
   Product: Wireshark
   Version: 3.2.3
  Hardware: All
OS: All
Status: CONFIRMED
  Severity: Major
  Priority: Medium
 Component: TShark
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: pe...@lekensteyn.nl
  Target Milestone: ---

Build Information:
TShark (Wireshark) 3.3.0 (v3.3.0rc0-972-g43c4e886256a)

Copyright 1998-2020 Gerald Combs  and contributors.
License GPLv2+: GNU GPL version 2 or later

This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with libpcap, with POSIX capabilities (Linux), with libnl 3,
with GLib 2.62.2, with zlib 1.2.11, without SMI, with c-ares 1.15.0, with Lua
5.2.4, with GnuTLS 3.6.12 and PKCS #11 support, with Gcrypt 1.8.5, with MIT
Kerberos, with MaxMind DB resolver, with nghttp2 1.39.2, with brotli, with LZ4,
with Zstandard, with Snappy, with libxml2 2.9.10.

Running on Linux 5.5.6-arch1-1, with Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz
(with SSE4.2), with 64143 MB of physical memory, with locale en_US.UTF-8, with
libpcap version 1.9.1 (with TPACKET_V3), with GnuTLS 3.6.12, with Gcrypt 1.8.5,
with brotli 1.0.7, with zlib 1.2.11, binary plugins supported (0 loaded).

Built using clang Clang 9.0.1 .
--
On exiting tshark after a live capture, it crashes due to an out-of-bounds
read.

Steps to reproduce:
1. cmake -GNinja -DENABLE_ASAN=1
2. ninja tshark dumpcap randpktdump
3. tshark -i randpkt -c1
(This is a minimum non-interactive reproducer that does not require capture
permissions. It can also be reproduced with a real interface.)

Expected result:
Capture stops with no issues.

Actual result:
valgrind reports two invalid reads, ASAN blows up (see trace at the end).

More information:
This issue was introduced in commit v3.2.3rc0-57-g84cf682883 (fixing Bug 16457)
which has unfortunately been backported and released today. Apart from git
master, it affects 3.0.10 and 3.2.3 only. I initially triggered it on macOS and
could reproduce this regression on Linux.

ASAN trace:
$ tshark -i randpkt -c1
Capturing on 'Random packet generator: randpkt'
1   0.00  → 0x7ad4   IEEE 802.15.4 3595 Reserved, Dst:
0x7ad4[Malformed Packet: length of contained item exceeds length of containing
item][Malformed Packet]
1 packet captured
=
==140142==ERROR: AddressSanitizer: heap-use-after-free on address
0x60400550 at pc 0x7efc27003dc5 bp 0x7ffeed6852c0 sp 0x7ffeed6852b8
READ of size 8 at 0x60400550 thread T0
#0 0x7efc27003dc4 in wtap_block_free_option wiretap/wtap_opttypes.c:200:16
#1 0x7efc26ffa024 in wtap_block_free_options wiretap/wtap_opttypes.c:224:9
#2 0x7efc26ff9c60 in wtap_block_free wiretap/wtap_opttypes.c:236:9
#3 0x7efc26ffa251 in wtap_block_array_free wiretap/wtap_opttypes.c:250:9
#4 0x7efc26ff3c37 in wtap_close wiretap/wtap.c:1254:2
#5 0x56238f9b7fc2 in cf_close tshark.c:4248:5
#6 0x56238f9adb35 in main tshark.c:2284:3
#7 0x7efc265f7022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
#8 0x56238f88602d in _start (run/tshark+0x13d02d)

0x60400550 is located 0 bytes inside of 40-byte region
[0x60400550,0x60400578)
freed by thread T0 here:
#0 0x56238f927229 in free (run/tshark+0x1de229)
#1 0x7efc268720cd in array_free
/usr/src/debug/build/../glib/glib/garray.c:386:7
#2 0x7efc27008c7e in wtap_opttypes_cleanup wiretap/wtap_opttypes.c:1275:17
#3 0x7efc26ff8b9d in wtap_cleanup wiretap/wtap.c:1624:2
#4 0x56238f9adb24 in main tshark.c:2282:3
#5 0x7efc265f7022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
#6 0x56238f88602d in _start (run/tshark+0x13d02d)

previously allocated by thread T0 here:
#0 0x56238f927559 in malloc (run/tshark+0x1de559)
#1 0x7efc26843929 in g_malloc
/usr/src/debug/build/../glib/glib/gmem.c:99:13
#2 0x7efc268248f3 in g_slice_alloc
/usr/src/debug/build/../glib/glib/gslice.c:1024:11
#3 0x7efc268788d4 in g_array_sized_new
/usr/src/debug/build/../glib/glib/garray.c:194:11
#4 0x7efc270080ee in wtap_opttype_block_register
wiretap/wtap_opttypes.c:100:26
#5 0x7efc27004f2a in wtap_opttypes_initialize
wiretap/wtap_opttypes.c:1224:5
#6 0x7efc26ff8994 in wtap_init wiretap/wtap.c:1607:2
#7 0x56238f9a38da in main tshark.c:916:3
#8 0x7efc265f7022 in __libc_start_main (/usr/lib/libc.so.6+0x27022)
#9 0x56238f88602d in _start (run/tshark+0x13d02d)

SUMMARY: AddressSanitizer: heap-use-after-free wiretap/wtap_opttypes.c:200:16
in wtap_block_free_option
Shadow bytes around the buggy address:
  0x0c087fff8050: fa fa fd fd fd fd fd fa fa fa fd fd fd fd fd 

[Wireshark-bugs] [Bug 16474] [oss-fuzz] #21541: Stack-overflow in fAbstractSyntaxNType

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16474

Gerald Combs  changed:

   What|Removed |Added

   See Also||http://cve.mitre.org/cgi-bi
   ||n/cvename.cgi?name=CVE-2020
   ||-11647

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16470] The IEEE 802.3br frame preemption dissector is confused by unrelated packets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16470

--- Comment #15 from Guy Harris  ---
(In reply to Jaap Keuter from comment #13)
> (In reply to Guy Harris from comment #10)
> > Block 6 has a length of 646 bytes; that is *not* a multiple of 4. 
> 
> The capture file dissector could use an expert item here?

It has one in the master branch:

https://code.wireshark.org/review/36746

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16281] Only ACKs, but no DATA frames are visible in -> TCP Stream Graph -> Time Sequence (tcptrace)

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16281

--- Comment #25 from Allen L  ---
Created attachment 17716
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17716=edit
tcptrace 3.3.0rc0-700-g76c8c3ef0e7e

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16281] Only ACKs, but no DATA frames are visible in -> TCP Stream Graph -> Time Sequence (tcptrace)

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16281

Allen L  changed:

   What|Removed |Added

 CC||a11en...@pacbell.net

--- Comment #24 from Allen L  ---
It doesn't work in 3.2.2, but it is working in development version
3.3.0rc0-700-g76c8c3ef0e7e.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16470] The IEEE 802.3br frame preemption dissector is confused by unrelated packets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16470

--- Comment #14 from Jaap Keuter  ---
(In reply to levente.meszaros from comment #11)
> I agree with your analysis. With my last comment I only wanted to note that
> if the interface is not looked at when dissecting the conversation, then the
> dissector may be confused again by completely unrelated frames on other
> interfaces.

Yes, but this is a more generic problem which comes up at every layer in the
protocol stack. Image different VLANs, Provider bridges, MPLS labels, IP-in-IP,
tunnels of all kinds, etc.

Currently there are limited features incorporated to handle this, the so called
conversation mechanism. It basically does this by means of endpoint
identification, which started with TCP and UDP connections, but is being
stretched to cover other endpoint types as well. Unfortunately this design can
only bring us so far, to create a solid solution a partial redesign of the
dissection engine is needed, to create the concept of context, starting at the
lowest layer (phy).

BTW: current solution works by the grace of the interface direction (In/Out)
being present for the frames in the capture file. If not then this won't work
either.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16470] The IEEE 802.3br frame preemption dissector is confused by unrelated packets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16470

--- Comment #13 from Jaap Keuter  ---
(In reply to Guy Harris from comment #10)
> Please note, by the way, that the pcapng file attached to the bug is invalid.
> 

Which is easily spotted when loading the capture file as File Format, see the
View menu.

> Note the last sentence.
> 
> Block 6 has a length of 646 bytes; that is *not* a multiple of 4. 

The capture file dissector could use an expert item here?

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16486] cflow: Add support for dissecting fields with data type subTemplateList

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16486

Guy Harris  changed:

   What|Removed |Added

Summary|cflow SubtemplateList   |cflow: Add support for
   |sample pcap |dissecting fields with data
   ||type subTemplateList
 OS|Windows 10  |All
   Hardware|x86 |All
   Severity|Trivial |Enhancement

--- Comment #1 from Guy Harris  ---
Support added in

https://code.wireshark.org/review/c/36745/

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16486] New: cflow SubtemplateList sample pcap

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16486

Bug ID: 16486
   Summary: cflow SubtemplateList sample pcap
   Product: Wireshark
   Version: 3.2.2
  Hardware: x86
OS: Windows 10
Status: UNCONFIRMED
  Severity: Trivial
  Priority: Low
 Component: Dissection engine (libwireshark)
  Assignee: bugzilla-ad...@wireshark.org
  Reporter: deep.da...@keysight.com
  Target Milestone: ---

Created attachment 17715
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17715=edit
Sample pcap to test the cflow subtemplateList

Build Information:
Paste the COMPLETE build information from "Help->About Wireshark", "wireshark
-v", or "tshark -v".
--

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16470] The IEEE 802.3br frame preemption dissector is confused by unrelated packets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16470

--- Comment #12 from levente.mesza...@gmail.com ---
Oh, I've just seen your finding regarding Block Total Length.

Thanks again, I will fix this issue.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16470] The IEEE 802.3br frame preemption dissector is confused by unrelated packets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16470

--- Comment #11 from levente.mesza...@gmail.com ---
I agree with your analysis. With my last comment I only wanted to note that if
the interface is not looked at when dissecting the conversation, then the
dissector may be confused again by completely unrelated frames on other
interfaces.

BTW, I'm recording these PCAPng files from a network simulator, and it would be
very helpful if Wireshark could understand the conversations even if multiple
interfaces are recorded in the same file. For example, I could use Wireshark to
understand what's going on in a switch or a router.

Anyway, I just wanted to say thank you!

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16470] The IEEE 802.3br frame preemption dissector is confused by unrelated packets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16470

--- Comment #10 from Guy Harris  ---
Please note, by the way, that the pcapng file attached to the bug is invalid.

To quote section 3.1 "General Block Structure":

   
http://xml2rfc.tools.ietf.org/cgi-bin/xml2rfc.cgi?url=https://raw.githubusercontent.com/pcapng/pcapng/master/draft-tuexen-opsawg-pcapng.xml=html/ascii=ascii#rfc.section.3.1

of the current version of the pcapng spec:

Block Total Length (32 bits): an unsigned value giving the total size of
this block, in octets. For instance, the length of a block that does not have a
body is 12 octets: 4 octets for the Block Type, 4 octets for the initial Block
Total Length and 4 octets for the trailing Block Total Length. *This value MUST
be a multiple of 4.*

Note the last sentence.

Block 6 has a length of 646 bytes; that is *not* a multiple of 4.  Wireshark's
pcapng reader *happens* to round block lengths that are not a multiple of 4 up
to the next multiple of 4, but there is *no* guarantee that all pcapng readers
will do so - in fact, at least one is known *not* to do so.

If that was written by code maintained by you or your organization, please fix
it.  If it wasn't, please report the bug to the people who *do* maintain it,
telling them that it violates the pcapng spec and must be fixed.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16470] The IEEE 802.3br frame preemption dissector is confused by unrelated packets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16470

--- Comment #9 from Guy Harris  ---
(In reply to levente.meszaros from comment #4)
> Great, thanks!
> 
> If we are at it, will this also work if there are multiple interfaces in the
> PCAPng trace file?

I've been staring at clause 99 of IEEE Std 802.3-2018, and, at least as I
understand it:

Protocols running atop Ethernet hand to the MAC service layer, via
MA_DATA.request, a quadruplet of:

* destination MAC address;
* source MAC address;
* the MSDU;
* the FCS.

If preemption is being used, the MAC service layer hands the MAC PDU to the MAC
Merge service layer, which processes it in the eMAC or the pMAC.

If it's handed to the eMAC, the eMAC turns around and hands an mPacket,
composed of the preamble, the appropriate SMD octet, and the MAC PDU to the
physical layer, one bit at a time via a PLS_DATA.request.

If it's handed to the pMAC, the pMAC starts handing an mPacket, composed of the
preamble, the appropriate SMD octet, and the MAC PDU to the physical layer, one
bit at a time via PLS_DATA.request.  However, if the MAC Merge service layer
gets a HOLD request via MM_CTL.request, it stops handing the mPacket to the
physical layer as soon as it can, replacing the FCS part of the MAC PDU with an
FCS for the fragment, and holds onto the remainder of the original MAC PDU,
waiting until it gets a RELEASE request MM_CTL.request, at which point it
starts sending out a continuation fragment composed of a continuation fragment
preamble, the appropriate SMD octet and frag count, and the remainder of the
MAC PDU to the physical layer.  That, in turn, is also preemptable in the same
fashion.

So all fragments of a fragmented preempt able packet go over the same physical
layer, and *should* show up on the same interface.

Therefore, *as long as reassembly is done on a per-interface basis*, that
should work.  If we support having only one conversation in progress and one
reassembly in progress, that will *not* necessarily work if there's more than
one interface in the capture with LINKTYPE_ETHERNET_MPACKET.

Note also that, at least as I read clause 99, the reassembly code should *also*
check that the frame counts are the same in all the fragments being
reassembled; this is presumably done to make sure the receiver doesn't glue
together fragments from different MAC PDUs, in case, for example, some
fragments don't make it from the sender to the receiver.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16470] The IEEE 802.3br frame preemption dissector is confused by unrelated packets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16470

Guy Harris  changed:

   What|Removed |Added

   Hardware|x86-64  |All
 OS|Linux   |All

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 16470] The IEEE 802.3br frame preemption dissector is confused by unrelated packets

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16470

--- Comment #8 from Jaap Keuter  ---
(In reply to levente.meszaros from comment #4)
> Great, thanks!
> 
> If we are at it, will this also work if there are multiple interfaces in the
> PCAPng trace file?

No, that level of granularity is not incorporated into the dissection engine as
of yet.

-- 
You are receiving this mail because:
You are watching all bug changes.___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe