Bug 4898

Summary:	Default Mageia firewall is blocking video stream from local network DLNA (UPnP) server.
Product:	Mageia	Reporter:	Steve <kin7500-fm>
Component:	RPM Packages	Assignee:	Olivier Blin <mageia>
Status:	RESOLVED OLD	QA Contact:
Severity:	normal
Priority:	Normal	CC:	marja11, nic
Version:	Cauldron	Keywords:	NEEDINFO
Target Milestone:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Source RPM:	drakx-net-1.3-1.mga2.src.rpm	CVE:
Status comment:

Description Steve 2012-03-12 12:20:18 CET

Description of problem:
I'm running a Humax HDR set-top box TV recorder and using it as a DLNA (UPnP) server so that I can watch TV recordings on my PC in another room. I'm using VLC, with the UPnP plugin, as the client. This set-up only works if I disable the Personal Firewall via MCC, i.e. tick the box for "Everything(no firewall)".

If I just enable the firewall, by removing the tick from the box, with only the default options set, VLC can no longer see my Humax UPnP server, so there is something that is blocking the stream just by enabling the default firewall. This same issue is also present using XBMC as the client.

I have found that that VLC uses ports in the range 30000 to 60000, which are different each time VLC is launched (I understand that client ports are always dynamically chosen), so using the "Advanced" option I entered 30000:60000/udp to open this range of ports. This was the only change that I made to the default settings of the enabled firewall and now VLC can see the stream again.

Is it the intended action of the default settings to block ports in this range ?

Version-Release number of selected component (if applicable):
drakx-net-text-1.3-1.mga2

How reproducible:
Every time

Steps to Reproduce:
1.Set up a local network DLNA server.
2.Use VLC (with the UPnP plugin) to show the stream.
3.Enable/Disable the Personal Firewall, using MCC/Security/Set up your Personal Firewall.

Manuel Hiebel 2012-03-12 19:13:10 CET

Assignee: bugsquad => mageia

Comment 1 Marja Van Waes 2012-05-26 13:05:49 CEST

Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Comment 2 Marja Van Waes 2012-07-06 15:06:20 CEST

Please look at the bottom of this mail to see whether you're the assignee of this  bug, if you don't already know whether you are.


If you're the assignee:

We'd like to know for sure whether this bug was assigned correctly. Please change status to ASSIGNED if it is, or put OK on the whiteboard instead.

If you don't have a clue and don't see a way to find out, then please put NEEDHELP on the whiteboard.

Please assign back to Bug Squad or to the correct person to solve this bug if we were wrong to assign it to you, and explain why.

Thanks :)

**************************** 

@ the reporter and persons in the cc of this bug:

If you have any new information that wasn't given before (like this bug being valid for another version of Mageia, too, or it being solved) please tell us.

@ the reporter of this bug

If you didn't reply yet to a request for more information, please do so within two weeks from now.

Thanks all :-D

Comment 3 Steve 2012-07-06 21:00:08 CEST

I have just checked my rolling Cauldron(3) installation and the default settings of the Personal Firewall still block my Humax UPnP server. So nothing has changed in Cauldron and I therefore assume that Mageia2 will be the same.
As I do not have any expertise in iptables, and how they are used in the Personal Firewall I was hoping to get an answer to the question: "Is it the intended action of the default settings of the Personal Firewall to block ports in the range 30000 to 60000 ?"

If no-one is able to answer this question I suggest that the Status be changed to UNCONFIRMED and the Resolution is WONTFIX.

Comment 4 Nic Baxter 2015-02-28 02:36:01 CET

No further comment so unconfirmed & wontfix

Status: NEW => UNCONFIRMED
CC: (none) => nic
Ever confirmed: 1 => 0

Comment 5 Marja Van Waes 2017-09-10 17:36:09 CEST

(In reply to Steve from comment #3)

> 
> If no-one is able to answer this question I suggest that the Status be
> changed to UNCONFIRMED and the Resolution is WONTFIX.

Wow, you wrote that over 5 years ago, no one gave an answer, but somehow this report did never get closed.

I guess that's because a report can't be closed an unconfirmed at the same time.

Closing as OLD seems more appropriate to me, doing so now.

CC: (none) => marja11
Status: UNCONFIRMED => RESOLVED
Resolution: (none) => OLD