Poorly-characterised issue with Debian wireless networking

[kaberett]

So! My netbook is running Debian. It is fine with domestic wifi; it is fine with non-domestic wifi that's password-protected; it seems to break horribly when attempting to connect to public wireless networks that require you to load a page in a web browser and agree to T&C before finalising the connection. (The box is dual-boot with Win7; this isn't a problem there). It can see the network and attempt to connect; the applet does the one green light for "I can see it and am talking to it", then the two green lights for "and it is talking back", and then sits and spins before eventually giving up. Attempting to load things in browsers (mostly Iceweasel but I've also checked with Epiphany) at this point Does Not Work; in theory I suspect the network is trying but failing to redirect me to the do-you-agree page.

I am failing to come up with appropriate search strings to find existing solutions to this (though I'm sure there must be some); I'm also not braining well enough to actually do proper command-line diagnostics (and am in any case not anywhere near any appropriate networks atm). Any thoughts much appreciated.

Comments

[quirkytizzy]

I wish I knew. :( Me and technology don't get along. Here's hoping someone else will know!

[vass]

in theory I suspect the network is trying but failing to redirect me to the do-you-agree page.

That sounds very plausible.

Is it one particular place with that sort of wifi, or have you tried more than one?

Maybe their T&C page has very stupid settings and won't load if your browser isn't one of the ones they recognise. (Does Iceweasel these days identify itself to servers as Firefox, or as Iceweasel? I would have assumed the T&C page should work with Firefox, IE, and Safari, probably also Chrome and Opera.)

[kaberett]

More than one, hence having done as much pattern-spotting as I have -- happens at the Southbank Centre, and with wifi on the X5 (a coach) and the X90/Oxford Tube (another coach, run by the same company).

[vass]

I use Debian as well. I've only even taken this laptop out of the house twice, to two NaNoWriMo write-ins last November. One of those was at a library, and I do vaguely remember having trouble with the public wifi too, but I can't remember the details of what went wrong, only that I ended up just tethering it to my phone. The other write-in had private wifi, and I didn't have a problem with that either.

[silveradept]

The silver lining is that you're not the first person dealing with captive portal (the technical term for this login redirect nonsense) issues on Linux. The bad thing is, my search engine attempts only have produced older material, all recommending an upgrade to the latest version, latest kernel, and latest software, including browser, as the solution that apparently magically works. For Debian, that may mean having to pin to the testing repository (wheezy?), or in the very worst case, the unstable one (sid).

[mair_in_grenderich]

I have no idea, but my (broken Ubuntu) install decided between nov and dec of last year that it (nm-applet) wasn't going to connect to *any* new wireless networks. I installed a thing called wicd-gtk and that will connect to networks where nm-applet won't.

However none of the networks in my case are the kind you describe, so I don't know if that will help any (or if the thing exists in debian).

(And obviously it doesn't solve whatever the underlying problem is, but I sort of gave up caring. And my new laptop was posted Royal Mail first class on Tuesday! It might arrive soon and I can install something unbroken on it! And maybe it won't whine the whole time and I won't have to wear ear defenders while using it?)

[swaldman]

This is probably a silly question, but what do you try to load in browsers in order to attempt to reach the login page? I ask because if it is anything secure (which can be a lot of things if you have HTTPS Everywhere installed), the redirect will fail.

But probably that's not the answer, in which case I can't help beyond saying "argh, captive portals suck".

[kaberett]

(1) I know about the https wossname and have avoided it :-)

(2) The OS never thinks it's sufficiently connected to allow the browser to get as far as implementing a redirect, AFAICT...

[shortcipher]

...*facepalm* :-p

My first thought is that perhaps you have a static DNS configuration instead of what the captive portal gives you, which may lead to failure to redirect and failure to reach anything else, depending on the portal's implementation. But then, the fact that the applet "gives up" suggests that either your particular applet notices this failure mode, or something lower-level is broken, e.g. wireless authentication never fully completes.

Happy to take a look when next in the same place as it (Friday?) and meanwhile there may be informative lines (mentioning wpa_supplicant?) in /var/log/syslog (possibly other files in /var/log?) which I believe are kept for 7 days by default (rotated to syslog.0, syslog.1.gz etc.)