mirror of
https://github.com/GNS3/gns3-server.git
synced 2026-10-12 21:45:41 +03:00
1c85befbab
The esw kernel fast-path scenario deletes and re-creates a link, which re-enslaves the peer anchor — and on NetworkManager hosts NM's netdev state machine can release an NM-managed TAP from its bridge some 60-70 ms after enslavement, ~50% of re-enslavements, while the tap is in NM's not-yet-assumed state. The freed port stays administratively up and no GNS3 process logs anything: the membership assert sees the join, then the ping measures a silent blackhole (this was the line-277 e2e failure). Root-caused with a server-free harness (one uBridge, one fresh tap, one bridge, an addif/delif loop): the same tap frees 20/40 while NM-managed, 0/40 after `nmcli device set <tap> managed no`, 20/40 again when re-managed. Docker's veth host ends are not NM-managed, which is why only TAP anchors ever showed it — including the "anchor lost its bridge membership after a ports_mapping update (TAP peers only)" incident from the switch's development, whose conclusion is corrected in the docs. Unmanage the anchors once the routers have booted, before the scenario re-enslaves them; document the failure signature and the host-side remedy (per-device nmcli call, or NM unmanaged-devices configuration) in the L2-anchor spec and the switch feature doc.