https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6235
Summary: BACnet context tags greater than 14 give [Malformed
Packet]
Product: Wireshark
Version: 1.6.1
Platform: x86-64
OS/Version: Windows 7
Status: NEW
Severity: Major
Priority: Low
Component: Wireshark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: lm@xxxxxxxxxxx
Created an attachment (id=6820)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=6820)
Screen capture of packet reported as being malformed
Build Information:
Version 1.6.1 (SVN Rev 38096 from /trunk-1.6)
Copyright 1998-2011 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
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 GTK+ 2.22.1, with GLib 2.26.1, with WinPcap (version
unknown), with libz 1.2.5, without POSIX capabilities, without libpcre, without
SMI, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.10.3, with
Gcrypt 1.4.6, without Kerberos, with GeoIP, with PortAudio V19-devel (built Jul
18 2011), with AirPcap.
Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.10.3, Gcrypt 1.4.6, without AirPcap.
Built using Microsoft Visual C++ 9.0 build 21022
--
When a context tag greater than 14 is encountered in a BACnat packet the
processing appears to get out of sync with the datastream resulting in a
Malformed Packet report. The attached depicts an example of this.
The octets of interest are f9 0f 00 (highlighted on the attachment).
f9 is the initial tag octet. Bit 3 indicates that this is a context tag with
the three least significant bits being the length of primitive data asociated
with the tag (in this case 1). Tag numbers 0 to 14 are encoded in the four
most significant bits of this octet however tag numbers 15 to 254 are encoded
by setting the four most significant bits of this octet as binary 1111 and
following this initial tag octet by an octet containging the tag number (in
this example the 0f octet). The 00 octet is the 1 byte of primitive data
however it is not being treated as such. It is being interpreted as a new tag
(Application Tag: Null, Length/Value/Type: 0).
It would appear that the extra octet included to accommodate an extended tag
number causes the interpretation of the packet to become 'confused'!
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
