ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 4507] New: IEEE 802.15.4 frame check sequence in "Chipcon

Date: Fri, 19 Feb 2010 01:49:01 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4507

           Summary: IEEE 802.15.4 frame check sequence in "Chipcon mode"
                    not displayed correctly
           Product: Wireshark
           Version: 1.2.5
          Platform: x86
        OS/Version: Windows Vista
            Status: NEW
          Severity: Trivial
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: honarbacht@xxxxxxxxx


Created an attachment (id=4307)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=4307)
A capture file illustrating the bug. Made with ubisys technologies' IEEE
802.15.4 USB Stick with dedicated RNDIS firmware for Wireshark.

Build Information:
Version 1.2.5 (SVN Rev 31296)

Compiled with GTK+ 2.16.2, with GLib 2.20.3, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with c-ares 1.6.0, with Lua 5.1, with GnuTLS 2.8.1, with Gcrypt 1.4.4, with MIT
Kerberos, with GeoIP, with PortAudio V19-devel (built Dec 17 2009), with
AirPcap.

Running on 32-bit Windows Vista Service Pack 2, build 6002, with WinPcap
version
4.1.1 (packet.dll version 4.1.0.1753), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.8.1, Gcrypt 1.4.4, without AirPcap.

Built using Microsoft Visual C++ 9.0 build 30729
--
Texas Instruments (formerly Chipcon) IEEE 802.15.4 devices like the CC2420,
CC2430, CC2431, CC2520, CC2530, etc. provide a so called auto-CRC mode, which
replaces the original 16-bit CRC of received frames with two bytes as shown in
figure 21 of the CC2420 data sheet (TI document no. SWRS041B) on page 39: "Data
in RXFIFO when MDMCTRL0.AUTOCRC is set". Wireshark does not interpret these
values correctly.

1) The RSSI is a signed value, while Wireshark treats it as unsigned. In
addition, an implementation dependent offset (RSSI_OFFSET) must be taken into
account to convert the RSSI_VAL into an absolute power reading (1 dBm = 0 mW).
The equation is P = RSSI_VAL + RSSI_OFFSET (dBm), c.f. page 48 of above
mentioned document. RSSI_OFFSET depends on the chip, analog front-end: quality
of matching network, presence of external low-noise amplifier, etc. For
example, CC2420 (and CC2430, CC2431, CC2480) RSSI_OFFSET = -45dBm, CC2520 (and
CC2530) RSSI_OFFSET = -76dBm. Therefore, the value should be displayed as 8 bit
signed value in units of dB (instead of dBm). Alternatively, the RSSI_OFFSET
must be made configuruable by the end-user and taken into account when
displaying absolute power values (units of dBm).

2) Wireshark's dissector expects these bytes in different byte order
(little-endian vs. big-endian issue). Notice that in the attached capture the
bytes have already been swapped in the capture hardware to accommodate for the
current behavior. However, this should be changed in Wireshark.

Attached is a capture that provides some actual "over-the-air" data. The
capture hardware was a ubisys technologies IEEE 802.15.4 USB Stick with
dedicated RNDIS firmware for Wireshark. The frames were received by a CC2420
and then encapsulated into ZEPv2/UDP/IP/Ethernet and transmitted to the host
via RNDIS.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.