John Calcote wrote:
>
> Jim,
>
> I've checked a set of changes where we pass the correct address length
> to all calls to sendto now. Rather than change function signatures all
> over the place to add address lengths, I just use the family member to
> determine what the correct length should be and pass this value. A
> better solution would be to rework the code so that sizeof
> sockaddr_storage is used whenever a buffer is expected to receive an
> address, and to pass around the length of previously stored addresses
> with the address itself.
>
> This change was a bit less intrusive - you don't need a lot of churn
> right now, I'm presuming. :)
Absolutely. These fixes solved the problem. Now I am running into some
issues on AIX :'(
I'm looking at it now and will send a follow up to the list if I need
some advice.
>
> John
>
> jim marshall wrote:
>> I've been trying to figure out why the slptool 2.0.0 does not work on
>> Solaris. I have debugged through some code, and have come to
>>
>> SLPNetworkSendMessage (sockfd=7, socktype=1, buf=0x2a570, bufsz=49,
>> peeraddr=0xffbff3f0, timeout=0xffbff178) at
>> ../../common/slp_network.c:155
>>
>>
>> 155 xferbytes = sendto(sockfd, (char *)cur,
>> 156 (int)(end - cur), flags, peeraddr,
>> 157 sizeof(struct sockaddr_storage));
>>
>> This call returns -1 (errno==22, Invalid argument). Given this, I am
>> presuming the problem is the 'peeraddr' structure being invalid
>> (since "(int)(end - cur)" is 49, which does not overflow a size_t).
>> Looking at where the peeradr is set (in NetworkConnectToSlpd)
>> everything looks fine:
>>
>> (gdb) print *(struct sockaddr_in *) addr
>> $95 = {sin_family = 2, sin_port = 427, sin_addr = {S_un = {S_un_b = {
>> s_b1 = 127 '\177', s_b2 = 0 '\0', s_b3 = 0 '\0', s_b4 = 1
>> '\001'},
>> S_un_w = {s_w1 = 32512, s_w2 = 1}, S_addr = 2130706433}},
>> sin_zero = "\000\000\000\000\000\000\000"}
>>
>> I'm not sure where else to look for this.
>>
>> Any thoughts?
>>
>>
>> Thanks
>> -Jim
>>
>> -------------------------------------------------------------------------
>>
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Openslp-users mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>>
>
>
>
>
--
Jim Marshall
Sr. Staff Engineer
WBEM Solutions, Inc.
978-947-3607
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Openslp-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openslp-users
