Description of problem:

I installed lastest Fedora 19 boinc-client and boinc-manager.
I enabled and started boinc-client.service.
I added my user to boinc group.
I chmod g+rw all files in /var/lib/boinc directory.
I created a symbolic link in my home directory pointing to gui password file.
I allowed incoming connections to TCP port 31416 in the firewall.
I restarted the system.

When I start boinc manager, it constantly complains about not being able to connect to the client.
If I stop firewalld.service, then it can connect succesfully.

I also tried to open the same port for UDP (I haven't seen specified whether it's an UDP or TCP port, though I guessed it was TCP). The problem persists with UDP port open.

Version-Release number of selected component (if applicable):

7.0.65-1.git79b00ef.fc19 (x86_64) both for client and manager.


How reproducible:

Following the same steps described before.


Steps to Reproduce:
1. Install last stable version of boinc client and manager from official Fedora 19 repositories.
2. Add user to boinc group.
3. Provide read/write access for all files and directories under /var/lib/boinc (and this directory itself) to users belonging to boinc group.
4. Create a symbolic link in your home directory pointing to /var/lib/boinc/gui_rpc_auth.cfg and give it the same name.
5. Open port 31416 in firewall for incoming connections.
6. Enable and start boinc-client.service
7. To have your user effectively belong to boinc group, close and reopen the session. If you want to be 100% sure, just reboot the system after everything is done.
8. Run boincmgr.
(after failure)
9. Kill boincmgr.
10. Disable firewalld.service.
11. Run boincmgr.

Actual results:

boincmgr window opens and a popup complains about not being able to connect to localhost. Whenever you close the popup, it appears again almost immediately. The only way to close boincmgr is to kill boinc_gui process.
After disabling firewall, boincmgr works.

Expected results:

boincmgr opens normally and allows to connect to localhost without need to stop the firewall.

Additional info:

I believe creating symbolic link to password file (something I read and tried to see if it worked this way) makes it unnecessary to enter the password to connect to localhost, though I'm not sure. Anyway, if you disable the firewall and explicitly connect to localhost giving the password, when you restart the firewall the problem appears again.