Recursive Query.

kalpesh varyani kalpesh.link at gmail.com
Thu Aug 13 20:17:29 UTC 2009


Hi All,

I have looked into the code socket.c file and tusc output for the requirsive
query.

tusc O/P :
-----------------------------------------------------------------------------------------------------------------------------
#3 connect(516, 0x347694, 16) ......................................
*ERR#245 EINPROGRESS*
                         sin_family: AF_INET
                           sin_port: 53
                    sin_addr.s_addr: 192.168.2.96
#2 write(12, "A u g   1 1   1 7 : 5 5 : 3 4 . ".., 61) ............. = 61
#5 write(7, "\0\00204\0c0\0\0", 8) ................................. = 8
#3 sendmsg2(516, "\0\0\0\0\0\0\0\0z fec8\b\0\0\001".., O_RDONLY) ... = 49
------------------------------------------------------------------------------------------------------------------------------

In above tusc output, we are seen that connect is fail with the
"EINPROGRESS" and after then sendmsg2 call and it got failed.

Code for BIND-9.4.3-P1:

        cc = connect(sock->fd, &addr->type.sa, addr->length);
        if (cc < 0) {


        if (cc < 0) {
                /*
                 * HP-UX "fails" to connect a UDP socket and sets errno to
                 * EINPROGRESS if it's non-blocking.  We'd rather regard
this as
                 * a success and let the user detect it if it's really an
error
                 * at the time of sending a packet on the socket.
                 */
               * if (sock->type == isc_sockettype_udp &&  errno ==
EINPROGRESS) {
                   cc==0;
                   goto success;*

succecss:

   if (cc == 0) {
                sock->connected = 1;
                sock->bound = 1;
                dev->result = ISC_R_SUCCESS;
                isc_task_send(task, (isc_event_t **)&dev);

                UNLOCK(&sock->lock);
                return (ISC_R_SUCCESS);
        }

-----------------------------------------------------------------------------------------------------------------------------
In above code we have same code for the success retrun from the connect and
also connect retrun "*EINPROGRESS" i.e. cc *==0, it means that we are not
taking care of the "EINPROGRESS".

Regards
Dinesh.



On Wed, Aug 12, 2009 at 5:48 AM, kalpesh varyani <kalpesh.link at gmail.com>wrote:

>  thanks for reply.
>
>  This issue is seen only on hp-ux 11.11/11.23 env. I have checked the
> configuration and
>  environment issue not finding anything wrong.
>
> Regards
> Kalpesh
>
> On Tue, Aug 11, 2009 at 11:20 PM, Cathy Almond <cathya at isc.org> wrote:
>
>> I would recommend tracing or similar to find out why your named daemon
>> is not able to send to the IP address being logged.  You may find that
>> there are network connectivity issues or that the remote IP is sending
>> back an ICMP response.
>>
>> The reason this particular logged error is seen on HP-UX is seemingly a
>> feature of the sockets implementation whereby the set-up of the
>> destination address may fail, but it isn't trapped until the send fails
>> with EDESTADDRREQ.
>>
>> The underlying failure to send is a configuration/environmental issue
>> and this is what needs to be investigated.
>>
>> Cathy
>>
>>
>> Kevin Darcy wrote:
>> > Well, you could file a bug report, but I'm not aware of this error
>> > happening on other platforms, so it might end up being a kernel issue of
>> > some sort.
>> >
>> >
>> >                                          - Kevin
>> >
>> > kalpesh varyani wrote:
>> >> Hi Kevin,
>> >>
>> >> Thanks a lot.
>> >>
>> >> Please find the more details for the same.
>> >>
>> >> BIND version  : 9.3.6
>> >>
>> >> OS version : HP-UX 11.23
>> >>
>> >> I have look at the *socket.c* file and seen that "
>> >>
>> >> This error indicates that sendmsg(2) failed with EDESTADDREG ".
>> >>
>> >>
>> ----------------------------------------------------------------------------------------------------------
>> >>
>> >>
>> >>      cc = sendmsg(sock->fd, &msghdr, 0);
>> >>               send_errno = errno;
>> >>
>> >>
>> >>     /*
>> >>                          * The other error types depend on whether or
>> >> not the
>> >>                          * socket is UDP or TCP.  If it is UDP, some
>> >> error
>> >>                          * that we expect to be fatal under TCP are
>> merel
>> >>                          * annoying, and are really soft errors.
>> >>                          *
>> >>                          * However, these soft errors are still
>> >> returned as
>> >>                          * a status.
>> >>                          */
>> >>
>> >>                         isc_sockaddr_format(&dev->address, addrbuf,
>> >> sizeof(addrbuf));\
>> >>                         isc__strerror(send_errno, strbuf,
>> >> sizeof(strbuf));
>> >>                         UNEXPECTED_ERROR(__FILE__, __LINE__,
>> >> "internal_send: %s: %s",
>> >>                                                  addrbuf, strbuf);
>> >>                         dev->result = isc__errno2result(send_errno);\
>> >>                         return (DOIO_HARD);
>> >>
>> >>
>> --------------------------------------------------------------------------------------------------------------------
>> >>
>> >>
>> >>
>> >>
>> >> Note : This same is also seen on BIND-9.4.3-P3
>> >>
>> >> Regards
>> >> Kalpesh
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> On Tue, Aug 11, 2009 at 10:30 PM, Kevin Darcy <kcd at chrysler.com
>> >> <mailto:kcd at chrysler.com>> wrote:
>> >>
>> >>     "#53" designates *port* 53. Nothing unusual about that.
>> >>
>> >>     To me, this looks more like a kernel issue-- EDESTADDRREQ is what
>> >>     you get if you try to send data via a UDP socket that's not
>> >>     connect()ed. BIND keeps good track of what's connect()ed and what
>> >>     isn't; it's like the kernel is losing the association somehow.
>> >>
>> >>     Without knowing what OS this is running on, or what version of
>> >>     BIND, it's kind of hard to troubleshoot further than that.
>> >>
>> >>
>> >>            - Kevin
>> >>
>> >>     kalpesh varyani wrote:
>> >>
>> >>         thanks for your quick reply
>> >>          I am seen below error msg " once per 60sec" and no  seen any
>> >>         query failure.
>> >>          general: error: internal_send: 192.168.2.222#53: Destination
>> >>         address required
>> >>         general: error: /lib/isc/unix/errno2result.c:116: unexpected
>> >>         error:
>> >>          general: error: unable to convert errno to isc_result: 217:
>> >>         Destination address required
>> >>          general: error: /lib/isc/unix/socket.c:1533: unexpected error
>> >>         :
>> >>          general: error: internal_send: 192.168.2.222#53: Destination
>> >>         address required
>> >>          general: error: /isc/unix/errno2result.c:116: unexpected
>> >>         error:
>> >>         Regards
>> >>         Hiro Lalwani
>> >>
>> >>
>> >>          On Tue, Aug 11, 2009 at 10:14 PM, donovan jeffrey j
>> >>         <donovan at beth.k12.pa.us <mailto:donovan at beth.k12.pa.us>
>> >>         <mailto:donovan at beth.k12.pa.us
>> >>         <mailto:donovan at beth.k12.pa.us>>> wrote:
>> >>
>> >>
>> >>            On Aug 11, 2009, at 12:39 PM, kalpesh varyani wrote:
>> >>
>> >>                Hi,
>> >>                    I have below configuration.
>> >>                    DNS server1 -- Forwarder
>> >>                    DNS server2-- Authoritative
>> >>                    I am seeing following errors on server1.
>> >>                    ----------------------------
>> >>                general: error: internal_send: 192.168.2.222#53:
>> >>             Destination
>> >>                address required
>> >>                general: error: /lib/isc/unix/errno2result.c:116:
>> >>             unexpected
>> >>                error:
>> >>                 general: error: unable to convert errno to isc_result:
>> >>             217:
>> >>                Destination address required
>> >>                 general: error: /lib/isc/unix/socket.c:1533:
>> >>             unexpected error
>> >>                :
>> >>                 general: error: internal_send: 192.168.2.222#53:
>> >>             Destination
>> >>                address required
>> >>                 general: error: /isc/unix/errno2result.c:116:
>> unexpected
>> >>                error:
>> >>                    Could any of help me, to resolve this issue.
>> >>
>> >>
>> >>            sounds like a routing or firewall issue. Although from the
>> >>         limited
>> >>            post " #53 " doesn't look right.
>> >>
>> >>            -j
>> >>
>> >>
>> >>
>> >>
>> ------------------------------------------------------------------------
>> _______________________________________________
>> bind-users mailing list
>> bind-users at lists.isc.org
>>   https://lists.isc.org/mailman/listinfo/bind-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20090814/cada79f9/attachment.html>


More information about the bind-users mailing list