accept() / getpeername() return 0.0.0.0

[Mike King]

I think I'm dealing with a bug in a library or some weird problem. The
following code compiles and works as I'd expect on Linux and cygwin, but on
the machine that matters (HP PA64, HPUX 11.11) it identifies the peer as
0.0.0.0 in both the accept() and getpeername() return vals, also identifies
the peer port as 0. I'm using gcc 4.1.2, downloaded from HP's site,
compiling with 'gcc sockprob.c -o sockprob', then running it with
'./sockprob.c MY.I.P.ADD 7890', then connect to the server socket with
'telnet MY.I.P.ADD 7890'. Cygwin and Linux show the ip and port of the
connector, but HPUX is showing 0.0.0.0. I run a 'netstat -n' and it shows
the correct ip/port for the server and client. I just don't get it. Does
anyone have any advice?

#include <unistd.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <netinet/in.h>
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <string.h>

char* ipstring;
int port1;

void parseargs(int, char**);

int main(int argc, char* args[])
{ struct sockaddr_in adr1; /* address for the server */
int ss1, as1; /* file descriptors for server socket, active
socket */

struct sockaddr_in from1; /* address for peer */
socklen_t from1_len;

parseargs(argc, args);

if((ss1 = socket(PF_INET, SOCK_STREAM, 0)) < 0)
{ perror("socket failed");
return 1;
}

memset(&adr1, 0, sizeof(adr1));
adr1.sin_family = AF_INET;
adr1.sin_port = htons(port1);

if(!inet_aton(ipstring, (struct in_addr*)&(adr1.sin_addr)))
{ perror("inet_aton failed");
return 1;
}

if(bind(ss1, (struct sockaddr*) &adr1, sizeof(adr1)))
{ perror("bind failed");
return 1;
}

if(listen(ss1, 1) < 0)
{ perror("listen failed");
return 1;
}

from1_len = sizeof(from1);
memset(&from1, 0, sizeof(from1));
from1.sin_family = AF_INET;

if((as1 = accept(ss1, (struct sockaddr*) &from1, &from1_len)) == -1)
{ perror("Error accepting");
return 1;
}

printf("peer address from accept() is %s %d\n",
inet_ntoa(from1.sin_addr), ntohs(from1.sin_port));


if(getpeername(as1, (struct sockaddr*) &from1, &from1_len))
{ perror("getpeername failed");
return 1;
}

printf("peer add/port from getpeername() is %s %d\n",
inet_ntoa(from1.sin_addr), ntohs(from1.sin_port));

return 0;
}

void parseargs(int argc, char* args[])
{
/* command line is sockprob ip port */
ipstring = args[1];
sscanf(args[2], "%d", &port1);
return;
}

 

[Eric Sosman]

I think I'm dealing with a bug in a library or some weird problem.
> [...]

Whatever bug or weird problem confronts you, it is not a
problem with the C language or the way C is used. It may
surprise you to learn that C's networking support is rather
limited. In fact, it consists entirely of the following list
of headers, types, and functions:



Yes, that's the complete list; you didn't miss anything.

Try your question on a newsgroup devoted to HPUX, or at
least to Unix. It isn't about C.

 

[Mike King]

10-4

No it doesn't suprise me. I know how small the c language is. I thought
maybe you all had some advice on tracking down library bugs, like
identifying the actual executable the linker uses, typical problems with
non-native compilers, etc.

#include<sincere/apology.h>

Mike

I think I'm dealing with a bug in a library or some weird problem.
[...]

Whatever bug or weird problem confronts you, it is not a
problem with the C language or the way C is used. It may
surprise you to learn that C's networking support is rather
limited. In fact, it consists entirely of the following list
of headers, types, and functions:



Yes, that's the complete list; you didn't miss anything.

Try your question on a newsgroup devoted to HPUX, or at
least to Unix. It isn't about C.

 

[jaysome]

I think I'm dealing with a bug in a library or some weird problem. The
following code compiles and works as I'd expect on Linux and cygwin, but on
the machine that matters (HP PA64, HPUX 11.11) it identifies the peer as
0.0.0.0 in both the accept() and getpeername() return vals, also identifies
the peer port as 0. I'm using gcc 4.1.2, downloaded from HP's site,
compiling with 'gcc sockprob.c -o sockprob', then running it with
'./sockprob.c MY.I.P.ADD 7890', then connect to the server socket with
'telnet MY.I.P.ADD 7890'. Cygwin and Linux show the ip and port of the
connector, but HPUX is showing 0.0.0.0. I run a 'netstat -n' and it shows
the correct ip/port for the server and client. I just don't get it. Does
anyone have any advice?

As others have pointed out, your question is off-topic. Regardless,
the best advice I can give is to use a debugger. Doesn't HP PA64, HPUX
11.11 have a debugger?

If this were Windows, I'd use the Microsoft Visual Studio debugger to
nail down the problem (probably in minutes, if not seconds). I've used
Eclipse on Linux to nail down similar problems with 64-bit
platforms--maybe you can use Eclipse (which uses gdb)?

Best regards

 

[Mike King]

It was a type mismatch - socklen_t is defined as size_t, defined as long,
which is 8 bytes with the compiler I was using. The library code was
expecting a 4 byte int even though the header file says socklen_t. When I
added a 32 bit left shift to the socklen_t variable, it worked. The
functions had been getting the 4 high bytes which were all 0, so the
function didn't populate my sockaddr struct because it didn't think they
were big enough.

Sorry again for the off topic post - you won't hear from me any more.

Thanks,
Mike

 

[Keith Thompson]

It was a type mismatch - socklen_t is defined as size_t, defined as long,
which is 8 bytes with the compiler I was using.

[snip]

Please don't top-post. See:
http://www.caliburn.nl/topposting.html
http://www.cpax.org.uk/prg/writings/topposting.php

size_t is guaranteed to be an unsigned type. It can't be defined as
long; it might be defined as unsigned long.