SixXS::Sunset 2017-06-06

Linux (firefox?) flipping back and forth between v4 and v6
[de] Shadow Hawkins on Wednesday, 10 April 2013 17:59:31
Hi, every now and then I have the very annoying problem with Firefox that it quickly switches back and forth between using IPv4 and IPv6 when accessing my webmail. Since the webmail actually checks the IP, I get logged off when that happens. Occasionally this switch happens very rappidly: I log in, it kicks me out because of the v4/v6 IP change, I log in again, try to open an email and again get kicked off because of IP change, and so forth for a couple of iterations. I can't reproduce the problem at all. I don't believe it is firefox's fault, since once I had the same behavior with chromium. My openwrt router uses aiccu and radvd to provide IPv6 connectivity to my network. Enabling 'verbose' mode for aiccu hasn't give me any more info. I'm also at a loss how to notice if radvd withdraws the default route, since it seems that no messages are logged for router advertisements in Linux. Does anyone have a clue? Fortunately it doesn't happen particularly often (which is why I suspect a tunnel issue), but when it does it's maddening and I can't seem to trace the problem to its root. Thanks, ~David
Linux (firefox?) flipping back and forth between v4 and v6
[ch] Jeroen Massar SixXS Staff on Wednesday, 10 April 2013 20:06:14
Since the webmail actually checks the IP
This check is quite futile and only causes issues with NATs. proxies and other such setups where addresses are expected to change. You should disable that check. A better way to protect your cookies from being stolen is to use SSL/https.
I don't believe it is firefox's fault, since once I had the same behavior with chromium.
The problem is that with the advent of Happy Eyeballs it is really hard to determine what part of the full stack (Kernel, libc, system-resolver, application) makes the decision on which address will be used. Yes, indeed, the application can make their own decision too, which adds to the fun. (OSX is the best in that area as they use latency to determine which address gets contacted, thus then it really becomes random what gets used).
Enabling 'verbose' mode for aiccu hasn't give me any more info.
AICCU does not make decisions on what addresses gets used, it just sends packets. Now of course, those tunneled packets might be slower than native IPv4 packets due to the tunnel overhead and thus in that case IPv4 might get preferred over IPv6 if something in the stack decides based on that merit.
I'm also at a loss how to notice if radvd withdraws the default route, since it seems that no messages are logged for router advertisements in Linux.
tcpdump could help there, but as you are on Linux just do a 'ip monitor" to see netlink messages that might affect any routing changes.
I can't seem to trace the problem to its root.
Because of the stack that can decide which remote address is chosen you will have a hard time.... Chromium btw exposes a little bit of it's decision making process, check chrome://dns for this.
Linux (firefox?) flipping back and forth between v4 and v6
[de] Shadow Hawkins on Wednesday, 10 April 2013 23:01:23
Jeroen Massar wrote:
> Since the webmail actually checks the IP This check is quite futile and only causes issues with NATs. proxies and other such setups where addresses are expected to change. You should disable that check. A better way to protect your cookies from being stolen is to use SSL/https.
The webmail is only accessible over https, so I guess turning off the IP check won't hurt. I'll probably do that.
> Enabling 'verbose' mode for aiccu hasn't give me any more info. AICCU does not make decisions on what addresses gets used, it just sends packets.
Sure, but I was afraid that the tunnel may be down for short periods of time.
Now of course, those tunneled packets might be slower than native IPv4 packets due to the tunnel overhead and thus in that case IPv4 might get preferred over IPv6 if something in the stack decides based on that merit.
I think they're slower almost all the time, so most likely that's not the issue either.
> I'm also at a loss how to notice if radvd withdraws the default route, since it seems that no messages are logged for router advertisements in Linux. tcpdump could help there, but as you are on Linux just do a 'ip monitor" to see netlink messages that might affect any routing changes.
Now that's a great hint. I see very often messages like:
fe80::c43d:c7ff:fea7:xxxx dev br0 lladdr c6:3d:c7:a7:xx:xx router STALE fe80::c43d:c7ff:fea7:xxxx dev br0 lladdr c6:3d:c7:a7:xx:xx router REACHABLE
with some seconds in between. That is the address of my default route. Now what may be causing this? Google is not very helpful...
Chromium btw exposes a little bit of it's decision making process, check chrome://dns for this.
Thanks, I will look at that too.
Linux (firefox?) flipping back and forth between v4 and v6
[ch] Jeroen Massar SixXS Staff on Thursday, 11 April 2013 04:53:25
David Mohr wrote:
Jeroen Massar wrote:
tcpdump could help there, but as you are on Linux just do a 'ip monitor" to see netlink messages that might affect any routing changes.
Now that's a great hint. I see very often messages like:
fe80::c43d:c7ff:fea7:xxxx dev br0 lladdr c6:3d:c7:a7:xx:xx router STALE fe80::c43d:c7ff:fea7:xxxx dev br0 lladdr c6:3d:c7:a7:xx:xx router REACHABLE
with some seconds in between. That is the address of my default route. Now what may be causing this? Google is not very helpful...
Those are standard expiry messages for a node. Check Neighbor Discovery Protocol (NDP) it is standard part of IPv6. The fact that it goes stale simply means it was unused for a while and thus the system was unsure that it was active. The state change to reachable means that it was able to contact it again. See tcpdump and you'll understand it better (check for the sequence of a Neighbour Discovery Request, an answer and packets flowing).

Please note Posting is only allowed when you are logged in.

Static Sunset Edition of SixXS
©2001-2017 SixXS - IPv6 Deployment & Tunnel Broker