View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013261 | MMW v4 | DLNA/UPnP | public | 2016-05-03 17:03 | 2021-09-17 00:29 |
| Reporter | peke | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Target Version | 4.1.18 | Fixed in Version | 4.1.18 | ||
| Summary | 0013261: MediaServer: Some Components are still blocked by firewall | ||||
| Description | Even 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 Reproduce | Testing: 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 Information | RNH-615-77910 | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 1845 | ||||
| related to | 0015176 | closed | Ludek | MMW 5 | Playing from portable version to a renderer may fail (as portable version doesn't auto-conf firewall) |
| related to | 0016580 | closed | Ludek | MMW 5 | DLNA: MM5 sometimes fails to see some DLNA Servers |
| related to | 0017209 | closed | Ludek | MMW 5 | UAC prompt is shown after every re-install (also in Portable mode) |
| related to | 0017917 | closed | Ludek | MMW 5 | Sync: Check connection type |
| related to | 0018264 | closed | Ludek | MMW 5 | Firewall Rules: Auto rules needs to be tweaked in order that MM5 gets discoverable by Devices and MMA |
| related to | 0018310 | closed | Ludek | MMW 5 | Improve configuration/management of MM firewall rules |
|
|
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. |
|
|
Assigned for triage. |
|
|
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 ? |
|
|
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. |
|
|
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. |
|
|
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) |
|
|
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 |
|
|
Verified 1791 |
|
|
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 |
|
|
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. |
|
|
fyi, could this user's experiences be related (config settings re. web node fail to stick)? |
|
|
That should not be related. This latest change should fix the problem. |
|
|
Verified 1798 Not additional regression reports were filed by users since release of 1798 |
|
|
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) |
|
|
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. |
|
|
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. |
|
|
Today MS introduced cumulative security update KB3176495 on Win 10 Pro x64 1607 that addressed many issues. |
|
|
Verified 1805 and also confirmed by one of our users |
|
|
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 ). |
|
|
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". |
|
|
Verified 1807 On my PC no regression. |
|
|
Reminder sent to: rusty @Rusty Can you please confirm fix on your PC that observed last report and close. |
|
|
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. |
|
|
Verified 1808 had one PC not upgraded yet. |
|
|
Reopen As this do not apply is PC is falsely connected to Public network. |
|
|
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. |
|
|
By default Windows treat only first connected network as Private and all others as Public. |
|
|
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 |
|
|
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 |
|
|
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. |
|
|
Another report: http://www.mediamonkey.com/forum/viewtopic.php?f=20&t=88256 |
|
|
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... |
|
|
@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 |
|
|
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. |
