[arch-general] ReadyDLNA/MiniDLNA doesn't work behind wireless
Good afternoon, as said in the subject I am having some issues running MiniDLNA on my home server. The service fires up properly (the status web page is properly accessible), however the server is not visible when I scan for it in my DLNA-enanched applications, on all the platforms (my Android phone and tablet + my computer). In the past it was working when my home server was connected through Ethernet, but I had to make a really bad setup and I would prefer to keep it on wireless. Did anyone have a problem similar to mine? -- Giovanni Santini My blog: http://giovannisantini.tk My code: https://git{hub,lab}.com/ItachiSan My GPG: 2FADEBF5
On 06/04/2017 08:38 AM, Giovanni Santini via arch-general wrote:
Good afternoon, as said in the subject I am having some issues running MiniDLNA on my home server. The service fires up properly (the status web page is properly accessible), however the server is not visible when I scan for it in my DLNA-enanched applications, on all the platforms (my Android phone and tablet + my computer). In the past it was working when my home server was connected through Ethernet, but I had to make a really bad setup and I would prefer to keep it on wireless. Did anyone have a problem similar to mine?
The status page is properly accessible from where? A x86 computer that's on your wired network? or from a device connected to network via wireless?
Il 04/06/2017 16:10, ITwrx.org ha scritto:
The status page is properly accessible from where? A x86 computer that's on your wired network? or from a device connected to network via wireless?
MiniDLNA publishes automatically a web page on port 8200 for checking its status. My computer is an old x64-capable server. It is connected to my network through a wireless USB adapter. -- Giovanni Santini My blog: http://giovannisantini.tk My code: https://git{hub,lab}.com/ItachiSan My GPG: 2FADEBF5
Hi, On 6/4/2017 4:45 PM, Giovanni Santini via arch-general wrote:
Il 04/06/2017 16:10, ITwrx.org ha scritto:
The status page is properly accessible from where? A x86 computer that's on your wired network? or from a device connected to network via wireless?
MiniDLNA publishes automatically a web page on port 8200 for checking its status.
My computer is an old x64-capable server. It is connected to my network through a wireless USB adapter.
Just a wild guess: is your wireless network a separate subnet? If so, there's your problem. AFAIK MiniDLNA uses SSDP[1] to announce itself, using a site-local multicast-IP that isn't routed. You need to bridge your wireless network into the wired one, meaning it has to be the same subnet. -- Regards, Arno [1] https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol -- Gruß, Arno.
Il 04/06/2017 17:24, ihad ha scritto:
Hi,
...
Just a wild guess: is your wireless network a separate subnet? If so, there's your problem. AFAIK MiniDLNA uses SSDP[1] to announce itself, using a site-local multicast-IP that isn't routed. You need to bridge your wireless network into the wired one, meaning it has to be the same subnet.
Hey, no, both of them are configured through DHCP and they both use the same subnet (mask 255.255.255.0, base 192.168.0.0). -- Giovanni Santini My blog: http://giovannisantini.tk My code: https://git{hub,lab}.com/ItachiSan My GPG: 2FADEBF5
On 06/04/2017 09:45 AM, Giovanni Santini via arch-general wrote:
Il 04/06/2017 16:10, ITwrx.org ha scritto:
The status page is properly accessible from where? A x86 computer that's on your wired network? or from a device connected to network via wireless? MiniDLNA publishes automatically a web page on port 8200 for checking its status.
My computer is an old x64-capable server. It is connected to my network through a wireless USB adapter.
this computer is the one you successfully accessed the minidlna web page from? or a different computer connected via ethernet? i'm just trying to verify that you have successfully accessed the webpage for minidlna from a wireless device/computer. if yes, then you could use nmap or a nmap gui (nmap-qt4 ?) to scan the host that is supposed to be serving minidlna and make sure that port is actually open/visible. IOW, just start ruling things out. If that port is open/accessible from a remote machine then try different apps on the clients to make sure it's not just buggy clients. you might also try different minidlna servers. i know when i tried to use minidlna the servers and client apps were very picky and some were very flakey too. i ended up ditching minidlna(even though i had it working most of the time) and just using samba just because i didn't like how non-robust it all was. -- Information Technology Works https://ITwrx.org @ITwrxorg
Il 04/06/2017 18:08, ITwrx.org ha scritto:
this computer is the one you successfully accessed the minidlna web page from? or a different computer connected via ethernet? i'm just trying to verify that you have successfully accessed the webpage for minidlna from a wireless device/computer.
if yes, then you could use nmap or a nmap gui (nmap-qt4 ?) to scan the host that is supposed to be serving minidlna and make sure that port is actually open/visible. IOW, just start ruling things out. If that port is open/accessible from a remote machine then try different apps on the clients to make sure it's not just buggy clients. you might also try different minidlna servers. i know when i tried to use minidlna the servers and client apps were very picky and some were very flakey too. i ended up ditching minidlna(even though i had it working most of the time) and just using samba just because i didn't like how non-robust it all was.
The computer I was referring to is the server I am trying to access. I've accessed the webpage from my laptop. There is a strange thing indeed: the server has actually no firewall, however the 1900 UDP port, which should be open for SSDP seems closed. Here it is the result of some investigation --- # On my laptop $ nmap -sU -p 1900 santini_server Starting Nmap 7.40 ( https://nmap.org ) at 2017-06-05 11:32 ora legale Europa occidentale Nmap scan report for santini_server (192.168.0.109) Host is up (0.027s latency). PORT STATE SERVICE 1900/udp closed upnp MAC Address: 00:1E:2A:43:47:3E (Netgear) Nmap done: 1 IP address (1 host up) scanned in 12.43 seconds # On the server $ sudo iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination --- No idea why MiniDLNA does not check the port. -- Giovanni Santini My blog: http://giovannisantini.tk My code: https://git{hub,lab}.com/ItachiSan My GPG: 2FADEBF5
On 06/05/2017 04:37 AM, Giovanni Santini via arch-general wrote:
The computer I was referring to is the server I am trying to access. I've accessed the webpage from my laptop.
There is a strange thing indeed: the server has actually no firewall, however the 1900 UDP port, which should be open for SSDP seems closed.
Here it is the result of some investigation --- # On my laptop $ nmap -sU -p 1900 santini_server Starting Nmap 7.40 ( https://nmap.org ) at 2017-06-05 11:32 ora legale Europa occidentale Nmap scan report for santini_server (192.168.0.109) Host is up (0.027s latency). PORT STATE SERVICE 1900/udp closed upnp MAC Address: 00:1E:2A:43:47:3E (Netgear)
Nmap done: 1 IP address (1 host up) scanned in 12.43 seconds
# On the server $ sudo iptables --list Chain INPUT (policy ACCEPT) target prot opt source destination
Chain FORWARD (policy ACCEPT) target prot opt source destination
Chain OUTPUT (policy ACCEPT) target prot opt source destination --- No idea why MiniDLNA does not check the port. i just installed minidlna and got it working from vlc over wireless. it didn't work at first. "systemctl status minindlna" showed that it wasn't able to identify the network interface i provided. i have no idea why(old method in minidlna?). i commented that line in config back out and made sure minidlna could read my testing media directory and it worked at that point. i used nmap -sS -sU -T4 -A -v 192.168.1.1 to see if port 8200 was open. it was.
so, if "systemctl status minidlna" or "journalctl -b" shows no problems for minidlna then maybe test with nmap from both wired and wireless and see if there is a difference. If there is, then you have network config issue. the arch wiki page for minidlna has a section about wireless in the troubleshooting section i notice.
On Mon, Jun 5, 2017 at 4:12 PM, ITwrx.org <info@itwrx.org> wrote:
--- No idea why MiniDLNA does not check the port. i just installed minidlna and got it working from vlc over wireless. it didn't work at first. "systemctl status minindlna" showed that it wasn't able to identify the network interface i provided. i have no idea why(old method in minidlna?). i commented that line in config back out and made sure minidlna could read my testing media directory and it worked at that point. i used nmap -sS -sU -T4 -A -v 192.168.1.1 to see if port 8200 was open. it was.
so, if "systemctl status minidlna" or "journalctl -b" shows no problems for minidlna then maybe test with nmap from both wired and wireless and see if there is a difference. If there is, then you have network config issue. the arch wiki page for minidlna has a section about wireless in the troubleshooting section i notice.
Although I don't run minidlna over the wireless interface on the server I use, and only use the wired interface, I presume that the key here may be as you suggest that the lines in /etc/minidlna.conf near the start of the file that are relevant, which in my case are: # port for HTTP (descriptions, SOAP, media transfer) traffic port=8200 # network interfaces to serve, comma delimited #network_interface=eth0 network_interface=eth0 would need to include the correctly specified interface(s) for the server running minidlna for the OP. I wonder what the latter line actually is for that file in the problem machine? -- mike c
Il 05/06/2017 23:11, Mike Cloaked via arch-general ha scritto:
On Mon, Jun 5, 2017 at 4:12 PM, ITwrx.org <info@itwrx.org> wrote:
i just installed minidlna and got it working from vlc over wireless. it didn't work at first. "systemctl status minindlna" showed that it wasn't able to identify the network interface i provided. i have no idea why(old method in minidlna?). i commented that line in config back out and made sure minidlna could read my testing media directory and it worked at that point. i used nmap -sS -sU -T4 -A -v 192.168.1.1 to see if port 8200 was open. it was.
so, if "systemctl status minidlna" or "journalctl -b" shows no problems for minidlna then maybe test with nmap from both wired and wireless and see if there is a difference. If there is, then you have network config issue. the arch wiki page for minidlna has a section about wireless in the troubleshooting section i notice.
Although I don't run minidlna over the wireless interface on the server I use, and only use the wired interface, I presume that the key here may be as you suggest that the lines in /etc/minidlna.conf near the start of the file that are relevant, which in my case are:
# port for HTTP (descriptions, SOAP, media transfer) traffic port=8200
# network interfaces to serve, comma delimited #network_interface=eth0 network_interface=eth0
would need to include the correctly specified interface(s) for the server running minidlna for the OP. I wonder what the latter line actually is for that file in the problem machine?
Good morning, Thanks to everyone for your support. Seems the problem was different, as my router started acting really weird. I just replaced it and MiniDLNA 'n stuff work flawlessly. So, always replace defective routers. :P Thanks again. -- Giovanni Santini My blog: http://giovannisantini.tk My code: https://git{hub,lab}.com/ItachiSan My GPG: 2FADEBF5
participants (4)
-
Giovanni Santini
-
ihad
-
ITwrx.org
-
Mike Cloaked