NIO stack - decryption failing #77
Comments
|
The decryption is failing, because the message length is longer than the read buffer. In I increased the minimum size of the buffer until I stopped getting decryption errors by modifying the buffer creation in Server.swift:71 With a short interaction using my configuration, the longest message size was 1155 bytes. Even with a initial buffer size of 2046, I was only able to avoid a decryption failure by making the minimum buffer size larger than the longest message. Here is an extract: This workaround seems to temporarily cure the decryption issue, but I expect the long term solution requires working out why the buffer is not growing in size as required. |
|
Fixed by PR #79 which implements the workaround mentioned above. |
|
Great investigation so far. The HAP specification notes the following on the transport security:
So my guess is that if you make the buffer 1042, it should be able to receive frames just fine. However while handling reads from the channel, we're not looking at the frame's header, but just forward whatever we get to the So while I'm happy to take the workaround suggested in the PR, a proper fix would be to read the frame headers. Either by merge the |
|
Yes, I noted the mention in the public available spec that frames would be no larger than 1024 bytes, however a minimum buffer size of 1024 still results in decryption failures, due to the occasional frame of length 1155 (as shown in the above log extracts). Either the spec changed or there are some devices on my network (HomePods?) which are not respecting the requirement. Setting the minimum buffer size to 1200 has worked successfully so far. I've added that workaround in PR #79 I agree that a proper fix would be to ensure that a complete frame is read before sending for decryption. |
|
I've started working on a proper fix for this in #80. A fixed read buffer of 1042 (not 1024) would probably workaround the issue, as then each frame would at most fill the entire buffer. However I don't think the current allocator works that way, so that's why it's probably failing for you. Setting a bigger size would only defer the issue until bigger messages are send by the client. |
|
Great, let me know when you would like me to test it out on my local network. I've experimented with simple setups in To see the packet lengths, change the log level of You can search the log for lines beginning with Then add a TV accessory to and add the accessory to the bridge You will need to use the PR #78 changes to be able to sucessfully add the With the setup above, I am seeing packets as long as 1338 bytes. I checked which device was sending the longer messages, and discovered they were coming from both the iOS 12.1 iPhone I used to add the bridge, and from one (of two) HomePod's on the network which is the primary HomeKit Hub for the test Home. With these changes, are you able to reproduce the long packets ? |
|
Thanks, this helps a lot. I've got a fix ready in my PR. With the steps to reproduce that you provided, the problem does no longer appear. I also reduced the amount of memory allocations required when encrypting / decrypting. As a result the code should be a little more performant on constrained environments, like the Raspberry Pi. I've updated my home installation to that branch, to further test it. Can you let me know how it works for you? |
I'm moving my project over to the new master, but am seeing issues with the NIO stack. I am able to pair with a controller, but HAP gets into an infinite loop reverifying connections over and over, preceded by the following message:
Here is a log extract after pairing. The bridge worked fine in the same HomeKit network and config with the previous network stack. Any pointers on where to look in the NIO code for what is causing this problem ?
The text was updated successfully, but these errors were encountered: