AlliedTelesis switches support merge #3
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…evel" This reverts commit 125a09b. Reason: I left behind the old pf/ allied telesis files
Default does the right thing (w/o logging warnings) now
Contributor
Author
|
completed review |
obilodeau
added a commit
that referenced
this pull request
Mar 20, 2012
AlliedTelesis support in 802.1X / MAC-Auth
Closed
fdurand
pushed a commit
that referenced
this pull request
Nov 5, 2025
Root cause: Async deletion created race condition with recreation events Flow before (BROKEN): 1. Delete vswitchbr → spawn async goroutine for deletion 2. Recreate vswitchbr → RTM_NEWLINK events arrive IMMEDIATELY 3. Events check intNametoInterface → interface STILL there (deletion goroutine hasn't run) 4. Events skip or race 5. Deletion goroutine finally runs → clears maps 6. More recreation events arrive → multiple process the interface → DUPLICATES Flow after (FIXED): 1. Delete vswitchbr → handleDeletedInterfaceSync (SYNCHRONOUS) - Immediately clears intNametoInterface - Immediately clears DHCPConfig.intsNet - Immediately clears VIP maps - Immediately clears processingInterfaces (debounce reset) 2. Recreate vswitchbr → Multiple RTM_NEWLINK events arrive 3. Event #1: Not in map, take lock, not in debounce, set debounce, process 4. Event #2: Not in map, try lock, WAIT (event #1 holds lock) 5. Event #2: Get lock, check debounce, HIT (event #1 set it), SKIP 6. Event #3+: Same as #2 Key changes: 1. Deletion is now SYNCHRONOUS (handleDeletedInterfaceSync) - Called directly from event loop, not via goroutine - Ensures deletion completes before any recreation events are processed 2. Clean state after deletion - All maps cleared immediately - Debounce cleared to allow immediate recreation - But synchronous processing ensures only ONE recreation event processes 3. Proper sequencing - Delete completes fully → then recreation events are processed - No race between deletion and recreation - Synchronous processing serializes multiple recreation events Expected behavior: - Delete and recreate vswitchbr multiple times - netstat should show exactly 1 unicast + 1 broadcast listener - No accumulation of duplicate listeners - DHCP should work immediately after recreation Testing: for i in {1..5}; do ip link del vswitchbr 2>/dev/null || true ip link add vswitchbr type bridge ip addr add 10.255.255.1/24 dev vswitchbr ip link set vswitchbr up sleep 2 netstat -nlp | grep "10.255.255.1:67" | wc -l # Should always be 1 done
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.