Bug 699432
Summary: | SoaS/Sugar spin needs additional firewall ports open for Salut to work. | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Samuel Greenfeld <samuel> | ||||||||
Component: | spin-kickstarts | Assignee: | Peter Robinson <pbrobinson> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | unspecified | Docs Contact: | |||||||||
Priority: | unspecified | ||||||||||
Version: | rawhide | CC: | awilliam, bruno, kevin, martin, maxamillion, pbrobinson, satellitgo, simon, tflink, vanmeeuwen+fedora | ||||||||
Target Milestone: | --- | Keywords: | Tracking | ||||||||
Target Release: | --- | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2020-03-08 11:19:57 UTC | Type: | --- | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Attachments: |
|
Description
Samuel Greenfeld
2011-04-25 15:48:09 UTC
I'll look at what's required to fix this. From my testing you only need to open the mdns port to get collaboration working (you should check as well if selinux is set to permissive). There was once a bug about opening the mdns port by default for quite a long time (I can not find it anymore, might have been closed in database cleanups) but it was never dealt with. Maybe making this happen would be a great thing to make link-local collaboration working out of the box. (In reply to comment #2) > From my testing you only need to open the mdns port to get collaboration > working (you should check as well if selinux is set to permissive). Its generally enforcing in live spins. Why is this a problem? > There was once a bug about opening the mdns port by default for quite a long > time (I can not find it anymore, might have been closed in database cleanups) > but it was never dealt with. Maybe making this happen would be a great thing to > make link-local collaboration working out of the box. It use to be (a long time ago) open by default, then it was decided it was a security risk so was closed. Looking at fedora-live-mini.ks which is what we use as the base for the soas.ks we have the following line: firewall --enabled --service=mdns Which should enable it. We just need to confirm (it might be that the firewall command is obsolete and we need to update it). (In reply to comment #3) > (In reply to comment #2) > > From my testing you only need to open the mdns port to get collaboration > > working (you should check as well if selinux is set to permissive). > > Its generally enforcing in live spins. Why is this a problem? I thought the sugar sping did set it to permissive at one point. Not sure what is the exact technical reason, but when I had to set it when testing here. > > There was once a bug about opening the mdns port by default for quite a long > > time (I can not find it anymore, might have been closed in database cleanups) > > but it was never dealt with. Maybe making this happen would be a great thing to > > make link-local collaboration working out of the box. > > It use to be (a long time ago) open by default, then it was decided it was a > security risk so was closed. > > Looking at fedora-live-mini.ks which is what we use as the base for the soas.ks > we have the following line: > firewall --enabled --service=mdns > > Which should enable it. We just need to confirm (it might be that the firewall > command is obsolete and we need to update it). This should work I think. It would just be better if a vanilla Fedora-Sugar installation would enable it by default as well, not only the live spin. But I guess we have to live with it.
> This should work I think. It would just be better if a vanilla Fedora-Sugar
> installation would enable it by default as well, not only the live spin. But I
> guess we have to live with it.
There's a new firewalld going into F-15 that's suppose to assist with these problems, I've not looked at it close enough to see whether its going to fix that issue but we might be able to add a /etc/firewalld.d/sugar file (or similar) with what we need, or set a policy or something. Not sure how advanced it is for F-15.
In my experience (as noted above) at least private invitations tend to try direct connections between computers on TCP 5298 for Salut, where the telepathy-salut daemon is listening ("netstat -anp" should verify this). I verified that a connection was attempted using wireshark/tcpdump, and filed this bug because I initially saw a rejection. I don't know if anyone else can confirm/deny this. Proposing as Sugar blocker and therefore project-wide NTH as this affects a key component of Sugar. As per comment #4, this may be fixed for at least live installs? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers (In reply to comment #7) > Proposing as Sugar blocker and therefore project-wide NTH as this affects a key > component of Sugar. I'm not 100% sure on what blocks a release of Sugar/SoaS but: * This issue is not a regression; F14 is similarly affected. * The single-user SoaS experience in both F14 & F15 is not impacted. * Since Sugar 0.90/F14 the collaboration stack in general has been extensively rewritten and still is being stabilized, so bugs in this area are expected. Of course the firewall blocking you could be a rather big bug. * It should not affect out-of-the-box SoaS installs, as they at least historically have used a public jabber server on the Internet over TCP originated from the SoaS instance. Users would have to delete the Jabber server name via a Control Panel in order to run purely locally and run into this issue. > As per comment #4, this may be fixed for at least live > installs? It depends on if you believe that mDNS is the only incoming-originating firewall port connection required. I will try to setup a few machines and take packet captures on a somewhat isolated network tonight or early this weekend. Discussed in the 2011-05-06 blocker review meeting. Rejected as NTH due to Samuel's assessment; particularly because this would not affect default SoaS installs. Created attachment 497684 [details]
Firewall configuration used for test endpoints
Firewall used for testing on both endpoints. It was created using the graphical Firewall configuration tool with SSH and mDNS incoming permitted.
The avahi-daemon.service was manually enabled via systemctl on the two F15 test systems used.
Created attachment 497688 [details]
Packet Capture of failure to join shared activity
1. Tcpdump was started.
2. Sugar-emulator started on host A @ 172.26.96.5 (Sugar via gdm running on host B @ 172.26.96.5). The only other host on the network is a schoolserver (not in use except for DHCP).
3. The Chat activity is started and shared on host A.
4. On host B, we see the Chat activity and attempt to join it, but the Chat activity hangs and will not let you type in the text field, etc.
5. After a while I close the Chat activity on both hosts B & A, which stops sharing the activity on A.
Note the two direct connection attempts to the presence service (TCP 5298) from host B to A and then A to B which are rejected at packets 8-9 (~9.13 seconds) and 14-15 (~9.32 seconds) with an ICMP host administratively prohibited response.
The 10.0.0.0 host is a smart switch trying to do IGMP snooping. It's unclear given my limited knowledge of multicast and this packet trace if anyone is responding to its group membership inquires, or if the switch is inquiring for updates because it sees recent changes in membership. Hopefully since we're seeing an incoming request Fedora's firewall isn't blocking this.
Created attachment 497689 [details]
Failed invitation capture
1. Restarted chat activity on host A.
2. Switched to the Network view, and attempted to invite host B.
Note the direct TCP presence connection attempts and ICMP rejections (both host A to B) at packets 10-11 (~0.86 seconds) and 38-39 (~25.50 seconds).
Has is been confirmed which ports are actually required? I don't think anyone has 100% confirmed what is necessary. I looked at this a bit again last night doing some tcpdumps on Fedora 14 (which has a more stable Sugar network stack at this point?) and using iptstat, but didn't really spot anything new: 1. mDNS (already configured) is definitely needed, as it is used to advertise available Sugar users and activities. 2. Incoming TCP (any port) to TCP port 5298 (telepathy-salut) is definitely needed, as Sugar connects to other Sugar systems using this, notably on Sugar startup as well as when an activity invite is sent. Tested with "-p tcp --dport 5298 -j ACCEPT" inserted in the middle of the INPUT rule stack; verified with tcpdumps/iptstat. 3. An additional multicast protocol of some sort needs to be explicitly allowed. I'm not quite certain what the minimal rule is, and why iptables' state table isn't automatically picking up on requests to join the group. Adding an INPUT rule of the form "-m addrtype --dst-type MULTICAST -j ACCEPT" will allow the Chat activity to work over Salut, but still likely is overbroad (although not the worse security hole in the world). Samuel: Have we got any further with these requirements? The requirements should ideally just match those required by http://xmpp.org/extensions/xep-0174.html In our case port.p2pj seems to be 5298, which is noted as a historically hard coded number, but not guaranteed. At the very least allowing mDNS and TCP port 5298 incoming would be a good starting point. I've adjusted the SoaS v7 firewall to add 5298, we already had mDNS This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23 This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. |