Author Topic: Invalid Tutorial on Website for reading Packets in 64bit  (Read 18707 times)


  • Not-a-newbie
  • *
  • Posts: 1
  • Karma: 0
    • View Profile
Invalid Tutorial on Website for reading Packets in 64bit
« on: December 12, 2014, 09:15:10 PM »

Our team and I have been implementing RakNet into our product since August. Occasionally, we've randomly been getting crazy RakNet packet IDs that haven't made much sense.. but we just didn't bother handling them and figured there was just some weird cases in RakNet that didn't pertain to our implementation. However we've randomly had issues that during our loading phase where certain people were getting disconnect notifications, or just just stalls that we couldn't explain, and when we'd go attempt to debug the code, the problem would disappear and we couldn't reproduce it. It's been quite the headache.

Fortunately today I manged to become the victim of this bug in our implementation of RakNet enough where I could debug it consistently. I was getting ID_DISCONNECTION_NOTIFICATION sent to me even though we didn't actually disconnect, however this invalid message caused me to handle the disconnection, and leave the server.

Essentially what was happening is that when we were reading packets from the RakNet Peer and trying to get the PacketID, we would read the identifier incorrectly if it had an ID_TIMESTAMP on it. we were setup to handle timestamps like the tutorials show when parsing the identifier, however at least one of the tutorials on the website (which is what we implemented) is not correct in the case of 64bit builds.

This tutorial here is what we copied in our code. As you can see it correctly looks for and attempts to offset the data to find the correct identifier for a message. However, "unsigned long" is 4 bytes in both 32/64bit builds. RakNet will use 4-byte timestamps in 32 bit, and 8-byte timestamps in 64bit (RakNet::Time). Another tutorial shows the implementation correctly:  (Section: Reading Packets)

They correctly use the sizeof(RakNet::Time) which will give the correctly give 4 bytes or 8 bytes depending on your build architecture.

Essentially this was spoofing invalid messages to our system that weren't true messages because of the offset issues in 64bit builds. Funny enough is that because we were reading part of the timestamp as the message identifier in these cases, we'd only get this issue at certain times of the day (makes it difficult to track down).

I think the first tutorial I linked needs to be updated to use sizeof(RakNet::Time) instead of sizeof(unsigned long). Many people following that could be having similar issues.

Take care!
- Cameron