(from Michael H)

thanks for these comments. I think they reflect some good points I've been thinking about recently: there are known issues with firewalls, AV scanners etc. While we very likely can't offer automated solutions for all of them, we might add some pre-install diagnostics which can point the user into the right direction.

The main issue I see is that this is very platform specific. Though we can probably reduce the issue to Windows as it's prone to this kind of issue and might cover the biggest part of our user base (you'll have the numbers - I don't :-)).

...

Port 9000 definitely is an issue. Twonky (Linux, mostly NAS devices) and McAfee are known to use them too. I've seen recent reports of AVG8 breaking SC too.

A quick connection test on port 9000 together with that kind of "blacklist" test might be very feasible for Windows. We're using a binary installer which can do all kinds of system related (and low-level if needed) stuff and is usually run in a context where it has the permission to do these kind of tests. I'd prefer this solution over integrating the logic in SC, as it's very system specific and usually a one time issue during installation.

> > Firewalls are one of our top issues we deal with every day in Support.

Firewalls blocking our ports? Or those "internet full protection suites" integrating AV, firewall, spam filter, backup, and many more odd functionalities in one hardly manageable package? I would have guessed we had more McAfee (scanner killing MySQL, backup running on port 9000) related issues than firewall trouble in the forums.

(from Michael H)

I've done a bit of testing. Result can be found here: (URL removed)

It's a simple app which does the following tests:

- check whether port 9000 is busy
- check whether we can reach some ports through the firewall
- check process list for WiLife's list of well known processes

The first check might tell us whether we're facing port conflicts.

Second _might_ tell us whether a firewall is blocking. I have no idea on how reliable this test is. I noticed Windows firewall would _not_ block access from the local machine, even when using the a real IP address (not localhost). ZoneAlarm does block.

Third check might help explain results from the first two checks. It can't be used alone, as eg. Norton AV (as used by Logitech) is recognized, though we're not using their firewalling product. It's a simple check for process which can be attributed to one or another product. This list currently is _very_ short (only about four products).

...

I've moved the file to slimdevices.com and announced it in the forums. 

http://forums.slimdevices.com/showthread.php?t=48166

Created attachment 3382 [details]
Possible User Confusion

Take a look at the attached, what if our customers don't see this McAfee message, or if they click "don't allow" and our software gets blocked?  I.E. McAfee Firewall blocks port 9000, but doesn't tell the customer.  I'll see if there is a way to unblock it in McAfee

I agree that this is a common problem.  People install our server then get some message from their Firewall asking to allow one or more connections.  Some customers I'm sure just don't understand the nature of the message-- it sounds threatening so they click "Do Not Allow."

In that case they need to remove the block from the firewall and/or add an exception for our ports in their firewall.

One note on Michael's Troubleshooting wizard... I tried my most basic test with it and sadly it failed.  On Windows XP, I went into the Firewall control panel and checked the "Don't Allow Exceptions" box.  I then ran the wizard but it did not realize all our ports were blocked.

I also recommend adding a test there to 1) ping squeezenetwork.com and 2) try sending/receiving a packet via 3483 TCP to SN.

> Take a look at the attached, what if our customers don't see this McAfee
> message, or if they click "don't allow" and our software gets blocked?  I.E.
> McAfee Firewall blocks port 9000, but doesn't tell the customer.  I'll see if
> there is a way to unblock it in McAfee

We can't force the user to use his brain. If he wants his system to fail, he will succeed. You can even configure your firewall _not_ to ask at all, but block anything unknown. That's exactly why we're trying some odd heuristics to 

if ports are blocked && there's some process I know
then msg("User please configure your firewall prodcut XY")

What we need is some clear instructions on how to solve these issues manually. For every single product out there :-(.

> it and sadly it failed.  On Windows XP, I went into the Firewall control panel
> and checked the "Don't Allow Exceptions" box.  I then ran the wizard but it did
> not realize all our ports were blocked.

I mentioned this earlier in the discussion: Windows firewall will _not_ block accesses from the same machine, whatever the settings are. Other products I've tested (McAfee, ZoneAlarm) do. There's not much we can do about this. But the good news is that we already configure the Windows firewall during installation. I'd assume you don't get too many calls due to the Windows built in firewall, do you?

> I also recommend adding a test there to 1) ping squeezenetwork.com and 2) try
> sending/receiving a packet via 3483 TCP to SN.

Will see what I can do. First I have to get those few lines of code not to crash the wizard every now and then :-(

Michael,

It seems the next step is we should define exactly what feature list this wizard will include.  That way we can try to then define its schedule and target this bug for a milestone?

Let me know if you need anything further from my end.

Ok, here's what the troubleshooter currently does/can do:

1. check port to see whether it is used by some other task. There's a list of known applications which might conflict (McAfee Backup, Google Desktop etc.)

2. ping test ("ping www.squeezenetwork.com") to test connectivity

3. probe local ports to see whether we can connect to them: some, but not all firewalls block local access, thus the result of this test can be misleading

4. check process list for known "offenders" - this will pretty often find something which might cause problems, but they not always mean there's a problem. We should only use it to give the user a hint _if_ there is an issue.

I'd suggest we add 1-3. to the installer. If there's a problem with one of them, offer the user the possibility to launch the troubleshooter. But don't run the full series of tests in the installer already. This way we can keep complexity in the installer low and concentrate on the troubleshooter. The latter would be installed with SC and available from Windows' SqueezeCenter menu.

What do you think about this plan?

> I'd suggest we add 1-3. to the installer. If there's a problem with one of
> them, offer the user the possibility to launch the troubleshooter.

...except for test 1., where we should offer to use an alternative port in case of a conflict.

change 20631 - add firewall/port conflict detection to Windows installer.

- use alternative port if port 9000 is busy
- display warning if firewall has been discovered which can't be configured automatically by the installer

QA/Support - please test this installer, as I've seen spontaneous failures during testing of the troubleshooting wizard

Michael,

Per your suggestions:

> 1. check port to see whether it is used by some other task. There's a list of
> known applications which might conflict (McAfee Backup, Google Desktop etc.)

You must mean port 9000 here?  Or do you mean all our ports?  

> 2. ping test ("ping www.squeezenetwork.com") to test connectivity
> 

In addition to a general ping test, can you add in a test to try communicating with SqueezeNetwork over port 3483?  Maybe send a test-request to SN which will initiate a reply from SN and we can see if we hear the reply successfully?

> 3. probe local ports ...
> 
> 4. check process list for known "offenders" ...
> 
> I'd suggest we add 1-3. to the installer. If there's a problem with one of
> them, offer the user the possibility to launch the troubleshooter. 

I think this all sounds good.  We will test the new Setup Wizard from tonight's build with a variety of Firewalls and report back here.

> You must mean port 9000 here?  Or do you mean all our ports?  

Nope, 9000 only. Do you know about conflicting apps for the other ports (especially 3483)?

> In addition to a general ping test, can you add in a test to try communicating
> with SqueezeNetwork over port 3483?

Sounds reasonable. Will do today.

change 20669 - add connection test to sn.com:3483

Tested this new feature with Mcafee Total Protection and everything worked perfectly. 

SqueezeCenter prompted me that there was a firewall in play. 

When I opened SqueezeCenter it went straight to http://127.0.0.1:9010/

So far so good!!!

My tests are more problematic.  I'm testing Windows Live OneCare.

When installing SC, it correctly detected Windows Live OneCare and displayed a dialog box about this.  Then it followed with a dialog box stating that 3483 was being blocked.

When setup was complete, SqueezeCenter could not start and OneCare never asked me to add exceptions which it did with other applications.  The tray icon displays "Starting SqueezeCenter..." forever.

If I turn off the firewall, SC started successfully.  However, if I then turn the firewall back ON, SqueezeCenter stopped which I was not expecting.

I added exceptions for Squeezecenter.exe, Scanner.exe, and Mysqld.exe and everything works correctly.

I'm concerned though that we couldn't even start the server.  If it cannot start, then no firewall will even try to offer the user an "Allow" dialog.

> My tests are more problematic.  I'm testing Windows Live OneCare.

I think it's working as designed :-)

> When installing SC, it correctly detected Windows Live OneCare and displayed a
> dialog box about this.  Then it followed with a dialog box stating that 3483
> was being blocked.

Great. And what did the message say? It very likely said 
"check your firewall settings. Make sure outgoing connections to port 3483 are not blocked"
(need to add the other ports here, or point to some wiki/faq page).

And/or:
"A process has been found running on your machine which is known to possibly cause issues %nwith SqueezeCenter under certain conditions."

Now that's very vague. But the main issue seems to be that my placeholder strings need improvement :-). What the above should say is the same as before: "we're sorry, we can't configure your firewall automatically. Please DIY following instructions blahblah."

We really need someone to come up with real English instructions.

> When setup was complete, SqueezeCenter could not start and OneCare never asked
> me to add exceptions which it did with other applications.  The tray icon
> displays "Starting SqueezeCenter..." forever.

We can't configure all those firewalls. All we can do (today):

- change SC's http port if needed
- configure Windows default firewall
- give the user instruction to configure his other product himself

Security suites don't like being configured by 3rd party apps, as this could be mal-ware disabling protection. Thus we can't do this (besides the problem of never knowing all those products out there).

> I'm concerned though that we couldn't even start the server.  If it cannot
> start, then no firewall will even try to offer the user an "Allow" dialog.

Who says it didn't start? The tray icon just wasn't able to connect to it. That's a different issue (and very misleading). the tray icon isn't reliable, as it relies on network connectivity.

> Tested this new feature with Mcafee Total Protection and everything worked
> perfectly. 

Is this the one with the backup application?

>> When installing SC, it correctly detected Windows Live OneCare and displayed
>> dialog box about this...
>
> Great. And what did the message say? 

The 2 dialogs I got were:

1. A process has been found running on your machine which is known to possibly cause issues with SqueezeCenter under certain conditions.  "WindowsLive One Care"

and

2. "We tried to connect to www.squeezenetwork.com on port 3483, which used by Squeezebox.  But the connection failed.

If your internet connection is otherwise working fine, check your firewall settings.  Make sure outgoing connections to port 3483 are not blocked.  Many corporate firewalls might block this port."

Can we actually include URLs to FAQ articles in these dialogs?  Can they be clickable?

>> When setup complete, SqueezeCenter could not start and OneCare never asked
>> me to add exceptions which it did with other applications.  The tray icon
>> displays "Starting SqueezeCenter..." forever.
>
> We can't configure all those firewalls. All we can do (today):

I completely agree.  My concern here is not that we can't configuring the firewall.  My concern is that SqueezeCenter appears not to have started at all, which was my following comment.

>> I'm concerned though that we couldn't even start the server.  If it cannot
>> start, then no firewall will even try to offer the user an "Allow" dialog.
>
> Who says it didn't start? The tray icon just wasn't able to connect to it.
> That's a different issue (and very misleading). the tray icon isn't reliable,
> as it relies on network connectivity.

I did not know SqueezeTray.exe requires port accesses.  We have never recommended customers open their firewall to SqueezeTray in the past.  This may be helpful.

The way I determined SC was not running was, a) Squeezetray said "Starting" perpetually, and b) Taskmanager did not show MYSQLD.EXE or SQUEEZ~1.EXE running.

> Can we actually include URLs to FAQ articles in these dialogs?  Can they be
> clickable?

Not in the dialogs. But I could try adding separate pages with text boxes instead. This would provide more space for the messages themselves, and give the option of displaying clickable links. At the cost of increased complexity and code (one line vs. a couple of dozens). But it would imho be the best solution, as this way the instructions could be updated without the need to update the installer.

> I did not know SqueezeTray.exe requires port accesses.  We have never
> recommended customers open their firewall to SqueezeTray in the past.

They don't need to open it for SqueezeTray. It's using the same port 9000 as the web GUI. As long it's been opened for regular access, SqueezeTray should be fine. 

> The way I determined SC was not running was, a) Squeezetray said "Starting"
> perpetually, and b) Taskmanager did not show MYSQLD.EXE or SQUEEZ~1.EXE
> running.

These are clearly signs of failure :-/. I'll take a look at the status detection.

As I've now implemented most of the detection code in the installer, would it still be usefull having a troubleshooting app installed (or downloadable) to be run without the installation? It might be a bit chattier, too, giving detailed information about what is being probed and the results.

Yes, I think the Troubleshooter applet will be a big help.  And I agree, it can provide a lot more detail in case of a problem.  In the installer, too much detail would be bad.  But in the Troubleshooter we can get what we need.

Also, for the Installer, do you want additional information on programs to look for?  What is included in your first version?  (I'm guessing you have a text file with firewall, av, and security software filenames in it?)

For the Troubleshooter, let's define what will be included in the first version.  What is there currently?

May I also request an addition?  (i could also make this a separate bug, since it does not deal specifically with firewalls but with the Troubleshoot.  Or maybe it's time to change the Summary of this bug.)

A Log Sender:

 * Add a tab, or page, that allows for sending logs to Support.  It can contain 3 or more checkboxes labeled: 1) Connection log, 2) Server log, 3) Scanner log.  It also includes a box to enter in a "Customer name (optional)".  It also includes a box to enter in a "Support ticket number (optional)".  Lastly it has a "Send" button.  

 * The connection log is whatever test the Troubleshooter has performed and its results.  The Server and Scanner logs are the normal logs from SC, if they exist.  The Connection log checkbox is always checked by default.  The other two can be unchecked by default.

 * When a user checks one or more boxes and clicks Send, the logs are sent to Support via support (at) slimdevices.com (or we can use the Logitech e-mail address.  in fact, that might be better.)  Subject heading can be along the lines of "Logs sent in for review from <customername> (rn# <ticketnumber>)"

Let me know if this is doable?

I'll answer in detail tomorrow/next week. But as an info: here's the .xml file with the information I'm using to scan the process list:

http://svn.slimdevices.com/viewvc.cgi/7.1/trunk/platforms/win32/installer/ApplicationData.xml?revision=HEAD&content-type=text%2Fplain

It's an enhanced version of the wilife file you sent me.

> Yes, I think the Troubleshooter applet will be a big help.  And I agree, it can
> provide a lot more detail in case of a problem.  In the installer, too much
> detail would be bad.  But in the Troubleshooter we can get what we need.

Plus if we make it an optional download, we can have nightly updated releases of the info file without the need of a SC release cycle.

> For the Troubleshooter, let's define what will be included in the first
> version.  What is there currently?

- port 9000 conflict detection
- ping sn.com
- connect sn.com:3483
- port probing for firewall detection
- process detection

all in all about the same as the installer, but more verbose.

> A Log Sender:
> 
>  * Add a tab, or page, that allows for sending logs to Support.  It can contain

Should be feasible. Main issue is managing the log files' sizes. They tend to get big/huge, depending on the log settings. We'd have to truncate/compress them, which can lead to a bit of a performance issue on the machine.

But then: don't we often have a problem running SC when we want the logs the most? This should imho be an independant solution.

> Let me know if this is doable?

Could you please file a separate request for this? Sounds reasonable as part of the troubleshooter (except that I don't know how to handle compression using it :-().

Closing this bug. Thanks.

Log file sending request moved to bug 8535

Verified to be working in 22103.

This bug has now been fixed in the 7.1 release version of SqueezeCenter!  Please download the new version from http://www.slimdevices.com if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

This bug has been fixed in the 7.3.0 release version of SqueezeCenter!

Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already.  

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.

Reduce number of active targets for SC