Bug 56352 - tomcat-connectors-1.2.39-windows-x86_64-iis does not resolve workers DNS names
tomcat-connectors-1.2.39-windows-x86_64-iis does not resolve workers DNS names
Status: RESOLVED FIXED
Product: Tomcat Connectors
Classification: Unclassified
Component: isapi
1.2.39
PC All
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2014-04-05 14:21 UTC by Konstantin Kolinko
Modified: 2014-04-15 13:12 UTC (History)
1 user (show)



Attachments
2014-04-05_jk_56352_jkresolve_v1.patch (1.36 KB, patch)
2014-04-05 14:27 UTC, Konstantin Kolinko
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Konstantin Kolinko 2014-04-05 14:21:57 UTC
Following the "tomcat-connectors-1.2.39-windows-x86_64-iis does not work" thread on users list, from April 2rd

http://marc.info/?t=139644507500004&r=1&w=2
http://tomcat.markmail.org/message/sb7vbobngdqig5v6

It boils down to the following:
The following works:

> worker.ajp13w.host=127.0.0.1

The following does not work:

> worker.ajp13w.host=localhost

and connector tries to connect to 0.0.0.0:
jk_open_socket::jk_connect.c (735): connect to 0.0.0.0:8009 failed (errno=49)

------------
Looking at svn history, I see that implementation of method jk_resolve() was changed in r1529803 for the case when APR library is not available.

Reviewing the code of jk_resolve() in jk_connect.c, I see the following issue:
line 484
[[[
 freeaddrinfo(ai_list);
 ...
 memcpy(&(saddr->sa), ai->ai_addr, ai->ai_addrlen);
]]]

The "ai" variable is a pointer to the chosen item in "ai_list" linked list of addresses returned by getaddrinfo(). The bug is that freeaddrinfo(ai_list) is called too early, before the information is copied away.


Also, the following on lines 436-441:
[[[
#if JK_HAVE_IPV6
        if (prefer_ipv6)
            hints.ai_family = JK_INET6;
        else
#endif
            hints.ai_family = JK_INET;
]]]
As "hints" is a structure that is passed to getaddrinfo() method, I would expect those assignments to use AF_INET, AF_INET6. I suspect that this is non-issue, as those defines should be defined as equal to AF_xx constants anyway, but other code later uses AF_xx constants, so I expect the AF_xx ones to be used here as well.
("if (ai->ai_family == AF_INET6)")
Comment 1 Konstantin Kolinko 2014-04-05 14:27:41 UTC
Created attachment 31484 [details]
2014-04-05_jk_56352_jkresolve_v1.patch

Patch for the issue (not tested).
Comment 2 Mladen Turk 2014-04-07 11:03:24 UTC
The patch does nothing. JK_INET6 is defined as AF_INET6
The only thing that can be is the location of freeaddrinfo(ai_list);
It's a clear bug.
Comment 3 Mladen Turk 2014-04-07 11:50:37 UTC
The reason is probably in the missing
127.0.0.1 localhost
entry in the host file. Since the resolve code is now a copy from APR, the same behaviour exists with HTTPD for example.

However there is still a bug with freeaddrinfo, so this could cause more serious problems.
Comment 4 Konstantin Kolinko 2014-04-08 11:08:58 UTC
(In reply to Mladen Turk from comment #2)
> The patch does nothing. JK_INET6 is defined as AF_INET6

OK. Good to know. I am just saying that it looks odd.

> The only thing that can be is the location of freeaddrinfo(ai_list);
> It's a clear bug.

Thank you for fixing.

(In reply to Mladen Turk from comment #3)
> The reason is probably in the missing
> 127.0.0.1 localhost
> entry in the host file. Since the resolve code is now a copy from APR, the
> same behaviour exists with HTTPD for example.

If it fails to resolve the host name, I would expect some different behaviour rather than an attempt to connect to 0.0.0.0.

(Just for a record: Apparently, adding such entry did not help
http://markmail.org/message/pgzhzuwozcvxzab7
Comment 5 Jessica-Aileen Alten 2014-04-15 13:10:02 UTC
The problem seems to be solved with the new 1.2.40 release!
Comment 6 Konstantin Kolinko 2014-04-15 13:12:15 UTC
Thanks for confirming. Closing.