You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order for the TO1 protocol to work (device contacts rendezvous to get an address to contact its owner), the TO0 protocol must have been already performed (rendezvous is contacted by the owner to get a TO1d blob and the OV with a GUID, so that the rendezvous can know where to redirect the devices).
The log of the rendezvous server shows that it's rejecting a TO1HelloRV from a client since it has just started working, then it gets a couple of TO1D ( starting with the message type msg/20: 192.168.100.1:38486 "POST /fdo/101/msg/20 HTTP/1.1" 200 "-" "-" 1.984493ms) and it's storing some GUIDs as a result of that. Later it is processing the TO1 protocol as it should know now that it has GUIDs stored:
the msg/30, msg/32 message types show that the client is properly communicating with the rendezvous, the rendezvous (not shown in the logs) is sending msg/31, msg/33, as it should (see this).
So, what I want to say is that timing is important here, it's a MUST to return a ResourceNotFound when no GUIDs are found by the rendezvous according to the GUID given by the client. Then, as the rendezvous gets GUIDs it is able to fulfill the requests of the client. So, not a bug.
When I run FDO server or aio tests, 80% of times I can get T01 error. This error doesn't block fdo functions I tested.
For fdo services:
For fdo-aio:
The text was updated successfully, but these errors were encountered: