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