On 30 March 2012 18:04, Nick Wagner <ne...@wingedbeast.org> wrote:
> I personally prefer a solution where the daemon can handle network
> infrastructure changes, but while the group has talked about possible
> solutions now and then we've never implemented it.
>
Yea, that would be nice.
> Isn't this a larger issue for your application, though? Aren't other system
> services (or applications you need to run) going to have to deal with having
> an invalid interface on startup? If that's not the case, why not delay
> startup of the daemon instead?
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?
Thanks for the reply,
/Ryan
>
> --Nick
>
>
> On Fri, Mar 30, 2012 at 5:14 AM, Ryan Raasch <ryan.raa...@gmail.com> wrote:
>>
>> Hello,
>>
>> I have an application where we use the slpd. When the system is
>> started, however, our network interfaces are not ready when the init.d
>> scripts
>> are run. So, a network aware application needs to restart the daemon
>> when the network is ready. The network interface needed to be binded
>> is the 0.0.0.0 interface. But if the daemon, again is started too
>> early, although
>> the network is up, this error occurs.
>>
>> ****************************************
>> Mon Jan 26 02:25:39 1970
>> SLPD daemon started
>> ****************************************
>> Command line = /usr/sbin/slpd
>> Using configuration file = /etc/slp.conf
>> Using registration file = /etc/slp.reg
>> Listening on loopback TCP...
>> Listening on loopback UDP...
>> Couldn't bind to (IPv4) multicast for interface 0.0.0.0 (No such device)
>> Unicast socket on 0.0.0.0 ready
>> Agent Interfaces = 0.0.0.0
>> Startup complete entering main run loop ...
>>
>> Through the communication interface, there is no way of querying what
>> the status of the slpd is (which interfaces are available, etc.). To
>> remedy the
>> problem I made a small hack to exit the daemon if the multicast stuff
>> failed.
>>
>> As the damon is today, I understand there is no possibility to re-iterate
>> the
>> network interfaces. A restart is needed for this case. Could there not be
>> a
>> config parameter or switch to instruct the daemon to exit if it cannot
>> fulfill the
>> config's parameters as expected? Or an extra query api to the daemon to
>> determine net interface properties?
>>
>> diff --git a/slpd/slpd_incoming.c b/slpd/slpd_incoming.c
>> index bbb28cf..dc8869d 100644
>> --- a/slpd/slpd_incoming.c
>> +++ b/slpd/slpd_incoming.c
>> @@ -721,10 +721,13 @@ int SLPDIncomingInit(void)
>> sizeof(addr_str)));
>> }
>> else
>> + {
>> SLPDLog("Couldn't bind to (IPv4) multicast for interface
>> %s (%s)\n",
>> SLPNetSockAddrStorageToString(&myaddr, addr_str,
>> sizeof(addr_str)),
>> strerror(errno));
>> + return 1;
>> + }
>> }
>> else if (SLPNetIsIPV6() && myaddr.ss_family == AF_INET6)
>> {
>>
>> Cheers,
>> Ryan
>>
>>
>> ------------------------------------------------------------------------------
>> This SF email is sponsosred by:
>> Try Windows Azure free for 90 days Click Here
>> http://p.sf.net/sfu/sfd2d-msazure
>> _______________________________________________
>> Openslp-users mailing list
>> Openslp-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>
>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Openslp-users mailing list
Openslp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-users
