Re: A network-change detection and IPv6 quirk - on Windows

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