Re: recvfrom returns with an error code of 14, EFAULT "Bad Address"

From: Chris Ritchey (rethnor_at_yahoo.com)
Date: 07/03/03 

Date: 3 Jul 2003 14:40:31 -0700

Barry Margolin <barry.margolin@level3.com> wrote in message news:<4KZMa.16$Qd3.146@paloalto-snr1.gtei.net>...
> In article <480de79d.0307030820.7b959e89@posting.google.com>,
> Chris Ritchey <rethnor@yahoo.com> wrote:
> >I'll post the code at the bottom of the post. Whenever I try to
>
> It looks like you didn't post the correct code, I don't see any calls to
> recvfrom() in the excerpt.
>

Depest appologies I was posting about that, I was posting how I set
the socket up in case I did something wrong. I know that I'm not
handling any errors in my code as it is still very early in
development. What it does it takes the packet off the socket and
places it in a linked list where another function can pull it off and
use the data. The code is at the bottom of the page again.

> >retreive a udp packet sent via broadcast I get the errorcode
> >EFAULT(bad address). The same program sends out the packets without
>
> Sounds like you passed an uninitialized pointer as the buffer argument
> argument.

This is the main problem I am haveing. Before I pass the point to
recvfrom I am initializing it to NULL. This exact same function was
working before when the message was sent unicast instead of broadcast,
but when the message is sent through broadcast the same code returns-1
with errno set to 14, EFAULT.

> >any complaints but it fails when retreiving, I'm lost as to why it
> >would report this error. It returns the number of bytes correctly but
>
> If it returns the number of bytes, then how can it also be reporting an
> error code? Errno is only meaningful if recvfrom() returns -1.

Ah yes you are correct, I was looking at the number thinking it was
the size of the packet received and instead it was the size of the
packet that was sent. recv from is returning -1, I think in my
frustration (and annoyance with flies) over looked this.

> >returns the char* buffer as NULL. Any help would be appriciated and I
>
> I don't understand this at all. Buffer is an input parameter, not an
> output parameter. You have to pass in the pointer to the place where you
> want the data written.

Sorry wasn't feeling all that awake when I originally wrote this post.
What I ment was the char* buff that is passed by referance that was
being returned to null.

> >wouldn't be supprised if I was just missing something simple with
> >broacasting as I am still learning some aspects of socket
> >programiing.Thanks in advance to all whom reply and here is the code:
>
> Have you looked at the sample code in Unix Network Programming, Vol.1?

Yes I have but I was wondering there was something I needed to do
anything special with the the sockaddr_in other than
    sind_addr.s_addr = inet_addr(BCAST_ADDR)

Phew thanks for looking through my errors in my writting. Hopefully I
can give a clearer discription of the problem by correctly describing
what is going on :)

Here is half the function which uses recvfrom, the other half is
basically the same.

int Communications::QueueMessages(int socket)
{
    QueueNode *newNode = new QueueNode;
    newNode->message=NULL;

    cout << "QueueMessages: Entering... ";
    if(first == NULL) // Then last is NULL, and there are no
messages in queue
    {
        if( (newNode->messageSize = recvfrom(socket, newNode->message,
            MAXPACKETSIZE + 2, 0, (sockaddr*)&(newNode->client),
NULL)) < 0 )
        {
            cout << "Error message: " << strerror(errno) << endl;
            numMsg = 0;
            delete newNode;
            return numMsg; // nothing to retreive
        }
        newNode->next = NULL;
        first = last = newNode;
        numMsg = 1;
        newNode = new QueueNode;
    }
    ...

Where QueueNode is defined as

// nodes for the queue in communications
struct QueueNode
{
    char* message;
    int messageSize;
    sockaddr_in client;
    QueueNode* next;
};

Relevant Pages

  • Re: How does UDP work?
    ... >> When a packet comes through the wire, it is buffered internally by afd ... When we call recvfrom which issues ioctl to afd driver ... >> the buffer is copied when calling recvfrom. ... > the buffers by AFD.SYS even if nobody created a socket and issued a bind ...
    (microsoft.public.win32.programmer.networks)
  • Re: Can recvfrom() return more than 1 packet?
    ... Boltar wrote: ... If I'm using the recvfrom() call on a SOCK_DGRAM or SOCK_RAW socket, ... is there any possibility it would ever return more than 1 packet at a ...
    (comp.unix.programmer)
  • Re: Can recvfrom() return more than 1 packet?
    ... There is only a "whole IP packet" if the whole datagram fits in one ... recvfrom() on a SOCK_DGRAM socket is the ... SOCK_DGRAM socket causes you to receive datagrams. ...
    (comp.unix.programmer)
  • Re: Can recvfrom() return more than 1 packet?
    ... There is only a "whole IP packet" if the whole datagram fits in one ... getting back to the original post, what you get when you call recvfrom() ... SOCK_DGRAM socket causes you to receive datagrams. ...
    (comp.unix.programmer)
  • Re: How to terminate a socket in CLOSE_WAIT state
    ... FTP Server fixed for certain FTP clients who use both passive ... This was causing a PASSIVE opened socket to be left ... but instead expect the "half close" from the receiver. ... this sends a TCP/IP FIN packet to the ...
    (microsoft.public.win32.programmer.kernel)