mirror of
https://github.com/pyMC-dev/pyMC_Repeater.git
synced 2026-08-03 15:32:35 +02:00
agessaman
b2e45c2038
Room server pushes waited on dispatcher.wait_for_ack, but nothing in the repeater could ever resolve it, so every push timed out and re-pushed on the backoff schedule (issue #286's duplicate floods — worst for virtual companions on the same instance, whose ACKs never even cross the air): - no core AckHandler is registered (all RX lands in the router fallback), so received ACK CRCs were never fed to dispatcher ACK matching - inject_packet waited on packet.get_crc(), a packet-hash CRC that no ACK sender produces; the crypto CRC only the room server knows was ignored - PATH returns (how a flood-received DM is ACKed) were decrypted by PathHelper, but it read the encoded path_len wire byte as a raw count — an empty 3-byte-hash path (0x80) parsed as a 128-byte truncated payload — and the router's PATH branch never ran PathHelper for room/repeater destinations when any companion bridge existed Fixes: - router ACK branch feeds discrete ACK CRCs (RF and locally injected) to dispatcher._register_ack_received - PATH packets addressed to a local server identity are processed by PathHelper regardless of companion bridges; PathHelper decodes the encoded path_len via PathUtils, keeps the encoded byte in out_path_len, and registers the embedded ACK via ack_received_fn - inject_packet accepts expected_ack_crc/ack_timeout; the room server passes its crypto CRC and a hop-count-based timeout (the encoded byte would have produced a ~4-minute direct-push wait) Verified live on a real mesh: push to a same-instance virtual companion resolves via the PATH-embedded ACK (encoded path_len 0x80) and push to a firmware client resolves via the discrete RF ACK, no re-push loops. Fixes #286 Fixes #341