Hi Deano,
In my ignorance I didn’t recognise the multicast address and misunderstood what was required. I have now used the command as you suggested. Please forgive.
Here is the output from your command:-
alastair@localhost:~> firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: wlp3s0
sources:
services: dhcpv6-client nfs samba samba-client upnp-client
ports: 1900/udp 9790/tcp 9791/tcp
protocols:
forward: no
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
alastair@localhost:~>
By communication with the server I assume you refer to minimserver on the NAS I regret the minimwatch app on laptop is still grey.
This app when grey has a limited menu and this is same as always when grey and it does enable me to see the logs I posted earlier which show that the the that the monitor subscription to the NAS is still failing.
I can communicate with the NAS using my browser from this laptop and can see that the server is running.
Yes, that is what I was referring to ie the subject of this thread. A pragmatic option might just be to allow UDP traffic from your NAS IP address. A simple rule to add via firewalld.
Understood but will need to consider implications of opening up udp to the NAS when, already, I am concerned over the security of the NAS device and how it connects to the WAN. I would like to get this minimserver business resolved but it has taken your time and attention too long already. If you are able to continue with this thread I should perhaps first PM you with the background as this would give you a better understanding of my concerns. Let me know if you have time.
Regards,
Budge
Hi Deano,
I have have a bit more info from Simon of minimserver. He advises:-
This message is produced when a firewall is preventing MinimServer from establishing a connection/subscription with MinimWatch.
MinimWatch exposes a dynamically assigned port number for inbound connections and sends an outbound “subscribe” message to MinimServer requesting an inbound connection/subscription from MinimServer on that dynamic port. It is not possible to control or predict which port number will be used for the inbound connection.
After MinimWatch has sent the outbound “subscribe” message to MinimServer, it waits 4 seconds for the inbound connection/subscription. If the inbound connection/subscription isn’t received in that time (usually because of a blocking firewall), MinimWatch prints the message, cancels the subscription and tries again (forever).
Clearly if minimwatch is waiting for 4 seconds and the info is timed out at 3 seconds there could be a problem! I tried setting for 5 seconds but sadly still not working.
I doubt that will be the case, as it is the client that initiates the connection. The ipset rule with 3s timeout option is used to set the expiry time for a given added entry. This is to allow for a delayed response from the server.
BTW, the configuration files you created for this live in /etc/firewalld/direct.xml, and /etc/firewalld/ipsets/upnp.xml, and you can remove them if you want to start over. (Then restart the firewall.)
Reading this thread and after skimming the Minimwatch and Minimserver documentation,
You may have to verify your Minimserver has been upgraded to Minimserver 2 and not still running Minimserver .08.
There seems to be some confusion what should be configured on your openSUSE and what is configured on your NAS (which is running on an unknown OS).
The NAS should be configured to accept UDP port 1900, not the openSUSE client.
It’s likely already set up correctly but should be checked that the NAS should also have its SAMBA ports open.
The openSUSE client should not require any firewall configuration, by default the firewall does not block outbound connections in any way (although can be configured to do so). If you <really> believe your problem is the firewall blocking outbound connections, instead of fiddling around with ports I’d recommend simply switching to a more permissive firewall zone that can be used in private networks behind firewalls.
Despite the talk about uPnP in this thread, there is only one optional setup that is relevant UPnP and DLNA
I did not find any mention anywhere about secondary connections, particularly when SMB/CIFS network sharing is implemented. The documentation I read says that the UDP port is used only by Minimwatch to access the Minimserver to browse available resources, it’s not used by any network sharing at all. There is nothing I read that mentions anything unusual about Minimserver network sharing, it’s just ordinary SAMBA. You can think that accessing a share by Minimwatch is a primary and secondary connection, but it’s not like what you’d see with PASV FTP… It’s two completely separate connections managed by Minimserver, and so should be analyzed as two completely separate connections.
Yes, that is true. A random UDP port is chosen by the client, and that is what the minimserver uses to communicate back to the client.
It’s likely already set up correctly but should be checked that the NAS should also have its SAMBA ports open.
What does samba have to do with minimserver?
The openSUSE client should not require any firewall configuration, by default the firewall does not block outbound connections in any way (although can be configured to do so).
This is where you are misinformed. The replies from the server use a random port (chosen by the client), so this will present as unsolicited inbound traffic to the firewall.
If you <really> believe your problem is the firewall blocking outbound connections, instead of fiddling around with ports I’d recommend simply switching to a more permissive firewall zone that can be used in private networks behind firewalls.
No, this IS about INBOUND traffic to the client (and being blocked by firewalld).
Despite the talk about uPnP in this thread, there is only one optional setup that is relevant UPnP and DLNA
I did not find any mention anywhere about secondary connections, particularly when SMB/CIFS network sharing is implemented. The documentation I read says that the UDP port is used only by Minimwatch to access the Minimserver to browse available resources, it’s not used by any network sharing at all.
But this thread is not about network filesharing. It is about MinimServer which is a UPnP AV music server.
I see no reference to samba in that guide, and AFAIU the OP has already stated that the NAS is accessible from that standpoint already, (but perhaps I’m mistaken.)
Hi Tsu and many thanks for reading up on minimserver etc and for your reply.
I can confirm I am running Minimserver 2.*
There seems to be some confusion what should be configured on your openSUSE and what is configured on your NAS (which is running on an unknown OS).
The NAS should be configured to accept UDP port 1900, not the openSUSE client.
It’s likely already set up correctly but should be checked that the NAS should also have its SAMBA ports open.
*You are right that I am confused and not for the first time I have been looking at it in the wrong way. As for setting the configuration on the NAS I have not found a direct way to do this but as Minimserver has been set up from within the NAS from the QNAP “store” and it works with windoze on my network I assume the configuration is set correctly on the NAS. SAMBA is also enabled as it is used for other tasks, along with NFS. *
The openSUSE client should not require any firewall configuration, by default the firewall does not block outbound connections in any way (although can be configured to do so). If you <really> believe your problem is the firewall blocking outbound connections, instead of fiddling around with ports I’d recommend simply switching to a more permissive firewall zone that can be used in private networks behind firewalls.
I have not intentionally prevented any outgoing traffic from this laptop to the NAS. I am working in an increasingly more public environment here and until I have revised my whole network strategy regarding media usage here I am not anxious to take a more relaxed general approach. The fact that the minimwatch tool works when my firewall is turned off suggests to me that it should be possible to fix the problem by using the correct firewall settings and those for this environment.
Despite the talk about uPnP in this thread, there is only one optional setup that is relevant UPnP and DLNA
*I am familiar with the article and have spent some time on this when using RPi3bs. On these I use upmpdcli and mpv on the renderer with BubbleDS control point and these renderers all work with the NAS and minimserver. I have never got to grips with firewalling these RPi devices but none of them use or need to use minimwatch. *
I did not find any mention anywhere about secondary connections, particularly when SMB/CIFS network sharing is implemented. The documentation I read says that the UDP port is used only by Minimwatch to access the Minimserver to browse available resources, it’s not used by any network sharing at all. There is nothing I read that mentions anything unusual about Minimserver network sharing, it’s just ordinary SAMBA. You can think that accessing a share by Minimwatch is a primary and secondary connection, but it’s not like what you’d see with PASV FTP… It’s two completely separate connections managed by Minimserver, and so should be analyzed as two completely separate connections.
HTH,
TSU
*OK I understand the separation of the server and the secondary connection. In fact the only purpose I have for this connection is to make it possible to configure the minimserver remotely using minimwatch. I only ever connect to the NAS from this laptop using a web based tool. That being the case I am not inclined to open any unconfined UDP port on my laptop just to get minimwatch to work.
Apart from my own confusion I still have not solved the firewall problem. If there is more I can do please let me know and thanks again for your perspective on my efforts to date.
Unfortunately I attempted a reply to Tsu before seeing your own reply. My reply to him added little and your reply continues to make sense to me but you will have gathered I am not going to take the easy option of opening up everything.
I had hoped that Simon Nash’s post on his forum referring to a 4 second interval gave me hope so I created a new ipset with timeout set at 5 seconds hoping all would suddenly work. No such luck. I have been through the documentation on ipset etc and cannot see any obvious errors but I wonder if the problem is with nftables which are still set as the Backend. I think that is correct but remain out of my depth.
If you can continue with this I truly would appreciate it but am aware you only have limited time.
Regards,
Budge
I had hoped that Simon Nash’s post on his forum referring to a 4 second interval gave me hope so I created a new ipset with timeout set at 5 seconds hoping all would suddenly work. No such luck.
Yes, that was never the issue.
I have been through the documentation on ipset etc and cannot see any obvious errors but I wonder if the problem is with nftables which are still set as the Backend. I think that is correct but remain out of my depth.
Hi,
My internet connection just broke. Had to come to different building to check and I find I can get a connection where I work. Now I can at least let you know and there will be a short interruption because I cannot resume this conversation or sort out the problem on laptop tonight (for me). Will have to resume in the morning when folk are up and about.
Sorry about this. I just hope it was not my IT knowhow which cocked it up!
Regards,
Budge.
All good. We’re all just volunteers here, and fit this ‘support’ around our personal and work lives. Just leave it parked until you’re ready to turn your attention back to it. The notifications tell users when a thread is updated.
