I am binding a socket to my address to listen to connections. To do this, I get my address information using getaddrinfo() syscall, which grants me an ip independent way of doing what I want. The problem is that the structs which this syscall returns have the ip address field all blank. For example:
struct addrinfo hints, *servinfo, *p;
int sock;
memset(&hints, 0, sizeof(struct addrinfo));
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_PASSIVE;
getaddrinfo(NULL, port, &hints, &servinfo)
for (p = servinfo; p != NULL; p = p->ai_next)
if (p->ai_family == AF_INET6)
break;
sock = socket(p->ai_family, p->sock_type, p->protocol);
bind(sock, p->ai_addr, p->ai_addrlen)
In the code above. the *p variable should have some kind of information on an IPv6 address of my machine since the bind succeeds, but the field p->ai_addr->sin6_addr (assume this would work without a casting) is blank. How can I know exactly what address I will be using?
The address is not blank - it is all zeroes, which is 0::0. This is the special wildcard address which means to bind to all local interfaces.
You should not care what address(es) your host has - this list might change at any time, including immediately after you check it.
Once you have a client connected, you can use getsockname() on the socket returned by accept() to determine which one of your local addresses that client connected to.
Why don't you bind to localhost (i.e. IPV4 127.0.0.1) or to ip6-localhost (i.e. IPV6 ::1) if you want to listen to local connections only?
Otherwise, leave all zeroes in the address like #caf suggested.
Related
I am trying to familiarize myself with the networking BSD API. I understand the fact that multi bytes data submitted to the BSD API (like address and port) must be in network byte order and that we should use converting functions like htons() and htonl() to do this. This snippet of code shows that:
#define IP_ADDRESS(a, b, c, d) ((((uint32_t)a) << 24) | (((uint32_t)b) << 16) | (((uint32_t)c) << 8) | ((uint32_t)d))
/* Set server port in BSD format */
memset(&serverAddr, 0, sizeof(serverAddr));
serverAddr.sin_family = AF_INET;
serverAddr.sin_addr.s_addr = htonl(IP_ADDRESS(192,168,1,1));
serverAddr.sin_port = htons(21);
/* Connect to server */
status = connect(H->bsdSocket, (struct sockaddr *)&serverAddr, sizeof(serverAddr));
Now I am trying to make use of getaddrinfo() in order to retrieve the address information from a server name. I tried that following code:
memset( &hints, 0, sizeof( hints ) );
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
getaddrinfo( "srvdc01", "21", &hints, &addr_list );
if (addr_list != NULL)
{
ctx->fd = (int) socket( addr_list->ai_family, addr_list->ai_socktype,
addr_list->ai_protocol );
if (ctx->fd >= 0)
status = connect( ctx->fd, addr_list->ai_addr, addr_list->ai_addrlen );
}
I would have expected that the address returned by getaddrinfo() would be in network byte order in such a way it could be fed directly to the connect() function. Unfortunately, this does not work with the library I am using as the resulting connect is reverting the address bytes (I use Wireshark to investigate this issue).
Is it allowed to safely use addresses returned by getaddrinfo() for feeding the socket() and connect() calls?
Thanks, Franck
=== Update ===
Thanks guys for your comments. I could clarify things a little more. I ran the following code snippet with the following results:
struct addrinfo hints, *addr_list, *cur;
struct sockaddr_in addr_in;
memset(&addr_in, 0, sizeof(addr_in));
addr_in.sin_family = AF_INET;
addr_in.sin_port = htons(21);
addr_in.sin_addr.s_addr = htonl(0xC0A80101UL); // 192.168.1.1
myprintf("%08x\n", addr_in.sin_addr.s_addr);
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
hints.ai_protocol = IPPROTO_TCP;
if( getaddrinfo( "srvdc01", "21", &hints, &addr_list ) == 0 )
{
for( cur = addr_list; cur != NULL; cur = cur->ai_next )
{
ctx->fd = (int) socket( cur->ai_family, cur->ai_socktype,
cur->ai_protocol );
if( ctx->fd >= 0 )
{
myprintf("%08x\n", ((struct sockaddr_in *)cur->ai_addr)->sin_addr.s_addr);
}
}
}
freeaddrinfo( addr_list );
The first printf output (after htonl) gives c0a80101 while the second one (after socket creation) gives 0101a8c0. This was surprising because on my little endian platform, I would have expected the htonl() call to swap bytes to bring them in network byte order.
After reviewing documentation of our embedded networking library (third party commercial library), we could find that the BSD API they provide is actually a (quite) limited wrapper on top of their vendor specific network library API. There is a small notice about the fact that their library always work with the native system endianness so their htonl() function is always a dummy call that does nothing.
Now, looking at the link provided by Martin R. http://pubs.opengroup.org/onlinepubs/009695399/functions/freeaddrinfo.html, I agree with him that getaddrinfo() should return an address information suitable for a call to connect() which is visibly not the case with this embedded library.
The POSIX documentation for getaddrinfo()
states that
Upon successful return of getaddrinfo(), the location to which res points shall refer to a linked list of addrinfo structures, each of which shall specify a socket address and information for use in creating a socket with which to use that socket address. The list shall include at least one addrinfo structure. The ai_next field of each structure contains a pointer to the next structure on the list, or a null pointer if it is the last structure on the list. Each structure on the list shall include values for use with a call to the socket() function, and a socket address for use with the connect() function or, if the AI_PASSIVE flag was specified, for use with the bind() function. The fields ai_family, ai_socktype, and ai_protocol shall be usable as the arguments to the socket() function to create a socket suitable for use with the returned address. The fields ai_addr and ai_addrlen are usable as the arguments to the connect() or bind() functions with such a socket, according to the AI_PASSIVE flag.
This implies that – on a POSIX compliant system – IP address and port number in ai_addr are
in network byteorder, as expected by the connect() function.
I'm trying to get my head around socket programming and have encountered some unexpected (for me) behaviour.
When I try to send data to "localhost" and set addrinfo.ai_family to AF_INET the message I send isn't coming through from my client process to my host process (recvfrom() doesn't return). If I set it to AF_INET6 all is fine. Same for AF_UNSPEC in which case it picks the IPv6 addrinfo (first in the list). Both host and client use the same ai_family of course.
I've also tried this with code copy pasted from beej's guide to network programming which had the same result. I'm using DGRAM sockets.
I tried connecting from a different pc I got the opposite results, IPv4 worked fine, IPv6 did not. I gather this may be due to me using a '6to4 gateway'. I really have no idea what this means.
The problem is related to my own machine as the code does work over IPv4 on another machine I tested it on.
I can't say if it's a sending or receiving problem.
What could prevent me from sending or receiving data to/from localhost using AF_INET sockets?
I'm on a windows7 64bit machine compiling with MingW.
If it makes any difference I'm running the same program for host and client processes with different arguments. I ran the release and debug programs together (so it's not the same program twice) but got the same results.
Thanks in advance and apologies if this is considered a stupid question.
code:
typedef struct addrinfo addrinfo_t;
typedef struct sockaddr_storage sockaddr_storage_t;
typedef struct sockaddr_in sockaddr_in_t;
typedef struct sockaddr_in6 sockaddr_in6_t;
void connect_to_server(const char* server_name, const char* message)
{
int status;
init_networking();
addrinfo_t hints;
addrinfo_t* res;
memset(&hints, 0, sizeof(addrinfo_t));
hints.ai_family = AF_INET; //or AF_INET6
hints.ai_socktype = SOCK_DGRAM;
if ((status = getaddrinfo(server_name, "4950", &hints, &res)) != 0)
{
fprintf(stderr, "getaddrinfo error: %s\n", gai_strerror(status));
exit(1);
}
SOCKET s = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
if (s == -1)
{
fprintf(stderr, "could not create a socket, errno: %u\n", errno);
exit(1);
}
int bytes_sent = sendto(s, message, strlen(message), 0, res->ai_addr, res->ai_addrlen);
close(s);
printf("Sent %i bytes to port %i\n", bytes_sent, ((sockaddr_in_t*)res->ai_addr)->sin_port);
freeaddrinfo(res);
}
void setup_server()
{
int status;
init_networking();
addrinfo_t hints;
addrinfo_t* res;
memset(&hints, 0, sizeof(addrinfo_t));
hints.ai_family = AF_INET; //or AF_INET6
hints.ai_socktype = SOCK_DGRAM;
hints.ai_flags = AI_PASSIVE;
if ((status = getaddrinfo(NULL, "4950", &hints, &res)) != 0)
{
fprintf(stderr, "getaddrinfo error: %s\n", gai_strerror(status));
exit(1);
}
SOCKET s = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
if (s == -1)
{
fprintf(stderr, "could not create a socket, errno: %u\n", errno);
exit(1);
}
//Bind the socket to own address (mostly the port number contained in the address)
if (bind(s, res->ai_addr, res->ai_addrlen) < 0)
{
fprintf(stderr, "failed to bind, errno: %u\n", errno);
exit(1);
}
freeaddrinfo(res);
const size_t read_buffer_size = 1024;
void* read_buffer = malloc(read_buffer_size);
sockaddr_storage_t peer_address;
int peer_address_length = sizeof(sockaddr_storage_t);
sockaddr_storage_t own_sock_addr;
int own_sock_addr_len = sizeof(sockaddr_storage_t);
getsockname(s, (struct sockaddr*)&own_sock_addr, &own_sock_addr_len);
printf("Listening on port %i\n", ((sockaddr_in_t*)&own_sock_addr)->sin_port);
int bytes_received = recvfrom(s,
read_buffer,
read_buffer_size-1,
0,
(struct sockaddr*)&peer_address,
&peer_address_length );
printf("Received %i byte message:\n%s\n", bytes_received, (char*)read_buffer);
}
AF_INET is for IPv4, and AF_INET6 is for IPv6. When sending an IPv4 datagram, the receiver must be receiving data on the destination IP/port using either an IPv4 socket or an IPv6 dual stack socket (an IPv6 socket that accepts both IPv4 and IPv6 traffic). When sending an IPv6 datagram, the receiver must be receiving data using an IPv6 socket. Otherwise, the datagram will be ignored, So it sounds like the one machine is using an IPv6 socket that ignores your IPv4 datagram, and the other machine is using an IPv4 socket that ignores your IPv6 datagram.
When you are calling getaddrinfo(), you are specifying AF_UNSPEC as the address family in both client and server. AF_UNSPEC tells getaddrinfo() that you want both IPv4 and IPv6 addresses, so it returns a linked list that potentially contains multiple entries for all of the available IPv4 and IPv6 addresses. On the server side, you are creating a single listening socket for only the first entry in the list, which may be IPv4 or IPv6. On the client side, you are creating a single sending socket for only the first entry in the list, which may be IPv4 or IPv6. So the actual address families used in both operations are going to be random and may mismatch each other at times.
On the server side, you need to either:
use AF_INET or AF_INET6 directly, instead of AF_UNSPEC, and then code the client accordingly to match.
loop through the entire addrinfo list creating a separate listening socket for every entry. That way, clients can send data to any IP/Port family the server is listening on.
use AF_INET6 only when creating the listening socket(s), but then enable dual stack functionality on them (Vista+ only) so they can receive both IPv4 and IPv6 datagrams. You will then have to pay attention to the address family reported by the sockaddr that recvfrom() returns in order to know whether any given datagram is using IPv4 or IPv6.
On the client side, you need to use AF_INET or AF_INET6 directly, instead of AF_UNSPEC, depending on what the server is actually listening on. It does not make sense to use AF_UNSPEC for a UDP client socket (it does make sense for a TCP client socket), unless the UDP protocol you are implementing replies to each datagram with an ack. Without that, the client has no way to know whether the server is accepting IPv4 or IPv6 datagrams (unless the user tells the app). With acks, the client could loop through the returned addrinfo list, sending a datagram to an entry in the list, wait a few seconds for an ack, and if not received then move on to the next entry in the list, repeating as needed until an ack actually arrives or the list is exhausted.
I am writing a server-client program and in the server I use getaddrinfo and getsockname on the server to get info about the local IP addr and locally bound port number .
Using this info, I start my client program and use the getaddrinfo and then just print out the returned values in the servinfo data structure:
getaddrinfo(argc[1], argc[2], &hints, &servinfo); >> server hostname and server port number are passed via command line.
But I notice that the sin_port in servinfo is not the port I am passing via the command line.
1) Does this getaddrinfo return the port number being used by the client as the source port number ?
2) My connect call after the getaddrinfo and socket calls in failing. I do not know why. How do I debug it ?
My client code snippet:
memset(&hints, 0 ,sizeof hints);
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_CANONNAME | AI_NUMERICSERV;
getaddrinfo(argc[1], argc[2], &hints, &servinfo);
for (p = servinfo till p!=NULL)
sockfd = socket(p->ai_family, p->ai_socktype, p->ai_protocol)
connect(sockfd, p->ai_addr, p->ai_addrlen) >>>>> Connect not going through.
I start my client program like this:
./a.out myservername 18844
Thanks !
New answer: You are invoking your program with only one argument, so argv[1] contains "18844" and argv[2] is a null pointer. This is going to try to connect to a host with numeric IP 18844 and an unspecified port number (which will end up being 0 and failing).
Old answer: (relevant but not your problem) sin_port and the whole sockaddr_in structure is in network byte order. You'll need to convert the port with ntohl to use it as a number, but you would be better off never touching sockaddr structures' internals whatsoever. Instead, use getnameinfo with NI_NUMERICHOST and NI_NUMERICSERV to get the address back into a string-based numeric form, then strtol to read the port ("service") number into an integer. This works even for non-IPv4 network address/protocol families (like IPv6) and requires no additional code for supporting new ones.
Does anyone know if it's possible to use getaddrinfo with unix sockets in C (AF_UNIX). I've tried a couple of things but I can't make it work.
This is basically what I'm trying:
struct addrinfo hints, *res;
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNIX;
hints.ai_socktype = SOCK_STREAM;
if(getaddrinfo("What should I put here?", "What should I put here?", &hints, &res) != 0){
//do sth about
}
My question is how to fill the node and service fields, in case that is possible to use it with unix sockets.
Thanks in advance.
Some implementations of getaddrinfo() have supported AF_UNIX socket addresses, but they no longer do so due to security concerns.
You don't really need a function to "look up" an AF_UNIX address anyway - if you know the socket path, then you can just copy it straight into a sockaddr_un of sufficient size. There's no resolution step for AF_UNIX addresses - the socket name is the socket address.
From man 3 getaddrinfo:
The hints parameter specifies the preferred socket type, or protocol. A NULL hints specifies that any network address or protocol is acceptable. If this parameter is not NULL it points to an addrinfo structure whose ai_family, ai_socktype, and ai_protocol members specify the preferred socket type. AF_UNSPEC in ai_family specifies any protocol family (either IPv4 or IPv6, for example). 0 in ai_socktype or ai_protocol specifies that any socket type or protocol is acceptable as well. The ai_flags member specifies additional options, defined below. Multiple flags are specified by logically OR-ing them together. All the other members in the hints parameter must contain either 0, or a null pointer.
So it looks like you need to pass in the hints parameter to tell it you want a unix socket.
A lot late, but just for the records, did you try this -
struct addrinfo hints, *res;
memset(&hints, 0, sizeof(hints));
hints.ai_family = AF_UNSPEC; //is the address family(IPV4 or 6) or UNSPEC for either
hints.ai_socktype = SOCK_STREAM;
if(getaddrinfo(parm1, parm2, &hints, &res) != 0){
//do sth about
}
parm1 -> is the host name or address to connect to. A call with NULL here puts the address of local host, in which case you specify hints.ai_flags=AI_PASSIVE.
parm2 -> is the name of the intended service (http, ftp etc) or the corresponding port number for that service the socket is used for
Is it possible to obtain the sender IP and (dynamically obtained) port with C sockets? I have the following:
memset(&hints, 0, sizeof hints);
hints.ai_family = AF_UNSPEC;
hints.ai_socktype = SOCK_DGRAM;
if ((rv = getaddrinfo(NULL, DATABASEPORT, &hints, &servinfo)) != 0) {
fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(rv));
exit(1);
}
for(p = servinfo; p != NULL; p = p->ai_next) {
if ((sockfd = socket(p->ai_family, p->ai_socktype, p->ai_protocol)) == -1) {
perror("socket");
continue;
}
break;
}
Which is pretty much taken from a guide (though I kind of get it?). But I'm having trouble identifying which information I would use to find out the client data.
Any and all help is appreciated, thanks!
Generally you get the local address/port information with the getsockname(2), but here you don't have it yet - the socket is not connected and nothing has been sent. If this is a simple UDP client - consider using connected UDP sockets - you'd be able to see local IP/port right after the connect(2).
For non-connected UDP sockets, there's no way to get the local address. You can of course get the remote address by using recvfrom instead of read/recv to read packets. If you'll only be communicating with a single server, just go ahead and use connect. If you need to communicate with more than one server, you can probably just make a dummy connect (on a new socket) to one of the servers to get your local address, but it's possible (if the host uses nontrivial routing) that connecting to different remote hosts will result in different local addresses. This can even happen in a fairly trivial environment if you connect both to localhost (127.0.0.1) and remote servers.