Closed nonameplum closed 3 years ago
@maximkulkin It seems like the issue is present only on the last commit https://github.com/maximkulkin/esp-homekit/commit/379f593baad364c90233587a96241f636719d103
The issue that I observed is that once the server does the first homekit_client_process
and makes the Calculating public key
and sends the payload it gets stuck because then in homekit_run_server
-> select(server->max_fd + 1, &read_fds, NULL, NULL, &timeout);
returns all the time 0
. It keeps do "nothing" until the client is disconnected and start over again.
That's not what's happening. Last commit was dealing with streaming TLV responses, so the problem is most likely in TLV stream serialization. On the payloads you've provided I'm seeing of by one error in data, but I can't find the problem in the code yet.
@maximkulkin Aha. Yup, as I found that the last commit is problematic for sure this is related to the TLV. I just added a log for the select(server->max_fd + 1, &read_fds, NULL, NULL, &timeout);
returned value and compared to the working version and I saw that is returns 0
.
I can put more logs if you like if that could help you spot the issue.
Thanks for the investigation!
Should be fixed now
Thanks @maximkulkin
Yes, it's fixed now beside a weird issue that I have which is when I run my UDP server (https://github.com/nonameplum/esp-homekit-demo/blob/dca2f6811c60333fe8247247d9795199971a8f3b/helpers/udp_command.c#L73) that I use to send messages to IoT device over UDP.
When UDP server is running, pairing faze 2/3 fails with -173 BAD_FUNC_ARG
error, because in wc_SrpSetPassword
srp->side != SRP_CLIENT_SIDE
.
In pre TLV implementation I don't encounter this issue.
I bet you also don't encounter this issue if you do not run your UDP server.
@maximkulkin Exactly when I do not run the UDP server then it works fine.
The thing is that if I checkout some older commit (it seems like its enough if I go back to https://github.com/maximkulkin/esp-homekit/commit/cd6c0d3b695e95fbb3fce3c95462db148ab81cc3 or for sure anyone before the new mDNS implementations) it works also fine when the UDP server is running.
Also, I have checked for the last days the newest master (mDNS that I was curious), and what I observed is that now esp-homekit takes a bit more memory as I had to disable some of my features because devices couldn't pair as the pairing most of the time failed because of lack of memory during the process. Another one is that mDNS and so device availability on the Home app in my particular case works much worse. It's like in the 10 minutes range the device is available 2-3 times and only let's say for 5~60 seconds.
So for now I have switched back to https://github.com/maximkulkin/esphomekit/commit/a4b8d3e8020c7af92d49ed7f2f35c461f1917d01 as with it, I can enable all of my features and it still has enough memory to pair devices without a problem. Also, the UDP server can work seamlessly. To improve my issue of device availability I just change the MDNS_TTL=10
, with such TTL my devices are available more than 90 percent of the time.
Hey @maximkulkin, I have updated my repo to use current master https://github.com/maximkulkin/esp-homekit/commit/379f593baad364c90233587a96241f636719d103 and I can't get a device paired in comparison to https://github.com/maximkulkin/esp-homekit/commit/0f8dd68bc1499f38f82771ac58ddaf3c778cd87f that I lastly used and worked fine
I did the same process using both builds (erased device with first pairing) and compared the logs (I will paste probably the crucial difference):
The repeating behaviour that I found (on master) is that :
I have checked and compared
server.c
changes but here are a lot of changes and I'm not sure if this is related to the changes made in the methodhomekit_client_process
.I verified that at the end of
homekit_client_process
client->disconnect == false
(that was my first suspicion). On the other hand after the logFinished processing
nothing happens for a long time and then the disconnection is made.If you would like me to put more logs or details let me know. I would love to get it running as I'm quite excited to try out the new MDNS implementation. Btw I also see more heap used in the new implementation.
Logs
Old one (working)
Master