Currently, the update response is sent whenever an event tag with eventtype 3 or 13 is found in the request and eventresult is 0. In my tests, the client sent event tags with eventtype 3 and eventresult 2 for update check requests (see an example request from the client below). Those requests were met with an empty response from the server, because the server entered the branch on line 88.
I believe checking for eventtype 3 or 13 and eventresult 0 is not the right way to detect whether the client wants to get update information. According to the spec, I think it is more reliable to verify whether the <updatecheck /> tag is present in the request. (Side note: The spec actually forbids the client from sending both an <updatecheck /> tag and an <event /> tag in the same request, but the reMarkable client seems to ignore this rule.)
This PR implements this logic change. I tested it successfully on my rM2 (upgraded from 2.5.0.27 to 2.6.1.71).
Currently, the update response is sent whenever an event tag with eventtype 3 or 13 is found in the request and eventresult is 0. In my tests, the client sent event tags with eventtype 3 and eventresult 2 for update check requests (see an example request from the client below). Those requests were met with an empty response from the server, because the server entered the branch on line 88.
I believe checking for eventtype 3 or 13 and eventresult 0 is not the right way to detect whether the client wants to get update information. According to the spec, I think it is more reliable to verify whether the
<updatecheck />
tag is present in the request. (Side note: The spec actually forbids the client from sending both an<updatecheck />
tag and an<event />
tag in the same request, but the reMarkable client seems to ignore this rule.)This PR implements this logic change. I tested it successfully on my rM2 (upgraded from 2.5.0.27 to 2.6.1.71).