Closed GoogleCodeExporter closed 9 years ago
Have made the suggested change in scapy_extensions revision 93. Please retest
and confirm fixed :)
Original comment by rmspe...@gmail.com
on 14 Sep 2014 at 5:33
I applied the updated and even installed on a different system (without
scapy-com). I'm not sure what this broke. I don't recall this happening when I
tested it before. Here is what I'm seeing.
First, I captured a file on the system that has a default version of scapy
using zbdump. Then I tried parsing the file using the updated version of
zbscapy.
System with the normal scapy installation (via apt-get) does not parse
generated pcap properly.
=========================================
cutaway@sys_w_orig_scapy:~$ zbscapy
WARNING: Most KillerBee functionality requires root privileges.
Welcome to Scapy (2.2.0)
KillerBee Extension v0.6
>>> cnt = 0
>>> cap = PcapReader('/tmp/zb_test.pcap')
WARNING: PcapReader: unknown LL type [195]/[0xc3]. Using Raw packets
=========================================
System with scapy-com installation does parse pcap file properly.
=========================================
cutaway@sys_w_scapy-com> zbscapy
WARNING: Most KillerBee functionality requires root privileges.
Welcome to Scapy (2.2.0-dev)
KillerBee Extension v0.6
>>> cap = PcapReader('/tmp/zb_test.pcap')
>>>
=========================================
Any ideas?
cutaway
Original comment by cutaways...@gmail.com
on 15 Sep 2014 at 3:31
Hmm. I could believe that the normal scapy (not scapy-com) doesn't recognize
the 802.15.4 link-layer type and that's why it fails. It looks like scapy-com
works now, using the update you suggested (can you verify in that I patched
what you thought should be the change?). Is this last comment saying that
something else changed now that you've updated? I'd expect that the normal
scapy installation never parsed the packets correctly...? If not, I'll look
into it but I'm surprised. If that is the case (that the normal scapy never
parsed 802.15.4 PCAP correctly), what broke in this KillerBee version?
Original comment by rmspe...@gmail.com
on 16 Sep 2014 at 1:00
I'm obviously using zbscapy incorrectly. I'm trying to figure it out so I can
test it properly. Personal email sent. I'll post my update when I figure out
how to implement zbscapy properly.
cutaway
Original comment by cutaways...@gmail.com
on 16 Sep 2014 at 7:32
I believe this is working properly and can be closed. The other things I'm
seeing are not related to this issue.
cutaway
Original comment by cutaways...@gmail.com
on 16 Sep 2014 at 9:31
Actually, and I apologize, I believe I referred to the wrong field in my
original recommendation. I made that without fully understanding what kbdecrypt
was doing. My current testing shows that 'ext_src' should actually be 'source'.
For example:
======================================
Out[36]: <Dot15d4FCS fcf_reserved_1=0 fcf_panidcompress=True fcf_ackreq=False
fcf_pending=False fcf_security=False fcf_frametype=Data fcf_srcaddrmode=Short
fcf_framever=0 fcf_destaddrmode=Short fcf_reserved_2=0 seqnum=121 |<Dot15d4Data
dest_panid=0x0a36 dest_addr=0xffff src_addr=0x0 |<ZigbeeNWK discover_route=0
proto_version=2 frametype=command flags=security+extended_src
destination=0xfffc source=0x00 radius=1 seqnum=110 ext_src=xx:xx:xx:xx:xx:xx
|<ZigbeeSecurityHeader reserved1= extended_nonce=1 key_type=network_key
nwk_seclevel=ENC-MIC-32 fc=0xc073 source=xx:xx:xx:xx:xx:xx key_seqnum=43
data='\x83sF\x3fe\t\x95W\x17' |>>>>
======================================
Note that this packet has the field ZigbeeSecurityHeader.source. I assumed,
incorrectly, that the 'ext_src' field in the ZigbeeNWK layer was what
'ext_source' was referring to.
So, a fix was still required. It just needs to be updated again. My current
testing shows that by making this modification the kbdecrypt function runs
without error.
Thank you,
cutaway
Original comment by cutaways...@gmail.com
on 16 Sep 2014 at 11:46
Commit #94 has updated per your request. See if that works.
Original comment by rmspe...@gmail.com
on 28 Sep 2014 at 8:47
Original issue reported on code.google.com by
cutaways...@gmail.com
on 11 Sep 2014 at 7:25