[SOLVED] IPv6 failures prevent loading of sites offering IPv6+IPv4

I'm trying to switch back to dwb (webkit browser) from firefox. Unfortunately, I have been unable to access these forums from dwb. At first I thought it was an isolated incident, but this has now persisted for at least 12 hours. The same pages are accessed fine from firefox on the same computer.

I just installed luakit (another webkit browser). Luakit is also unable to load any pages at bbs.archlinux.org.

Both webkit browsers are able to access archlinux.org, but just not the bbs. Both browsers are perfectly able to view a local copy of a page from bbs.archlinux.org (downloaded via firefox). In both cases, any means of navigating to a bbs.archlinux.org page progresses to only 10% completion and hangs - none of the page is displayed.

I have cleared the cookies, and removed ~/.local/share/webkit and ~/.cache/webkit, but this lead to no change.

I'm not sure how to gather more diagnostic information - any suggestions would be appreciated. Also, are other webkit users having any issues with the forums? I've found a couple superficially related posts on these forums, but they were from several years ago and seemed specific to javascript-ladden pages - I am unable to load *any* page from the specific domain/server bbs.archlinux.org, but only in webkit browsers.

---- updates:

Both browsers tested use webkitgtk2, so I also tried a gtk3 version using webkitgtk - this fails in the same way.

I also tried surf which I ran from the command line (`surf bbs.archlinux.org`). This produce several lines of output relating to the pipelight plugin then stalled without loading the page. Thinking this might be a piece of the puzzle, I disabled all pipelight plugins (just silverlight5.1 in my case) and tried again. Surf now produces no output and still does not load the page.

Running dwb from a terminal also produces no error output. If silverlight is activated it produces various output upon starting, then I get a line for the "cookies" plugin, then nothing until I kill the browser.

I've also confirmed the same results with vimprobable (vimprobable-git from AUR).

WHOA ... well there was a useful question with a surprising answer. Both w3m and lynx show the exact same problem: they can display archlinux.org, but hang indefinitely trying to connect to bbs.archlinux.org.

I have never set up a proxy, and I know next to nothing about them. Conceptually I get it, and I checked out the wikipedia and archwiki pages on them to be sure, but in terms of practical application I'm clueless. `env | grep -i proxy` returns no matches.

As w3m + lynx both failed to connect I also just tried wget. As seen below, I can wget "archlinux.org", but not "bbs.archlinux.org" (I also get the same results with `wget alderaan.archlinux.org`)

wget gives you the --inet{4,6}-only switch: both also work on my custom and vanilla kernels.

Are you in one of those parts of the State with a monopoly ISP? This is (to me) looking increasingly less like an issue with the BBS or your setup. If your are reliant on $bigisp at home and work, I'd be inclined to blame them.

I suspect it is an ISP issue. At home it is one of the BigISP, and work is a university with a dreadful IT department.

But assuming this is an ISP issue, firefox gets around it just fine - I'm curious how. But more on point, I wonder whether disabling IPv6 is a good long term solution.

EDIT: it seems firefox likely worked as there is an option in about:config "network.http.fast-fallback-to-ipv4" which is set to true. I'd prefer to get webkit to fallback to IPv4 over entirely disabling IPv6 - if for no other reason than if my ISP every gets their act together, I will not have to remember to reenable it.

Thanks for the help figuring this out. I never would have thought to check w3m/lynx which led to pinpointing the problem - even if the solution is ugly for now.

I've disabled ipv6 in the bootloader for now, and hope this is a temporary issue with the ISP. They were slow to get on the ipv6 bandwaggon back when it was first rolling out, but I definitely have had working ipv6 connections previously.

The fifth bullet point has a big red X. And it notes that the browser (firefox in this case) falls back to IPv4, but webkit it seems did not.

The bbs.archlinux.org vs archlinux.org seems to be partial coincidence. The bbs page seems to offer both IPv6 and IPv4, firefox would fallback on IPv4 while webkit would choke on the v6. But at archlinux.org only IPv4 is offered, so both browsers work. I've confirmed this pattern on other sites that work and/or fail.

Yes, I'm connected via ethernet cable directly to the router. Though this problem was initially noticed at work where I connect wirelessly to a different network - however all information in this thread has been gathered from the home Comcast connection.

I'm not sure how to interpret that output, but there should be nothing else on this network (on my end at least). I have a comcast co-ax cable line come into this room and no other room of my home. This cable goes to the modem which is connected via ethernet cable to my computer. There are no other computers in my home.

From skimming the ndisc6 man page, I'm under the impression that 00:1D:45:70:4E:32 is the mac address of a discovered "neighbor". I'm checking my modem and ethernet card now, but neither of them seem to match that.

I'm currently out and on a public wifi with the same computer and can confirm that all sites are perfectly reachable with all browsers. So this is specific to my ISP (and perhaps my university's network).

So I'm perfectly content considering this a fully solved and closed issue - many thanks to JWR and Fukawi. Fukawi, if there are other productive ways to dig a little deeper, I'd definitely be interested in learning more - either for curiosity's sake or to get details to report to my ISP if that seems to be the right path. But again, I'm content with having a workaround that consistently works (disabling ipv6 at home).

But again, I'm content with having a workaround that consistently works (disabling ipv6 at home).

Understood, I was only digging deeper for curiosity's sake

I'm guessing 00:1D:45:70:4E:32 is your Comcast modem/router then? I don't know how it works in the states; do Comcast manage that device for you? It seems strange that it would start advertising IPv6 if you didn't tell it to. FWIW, after changing accept_ra earlier, than will only stop a new address being assigned via RA's; the existing one would stay until it expired. Setting accept_ra to 0 in sysctl.conf might be less drastic than disabling IPv6 altogether and allow you to easily enable IPv6 if (when) you need it

To answer some of the questions: yes comcast manages the device. It doesn't surprise me that they'd change something like that. The "grr" thread is filled with stories of what the couple big ISPs around here regularly do that is absolutely insane. But the service is pretty reliable, as long as we tolerate their whims.

I've actually opted for leaving ipv6 on, but I have a shell function to toggle it as needed. The function case a case statement for "on, off" and other handy mnemonics, but essentially it just runs `sudo sysctl net.ipv6.conf.all.disable_ipv6=1` or with the 1 as 0.

This is a laptop I carry around, so any time I connect to my home network I have to physically plug in the ethernet cord on the side - so running a single simle command is no inconvenience. In fact, I have another shell function called "ether" as I so rarely use ethernet - so when I connect at home "ether" runs dhcpcd, starts up offlineimap, and some other little bits. So I can just add the sysctl command to that function and it will be seamless - this way ipv6 is only down when I connect to this one network.

Ah I see, when you said you disabled it in the kernel I thought you meant at boot time in your bootloader

So strange to hear the ISP manages your CPE -- over here you buy whatever modem you want (usually a "supported" one from the ISP) but configuring and managing it is generally your responsibility. Even our business connection at work I had to ask nicely to get them to configure the Cisco 887 before they sent it out.

I guess if they're playing funny buggers with it, there's not much you can do except act in self-defence and wait for them to figure out WTF they're doing.

Sorry for the confusion - I *did* breifly put this in my bootloader. But then I remembered the sysctl method which I had to use on *all* networks around here when IPv6 first "went live." So I removed it from my bootloader and just used the sysctl toggle.