search

zsmartsystems / com.zsmartsystems.zigbee.sniffer

ZigBee sniffer using Ember NCP and routing packets to Wireshark for display
Eclipse Public License 1.0
33 stars 18 forks source link

Questions about Wireshark display and configuration #14

Closed sraillard closed 1 year ago

sraillard commented 4 years ago

I have tested the sniffer with Ember version 6.7.1.0 on Windows, and it seems to work correctly.

I have few questions about Wireshark, here is the display I have: image

I have tried the 3 different options, but the dissector always show the "TI-CC24xx" frame format:

image

Is-it a Wireshark issue?

cdjackson commented 4 years ago

Device ID: is-it hardcoded to 1?

I'm not sure - I would need to check the code. What do you expect it to be? This is just the IP layer encapsulation - not 802.15.4.

Is-there a way to show the link quality?

Sorry - I'm not an expert on Wireshark. If the data is in the packet as you suggest then Wireshark should display it. I'm not sure though if I had a definition of the data format when I wrote this, or if I reverse engineered it, so it's possible the LQI is in the wrong place in the packet. Maybe you can see if you can find the definition for the 802.15.4 encapsulation and we can check.

sraillard commented 4 years ago

From the ZEP dissector code, the DeviceID is "the ID of the device that detected this packet". My understanding is this should identify the sniffing device and it may be useful when multiple sniffers are sending data.

In the code WiresharkZepFrame.java, the DeviceID is intialized at 1 in line 113 and the method setDeviceId is never called from ZigBeeSniffer.java. So we can assume this is a fixed value of 1. Maybe this value can be set to the last 16-bits of the EUI address of the module sniffing?

Regarding the LQI not displayed, this is a bug for in the ZEP dissector of Wireshark, I have opened a bug: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16369

Regarding the frame format, when in LQI mode, this is clearly the "TI-CC24xx" frame format that is used, there is a test at line 215 in the dissector code: https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/dissectors/packet-zep.c

And in the code WiresharkZepFrame.java, at lines 201 and 202, this is clearly the two bytes for the "TI-CC24xx" frame format. 0x80 just tell that the checksum is OK (hardcoded). What is missing, is a call to serRssi from ZigBeeSniffer.java (there is a typo in the method, this should be setRssi).

cdjackson commented 4 years ago

Maybe this value can be set to the last 16-bits of the EUI address of the module sniffing?

I'm not against that. Another option could be to provide a command line option so that if you have multiple sniffers (which is the only situation where this matters) then you have explicit control over the naming.

Eg. hard code it to 1 by default, but provide an option to use another number?

If you want to create a PR for both these (device id and rssi fix), then that would be great.

sraillard commented 4 years ago

Ok, we'll try to arrange that with @mikomarrache

sraillard commented 4 years ago

The PR has been posted: https://github.com/zsmartsystems/com.zsmartsystems.zigbee.sniffer/pull/16

sraillard commented 4 years ago

The Wireshark patch to fix the display of the LQI value in the ZEP frame has been merge in the master branch, so it may be soon in a Wireshark release: https://code.wireshark.org/review/#/c/36054/

sraillard commented 1 year ago

Wireshark has been fixed and the PR has been merged, I'm closing this issue.