mirror of
https://github.com/GNS3/gns3-server.git
synced 2026-10-12 21:45:41 +03:00
1db9f171ca
Three fixes from live-calibrating the kernel impairment filters on an isolated instance (Docker-to-Docker veth link, per-sequence evidence): - update_filters skipped an unchanged filters dict as a no-op, so a one-shot window_drop outage that had already passed could never be re-armed: re-applying the same values produced no datapath command at all. A PUT still carrying window_drop now reconciles, restarting the schedule from the apply as documented. Measured: identical re-apply moves the outage window from seq 50-70 to 70-91 (arm at +8s of the new apply). - gemodel parameter semantics were documented backwards in the validation rules, available_filters, the MCP/copilot descriptions and the feature docs. Measured against the kernel (per-direction counters, offered = sent + dropped): p is the good-to-bad transition chance, r the bad-to-good transition, 1-h the loss chance in the bad state (the good state loses nothing) - mean one-way loss p/(p+r)*(1-h), e.g. [10,30,100] -> 24.8%/25.7% measured vs 25% predicted, [5,45,100] -> 10.8% both ways vs 10%. - kernel_datapath was silently stripped from every REST/MCP link payload by the response model (LinkBase carried no such field), so clients could not tell a kernel link from a relay one. Also verified on the same setup: the 3-argument window_drop form works exactly as specified ([3000,5000,100] -> a single seq 31-55 outage, [20000,6000,100] -> seq 115-144), and both generations of the command builder emit the parameters unpadded. Adds an API test for the field and controller tests for the no-op skip and the window_drop re-arm exemption.