Bug 16311 - Autodiscovery interacts oddly with firewall setup
Summary: Autodiscovery interacts oddly with firewall setup
Status: RESOLVED OLD
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 5
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia tools maintainers
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-06 22:07 CEST by Mike Arnautov
Modified: 2018-04-14 13:59 CEST (History)
3 users (show)

See Also:
Source RPM: drakx-net-2.22-1.mga5.src.rpm
CVE:
Status comment:


Attachments

Description Mike Arnautov 2015-07-06 22:07:41 CEST
Description of problem: I have an HP printer with no interfaces other than wifi. This fails to be auto-discovered by either system-config-printer or by hp-setup -- I have to supply the printer's actual IP address in either case. Suspecting that the failure of auto-discovery was somehow caused by the firewall, I performed a series of experiments and found the following strange behaviour:

For network auto-dicsovery to work, "network services autodiscovery" must be enabled in the firewall. This may not seem surprising, until I add that this is the case whether or not the firewall is disabled! To put it otherwise, if you do not wish firewall enabled, you must still enable "network services autodiscovery" in the firewall before disabling the firewall.

Network auto-discovery will also work if the firewall is enabled, but not applied to Ethernet interface(s). This is true even if having enabled the firewall (without "network services autodiscovery") you are still looking at the window asking you which interface(s) it should be applied to. Until you click OK to confirm applicability to your Ethernet interface(s), auto-discovery will work. Once you click OK, with Ethernet interface(s) checked, it will stop working. If you uncheck Ethernet interface(s) before clicking OK, auto-discovery will continue working.

This does not look like intended behaviour. :-)


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


How reproducible: 100%


Steps to Reproduce:
1. Set the firewall to any of the above described states
2. Run /usr/bin/hp-probe
3.


Reproducible: 

Steps to Reproduce:
David Walser 2015-07-06 22:24:32 CEST

CC: (none) => thierry.vignaud
QA Contact: security => (none)
Assignee: bugsquad => mageia
Component: Security => RPM Packages

Florian Hubold 2015-07-07 08:53:36 CEST

CC: (none) => doktor5000

Comment 1 Marja Van Waes 2018-04-14 11:50:35 CEST
Thank you for having taken the needed time to report this issue!

Did this bug get fixed? If so, please change it's status to RESOLVED - FIXED

If it didn't, then we regret that we weren't able to fix it in Mageia 5. Mageia 5 has officially reached its End of Life on December 31st, 2017 https://blog.mageia.org/en/2017/11/07/mageia-5-eol-postponed/

If you haven't seen that this bug got fixed, then please check whether this bug still exists in Mageia 6. If it does, then please change the Version (near the top, at the left) to "6". If you know it exists in Cauldron, then change Version to Cauldron. If you see it in both Cauldron and Mageia 6, then please set version to Cauldron and add MGA6TOO on the Whiteboard.

Thanks,
Marja

Assignee: mageia => mageiatools
CC: (none) => marja11

Comment 2 Mike Arnautov 2018-04-14 13:33:39 CEST
To the best of my knowledge not fixed in Mageia 5. Mageia 6 exhibits a different anomalous behaviour. I'll submit a new bug report.
Comment 3 Marja Van Waes 2018-04-14 13:59:30 CEST
(In reply to Mike Arnautov from comment #2)
> To the best of my knowledge not fixed in Mageia 5. Mageia 6 exhibits a
> different anomalous behaviour. I'll submit a new bug report.

Thanks, that should indeed go into a new bug report.

Closing this one as OLD

Resolution: (none) => OLD
Status: NEW => RESOLVED


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