[Wireshark-bugs] [Bug 15698] [Modbus] Wrong register number shown in responses
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15698 Alexis La Goutte changed: What|Removed |Added CC||alexis.lagou...@gmail.com, ||mman...@netscape.net -- 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 15698] New: [Modbus] Wrong register number shown in responses
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15698 Bug ID: 15698 Summary: [Modbus] Wrong register number shown in responses Product: Wireshark Version: 3.0.0 Hardware: All OS: All Status: UNCONFIRMED Severity: Minor Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-ad...@wireshark.org Reporter: adam.wiresh...@shikadi.net Target Milestone: --- Created attachment 17054 --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=17054=edit Example packet capture Build Information: Compiled (64-bit) with Qt 5.12.2, with libpcap, with POSIX capabilities (Linux), with libnl 3, with GLib 2.60.0, with zlib 1.2.11, without SMI, with c-ares 1.15.0, with Lua 5.2.4, with GnuTLS 3.6.6 and PKCS #11 support, with Gcrypt 1.8.4, with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.36.0, with LZ4, with Snappy, with libxml2 2.9.9, with QtMultimedia, with SBC, with SpanDSP, with bcg729. Running on Linux 4.17.12-arch1-1-ARCH, with Intel(R) Xeon(R) CPU E5-2665 0 @ 2.40GHz (with SSE4.2), with 15964 MB of physical memory, with locale LC_CTYPE=en_AU.UTF-8, LC_NUMERIC=en_AU.UTF-8, LC_TIME=en_DK.UTF-8, LC_COLLATE=C, LC_MONETARY=en_AU.UTF-8, LC_MESSAGES=en_AU.UTF-8, LC_PAPER=en_AU.UTF-8, LC_NAME=en_AU.UTF-8, LC_ADDRESS=en_AU.UTF-8, LC_TELEPHONE=en_AU.UTF-8, LC_MEASUREMENT=en_AU.UTF-8, LC_IDENTIFICATION=en_AU.UTF-8, with libpcap version 1.9.0-PRE-GIT (with TPACKET_V3), with GnuTLS 3.6.7, with Gcrypt 1.8.4, with zlib 1.2.11, binary plugins supported (14 loaded). Built using gcc 8.2.1 20181127. -- If a Modbus/TCP request packet has multiple messages, when the responses come in, the wrong register numbers are shown. For example, the attached sample capture shows: * Packet 36: Query numbers 5, 6 and 7 * Packet 37: Response to query 5, but registers shown are from query 7 (29203/29204) instead of query 5 (20803/20804) * Packet 39: Response to queries 6 and 7, but both registers again shown from query 7 (29203/29204) instead of query 6 (29201/29202) and query 7 (which is now correct here). It seems that when the dissector looks at a response packet, it correctly matches it to the request packet and retrieves the register numbers from there. But once it finds the packet it assumes there is only one request in it, grabbing the last register numbers, rather than looking for the matching query number first. -- 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 3303] Fragmented TLS records result in missing Certificate handshake messages and "Encrypted Handshake Message"
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3303
--- Comment #37 from Peter Wu ---
(In reply to Hubert Kario from comment #36)
> (In reply to Peter Wu from comment #34)
> > I am adjusting title ("Problem with fragmentation at the SSL record layer")
> > to closely reflect this bug. Application Data is already properly handled.
> > Alert messages are no longer allowed to be fragmented in TLS 1.3 and other
> > record content types might not permit fragmentation either.
>
> well, that does not disallow fragmentation of alert records in TLS 1.2 and
> earlier...
An actual client/server implementation will always see the full stream from the
start with no gaps, that might not be true for Wireshark. Someone might start a
packet capture in midst of a session (worst case: in the middle of a fragmented
record), or packets might be missing/corrupted (e.g. in case of 802.11 monitor
mode captures with bad signal strength).
To ensure that the best possible guess can be provided, I'll therefore not
always try to start handshake reassembly and report things as "Encrypted
Handshake Message" for example.
The Alert message case is relatively simple, it is always 2 bytes when
unencrypted. This message will never be fragmented unless you are using testing
tools like tls-fuzzer. The worst that can happen is that the alert message
details are not displayed. Decryption will keep working and other handshake
messages are not broken. So it will likely never be implemented even if
technically allowed by the TLS 1.2 spec. (If you really need it, consider
opening a separate bug request.)
> the other problem is that the end of some messages (like Finished or
> KeyUpdate) needs to be aligned with the record message end - that looks to
> me like something wireshark should flag as possible issue
Yes, and similar for e.g. Server Hello before switching to Encrypted
Extensions. TLS has many cases where things can go wrong, but conformant
implementations will not run into them so implementing it would be pretty low
on the priority list. People would be much happier with an HTTP/3 dissector for
example :)
> it's easy to create fragmented messages using tlsfuzzer[1], there already
> are multiple scripts[2] that send messages either intentionally fragmented
> or automatically fragmented because they are too large to fit into a single
> record message
>
> feel free to ask me about generators for specific examples or corner cases
Thanks, but I think that I might need Scapy to craft small captures for the
test suite. Tests can use a fixed handshake message (e.g. Certificate) have to
cover:
- A hs msg split over two and three records (in a single/different frames).
- Similar, but with another hs msg starting in the last record.
- The above, but with varying number of available data in each fragment
(to check whether an unknown length would be a problem).
- Interaction with TCP: a record starting in segment 1 and using partial data
from segment 2. Various combination of handshake messages that cross this case.
(There are likely more cases, like mixing unrecognized data in between.)
A fuzzer would be nice though just to verify whether all "good" cases are
handled. E.g. given a sequence of (say) 3 handshake messages fragmented in
various ways, check that tshark also displays exactly 3 reassembled handshake
messages. Would tlsfuzzer be suitable for writing such a fuzzer?
--
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.___
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 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12845 --- Comment #58 from Pavel Sindelka --- (In reply to Tomasz Mon from comment #57) ... > @Pavel Sindelka Please try with the latest automated build and report the > outcome. Done (3.1.0rc0-541-g7187120b), works perfect - I haven't even noticed the "initializing external capture plugins" message and the "Interface Options" dialog for the hub to which the USB controller is connected opens immediately. 100 ms delays before retrying to read a queue can only sum up into "ages" if there are hundreds of read operations, as "ages" actually mean tens of seconds, probably not more than two minutes. So I'd assume that on my PC, the Windows really give out just one byte at a time and the next byte is either never available right after reading the previous one (which kind of makes sense in a multi-processing environment) or you insert the delay after each read without checking whether new data is already available. Great job, sir. Many thanks for USBPcap again. -- 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 15459] OSPF: Outdated and wrong Link Local Signalling TLV
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15459 Uli Heilmeier changed: What|Removed |Added Status|INCOMPLETE |IN_PROGRESS -- 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 15459] OSPF: Outdated and wrong Link Local Signalling TLV
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15459 Uli Heilmeier changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|INCOMPLETE --- Comment #3 from Uli Heilmeier --- The patch fixes only OSPFv2. For the OSPFv3 implementation I'm still looking to get sample capture to verify it. -- 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 15065] Wireshark can call extcap with empty multicheck argument
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15065 --- Comment #3 from Tomasz Mon --- Expanding on to previous comment, the extcap in point 3 is called with: C:\Development\wsbuild64\run\RelWithDebInfo\extcap\USBPcapCMD.exe --capture --extcap-interface \\.\USBPcap1 --fifo \\.\pipe\wireshark_extcap_\\.\USBPcap1_20190415200526 --capture-from-all-devices --capture-from-new-devices So only the "point 3" is now correct. However, after doing points 4 and 5, the extcap is called with: C:\Development\wsbuild64\run\RelWithDebInfo\extcap\USBPcapCMD.exe --capture --extcap-interface \\.\USBPcap1 --fifo \\.\pipe\wireshark_extcap_\\.\USBPcap1_20190415200545 --snaplen 65535 --bufferlen 1048576 --capture-from-all-devices --capture-from-new-devices --devices " " So the bug is still present. -- 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 15065] Wireshark can call extcap with empty multicheck argument
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15065 --- Comment #2 from Tomasz Mon --- (In reply to Tomasz Mon from comment #1) > In fact, it looks that neither is correct as the argument list from point 3 > does not include the "--capture-from-new-devices" which is enabled by > default. This was fixed in https://code.wireshark.org/review/#/c/32848/ -- 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 15697] nas-5gs, decoding “Authorised QoS rules” has issue
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15697 Alexis La Goutte changed: What|Removed |Added Status|UNCONFIRMED |INCOMPLETE Ever confirmed|0 |1 CC||alexis.lagou...@gmail.com -- 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 13355] extcap: multicheck not working
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13355
--- Comment #6 from Tomasz Mon ---
The only remaining issue is that, while extcap_example.py provides multicheck,
it doesn't actually contain any checkboxes. The "{enabled=true}" option is
needed in order for an entry in multicheck to have checkbox appear.
This problem is solved in https://code.wireshark.org/review/#/c/32842/
--
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 10756] Wireshark does not close remote connection
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10756 Anders Broman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Anders Broman --- Remote capture has ben significantly reworked please retry with Wireshark 3.0 and report problems in new bug reports, if any. -- 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 10982] Adding a way to get to the RTP of a voip call from a SIP message
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10982 Anders Broman changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #1 from Anders Broman --- Something like this is implemented in 3.0 if not good enough feel free to reopen detailing what's missing. -- 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 3303] Fragmented TLS records result in missing Certificate handshake messages and "Encrypted Handshake Message"
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3303
--- Comment #36 from Hubert Kario ---
(In reply to Peter Wu from comment #34)
> I am adjusting title ("Problem with fragmentation at the SSL record layer")
> to closely reflect this bug. Application Data is already properly handled.
> Alert messages are no longer allowed to be fragmented in TLS 1.3 and other
> record content types might not permit fragmentation either.
well, that does not disallow fragmentation of alert records in TLS 1.2 and
earlier...
other types include change_cipher_spec (the messages are 1 byte long and empty
ones are disallowed) and heartbeat (that always explicitly forbid
fragmentation)
the other problem is that the end of some messages (like Finished or KeyUpdate)
needs to be aligned with the record message end - that looks to me like
something wireshark should flag as possible issue
finally, in TLS 1.3 you can't have interleaving of handshake message records
with other records, but it is allowed in TLS 1.2 (and Java is known to do that)
(see section 5.1 in RFC 8446[3] about the above)
> This bug is long overdue (it is over 10 years old!). Issues include:
>
> - Certificate handshake messages are not dissected (this bug + duplicates).
> - Broken decryption with TLS 1.3 (bug 15537)
> - Broken decryption with extended_master_secret + RSA private key (bug 15625)
>
> I'm working on a patch now that adds reassembly support for handshake
> messages. It is not trivial and I likely need more tests to handle all
> potential edge cases.
it's easy to create fragmented messages using tlsfuzzer[1], there already are
multiple scripts[2] that send messages either intentionally fragmented or
automatically fragmented because they are too large to fit into a single record
message
feel free to ask me about generators for specific examples or corner cases
1 - https://github.com/tomato42/tlsfuzzer
2 - https://github.com/tomato42/tlsfuzzer/tree/master/scripts
3 - https://tools.ietf.org/html/rfc8446#section-5.1
--
You are receiving this mail because:
You are watching all bug changes.
You are the assignee for the bug.___
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 11561] x509ce CRLDistributionPoints dissection issue ?
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11561 Anders Broman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |NOTOURBUG -- 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 15154] CMPv2 KUR message disection gives unexpected value for serialNumber under OldCertId fields
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15154 Anders Broman changed: What|Removed |Added Status|CONFIRMED |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 15697] nas-5gs, decoding “Authorised QoS rules” has issue
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15697 --- Comment #1 from Anders Broman --- Could you attach a pcap illustrating the problem? -- 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 15154] CMPv2 KUR message disection gives unexpected value for serialNumber under OldCertId fields
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15154 --- Comment #9 from Gerrit Code Review --- Change 32861 merged by Anders Broman: CRMF: Handle 64 bit serialNumber https://code.wireshark.org/review/32861 -- 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 15154] CMPv2 KUR message disection gives unexpected value for serialNumber under OldCertId fields
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15154 --- Comment #8 from Gerrit Code Review --- Change 32861 had a related patch set uploaded by Anders Broman: CRMF: Handle 64 bit serialNumber https://code.wireshark.org/review/32861 -- 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 15154] CMPv2 KUR message disection gives unexpected value for serialNumber under OldCertId fields
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15154 --- Comment #7 from Gerrit Code Review --- Change 32860 merged by Anders Broman: CRMF: Handle 64 bit serialNumber https://code.wireshark.org/review/32860 -- 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 15697] New: nas-5gs, decoding “Authorised QoS rules” has issue
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15697 Bug ID: 15697 Summary: nas-5gs, decoding “Authorised QoS rules” has issue Product: Wireshark Version: 3.0.0 Hardware: x86 OS: Mac OS X 10.4 Status: UNCONFIRMED Severity: Major Priority: Low Component: Dissection engine (libwireshark) Assignee: bugzilla-ad...@wireshark.org Reporter: sok...@cisco.com Target Milestone: --- Build Information: Wireshark has issue in decoding “Authorised QoS rules”. i.e., after the “packet filter component type”, it skips one octet to decode “QoS rule precedence”. So, the decoding goes wrong from “QoS rule precedence” onwards. It impacts further QoS rule decoding as well. -- -- 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 15154] CMPv2 KUR message disection gives unexpected value for serialNumber under OldCertId fields
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15154 --- Comment #6 from Gerrit Code Review --- Change 32860 had a related patch set uploaded by Anders Broman: CRMF: Handle 64 bit serialNumber https://code.wireshark.org/review/32860 -- 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 15586] External extcap does not get all arguments sometimes
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15586 Dario Lombardo 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 15586] External extcap does not get all arguments sometimes
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15586 --- Comment #8 from Tomas Kukosa --- @Tomasz Mon it does work well now! Thanks! -- 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 15586] External extcap does not get all arguments sometimes
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15586 --- Comment #7 from Tomasz Mon --- @Tomas Kukosa Could you please check if you can trigger the missing parameters with the latest automated Wireshark build? -- 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 15459] OSPF: Outdated and wrong Link Local Signalling TLV
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15459 Anders Broman changed: What|Removed |Added Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #2 from Anders Broman --- Patch merged. -- 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 15021] ZigBee APS re-assemble with re-used sequence number
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15021 Kenneth Soerensen changed: What|Removed |Added See Also||https://bugs.wireshark.org/ ||bugzilla/show_bug.cgi?id=14 ||437 -- 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 14437] DNP3 dissector can't reassemble transport segments if the sequence number rolls over from 63 to 0
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=14437 Kenneth Soerensen changed: What|Removed |Added CC||knnthsr...@gmail.com See Also||https://bugs.wireshark.org/ ||bugzilla/show_bug.cgi?id=15 ||021 -- 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 13360] ZigBee Smart Energy add dissection of more clusters
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13360 Kenneth Soerensen changed: What|Removed |Added Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #15 from Kenneth Soerensen --- All commands and attributes in ZigBee Smart Energy 1.4 are now more or less dissected. -- 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 13355] extcap: multicheck not working
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13355 Dario Lombardo changed: What|Removed |Added CC||deso...@gmail.com -- 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 15654] LDP FEC Type 128 (PWid) is not recognized
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15654 Uli Heilmeier changed: What|Removed |Added Hardware|x86-64 |All Version|3.0.0 |Git Resolution|--- |FIXED Status|CONFIRMED |RESOLVED -- 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 15522] ieee80211: QoS Control not correctly dissected for MESH frames
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15522 Anders Broman changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Anders Broman --- Fix is merged. -- 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 15515] SocketCAN dissector doesn't decode error frames
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15515 Anders Broman changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Anders Broman --- Looks lik ethis one is 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 13360] ZigBee Smart Energy add dissection of more clusters
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13360 Alexis La Goutte changed: What|Removed |Added Status|INCOMPLETE |IN_PROGRESS CC||alexis.lagou...@gmail.com --- Comment #14 from Alexis La Goutte --- Can be close ? on always missing some stuff ? -- 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 13355] extcap: multicheck not working
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13355 Alexis La Goutte changed: What|Removed |Added CC||alexis.lagou...@gmail.com, ||lom...@gmail.com -- 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 12845] First start with non-empty extcap folder after install or reboot hangs at "initializing tap listeners"
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12845 --- Comment #57 from Tomasz Mon --- Regarding this issue, I tend to group all Wireshark versions into three categories: 1. With the actual deadlock 2. "taking ages" 3. "better performance" Originally there was indeed a deadlock. The deadlock was fixed when both https://code.wireshark.org/review/#/c/29159/ and https://code.wireshark.org/review/#/c/29163/ made it into the source code. The "taking ages" is probably the most suprising part, as (atleast I) had absolutely no idea that the innocent 100 ms wait between reading pipes can can so much impact on the performance. Before I made the "overlapped IO" change in Wireshark, I got confirmation from two USBPcap users that reducing the 100 ms interval to 1 ms significantly improves the situation. I believe that the versions with https://code.wireshark.org/review/#/c/32773/ are going to fall into the "better performance" category. This change basically makes Wireshark to read the data as soon as possible, without any artificial delays. The important thing to note here, is that the issue depends greatly on the Windows pipe buffering (that Windows chooses for the particular extcap called by Wireshark) and is pretty much unrelated to the buffer size that is passed to ReadFile call. On my computer with the "overlapped IO" I don't observe any statistically significant difference if the buffer passed to ReadFile() is 16 KiB or if it is merely a single byte. https://code.wireshark.org/review/#/c/32773/ got merged 2 hours ago. By looking at the git log, I am pretty sure Wireshark-win64-3.1.0rc0-537-g89f339af contains this change. @Pavel Sindelka Please try with the latest automated build and report the outcome. -- 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 15654] LDP FEC Type 128 (PWid) is not recognized
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=15654 --- Comment #3 from Gerrit Code Review --- Change 32855 merged by Anders Broman: LDP: Dissect interface parameter of PWID FEC https://code.wireshark.org/review/32855 -- 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
