Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Mar 2018 23:50:09 +0100
From:      Andreas Scherrer <ascherrer@gmail.com>
To:        freebsd-net@freebsd.org
Subject:   Re: Multicast/SSDP not working (on VLAN interface)
Message-ID:  <0b920e07-8ad3-deb9-a876-9523b18678f7@gmail.com>
In-Reply-To: <201803210044.w2L0iQww018953@pdx.rh.CN85.dnsmgr.net>
References:  <201803210044.w2L0iQww018953@pdx.rh.CN85.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Thank you for bearing with me.

On 21.03.18 01:44, Rodney W. Grimes wrote:

...

> Show me your full firewall rule set, without that I can only speculate
> as to where it is getting blocked, but given your symptoms I highly
> suspect the firewall is blocking the packets OUT of your SERVER back
> towards the client as they try to go out what ever interface your
> default route is on.

OK, I see your point. But I obviously forgot to mention some important 
things. I am sorry for that.

First of all, my rules file is 800+ lines, I am not sure how much it 
helps to throw that at anybody. I agree that this makes it somewhat more 
likely that the firewall IS the problem, but I do have reason to believe 
that it is not.

I did check on the interface the default route is pointing through: 
there is no incorrect outgoing traffic.

Obviously, if the firewall blocks the traffic, then I expect not to see any.

But there are the following rules as well:

   allow ip4 from me to "table($internal)" out xmit re1\* keep-state
   allow ip4 from me to "table($broadcast)" out xmit re1\*

table($internal) is basically RFC1918 and table($broadcast) contains 
224.0.0.0/4 and ff00::/8.

To test, I have also added the following rule

   allow ip4 from me to "table($broadcast)" out xmit <interface with DGW>

but did not see any outgoing multicast traffic from MiniDLNA.

Also, when MiniDLNA is running before I add the interface route for 
244.0.0.0/4, the VLC test client does NOT discover the MiniDLNA server 
(despite the route). If, however, the MiniDLNA service is (re)started 
after the route is in place (but before the test client is running), it 
does detect the server immediately.

I therefore suspect that the "MiniDLNA startup code" does something 
different when the route is there as compared to when it is not.

But I don't know what... I assume it is not related to mrouted (which is 
NOT running)?

Also, again, if setting the interface route for 224.0.0.0/4 absolutely 
IS required, I will not be able to make my intended setup work. I have 
multiple interfaces connected to potential clients for MiniDLNA.


Best regards
andreas



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0b920e07-8ad3-deb9-a876-9523b18678f7>