Ryan Is there any reason why listing all the interfaces you want to use in the slp.net.interfaces property wouldn't work?
cheers Matt -----Original Message----- From: Ryan Raasch [mailto:ryan.raa...@gmail.com] Sent: 03 April 2012 09:33 To: Nick Wagner Cc: openslp-users@lists.sourceforge.net Subject: Re: [Openslp-users] attach to device failed On 3 April 2012 03:37, Nick Wagner <ne...@wingedbeast.org> wrote: > I'm afraid I don't have the expertise to critique your three workarounds. > Does anyone else on the list care to comment? My typical approach to > these sorts of problems is usually to a) patch the application to > handle network changes, b) have something on the system detect the > network changes and do the appropriate application restarts, or c) > make sure everything starts late enough that there's an address and > let the user restart the app if they change the machine's address. Big thanks for the feedback! I think I have somewhat wrapped my head around the problem. The delayed started is not really the issue. I think it was my misunderstanding of the IGMP join stuff. 0.0.0.0 in the multicast context means default route. So, each of the interfaces need to be enumerated and used. Our implementation uses the b), and will suffice. However, what have been the proposed solutions to dynamically loading the changed interfaces? I made a quick hack with the code, but it wasn't an hour job to just call the functions terminate signal invokes. Where there any discussion regarding some type of SLPGetInterfaces() SLPScanInterfaces() etc. over the socket interface? Or where they more on the lines of signal handlers? I would be nice for any application to know which interfaces the daemon is registered on. /Ryan > > --Nick > > > On Mon, Apr 2, 2012 at 7:01 AM, Ryan Raasch <ryan.raa...@gmail.com> wrote: >> >> On 1 April 2012 19:48, Nick Wagner <ne...@wingedbeast.org> wrote: >> >> >> >> Yea, you are kinda' right. I want the daemon to listen on any and >> >> all interfaces ie. 0.0.0.0. But it seems that when the slp daemon >> >> starts up, and there is not default gw, the multicast setup fails. >> >> This is probably a fundamental misunderstanding on my part. If >> >> multicast needs a default route when any interface is used, that >> >> means that only one interface sends out the IGMP group join stuff. >> >> That would mean only one interface sends the service multicast >> >> packets (our is only a SA). >> >> What am i doing >> >> wrong, or do I just misunderstand the problem? >> >> >> > >> > Sockets that want to send multicast over a particular network >> > interface must set a socket option to send over that interface. >> > Otherwise, the stack will only send it out whatever network >> > interface it considers the primary/default. And the socket option >> > (IP_MULTICAST_IF) takes an ip address, although I have no idea if >> > that preference "sticks" if the interface changes its address >> > subsequent to the setsockopt. I've never tried to do any of this >> > with 0.0.0.0, it could be that it just fails. >> > >> Ok. I think i have an understanding of the startup. The daemon starts >> up, and must send out IGMP join requests on the interfaces. If the >> 0.0.0.0 is given, then the kernel just chooses the default route, and >> sends it. That is why when our system does not yet have the default >> route setup, the mulicast setup fails. >> >> BTW, our concerns are about restarting the slp daemon. In an small >> system, there are always ewww responses, when a daemon needs to be restarted. >> I know most don't see an issue with this, but there could be blocking >> issues with restarting the damon (using system()). >> >> > I don't know anything about your device/product, but is there a >> > point in your device that you know it has the necessary ip >> > addresses? Either via moving the daemon startup in rc.d, or using >> > whatever watchdogs your device may have? And is slpd the only >> > program on your device that has this sort of ip address issue? >> >> The difference would be that most daemons only listen, where the slp >> needs to register itself, ie. send data to a multicast address. >> >> I have guessed 3 "possible" work-arounds to this. >> >> 1. Is there a way to setup a routing rule with iptables or >> equivalent, to forward multicast addresses from the loopback >> interface? >> >> 2. Some type of simple userspace daemon which listens to loopback >> multicast and then forwards the traffic to the interfaces. Of course, >> this is a thought without reading the slp protocol in depth :-P >> >> 3. Allow SIG_HUP to call re-initialize network also (opposite to >> HandleSigTerm()) >> without exiting daemon. >> >> /Ryan >> >> > >> > --Nick > > ---------------------------------------------------------------------------- -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Openslp-users mailing list Openslp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-users This email, including any attachment, is a confidential communication intended solely for the use of the individual or entity to whom it is addressed. It contains information which is private and may be proprietary or covered by legal professional privilege. If you have received this email in error, please notify the sender upon receipt, and immediately delete it from your system. Anything contained in this email that is not connected with the businesses of this company is neither endorsed by nor is the liability of this company. Whilst we have taken reasonable precautions to ensure that any attachment to this email has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses, and would advise that you carry out your own virus checks before opening any attachment. ------------------------------------------------------------------------------ Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev _______________________________________________ Openslp-users mailing list Openslp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openslp-users
