zbstumbler not finding anything, #DEBUG Clearing overflow

[martinoamigo]

Hi,

I just received my APIMote v4, and currently zbstumbler doesn't find any of my networks. Example output:

$ sudo zbstumbler
zbstumbler: Transmitting and receiving on interface '/dev/ttyUSB1'
# DEBUG Clearing overflow
# DEBUG Clearing overflow

With verbose output:

$ sudo zbstumbler -c 14 -v
zbstumbler: Transmitting and receiving on interface '/dev/ttyUSB1'
Transmitting beacon request.
Transmitting beacon request.
Received frame.
Received frame is not a beacon (FCF=4188).
Received frame.
Received frame is not a beacon (FCF=4188).
Transmitting beacon request.
Transmitting beacon request.
Transmitting beacon request.
Transmitting beacon request.
Transmitting beacon request.
^XTransmitting beacon request.
Transmitting beacon request.
Transmitting beacon request.

These will seemingly run forever. When I run zbwireshark or zbdump, it also outputs # DEBUG Clearing overflow in the terminal, and "Bad FCS" in Wireshark. Not sure if that's related, as I noticed a few others with Bad FCS on APIMote.

Any help would be appreciated

Looks like the device is working from zbwireshark/zbdump (the clearing overflow happens when your computer can't fetch packets fast enough from the device so it drops frames). The zbstumbler looks like the device is transmitting and receiving correctly -- I'd suggest working through that to see if perhaps your beacons are not being sent in response to beacon requests, or perhaps they don't follow the spec verbatim, or you're dropping frames or missing responses due to proximity/speed. All of those could play a role and I've seen all happen before depending on the setup/target.

[martinoamigo]

Thanks! I was able to get zbstumbler working by putting my device into pairing mode. I also messed around with the proximity a bit.

As for the 'Bad FCS', any thoughts? I'm trying to sniff a transport key from a pairing, but there is no key to be found. I'm thinking this is related to the 'Bad FCS', and it's just not recognizing the key transport.

[rmspeers]

Glad to hear, I figured that was the issue with pairing mode/etc. As for not getting the key transport key, presuming that your device is sending it per the appropriate spec you are looking for, like HA 1.2, then it could be a corruption of the packet due to Bad FCS. The best way to figure out if that is the case is to look at the sequence of pairing packets and see if you can identify one that should be it but that is corrupted, based on how the pairing handshake works. I’m happy to quickly glance at a PCAP of that if helpful to you, you can send via email if you don’t want to post here.

…

On Apr 12, 2019, at 4:19 PM, Evan Martino ***@***.***> wrote: Thanks! I was able to get zbstumbler working by putting my device into pairing mode. I also messed around with the proximity a bit. As for the 'Bad FCS', any thoughts? I'm trying to sniff a transport key from a pairing, but there is no key to be found. I'm thinking this is related to the 'Bad FCS', and it's just not recognizing the key transport. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#168 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJbQCTPJ-Eay2Xd-3oTncUMF6-jGgCauks5vgOpegaJpZM4cqt8g>.

[martinoamigo]

Spot on, I'm pairing a light bulb (presumably using HA 1.2) and a smart hub. I'll email you the PCAP, a second eye would be incredibly helpful.

From what I can tell, some of the IEEE packets captured should be interpreted as Zigbee packets (including the one that would have the Key Transport Key). Might be similar to #98, however I don't have a RZUSBstick to confirm.

[antoineQue]

Hi guys,
I'm also working with the ApiMote v4 beta and some Xiaomi stuff (gateway, window and motion sensor).

Using zbstumbler give me the same output as yours: no PANID is retrieved and Debug Clearing overflow for each zigbee packet. I also have the same pcap capture while sniffing the association (hub - sensor), no transport key.

First, I assumed that the default TC link key ZigBeeAlliance09 was not used and instead, a unique link key used for each node, given by Xiaomi. I'm also afraid Xiaomi is not implementing a non official Zigbee stack (or proprietary modifications).

Concerning proximity, I'm working with ApiMote and sensors close to each other (my desk) and the gateway at 4 meters.

pcap and zbstumbler capture:
pcap-zbstumbler.zip

Peace !

[taylorcenters]

Hi we believe the apimote instability issues have been addressed by the most recent PR. Please try the latest software and reopen the issue if this is still a problem. Thanks

[xsoltek]

Hello i have the same issue here, i reflashed my Apimote with the 2 different hex ( apimotev4_202106.hex & apimotev4_gf.hex) in the firmware folder . in zbstumbler when it find the correct channel i have the error
NameError: name 'Dot154PacketParset' is not defined

Moreover, when i try zbdump i have the DBUG b'Clearing overflow'

Any ideas ?