|
Bugzilla – Full Text Bug Listing |
| Summary: | firewall can't (easily) open port for (incoming) broadcasts | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 13.1 | Reporter: | Markus Greger <Markus.greger> |
| Component: | Network | Assignee: | YaST Team <yast-internal> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | astieger, Markus.greger, matthias.gerstner, meissner, mpluskal, snwint |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| URL: | https://trello.com/c/BYwpmAh2 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Markus Greger
2016-08-01 11:53:46 UTC
Hi Markus, would you like to double check whether this issue is reproducible on a newer version such as openSUSE Leap 42.1 or Tumbleweed? openSUSE 13.1 is out of date now and will not get update any longer. I'm assigning to maintainers to follow up this issue, thanks. I'm somewhat reluctant on updating and thus decided to use 13.1 as evergreen version. Nonetheless the forum link contains the sentence "The server is running Leap 42.1, but this problem has existed since OpenSUSE 8.x." Time permitting I may try a live cd running under qemu. However it should be straight forward to test like - server: echo “HELLO” | socat – UDP-DATAGRAM:192.168.0.255:5000,broadcast - client: nc -lu -w 60 192.168.0.255 5000 or tcpdump -i <interface> -v -X -s 80 port 5000 Might even work on one machine... (In reply to Markus Greger from comment #2) > I'm somewhat reluctant on updating and thus decided to use 13.1 as evergreen > version. > > Nonetheless the forum link contains the sentence > "The server is running Leap 42.1, but this problem has existed since > OpenSUSE 8.x." > > Time permitting I may try a live cd running under qemu. > > However it should be straight forward to test like > > - server: > echo “HELLO” | socat – UDP-DATAGRAM:192.168.0.255:5000,broadcast > > - client: > nc -lu -w 60 192.168.0.255 5000 > or > tcpdump -i <interface> -v -X -s 80 port 5000 > > > Might even work on one machine... Just realized: OpenSuse Leap doesn't have a live version. There goes this plan ... Hm, no idea. Marcus (Meissner), could you please comment on this (see comment 0). Should it be able to do this? Reporter, could you attach your /etc/sysconfig/SuSEfirewall2 generated by YaST? (In reply to Markus Greger from comment #0) > Configuring a firewall port <port-number> via > > yast -> firewall -> Allowed Services -> Advanced > yast -> firewall -> Broadcast -> Add > > will not allow incoming broadcasts on <port-number>. The "Allowed Services -> Advanced" will only open up ports for unicast, so this setting is not concerning broadcasting. I think the problem here is the "firewall -> Broadcast -> Add" setting, which is titled "Accepting the Broadcast Reply" in yast. It might be a bit confusing what this actually does. It actually only allows "related" traffic for that port to be accepted. So when you send out a broadcast from your machine, the replies to that broadcast will be accepted (at least that is what I think it is for, without having tested it). To allow any kind of broadcast to be accepted for a port you need to configure it in "firewall -> Broadcast -> Broadcast Configuration -> (Internal/DMZ/External Zone)". Of course you also need to use the correct zone for all these settings. If you didn't assign any zones then all your interfaces will end up in the external zone for everything. Would it be possible for you to test my suggestion so we can progress with this bug? Thank you. (In reply to Matthias Gerstner from comment #6) I tested listening with nc like while true ; do nc -lu -w 1 0.0.0.0 15000 ; done I tested sending (from a different computer) with repeated socat's like i=0; while [ $i -le 100 ]; do i=$(( i + 1 )); echo “HELLO-$i-`hostname`” | socat - UDP-DATAGRAM:REPLACE-IPV4-BROADCAST-ADDR-HERE:15000,broadcast; sleep 1; done My tests confirm adding the port to "firewall -> Broadcast -> Broadcast Configuration -> (Internal/DMZ/External Zone)" makes broadcast traffic pass through in OpenSuse 13.1 as well as in Leap 42.2. I've not tested the "related traffic" part of comment #6. I would think a non obvious configuration - which took quite some time to get down to - leads to non obvious system behavior and thus to a bug (see: https://en.wikipedia.org/wiki/Software_bug "A software bug is an error, flaw, failure or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways."). Therefore it would be great if the yast configuration dialog could be worked over to change behavior or to make it easier to comprehend. Thank you. Okay so the reporter confirmed that this is not exactly a bug in the firewall but an issue with confusing UI design. Yast maintainers, are you willing to improve the situation? I think changing some string labels, adding a description should do the trick. Actually no, Leap 42.3 will not change and all strings are frozen, Leap 15 will most probably have a different YaST module, because we plan to witch to firewalld. User confused by UI, no change is planned, instead switching to new yast module for SLE-15. |