John Calcote wrote:
AIX has some funny ideas about what a sockaddr looks like. For
instance, most systems treat the family member as a short - containing
2 bytes. AIX treats family as if it were a byte, and expects another
byte sized field to exist next to it containing the size of the
address. In these cases, you just have to work around the differences
in code. Let me know where you're failing (probably in some socket
call like bind, connect, send or recv) and I'll patch the code for you
so the sockaddr is handled correctly.
It is failing at the constants for all the const in6_addr structs in
common/slp_net.c
_errors on AIX_
../../common/slp_net.c:59: warning: excess elements in array initializer
../../common/slp_net.c:59: warning: (near initialization for
'in6addr_srvloc_node.u6_addr.u6_addr32')
../../common/slp_net.c:59: warning: excess elements in array initializer
../../common/slp_net.c:59: warning: (near initialization for
'in6addr_srvloc_node.u6_addr.u6_addr32')
.....
All of the constant initializers are generating this warning in that
file. I honestly haven't even looked at it thus far. Except that I know
the layout of in6_addr is different from the Solaris one (AIX has a
different order and size).
_aix in6_addr:_
struct in6_addr {
union {
u_int32_t u6_addr32[4];
#ifdef notyet
u_int64_t u6_addr64[2];
#endif /* notyet */
u_int16_t u6_addr16[8];
u_int8_t u6_addr8[16];
} u6_addr;
};
I was going to look at it over the weekend, but if you can fix it please
feel free.
Thanks!
John
On Fri, Feb 15, 2008 at 4:17 PM, jim marshall
<[EMAIL PROTECTED]> wrote:
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
>> Openslp-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openslp-users
>>
>>
>
>
>
>
--
Jim Marshall
Sr. Staff Engineer
WBEM Solutions, Inc.
978-947-3607
--
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
Openslp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openslp-users
