Bug 452541 - MT_INTERFACE is a pain
MT_INTERFACE is a pain
Product: Fedora
Classification: Fedora
Component: mediatomb (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Marc Wiriadisastra
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-06-23 13:06 EDT by Bastien Nocera
Modified: 2008-12-20 07:39 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-12-20 07:39:34 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bastien Nocera 2008-06-23 13:06:03 EDT

When changing the configuration of my system (swapping between different Wi-Fi
drivers), then I need to edit the mediatomb.conf file to change MT_INTERFACE.

First, why are the multicast settings setup in the mediatomb startup script?
Couldn't NetworkManager and/or the network-scripts do that?

Secondly, could this be applied to all the internal interfaces by default?
Lennart probably has some better idea on how to avoid the Upnp services to not
show up on the internet.

Finally, at the very least, the mediatomb startup script should fail to start up
if the device mentioned in the configuration file doesn't exist.
Comment 1 Sergey Bostandzhyan 2008-06-26 07:52:16 EDT
The main problem here lies within libupnp, the webserver works on all interfaces
but SSDP stuff only on the specified one, so in the end you have to specify one
of the interfaces, since binding to all or to a number of interfaces is simply
not supported by the library.

We are going to replace libupnp with our own lib, then things like that should
become possible.

As for the multicast settings - well, I do not care which script does it, as
long as it gets done, if these settings are not applied the server will not
respond to SSDP M-SEARCH requests. You only need the settings if you use UPnP,
so I am not sure where those settings should be done on distribution level.

For the last part, i.e. failing to start on a wrong interface specification: we
could indeed add this check and catch these error cases before passing the
parameter to libupnp.

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