https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10783
--- Comment #12 from Matthijs Kooijman <[email protected]> --- Regarding the indentation errors: The original file is indented uses 4 spaces per level and never uses actual tabs. The patch is created with one tab per level. If you show tabs as 4 spaces, the indentation improves somewhat, but there are still if/while structures that do not have their contents indented. There's also trailing whitespace on some lines. The code opens and closes a new gcrypt object for each 16-byte block being decrypted. I don't know gcrypt, but I would not expect that to be needed (I even wonder if gcrypt cannot handle the 16-byte chunking and cipher feedback chaining method used already? Seems it does: https://www.gnupg.org/documentation/manuals/gcrypt/Available-cipher-modes.html though perhaps that doesn't allow also calculating the MIC?). The code currently only dissects un-encrypted command packets, but I think it should also try to dissect succesfully decrypted command packets as well? Non-command packets are shown only as a hex dump in the treeview, it would be useful if you could somehow also see the ASCII interpretation of those bytes (not sure how to approach that, though). I've attached a capture I've been using. The key used is 31:32:33:34:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff. The capture contains a number of seemingly succesful decryptions (haven't verified the data, but he MIC is said to be correct). Some packets have incorrect MICs. It's certainly possible that there are errors in the capture, but since these packets do have a correct FCS (checksum in the 802.15.4 layer), I suspect there is some problem in the lwmesh decryption. Also, it's remarkable that the failing packets all havbe 10-14 bytes of encrypted data, and all packets of that length have failing MICs. I was thinking that < 16 bytes wasn't properly handled, but there are also packets with 7 or 8 bytes that do have a matching MIC. Another option would be that these packets aren't proper LWM packets somehow, but my hardware shouldn't be sending anything else and the LWM headers look ok to me, so I suspect it's not that. I don't have time to investigate this further now, but perhaps this capture allows someone else to look closer. -- You are receiving this mail because: You are watching all bug changes.
___________________________________________________________________________ Sent via: Wireshark-bugs mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-bugs Unsubscribe: https://wireshark.org/mailman/options/wireshark-bugs mailto:[email protected]?subject=unsubscribe
