d337cf4a1e
Seeding and picking a server each happen once per connection. Neither had a guard, so a client pipelining into the recv buffer could re-run the handshake before the queued disconnect drained and reach both handlers again. A second play-server is the one that mattered: this connection may already have spent its auth id on a game login, and the id it would be handed back is the spent one, which nothing will redeem. Rejecting the packet is the honest answer -- the client is out of protocol order, not unlucky. Account login and game login already guarded on SentFirstPacket. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| IncomingAccountPackets.cs | ||
| IncomingEntityPackets.cs | ||
| IncomingExtendedCommandPackets.cs | ||
| IncomingHousePackets.cs | ||
| IncomingItemPackets.cs | ||
| IncomingMessagePackets.cs | ||
| IncomingMobilePackets.cs | ||
| IncomingMovementPackets.cs | ||
| IncomingPlayerPackets.cs | ||
| IncomingTargetingPackets.cs | ||
| IncomingVendorPackets.cs | ||