Offhand, the request (packet number 8) looks correct and I don't see a
response. If you've already verified firewall and ping possibilities, try
taking the entertainment device out of the picture. Use slpd on a different
machine -- running only as a service agent -- and register a service with
slp.reg. See if your test app can discover that service. You can also play
with combinations of slpd and slptool to see what with a DA offline, a DA
local to your machine, and a DA on another machine. Sniffing the traffic
and examining the srvloc packets may also give you some insight. It really
comes down to isolating the possibilities and testing for each particular
one.
One other thing to consider -- I've seen some smaller embedded devices
assume that there will always be a DA online, and not respond to some or any
of the multicast requests. It's not right, but for one thing it means they
don't have to worry about supporting predicate matching. And there's
usually at least one DA in our typical systems so it never comes back to
bite them.
--Nick
On Mon, Sep 26, 2011 at 6:50 AM, JanakiRam Palepu <palepujanaki...@gmail.com
> wrote:
> Thanks Nick for your suggestion.
>
> However , i am still unable to discover the SLP Services even after
> changing the string to "service:acn.esta".
>
> PFA , Wireshark Trace for your reference.
>
> Please help me resolve the issue.
>
> Thanks,
> Janakiram
>
>
> On Fri, Sep 23, 2011 at 7:47 PM, Nick Wagner <ne...@wingedbeast.org>wrote:
>
>> Wireshark is your friend. I'll walk you through the trace. Packets 6, 7,
>> 11, and 12 are all SLP (SRVLOC) packets. They are being multicast from your
>> machine to the SLP multicast address/port. Packets 6 & 11 are libslp
>> looking for directory agents -- if you open up one of the packets you can
>> see that the service type list is "service:directory-agent". But packets 7
>> & 12 show a problem. They are requesting "acn.esta" when they should be
>> requesting "service:acn.esta". Make sure the string you are passing to the
>> SLPFindSrvs call is "service:acn.esta" and we can work from there.
>>
>> --Nick
>>
>>
>> On Fri, Sep 23, 2011 at 7:33 AM, JanakiRam Palepu <
>> palepujanaki...@gmail.com> wrote:
>>
>>> Thanks Nick for your valuable suggestions.
>>>
>>> I've tried the possible ways suggested. Please find my inline replies.
>>>
>>> On Thu, Sep 22, 2011 at 8:27 PM, Nick Wagner <ne...@wingedbeast.org>wrote:
>>>
>>>> Whenever I this sort of thing happens, there are a few steps I take:
>>>>
>>>> 1) Check your firewall and make sure it is either off or your
>>>> application is properly excepted. This has solved countless problems for
>>>> me.
>>>>
>>>
>>> Firewall on Mac was turned-off by default. I got the results ( published
>>> earlier with/wihtout SLPD existence ) were tested when Firewall was
>>> turned-Off.
>>> I dont think this option applies to my case.
>>>
>>>
>>>> 2) If you are expecting unicast traffic between two devices, make sure
>>>> they can send packets to each other. Are they both plugged in? Are their
>>>> IP configurations correct? Can they ping each other?
>>>>
>>>
>>> I can ping the entertainment device from my mac and subnet mask for
>>> device as well as Mac are set to same value. I am sure that my network
>>> settings are properly set to communicate with device.
>>>
>>>
>>>> 3) Get a wireshark trace of what's going on in your network. This will
>>>> help you determine if no multicast is leaving your machine, if no other app
>>>> is responding to your requests, or if something else is going on. The
>>>> wireshark display filter keyword for SLP is "srvloc".
>>>>
>>>
>>> I've downloaded the Wireshark Tool from their website as per your advice
>>> and able to capture the log in my network. Please find the attached log.
>>>
>>> As am new to this tool , i could not interpret/understand the results
>>> shown in log. It would be great if you can help me to understand the issue.
>>>
>>> My Mac IP : 192.168.1.97
>>> Entertainment Device IP : 192.168.1.999
>>>
>>>
>>>>
>>>> 4) If you think it is your application, either in a debugger or with
>>>> sprinkled test messages trace your code execution to see how it operates.
>>>> In your case, see if SLPFindSrvs actually gets to the point where it sends
>>>> a multicast packet, or if it somehow returns early.
>>>>
>>>
>>> I've investigated further on the calls being made internally when
>>> SLPFindSrvs is being called. I suspect that NetworkMcastRqstRply is unable
>>> to communicate futher hence its not able to detect the SLP Service inabsence
>>> of Slpd.
>>>
>>> I am attaching the SLP Log for your reference.
>>>
>>> Please provide your analysis on the reports i have provided.
>>>
>>> Thanks in Advance.
>>>
>>> Regards,
>>> Janakiram
>>>
>>
>>
>
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Openslp-devel mailing list
Openslp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-devel
