Address family not supported by protocol

When I tried to do a send to, I got the following error:

Address family not supported by protocol

below is part of my code:

Code:

---

rlen = recvfrom(recv_s,f,sizeof(Frame),0,(struct sockaddr*)&client,&client_len);
        if (rlen < 0) {
            perror("Error: recv failed");
            exit(1);
        }



if (sendto(recv_s,ack_f,sizeof(Frame),0,(struct sockaddr *)&client,sizeof(client)) != rlen) {
                perror("Error: Sending message failed");
                close(recv_s);
                close(send_s);
                exit(1);
        }

---

basically the client information is filled from the recvfrom... but I don't know why when it tries to send it back it gives that error

Are you properly initializing the sin_family member of the sockaddr_in?

hmm.. here's what I've done so far.. I tried to print what the sin_family of client after the call to recvfrom and it gives me some huge number... I think it's supposed to be 2 right for AF_INET? So why is it not getting 2 there... weird

Is sin_family required to be in network-byte-order?

Quote:

---

Originally Posted by -EquinoX-

hmm.. here's what I've done so far.. I tried to print what the sin_family of client after the call to recvfrom and it gives me some huge number... I think it's supposed to be 2 right for AF_INET? So why is it not getting 2 there... weird

---

Have you examined its value immediately after the call to recvfrom()? If it's wrong there, then you know you can't rely on the system to correctly set this value for you -- you'll need to do it yourself.

As far as endianness, I don't seem to remember ever accounting for that while setting this value. The address family is something local to the host. It never goes over the network, so my assumption is that it should be in host byte order. (Besides, you have the macro AF_INET -- it would be kind of silly to have to htons() that value when it's already defined for convenience)

I've indirectly specified the AF_INET family and it doesn't complain again now, though now I don't think that it's sending to the correct place... although I've specified the port number as well