-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The fallback.rs implementation generates incorrect down/up events on a loop #30
Comments
Sweet! Can you send a PR? :) |
@mxinden Since I see there was a new point release for libp2p, any chance this could be approved/added for the next one? I am using my own dependency patch but it's a cpu/battery concern for other Android users, especially depending on the processing they do of the spurious notifications. |
Just released your patch. Thanks @cafedetal. Again, impressive find. Given that this is a patch release, downstream dependencies can update to it without intermediaries having to update. Does that make sense? |
As #31 has been merged and a new version released, can we consider this issue closed? |
Thank you @stormshield-gt for the ping. |
The fallback implementation is always reporting down/up events for all interfaces due to a bug in the code:
https://github.com/mxinden/if-watch/blob/31c4780d803431914aab95ec9139aa8e5795f80c/src/fallback.rs#L53-L56
Line 53 will return true if the interface is in both the stored old address list and the newly reported list, therefore generating an IfEvent::Down for all of the addresses in the old list. The addresses then get re-added with a IfEvent::Up in the next block.
A simple reversal of the logic fixes the bug
Tested on android - no more interface spam after fixing that logic.
The text was updated successfully, but these errors were encountered: