Unexpected Blocking network recv call in XKoreProxy

[OmniDefenestrator]

I've been banging my head against trying to get OpenKore working in XKore 3 mode for a while now, and it looks like I may have stumbled across a possible blocking call that should be non-blocking (or at least a bug somewhere); I was hoping somebody could help me identify the cause.

I've set up XKore 3 and have my client pointing to it. I can log into the account server fine, but when I go to continue on to connect to the char server, XKore console says "connecting... connected", but then hangs until the client times out, which it does after a few seconds saying "Failed to connect to server".

In XKoreProxy L238, the recv() call seems to be blocking (determined through debug prints) even though immediately above it dataWaiting returns true (which evidently is supposed to indicate that recv will return in a non-blocking fashion).

I have confirmed that the client is actually sending a packet and kore is actually receiving and acking receiving it (at a TCP level through packet sniffing), but the bot's console doesn't update, nor does it progress beyond the recv() call it's stuck on.

Any devs have any idea why/how this may be happening? Alternatively, an explanation of how Kore's dataWaiting() works so that I can try to track down what's happening myself would also be appreciated. I'm afraid I'm not familiar with Perl, but I'm well-versed in Python and Java.

Let me know if you need any additional info.

Thanks!


UPDATE: It looks like the Kore actually is receiving the packet (if I visualDump inside of XKoreProxy.clientRecv, I see the packet). However, it looks like the regular handlers/callbacks aren't getting invoked when the packet is received. (FWIW, this server has changed their char login packet to 0386, but adding that to send/ doesn't help.)


UPDATE 2 / RESOLVED: Turns out if Kore receives a packet that is mislabeled as size 0 in recvpackets when it's actually not, it silently drops it.