Bug 905072 - Multicast test does not work correctly in Fedora 18
Summary: Multicast test does not work correctly in Fedora 18
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: firewalld
Version: 18
Hardware: Unspecified
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-01-28 14:11 UTC by Pavel Tisnovsky
Modified: 2016-01-15 10:31 UTC (History)
5 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-01-29 16:56:05 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Reproducer (1.21 KB, application/x-gzip)
2013-01-28 14:11 UTC, Pavel Tisnovsky
no flags Details

Description Pavel Tisnovsky 2013-01-28 14:11:49 UTC
Created attachment 688996 [details]
Reproducer

Description of problem:

In Fedora 18, it is not possible for two process (running on the same machine) to communicate using multicast addresses.


How reproducible:

- using reproducer stored in an attachment

Steps to Reproduce:
1. Build packet sender and packet listener tools (stored in an attachment)
2. Run sender in one terminal - it should start to periodically send packets to a multicast address 224.80.80.80
3. Run listener in second terminal
(4. Run second listener in the third terminal)
  
Actual results:

- listener does not receive any data

Expected results:

- listener(s) should receive 14 bytes long packets from the sender

Comment 1 Jiri Popelka 2013-01-28 14:21:16 UTC
This is not a net-tools' problem.
Try to turn firewall off (service firewalld stop).
If that helps change component to firewalld, otherwise change the component to kernel. Thanks.

Comment 2 Pavel Tisnovsky 2013-01-28 15:14:31 UTC
Ty Jiri,

when the firewall is turned off multicast communication seems to start working, so I'm changing component to firewalld.

Comment 3 Jiri Popelka 2013-01-29 16:56:05 UTC
Hi Pavel,

having sender and listener on one machine does not mean the packet does not go through firewall. AFAIK it does and it's blocked if not explicitly allowed.

If you want to run something that listens on port 12345/udp you need to explicitly allow it in firewall. In case of firewalld you can use the following commands (or use firewall-config):

# firewall-cmd --add-port=12345/udp
and if you want the change to survive restart, use also:
# firewall-cmd --permanent --add-port=12345/udp

Closing as notabug as it looks like it to me, feel free to reopen if you think otherwise.

Comment 4 David Sugar 2013-04-28 11:14:10 UTC
I am doing an experiment with an application that uses multicast also.  I found that while indeed the add port command adds the port to the firewall config, the sending process still cannot receive any (of its own) packets it sends over multicast, unless firewalld is turned off.  I also created a firewall service file for my multicast app based on the one for mdns, changing the address and ports as needed.  I believe this should be re-opened and I am thinking of creating a very simple test case application to better validate this bug.

Comment 5 Jiri Popelka 2013-04-29 11:26:19 UTC
Feel free to reopen when you have some test case or steps to reproduce.


Note You need to log in before you can comment on or make changes to this bug.