- The problem ...
Reported by godjonez, Apr 29, 2010
Noticed this on HTC Desire, running Android 2.1.
Shortly: When connected on WiFi to a network which specifies a domain name, hostnames in that domain do not resolve without appending the domain to the hostname.
As background, our university has a wireless network open to students so that the network itself is "open", not secured, but no traffic past the gateway is allowed prior authentication using a web browser. In particular, if you try to access any web page with a web browser before authentication, you will always be redirected to https://joynet:443/login
Only once you have successfully logged in on that page, all network connections work as you'd expect them to normally work.
The problem is that the hostname (in this case "joynet") cannot be resolved to its IP address. When I do ping to joynet on my laptop, it says it is pinging "joynet.joensuu.fi" [192.168.0.1]. If I do the same on Android phone, using Android Debug Bridge (adb), for "ping joynet" it says
it cannot find the hostname. If I do "ping joynet.joensuu.fi", it pings correctly on 192.168.0.1.
And this brings the problem that since the joynet gateway HTTPS server only shows the login form when hostname "joynet" is used in the HTTP headers, it makes it impossible to use WiFi on such networks because logging in is not possible. (going to https://joynet.joensuu.fi:443/login or https://192.168.0.1:443/login simply causes a redirection to https://joynet:443/login)
So my assumption here is that there is a bug that Android does not take into account the domain of the network it is connected to, and this causes local hostname lookups to fail.
Too long to read ... until ...
Comment 125 by project member rgreenw...@google.com, Nov 21 (46 hours ago)
The fix for this has gone in thanks to Kevin Tang. It will be available in the next major release.
the reason ...
Comment 129 by project member rgreenw...@google.com, Nov 21 (46 hours ago)
Guys, it was a matter of prioritization and resources. We don't have people to put on every requested feature and we certainly were not idle during this time. I apologize it took so long.
I can't say what the next version will be (neither know it nor can discuss it) but it will be after 4.2, which has already gone out.
Now we know that 4.2 is still being worked on due to some more pressing issues. So a few more months of waiting will not be so bad ...
Source
cheers ...
Reported by godjonez, Apr 29, 2010
Noticed this on HTC Desire, running Android 2.1.
Shortly: When connected on WiFi to a network which specifies a domain name, hostnames in that domain do not resolve without appending the domain to the hostname.
As background, our university has a wireless network open to students so that the network itself is "open", not secured, but no traffic past the gateway is allowed prior authentication using a web browser. In particular, if you try to access any web page with a web browser before authentication, you will always be redirected to https://joynet:443/login
Only once you have successfully logged in on that page, all network connections work as you'd expect them to normally work.
The problem is that the hostname (in this case "joynet") cannot be resolved to its IP address. When I do ping to joynet on my laptop, it says it is pinging "joynet.joensuu.fi" [192.168.0.1]. If I do the same on Android phone, using Android Debug Bridge (adb), for "ping joynet" it says
it cannot find the hostname. If I do "ping joynet.joensuu.fi", it pings correctly on 192.168.0.1.
And this brings the problem that since the joynet gateway HTTPS server only shows the login form when hostname "joynet" is used in the HTTP headers, it makes it impossible to use WiFi on such networks because logging in is not possible. (going to https://joynet.joensuu.fi:443/login or https://192.168.0.1:443/login simply causes a redirection to https://joynet:443/login)
So my assumption here is that there is a bug that Android does not take into account the domain of the network it is connected to, and this causes local hostname lookups to fail.
Too long to read ... until ...
Comment 125 by project member rgreenw...@google.com, Nov 21 (46 hours ago)
The fix for this has gone in thanks to Kevin Tang. It will be available in the next major release.
the reason ...
Comment 129 by project member rgreenw...@google.com, Nov 21 (46 hours ago)
Guys, it was a matter of prioritization and resources. We don't have people to put on every requested feature and we certainly were not idle during this time. I apologize it took so long.
I can't say what the next version will be (neither know it nor can discuss it) but it will be after 4.2, which has already gone out.
Now we know that 4.2 is still being worked on due to some more pressing issues. So a few more months of waiting will not be so bad ...
Source
cheers ...
