MantisBT

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0013261MediaMonkey (current)DLNA/UPnPpublic2016-05-03 13:032017-08-29 20:51
Reporterpeke 
PriorityimmediateSeveritymajorReproducibilitysometimes
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version 
Target Version4.1.18Fixed in Version4.1.18 
Summary0013261: MediaServer: Some Components are still blocked by firewall
DescriptionEven MMW is added itself to firewall white list in some cases windows is still blocking MMW DLNA/Sync Server to be seen on network.

One of the solutions we used in past were to change port so that windows ask for firewall exception where MMW is allowed complete access.

Unfortunately in some cases even on LOW firewall settings (Digitally signed apps are allowed) this do not work and MMA do not see MMW server.

I have found that not all MMW EXE files are authorized adn needs to be entered manually which is not possible under some systems versions adn on some it is even more complicated due the their architecture (like Windows Server 2012 R2)

In remote session with user I have found that after adding all exe files to firewall exception MMW was seen on MMA
Steps To ReproduceTesting:
1. Remove all the MM Firewall rules
2. Execute Firewall creation script from ~48578
3. Start MM
4. Check and if existing and Remove all the MM Firewall rules that do not belong MediaMonkey Firewall Group
4. Check MMA if it see MMW DLNA server
Additional InformationRNH-615-77910
TagsNo tags attached.
Fixed in build1845
Attached Filesjpg file icon Firewall_issue.jpg [^] (55,417 bytes) 2016-05-03 13:13


? file icon MediaMonkey Firewall policy Rules.wpw [^] (1,198 bytes) 2016-05-08 20:51

- Relationships

-  Notes
(0044537)
peke (developer)
2016-05-03 13:10

This is long standing issue and it should be fixed.

Easiest way to replicate is to start Winamp.exe in order to start MMW or use some other app to start MMW like clicking on downloaded MMIP in firefox where parent app will be firefox, which is then translated by firewall taht Mediamonkey.exe is not actual taht wants to be available on network but parent app that uses MMW to access network.
(0044538)
peke (developer)
2016-05-03 13:22

Assigned for triage.
(0044546)
Ludek (developer)
2016-05-04 06:08
edited on: 2016-05-04 06:09

I tried to replicate, but I cannot.

I run .../MediaMonkey/winamp.exe and even if this is not allowed in
Windows Firewall > Allowed programs
the MediaMonkey server is seen normally (because .../MediaMonkey/MediaMonkey.exe is in allowed programs).
I tested on Windows 7's default Windows Firewall

Assigned to Peke for more information:
a) which firewall app it was ?
b) to find how we could auto-configure the app ?

(0044551)
peke (developer)
2016-05-04 17:42

One of teh possible reasons could be explained with http://www.mediamonkey.com/forum/viewtopic.php?p=422919#p422919 [^]

I'll check if I can find more, I also suspect on Win 10 where most reports are referred to.
(0044567)
peke (developer)
2016-05-08 20:51

Problem is that somehow Widows firewall rules Change from Block unknown outbound change to block al incoming and outbound.

Using WFC Ive found that these two exceptions always work.

Exceptions attached as WPW file.
(0044569)
Ludek (developer)
2016-05-09 08:33
edited on: 2016-05-09 08:45

Ok, so we could probably set this via command line (netsh) on MM start:
https://docs.oseems.com/general/operatingsystem/windows/firewall-command [^]
http://go.microsoft.com/fwlink/?linkid=121488 [^]

We just need to find how to detect the misconfigurations so that the elevate prompt does not popup on each MM start.

Another alternative is to do it via HNetCfg OLE object (or INetFwMgr interface - https://msdn.microsoft.com/en-us/library/windows/desktop/aa365287(v=vs.85).aspx [^] )
as we already use for port forwarding/opening on NAT (when '[x] Allow external IPs' is enabled)

(0044570)
Ludek (developer)
2016-05-09 09:57
edited on: 2016-05-09 11:31

Fixed in 4.1.12.1791

When MediaMonkey server is starting it checks for existence of 'MediaMonkey auto-conf NUMBER' rule (where NUMBER is hash from the application exe path like C:\...\MediaMonkey.exe)

If the rule doesn't exist (e.g. on first run) then it runs the elevator and:

a) deletes all "MediaMonkey" rules added automatically by Windows Firewall (that can be unchecked if the user closed the prompt for allowing MM connections)

b) adds the 'MediaMonkey auto-conf NUMBER' rule to Windows Firewall > Allowed programs

(0044573)
peke (developer)
2016-05-09 17:02

Verified 1791
(0044746)
Ludek (developer)
2016-05-25 06:40
edited on: 2016-05-25 06:41

Re-opened, for one user the elevator fails to set up the rules for some reason and pop-ups on each MMW start!

Details:
http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=84947#p423652 [^]

(0044747)
Ludek (developer)
2016-05-25 07:49
edited on: 2016-05-25 07:51

Fixed in build 1798.

Although I don't know why the elevator fails to write the rules for the particular user I changed the workflow this way:

If MMW finds that the rule was not registered yet then it runs the elevator, but if there is any other exception than "Elevation Canceled" or if there is a success then it never checks for the rules again.
If user just canceled the elevator then it is checked up again on next server run.

(0044751)
rusty (administrator)
2016-05-25 09:13

fyi, could this user's experiences be related (config settings re. web node fail to stick)?
(0044772)
peke (developer)
2016-05-26 21:57

That should not be related.

This latest change should fix the problem.
(0044816)
peke (developer)
2016-05-31 09:55

Verified 1798

Not additional regression reports were filed by users since release of 1798
(0045390)
Ludek (developer)
2016-08-11 07:12
edited on: 2016-08-11 07:18

Tech. test note for troubleshooting (re 0013261:0044747) :
There is a section [FirewallRules] in MediaMonkey.ini. If you delete the section then the rules will be added again.

Note that the rule is created for each MM.exe location. So if you install MM to another folder then new rule is added (as noted here 0013261:0044570). So for the troubleshooting is better to suggest the users just to install to another folder (easier and better than editing the INI)

(0045392)
Ludek (developer)
2016-08-11 09:45
edited on: 2016-08-11 10:35

Re-opened:

Peke indicated that Windows 10 anniversary update disables our rules and that re-installing MM to another folder resolves the issue (per my suggestion above).

Assigned to Peke to check:
a) Whether "MediaMonkey auto-conf ..." rules are really disabled (checkbox disabled) in Windows Firewall > Allowed Programs

If a) is true then MM could auto-detect this situation and add the rules again (by running the elevator on server run)

On the other hand it would be a hack, because if user disables our rules manually then MM will enable them again on each MMW/server start.

Rusty suggested to re-create them on MM re-install.

(0045397)
Ludek (developer)
2016-08-11 17:41
edited on: 2016-08-11 17:42

Peke indicated that the rules were blocked after the update (Action: Block)

Fixed in build 1805.

After MM re-install the MM rules are deleted and created again.

(0045408)
peke (developer)
2016-08-12 21:10

Today MS introduced cumulative security update KB3176495 on Win 10 Pro x64 1607 that addressed many issues.
(0045433)
peke (developer)
2016-08-16 05:39

Verified 1805 and also confirmed by one of our users
(0045501)
rusty (administrator)
2016-08-26 12:03

Wi-Fi sync functionality still doesn't work in my environment after installing 4.1.14.1806. I then tried rebooting Windows and running MMW
-->
Windows popped up a message indicating that it was blocking certain traffic from MMW (allow local/trusted, but don't allow public). I enabled all access for testing purposes, and from this point forward Wi-Fi sync worked.

The problem is that:
a) users shouldn't have to reboot Windows
b) even if the step of rebooting windows is unavoidable, the user has no idea why Wi-Fi sync isn't working. If MMW is in a state where it is being blocked by the firewall, MMW should at least give the user some feedback to that effect so that they know to try rebooting. e.g.
MediaMonkey appears to be blocked by a firewall. See [knowlegebase]. (link to http://www.mediamonkey.com/mediamonkey-connection-issues [^] which would link to http://www.mediamonkey.com/support/index.php?/Knowledgebase/Article/View/152 [^] ).
(0045505)
Ludek (developer)
2016-08-28 13:04
edited on: 2016-08-28 14:48

a) Based on today's intensive testing/review I probably found what could cause this.
I've done also some others improvements in this area.
So please re-test with 1807 and report whether it is all right.

b) There is a problem for MMW how to detect a blocked incoming connection.
I've spent several hours on this, but haven't found a general way for MMW to detect this situation.
The firewall rules can be set to block only 'public' or only 'wireless' incoming connections and there doesn't seem to be a way for MMW to find this.

The only way (partial solution) seems to be to use dump of Windows Firewall Rules (using command line "netsh advfirewall firewall show rule name="MediaMonkey") and parse it to detect whether MMW is set as blocked or disabled, but this would work only for Windows Firewall (not for third party firewalls). In addition this rule is auto-deleted while user accepts the elevator that creates the "MediaMonkey auto-conf *" rules. So the situation currently can happen only when user cancels the MMW elevator. In that case we could show something like:
"MediaMonkey hasn't enough rights to configure Windows Firewall, Wi-Fi sync might not work".

(0045551)
peke (developer)
2016-09-02 08:56

Verified 1807 On my PC no regression.
(0045552)
peke (developer)
2016-09-02 08:57

Reminder sent to: rusty

@Rusty
Can you please confirm fix on your PC that observed last report and close.
(0045553)
rusty (administrator)
2016-09-02 14:30
edited on: 2016-09-02 14:37

I'm unable to verify as the problem only occurred upon system upgrade to Windows 1607 and this is my production system.

I can, however, confirm that updating to this new version didn't cause any loss of connectivity.

(0045594)
peke (developer)
2016-09-06 20:26

Verified 1808 had one PC not upgraded yet.
(0045868)
peke (developer)
2016-10-09 17:47
edited on: 2016-10-09 17:47

Reopen As this do not apply is PC is falsely connected to Public network.

(0045869)
peke (developer)
2016-10-09 17:49

There is nothing we can do about that as opening MMW to Public is security risk and I updated
http://www.mediamonkey.com/support/index.php?/Knowledgebase/Article/View/152 [^]
to reflect these findings.
(0045870)
peke (developer)
2016-10-09 17:54

By default Windows treat only first connected network as Private and all others as Public.
(0048428)
Ludek (developer)
2017-07-31 13:32
edited on: 2017-07-31 13:56

Re-opened:
As discussed offline there are still users experiencing issues after MMW upgrade (e.g. http://www.mediamonkey.com/forum/viewtopic.php?p=438027#p438027 [^] ). This is most probably related to 0013261:0045392 where MMW re-creates the rules after re-install and it fails in some environments for some reason.

Basically I see three possible reasons for a failure:
1) The update (re)creates "MediaMonkey auto-conf NUMBER" rules that doesn't work for some environments (maybe the DOMAIN is missing?) as it creates only PUBLIC and PRIVATE rules?
2) The update fails to delete all the other MediaMonkey related rules that blocks the connection?
3) The update fails to create "MediaMonkey auto-conf NUMBER" rule, has not enough privilegies?

@Peke: Do you know which of these cases is the most often? i.e. based on your experiences when analyzing the user's rules?

As for the case 1) -- Maybe changing it to include protocol "Any" (not only TCP/UPD) and profile "All" (not only public/private) could solve the issues?

=> changed in build 4.1.18.1843 and resolved for testing

(0048473)
Ludek (developer)
2017-08-06 08:28
edited on: 2017-08-06 08:45

Hmm, but I just see my note in the code "we need to add rule separatelly for 'private' and 'public', because 'any' incoming connections are auto-blocked in some environments", so I guess I will create additional 'private' and 'domain' rules separately and we will see how it is going to work in the various user environments. It seems kind of magic :-/

=> changed in build 4.1.18.1843 and resolved for testing

(0048474)
peke (developer)
2017-08-06 23:19

For testing purposes can you please add/create MediaMonkey Firewall group and add autoconf rules there?

That should allow us an easier tracking and managing.
(0048513)
rusty (administrator)
2017-08-11 10:46

Another report: http://www.mediamonkey.com/forum/viewtopic.php?f=20&t=88256 [^]
(0048532)
Ludek (developer)
2017-08-14 09:07

The user indicated that the rule TCP/Private was missing. I guess that the commands for DELETE "old", CREATE "new" can run asynchronously somehow and this might be the cause of the random troubles. Looking into it...
(0048533)
Ludek (developer)
2017-08-14 09:49
edited on: 2017-08-14 09:55

@Peke: Adding group is not possible https://social.technet.microsoft.com/Forums/office/en-US/669a8eaf-13d1-4010-b2ac-30c800c4b152/2008r2-firewall-add-rules-to-group-create-new-group?forum=winservergen [^]

Nevertheless I changed the flow and now runs all the Netsh AdvFirewall Firewall Commands as single command line (commands separated by '&') to ensure the correct order for the DELETE+ADD. I guess it was the root of all the problems (I also simulated this once). To be confirmed by users.

Fixed in 4.1.18.1845 and merged to 5.0.0.2075

(0048541)
rusty (administrator)
2017-08-15 13:01
edited on: 2017-08-28 18:36

Build 4.1.18.1845 hasn't been created yet, but I just want to revisit the idea of including this functionality in the UI since telling users to re-install to fix the issue is not intuitive (and since escalation shouldn't be forced for MM in Portable Mode).

The ideas discussed were:
a) 'Add Windows firewall exception' button

This would add/reset the firewall rule.

b) '[x] Add Windows firewall exception' checkbox

It would be enabled by default (if MM isn't in portable mode), but if the user disables it / applies it, it would remove the firewall settings, and if they enable it / apply, then it would add them back.



Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker