On 2016/03/27 12:28, Martin Pieuchot wrote: > On 26/03/16(Sat) 23:25, Stuart Henderson wrote: > > On 2016/03/26 23:21, Stuart Henderson wrote: > > > Sorry I don't have a simple test method, > > > > oh, there are some example programs in p5-IO-Socket-Multicast (in > > /usr/local/share/examples/p5-IO-Socket-Multicast), can't reboot > > again right now to test that they fail with ART, but they work ok > > without ART and it looks like they might be an easier way..just > > run server.pl on one box, client.pl on another. > > Thanks for the report unfortunately I don't understand the problem. > > p5-IO-Socket-Multicast server & client work just fine here with ART, > w/ and w/o default route for multicast addresses. > > avahi-based services also work fine here (group is 224.0.0.251). >
Hmmm. OK yes it does seem to be working with client.pl/server.pl here as well. So I'm only seeing the problem with minidlna. There aren't any unexpected messages in minidlna's log. Restarting minidlna at runtime doesn't help (though if it is restarted while gupnp-universal-cp is actually running it *does* show up; at least until you restart gupnp-universal-cp: most of these clients seem to cache the endpoints until restarted). Adding/removing routes at runtime (in various different orders) doesn't seem to help. I had an offlist report that minidlna was working with a recent snap, so I think it may well be connected with the -interface route that I mentioned I'm using, "route add 224/4 -interface 10.15.5.2". But looking at captures on the minidlna box itself it doesn't make sense, tcpdump shows the same "contentdirectory" udp packet from 239.255.255.250.1900 > 10.15.5.27.$client_port going out on vlan5 with either kernel (I checked the MAC addresses etc too), but with the ART one we don't see a subsequent TCP request on the location given in the udp packet.. I'm building my own kernels to test, the only difference is ART/not, so it's not some unrelated change. I am totally confused, next step I guess is to try and figure out if my switch can mirror the port and find another machine to capture on, to see if it does actually get transmitted...
