On Thu, 25 Feb 2016, Patrick McManus wrote:
the remedies are backwards looking (flush caches, close connections etc)..
so the phrasing about the hash was probably too lazy, but perhaps the basic
idea has merit?
We can certainly use a hash to figure out that we're dealing with a "yo-yo
interface", but what to do with that information is the tricky part.
I'm currently thinking of a few different routes of exploration:
1. check the routing table (updates) to better figure out when an adapter is
removed but doesn't affect the routing as then it shouldn't need to cause a
network change. Then it would also have to not signal a network change on a
new adapter until it gets routing added to it. I don't really know what the
Teredo adapters get in terms of routing by default - and especially not for
these yo-yo setups.
2. check data counters for the particular adapter so an unused adapter can be
ignored when removed. This will obvsiously not affect new adapters so it'll
only address half the problem.
3. Use of a hash to store added and removed adapters and keep them around for
N minutes (I'm thinking 300 seconds to start with). If an adapter is
added/removed and its name is already in the hash, it's a yo-yo and we ignore
it. It is a bit harsh and risky but... We could potentially work on a scheme
where the N value changes over time to adapt.
4. Short-term and the most abrupt: disable (behind a pref) the use of
NotifyIpInterfaceChange. It makes Firefox go back to the old
NotifyAddrChange() method which doesn't have this problem - mostly because it
doesn't support IPv6. Incidentally, Chrome only uses NotifyAddrChange to
detect network changes.
--
/ daniel.haxx.se
_______________________________________________
dev-tech-network mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-network
