Client switches network about ndprbrd HOT 13 CLOSED

I'm glad you've enjoyed this, however I'm not using it myself anymore, because I finally switched to another ISP which doesn't have this issue.

I've split your two bugs to separate github issues.

I like the idea of expiring old route early, if the address was discovered on a new interface.

from ndprbrd.

Issue number two is partly resolved after changing the source code from "del" to "flush", however, it' still a possible gap of up to what expiry is set when a client switches from one interface to another. I'm running it with expire=10, that's acceptable (instead of default 10 min), however is there anything bad you can think of having such a low expiration?

Would it be hard adding this feature, that is deleting an existing route instantly when the same IP is found on a new interface? I'm checking your code, but I'm not an experienced programmer you see... :)

One more question, when is below code run and why?

void replaceSystem(const std::string& addr, const std::string& iface) { subprocess::popen pr("ip", {"-6", "route", "replace", addr, "dev", iface, "protocol", proto_}); pr.wait(); }

from ndprbrd.

If routes expire after 10 seconds, I'm surprised why it works for you. In my tests neighbours were solicited and advertised every 30 seconds, so half of time the client shouldn't be accessible.

Would it be hard adding this feature

I think, the daemon would need to listen for all traffic on the interface, not only NDP. If NA message is enough, only RouteTable::learn needs to be updated, but I didn't see NA being generated without sending NS first; and while there is a route, NS for the host won't be send to other interfaces (without sending it raw). Maybe I just didn't investigate NDP options enough though.

So, it would need some coding and some testing. Not very hard, but depends on your skills.

One more question, when is below code run and why?

On startup, and when receiving Neighbor Advertisement message from interface.
On startup, for TAP interface created, for the whole /64. When receiving NA, it's called for that exact address.

from ndprbrd.

Yeah, I think I see what you mean. When continuously pinging a host I see many "request timed out" or "destination host unreacable". Maybe your right that 10 s is too low for deleting and readding the route.

It really should be fixed, maybe it's not that common switching between interfaces, but when you do there will be no access (default for 10 min...). There will be duplicate routes during this time but on two different interfaces.

Isn't it just possible adding another check in the function thats adding the routes? I mean before the second route gets added, first check the current routing table for the same IP, and if it exists remove it and then add the new route.

from ndprbrd.

Actually, check the routing table every time a new route gets added, just to see so that it isn't already there but on another interface

from ndprbrd.

It really should be fixed

Yeah, I never move devices between networks, so didn't need to implement that :P Maybe I'll implement it at some point, or maybe someone else will.

Isn't it just possible adding another check in the function thats adding the routes?

Please check my previous message.
If there is a route found already, NS is not send to other interfaces, so NA is not received from them. If NA is received - sure, another check in that function is all that's needed.

from ndprbrd.

But if it's like your saying, why does a second route then get added at all?

from ndprbrd.

Good question.

Probably there are some other scenarios where NA is sent, without NS. My statement is based on my observations, and you could e.g. have devices which behave differently from mine.
Then yes, I agree, at least in some cases that check will be enough.

from ndprbrd.

Well, I've tried both with my wireless Windows PC and Android phone, after switching WiFi-connection in a couple of seconds there is a duplicate route on my gateway for both clients. So I think a check before adding a new route to see if the IP already exists in the routing table (and removing it) would seem to be a good compromise.

If it's only a matter of a simple change in the RouteTable::learn, could you maybe guide me how to do it? :)
I'm not quite completely understanding the code...

from ndprbrd.

Actually, as I understand NDP a NA is sent when a client connects to a network (or atleast the first time any network requests are sent), and NS are sent when a client want to reach another client for the first time.

from ndprbrd.

Ah, that can explain it. When I was writing/testing ndprbrd, I didn't try that.

from ndprbrd.

May you try the version at https://github.com/google/ndprbrd/commits/move ?
I'll try to modify Travis configs later.

from ndprbrd.

It works great now, although there is a small random delay when switching WiFi and trying to access any IPv6 resource (until the change is first detected), but it's fully acceptable and in many cases probably even not noticeable. Thank you!

from ndprbrd.