Date: Wed, 21 Mar 2018 17:15:15 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: Andreas Scherrer <ascherrer@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: Multicast/SSDP not working (on VLAN interface) Message-ID: <201803220015.w2M0FFbg023791@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <0b920e07-8ad3-deb9-a876-9523b18678f7@gmail.com>
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. If your rule set is 800+ lines I highly suspect your doing something in a very non-optimal way. It also leads to be VERY suspeciious that it is infact in your firewall. Try as a very first rules: ipfw add 1 log allow ip from any to 224.0.0.0/4 ipfw add 2 log allow ip from 224.0.0.0/4 to any DO NOT put any restricting clauses on these.. if this makes things work simply move them down a few rules until you find the point at which things stop working. You may want to examine the log, as it would tell you what ipfw thinks the packet path is, and may shed some light on why other things are not happening the way you expect. Also do you have any nat, divert, or other things going on, they can all have an effect on mutlicast packets. > 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 You using an out xmit re1, and that is probably what is NOT happening. What does: route get default show? > > allow ip4 from me to "table($broadcast)" out xmit <interface with DGW> > > but did not see any outgoing multicast traffic from MiniDLNA. The packet may NOT match the specific out xmit $dgw clause. > 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. That could be, it could also be shutting down its response cause it gets an error from the firewall code saying "permission denied". > But I don't know what... I assume it is not related to mrouted (which is > NOT running)? You should not need mrouted, it does not sound as if your running as a multicast router. > 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. It should not be required. I run large amounts of OSPF which is a multicast protocol without any mrouted, and given the descriptiong of your topology your only trying to do mutlicast to directly attached machines, not routed multicast. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201803220015.w2M0FFbg023791>