[Frodo] Firewall popup - allow incoming connections
#1
Hiya,
I've been using the Frodo nightlies for quite a while but a couple of weeks ago when I updated to the latest the firewall in OSX 10.6.8 started to ask if I want to accept incoming connections. This happens every time I start XBMC now.

I've been waiting like a sucker for this to be solved on the newer versions but now I feel I must speak up.Wink

I guess it's a code signing issue? Found this thread: XBMC and Mac Firewall Popup
Will the solution to create a self signed certificate stick when I update and is the problem really on my end or the nightlies?

Thanks for any help Big GrinBig Grin
Reply
#2
We would have to code sign and I'm resisting that. Go into your OSX settings and grant XBMC incoming connections.
Reply
#3
ok. yeah I have granted xbmc incoming connections in the osx firewall settings several times, removed the entry and added it again. It does not stick.

Sooo should I resist to code sign it myself like I said above and live with this until a stable version comes?
Reply
#4
You can build and code sign it yourself, that is an option.
Reply
#5
ok, thanks
Reply
#6
Huh? Are you thinking everyone with a Mac and OSX Lion should build and sign?

This isn't a good solution. Please reconsider.
Reply
#7
i have this problem also, running on Mountain Lion, also with Server. the Firewall is important to me to keep it on. i tried to sign a certificate and does not work at all on Mountain Lion Sad

it is not nice, but until now the only solution i found is to get up and go to and click to allow on the stupid window to allow the communications Sad

Confused
Reply
#8
Same problem, also on Mountain Lion using Frodo. Annoying. Grrrrr
Reply
#9
It does it in Mavericks also here on my Macbook Pro. I don't know why my Mac Mini running Mavericks doesn't do it, though. Maybe since I set it up under Mountain Lion instead? I tried deleting my Plist file and starting over with the security settings in case the file got corrupted or something. ALL Apps except XBMC seem to work with the setting after the first run (i.e. If I turn trust signed apps mode off and run say Skype for the first time on the new list, it will ask the same way, but the next time I run it, it doesn't ask again whereas XBMC just IGNORES or GETS IGNORED when it runs and pesters you every stinking time. The only way to get rid of it is to disable the Firewall and that's a very very bad idea.

The point is that there's something else wrong there. You aren't supposed to have to be a registered developer to get through the Firewall. The user is supposed to be able to select "Allow Incoming Connections" in the Firewall for that App and that's supposed to be that. It's not supposed to ask again. There must be a reason why XBMC keeps asking and I don't know what it is. Since XBMC appears offhand to be the only App where I see it doing this thus far, I must assume it's something unique to XBMC. I'm not sure why it doesn't do this on my Mac Mini, though (actually since upgrading to 12.3, it might; I'm not at home right now so I can't doublecheck).
THEATER: Epson 3100 3D Projector, DaLite 92" screen, 11.1.6 (Marantz SR7012 + Yamaha HTR-5960 + Onkyo ESPro) - Mixed Dialog Lift  - PSB T45/B15/S50/X1T/CS500 Speakers & Def Tech PF-1500 15" sub ; Sources: PS4, LG UP875 UHD, Nvidia Shield (KODI), ATV4K, Zidoo X9S (ZDMC), LD, GameCube
Reply
#10
Nope I'm on 12.3 running Mavericks on my mac mini and am getting the same pop up and have tried the same things suggested here with no result. It is annoying and definitely a bit of an inconvenience.
Mac mini 2012
Drobo 4 bay
4 three terabyte HHD
Drobo 5 bay
5 four terabyte HHD
Reply
#11
(2014-03-01, 18:53)CharlieM Wrote: Nope I'm on 12.3 running Mavericks on my mac mini and am getting the same pop up and have tried the same things suggested here with no result. It is annoying and definitely a bit of an inconvenience.

No other software causes that here either. I even tried disabling the auto-registering for signed apps and manually clicked "yes" on the same requester XBMC gives and unlike XBMC, they don't ever ask again. I don't recall Eden giving me the problem until I upgraded to the newest Frodo. Now they both do it and so does the last Gotham Alpha I've tried. I can see XBMC on my Firewall list of allowed programs, but it gives the error every time anyway. It's like the name/id/whatever it gives to store the permission doesn't match the program that's running. Otherwise, it shouldn't/wouldn't give the error. NO other program does that here anymore. Just XBMC. There was a bug in their firewall back in Snow Leopard for awhile, but they apparently fixed it and it hasn't done it since with anything but XBMC. My best guess is there's something wrong in XBMC's code somewhere, but I wouldn't have a clue what it is.

Instead of trying to click on the allow/deny thing now, I just hit escape instead, but it's still annoying.
THEATER: Epson 3100 3D Projector, DaLite 92" screen, 11.1.6 (Marantz SR7012 + Yamaha HTR-5960 + Onkyo ESPro) - Mixed Dialog Lift  - PSB T45/B15/S50/X1T/CS500 Speakers & Def Tech PF-1500 15" sub ; Sources: PS4, LG UP875 UHD, Nvidia Shield (KODI), ATV4K, Zidoo X9S (ZDMC), LD, GameCube
Reply
#12
http://forum.xbmc.org/showthread.php?pid...pid1604493
Reply
#13
(2014-03-02, 00:21)Ned Scott Wrote: http://forum.xbmc.org/showthread.php?pid...pid1604493

I looked at that, scratched my head, shrugged, and turned off my firewall....which had previously been off for like, FOREVER, until I turned it on the other day just for laughs. Then I started getting the annoying pop-up we're discussing. So far, in over 3 years of OSX I've yet to encounter anything I'd consider a malicious attempt to hack me...unlike my prior 20+ years of Windows crumbling under a constant barrage of exploits.

However, that being said, I mean...c'mon...just do some programming voodoo to get rid of it. It's the ONLY program I've encountered where "allow this program" won't stick. Smile

PS...just kidding about programming something.

PPS...some of you might consider Little Snitch as an alternative firewall to get around the issue.
Reply
#14
(2014-03-04, 06:47)clipper99 Wrote:
(2014-03-02, 00:21)Ned Scott Wrote: http://forum.xbmc.org/showthread.php?pid...pid1604493

I looked at that, scratched my head, shrugged, and turned off my firewall....which had previously been off for like, FOREVER, until I turned it on the other day just for laughs. Then I started getting the annoying pop-up we're discussing. So far, in over 3 years of OSX I've yet to encounter anything I'd consider a malicious attempt to hack me...unlike my prior 20+ years of Windows crumbling under a constant barrage of exploits.

However, that being said, I mean...c'mon...just do some programming voodoo to get rid of it. It's the ONLY program I've encountered where "allow this program" won't stick. :)

Well, the programming might not be "hard" (or it might be, I honestly don't know), but I think the first issue is man power. Only very recently have some long standing audio issues in Mac OS X have been fixed for XBMC, and that required some devs who don't normally touch OS X having to see what they could do, and various things going back and forth, and such. Our OS X devs are also devs for other platforms and features. There's only so many hours in the week they can spend on XBMC before the beer in the fridge runs dry. When that happens then things like this are placed lower on "the list".

That's also assuming it's something that doesn't require some programming speciality, as even with just Mac OS X, no one person can really know very part of OS X programming. Or that it's even an area that the devs want to donate their time to work on.

Another factor is that XBMC isn't a typical OS X application. Even within typical OS X apps, only a few will make network connections in a way that would touch the firewall, I assume. On top of that, XBMC is a cross platform app that has several parts that don't always do things in an OS-native way.

I'm not a programmer myself, and I'm not trying to say this won't happen or make excuses. This is just to shed a little light on what happens behind the scenes. I have no doubt that this has been quite annoying for many users, but they should know that there's many factors involved when it comes to fixing issues and working on XBMC :)
Reply
#15
Note: This response has been edited upon discovering the problem/solution to the Firewall nag requester in question.

SHORT SUMMARY: The guisettings.xml file stored in Application Support/XBMC/userdata must be deleted from any prior/older install of XBMC such as Eden and let Frodo 12.3 generate a new file. Otherwise, the file will become corrupted (in either direction running old/new or new/old) with incompatible settings. A good solution might be to have newer versions of XBMC that are incompatible with the markup code from older versions to use a different settings file. The code would still need cleaned up to properly import older version settings as Frodo 12.3 clearly does NOT import Eden settings correctly.

Longer Discussion With an Example:

(2014-03-02, 00:21)Ned Scott Wrote: http://forum.xbmc.org/showthread.php?pid...pid1604493

I think the point is that OS X apps aren't supposed to have to be signed or tricked into self-signing. I've got many apps that need Firewall access and NONE keep asking every time I load the program. You approve once and it goes away. Likewise, if you tell it to block a program, it shouldn't ever ask you again either. That's the whole point of asking. But when it asks me again if I want to allow it and I say NO, the setting in the Preference Security Pane does not change. It's still set to allow. If I manually change it to block in that Firewall pane, it still asks when XBMC loads again. That's not normal for any program. XBMC is doing something wrong to cause that and I now know where the problem is after fuxing around with it for a few hours....

Eden here did NOT cause that requester to appear here at all until this new Frodo came out. In other words, there must be a preference file saved somewhere that is causing it to now appear in Eden also because every single version of XBMC gives this error now and they never did until I ran 12.3 here. I'm guessing if I go in and delete all the saved settings and start Eden again it will be OK once more until I run Frodo 12.3 at which point it will become corrupted again. That preference file is in ~/Application Support/XBMC/userdata/guisettings.xml

I've discovered that Eden (and god knows how many beta versions, etc.) does not play well with Frodo (and I assume Gotham as well) versions of XBMC. The settings are obviously different in some areas upon comparison. This explains the audio problems I was having as well when I upgraded. The settings are not being properly imported/updated and I think the corruption gets even worse when later running Eden again after Frodo has made its own settings changes. This affects default audio settings, vertical sync settings and some way, some how, the Firewall warnings.

For example,

I examined the various guisettings.xml file outputs stored in my Application Support folder for XBMC and it's obvious it's importing the Eden file incorrectly in Frodo:

Relevant Part of EDEN guisettings.xml with Correct 2.0 Audio Output Setting:

<audiooutput>
<ac3passthrough>false</ac3passthrough>
<audiodevice>CoreAudio:default</audiodevice>
<channellayout>0</channellayout>
<dontnormalizelevels>true</dontnormalizelevels>
<dtspassthrough>false</dtspassthrough>
<mode>0</mode>
<passthroughaac>false</passthroughaac>
<passthroughmp1>false</passthroughmp1>
<passthroughmp2>false</passthroughmp2>
<passthroughmp3>false</passthroughmp3>
</audiooutput>

Relevant Part of FRODO guisetting.xml After running Eden first and then Frodo 12.3 (Shows Up as 2.1 in Frodo):

<audiooutput>
<ac3passthrough>false</ac3passthrough>
<audiodevice>CoreAudio:default</audiodevice>
<channels>2</channels>
<dtspassthrough>false</dtspassthrough>
<guisoundmode>1</guisoundmode>
<mode>0</mode>
<multichannellpcm>true</multichannellpcm>
<normalizelevels>true</normalizelevels>
<passthroughdevice>Built-in Output</passthroughdevice>
<stereoupmix>false</stereoupmix>
</audiooutput>

Relevant Part of FRODO guisettings.xml With Corrected/Working 2.0 Audio AND/OR a Clean Install of Frodo 12.3:

<audiooutput>
<ac3passthrough>false</ac3passthrough>
<audiodevice>CoreAudio:default</audiodevice>
<channels>1</channels>
<dtspassthrough>false</dtspassthrough>
<guisoundmode>1</guisoundmode>
<mode>0</mode>
<multichannellpcm>true</multichannellpcm>
<normalizelevels>true</normalizelevels>
<passthroughdevice>Built-in Output</passthroughdevice>
<stereoupmix>false</stereoupmix>
</audiooutput>


As you can see, <channellayout>0</channellayout> should become <channels>1</channels> to get 2.0 in Frodo, but it becomes <channels>2</channels> instead which results in a 2.1 setting that doesn't work here. Since it doesn't happen on a clean install, I imagine the problem is in parsing/converting the older setting. These are just the stored settings, not the code itself that generated it or imported the previous file where the actual error must be.

This problem is, at least, correctable in the GUI preference pane. Frodo, upon upgrading from an Eden install will select 2.1 audio instead of 2.0 like it should, but at least you can go in and change it back and sound will then work once again. This problem does NOT happen on a fresh install of Frodo, only when running Frodo on an existing install of XBMC Eden. I believe the corrupted vertical sync settings (which are different in Eden and Frodo altogether) end up using the Eden settings when imported back and forth and the newer Frodo version disappears altogether. Obviously, something somewhere in the file is causing the "Allow" nag requester to appear as well since generating either a clean Eden guisettings.xml file or a clean Frodo one will eliminate the nag requester in either version. Run the other version of XBMC without deleting the guisettings.xml file first will result in the nag requester coming back again.

Thus, the workaround FIX is to pick one version of XBMC to use and delete the guisettings.xml file and let that version regenerate it. Make your setting changes to the way you want them and NEVER EVER run the other version of XBMC again unless you want it corrupted all over again (whence the solution is to delete that file and generate a new clean one all over again).

Now knowing where the problem obviously lies in XBMC, the developers COULD fix XBMC so that it correctly imports an older version of the guisettings.xml file from Eden, etc. and updates it correctly rather than in a corrupted manner. However, that would probably not fix the problem of running Eden again, which would corrupt the newer file with its older settings in some places. One would think that XBMC should/would do a version check and use a DIFFERENT guisettings file for the newer/incompatible version of XBMC so that the two versions don't collide like that (e.g. Frodo could/should use guisettingsFrodo.xml and that would completely avoid corrupting the older Eden file in either direction. It would still need to correctly parse/import the Eden file upon its first run to retrieve the old settings, but then would never cause a problem for either version again.
THEATER: Epson 3100 3D Projector, DaLite 92" screen, 11.1.6 (Marantz SR7012 + Yamaha HTR-5960 + Onkyo ESPro) - Mixed Dialog Lift  - PSB T45/B15/S50/X1T/CS500 Speakers & Def Tech PF-1500 15" sub ; Sources: PS4, LG UP875 UHD, Nvidia Shield (KODI), ATV4K, Zidoo X9S (ZDMC), LD, GameCube
Reply

Logout Mark Read Team Forum Stats Members Help
[Frodo] Firewall popup - allow incoming connections0