Don't pass HMACKs through reassembly code

ACKs to fragmented notices keep the multiuid field, but multipart becomes "".
This is interpreted as 0/z_message_length. This means ACKs to non-initial
fragments look like an initial fragment from the multipart field, but not when
checking uid == multiuid. The result is that they get smashed when passing
through reassembly.

6e8ec12b0ba9d476e065957028e4cf9cf69d6ac2 addressed this. For SERVACKs and
SERVNAKs, it drops all but the initial ones (uid == multipart) on the floor. It
ignores the problem for HMACKs. Normally ZSendPacket blocks on the HMACK before
sending each successive fragment, so there's no opportunity for them to
collide. But if calling ZSrvSendNotice with a custom send_function that doesn't
block, the HMACKs can smash into each other depending on timing.

Instead, fix it by using z_uid instead of z_multiuid as the multiuid key. For
compatibility, keep the SERVACK dropping behavior. (I'd like to get all the
SERVACKs too, but potentially that'll confuse clients somewhat.)

0 files changed, 0 insertions, 0 deletions