Bugzilla – Bug 4186
webinterface (server settings) not responding because of denied connection to www.google.com
Last modified: 2008-12-18 11:11:39 UTC
SlimServer is located behind a firewall and must use the proxy for internet access. Whats new (since 6.5.0) in Slim/Utils/Network.pm is function "serverAddr" calling "Slim::Utils::IPDetect::IP". On init this function tries to connect to www.google.com:80. My firewall drops these packets (no deny or refuse) so the interface blocks/stalls when choosing "server settings". Additionally this message 2006-09-22 19:34:56.3467 ERROR: Failed to detect server IP address. Interrupted system call is logged. As work-around i have replaced www.google.com with a local server. Just one more benefit of perl based open source software :-)
nokia770 skin?
no, the fishbone skin. same happens with the default one (http://server/Default/)
ah, I see. hadn't seen that call before. All this does is try to detect your ip address. it's used for support to help diagnose any network problems that are causing headaches for slimserver. The error is correctly reporting its inability to find the IP address, and perhaps we need to make sure this only checks once and sets a flag. I don't think this quite meets the criteria for major, but I'll leave it to Chris to determine the appropriate level and target.
okay. btw, this was the only problem i had while upgrading from 6.5b3 to 6.5.0. i rated this major, because of the impact of this bug: just click once on "server settings" and no more webinterface, no more music, ... i just stopped the server after 10 minutes. probably slimserver should read its "web proxy settings" and act accordingly. as i have my simple workaround this call is no longer major - at least for me :-)
KDF, am I correct in guessing this is with the skin itself? Would it also affect users who do not have an Internet connection at all?
Chris, this is due to a server call intended to grab socket communication data to grab teh IP address used by the server. Users with no connection would also see this problem. Those with dialup would see their connection triggered as well due to this call. It probably needs to fail a bit more silently and ensure we only try the connection once per restart
Is it sensible to try to fix this for 6.5.1?
Yes, we should try to.
would it not be ok to just return '127.0.0.1' on the first failure after the errorMsg?
Fixed in change 10134