Created an attachment (id=656) [details]
A test program that uses the network devices and routing table to decide
whether host can be accessed

Whipped up a little test program that checks whether a host/ip is reachable. It
uses gethostbyname which of course might be a problem in some situations (when
there _is_ connectivity).

Comment 2 Kalle Valo 2007-12-06 17:15:23 UTC

Why this was assigned to me?

Comment 3 Kalle Valo 2008-01-18 10:26:26 UTC

This is not my area, moving bug to Patrik Flykt.

Comment 4 Quim Gil 2008-09-29 08:39:02 UTC

This bug is in the Top 10 of the Bug Jar. Any updates? Do youn know whether
this will be fixed at least in Fremantle?

Thanks

Comment 5 Andre Klapper 2008-10-07 17:07:13 UTC

Patrik?
This would also fix two bugs blocked by this...

Comment 6 Andre Klapper 2008-11-27 13:23:45 UTC

Patrik, are there plans to address this for Fremantle?
This would also fix two bugs blocked by this...

Comment 7 Patrik Flykt 2008-11-27 13:49:42 UTC

(In reply to comment #6)
> Patrik, are there plans to address this for Fremantle?

Currently no.

If somene feels like it, please propose an API extension and implementation.

Comment 8 Andre Klapper 2008-12-04 13:17:22 UTC

(In reply to comment #7)
> (In reply to comment #6)
> > Patrik, are there plans to address this for Fremantle?
> 
> Currently no.
> If somene feels like it, please propose an API extension and implementation.

At least not my field of work.

Now I wonder if this really is a bug (and hence there should be an internal
copy of this) or more considered as an enhancement. At least it has 11 votes
and blocks two other issues so it should be handled.

Comment 9 Quim Gil 2008-12-05 13:05:46 UTC

Patrik's answer denotes that there are currently no specs to deal with local
connections so for his team this is not a bug but a feature request. Therefore
the related bugs are also, in fact, feature requests.

Comment 10 Andre Klapper 2009-06-15 15:52:01 UTC

After disconnecting from my wifi, starting the browser, entering
"http://localhost/" and pressing Enter I do NOT get a network search/connection
dialog at all in Diablo 5.2008.43-7 on a N810. Same in current Fremantle.

Hence updating bug summary.

(In reply to comment #10)
> After disconnecting from my wifi, starting the browser, entering
> "http://localhost/" and pressing Enter I do NOT get a network search/connection
> dialog at all in Diablo 5.2008.43-7 on a N810. Same in current Fremantle.

Yeah, microb now has special handling for localhost (bug 339 comment 7 & 12),
and it actually *is* able to access localhost when offline.  Programs that
don't use ICD (eg ping or ssh) also work fine.

The steps outlined in bug 1766 are still valid for testing this.

Comment 12 Quim Gil 2009-06-22 07:51:30 UTC

(In reply to comment #10)
> After disconnecting from my wifi, starting the browser, entering
> "http://localhost/" and pressing Enter I do NOT get a network search/connection
> dialog at all in Diablo 5.2008.43-7 on a N810. Same in current Fremantle.
> 
> Hence updating bug summary.

Tested with Fremantle w25: no matter whether you are in offline mode or only
disconnected, typing http://localhost/ in the browser location bar does
activate a connection.

Comment 13 Quim Gil 2009-09-28 09:54:44 UTC

After all this time there has been no progress here. I'd like to raise this to
a product manager but in order to do this properly something is missing: 

What are the use cases? 
What problems this feature would solve?

Actually is not obvious to me (personally) since as a user I have never missed
such feature.

Comment 14 Andre Klapper 2009-09-28 12:00:20 UTC

I assume running a local server on the N900 is one usecase.

Comment 15 Quim Gil 2009-09-28 12:06:35 UTC

Why a Maemo user would want to do that?

Yes, I'm playing evil advocate's role here. Since this request has been aroud
since the first days of maemo but it hasn't made it through our project plans,
it's goot to find the use cases and then make the decision based on them,
instead on by the feature in itself.

Comment 16 Andre Klapper 2009-09-28 12:14:10 UTC

e.g. to run a local wiki server (I think I saw this in one comment in Bugzilla
here). But I agree that we want to see other comments here, otherwise this
could become a WONTFIX.

(In reply to comment #15)
> Why a Maemo user would want to do that?

If you run any kind of service on the tablet it's reasonable to expect to be
able to access it from the tablet itself.  This can include various web
services (although bug 339 deals with those specifically), offline caching
proxies (bug 2931), media streaming services, exposing various system events as
an RSS feed etc.  One particularly intriguing (at least for me) possibility for
>= Fremantle devices is a local telephony server (eg asterisk) to provide
various "advanced" features like voicemail, conferencing, least-cost routing
etc, accessed via the built-in SIP client.

Most of the above may sound like advanced user territory, but with proper
packaging they could be useful to everyone.

Use case #1 - use of local web server
User installs a local web server (lightHTTPD, Apache) and CGI modules which
implement a web application (e.g. WIKI, local blogging software).
User is in a location where connectivity to the Internet is not available or
allowed (e.g. aircraft in flight).
User opens local browser.
User accesses http://localhost/<url>

Currently, this fails as the system will attempt to connect to a network and,
failing that connection, will NOT proceed to the access.

Comment 19 Neil MacLeod 2009-09-28 15:43:58 UTC

Alternatively, can anyone explain why it is a good idea/correct/valid for the
OS to attempt to establish a network connection for localhost requests, and
when it cannot establish a connection to then fail to resolve localhost?

Whether there is a current use case or not, surely the current need to
establish a network connection for non-network requests is *clearly* wrong
(unless I'm mistaken) and presents a problem for future development of services
that may wish to resolve locally. Even if there isn't a valid (or sufficiently
valid) use case today, there surely will be in future.

Yes, I was one of the original people who raised this .. I run two local
servers on my device -- a private Wiki for personal notes, travel scedules,
etc., when travelling, and another for shared pages when attached by WiFi.

Completely floored when I couldn't access the first when on an aeroplane!  The
wiki data was in a database, and I had to dig around manually and fortunately
found a cached HTML page with the data I needed.  Not being able to read/take
notes for the rest of the (8.5 hour) flight was "irritating", too.  

This just seems an extraorinarily unnecessary restriction .. never came across
it on any laptop, netbook, etc.

this bug is similar to https://bugs.maemo.org/show_bug.cgi?id=339

(In reply to comment #20)
> This just seems an extraorinarily unnecessary restriction .. never came across
> it on any laptop, netbook, etc.

I have not been able to reproduce this behaviour:

Shut down internet connections:

sudo gainroot
python

>>> import socket
>>> serv = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
>>> serv.bind((socket.gethostname(), 80))
>>> serv.listen(5)
>>> while True:
...     (client, address) = serv.accept()
...     while True:
...             print client.recv(20) # after this line, hit enter twice, then
load up browser and point to localhost
... 
GET / HTTP/1.1
Host
: localhost
User-Ag
ent: Mozilla/5.0 (X1
1; U; Linux armv7l; 
en-GB; rv:1.9.2a1pre
) Gecko/20091127 Fir
efox/3.5 Maemo Brows
er 1.5.6 RX-51 N900

Accept: text/html,a
pplication/xhtml+xml
,application/xml;q=0
.9,*/*;q=0.8
Accept
-Language: en
Accep
t-Encoding: gzip,def
late
Accept-Charset
: ISO-8859-1,utf-8;q
=0.7,*;q=0.7
Keep-A
live: 300
Connectio
n: keep-alive

As we can see above, the browser is perfectly able to connect to localhost
without any issues. Maybe I'm missing something?

Quim, a few arguments have been pointed out previously as to why someone would
like to do this. I think that we shouldn't even be asking those questions:
unless Nokia can provide a good reason why this is a bad idea, there should not
be any kind of pushing *against* it.

(In reply to comment #22)
> I have not been able to reproduce this behaviour:
> 
> python
> [...]
> the browser is perfectly able to connect to localhost

See comment 11, this bug only affects processes that use ICD, and microb has
implemented a workaround.

comment 22 is a reply to comment 12

I'm currently developing an app which connects to a LIRC server running at
localhost, and my users are annoyed by connection dialog popup. Any hopes of
fix anytime soon, or even a nice workaround?

If you know you're talking to localhost, then don't bother asking icd if
there's a network/to provide a network. That's roughly how the browser
cheats....

This fails the 'nice workaround' part because the correct definition of
localhost is not simple.

Comment 27 Andre Klapper 2012-03-21 18:06:52 UTC

The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia, hence resetting the ASSIGNED
status to NEW/UNCONFIRMED as nobody is working on this.

Note that very likely any feature requests for Maemo5 will not receive fixes
(WONTFIX) - I might mass-set this status in the future. There is a very small
chance for issues in open source components that contributed patches could be
included in the Maemo 5 CSSU Community updates - see http://wiki.maemo.org/CSSU
for more information.


For completeness (as Harmattan is mentioned in some reports), MeeGo 1.2
Harmattan used for the N9 and N950 is handled in
http://harmattan-bugs.nokia.com/ which has recently been closed for new bug
report entry [1].

[1]
http://www.developer.nokia.com/Community/Blogs/blog/n9-developer/2012/03/08/harmattan-bugzilla-closed-for-new-bugs

Comment 28 Andre Klapper 2012-03-24 11:40:14 UTC

The Maemo 5 User Interface and Maemo 5 platform components (e.g. libraries)
used for the N900 are considered stable by Nokia and it seems that there are no
plans for official updates currently, hence nobody plans to work on this
enhancement/wishlist request. 
(And in case you feel like discussing this situation: Nokia Customer Care or
http://talk.maemo.org would be the place to do so as you will not reach Nokia
officials in this community bugtracker - though all of this is really no news.)

Reflecting this status by setting RESOLVED WONTFIX for this
enhancement/wishlist request (see
https://bugs.maemo.org/page.cgi?id=fields.html#status for status explanations).

There is a small chance for issues in those Maemo components that are open
source: Contributed patches could be included and made available in the Maemo 5
Community CSSU updates. 
The Maemo CSSU project is run by a small team of volunteers; see
http://wiki.maemo.org/CSSU for more information.
So in case that you can provide a patch that fixes the reported problem, please
feel encouraged to file a request under
https://bugs.maemo.org/enter_bug.cgi?product=Maemo%205%20Community%20SSU .
Please note: The Maemo CSSU project is not related in any way to Nokia.


( Tag for mass-deleting bugmail: [cleanup20120324] )