Hello tomcat developers,
we noticed some wrong behavior (as i understand) it with the ipv6 support
inside mod_jk when connecting to tomcat ajp connector.
Sending to -dev list as i debugged mod_jk sources and i think the logic added
for the prefer_ipv6 option does not work in one case, as i have prototype patch.
I mentioned regression (?) in the subject as us updating from very old 1.2.37
mod_jk version (shipped in Ubuntu 14.04) are running into unpredictable
behavior and the prefer_iv6 not working in our case.
In short we see 2 behaviors both when defining host in JKWorkersFile as
"localhost"
1.) In one machine type 100% of the cases mod_jk resolves the name to ::1
instead of 127.0.0.1 ignoring the prefer_ipv6 default value of 0
2.) In 2nd machine type we see unpredictable behavior with it sometimes
resolving to ::1 and other times to 127.0.0.1
Details on our setup:
- Ubuntu 18.04 LTS
- tomcat 8.5.30-1ubuntu1.4 (From ubuntu 18.04 packaging)
- OpenJDK 10
- Tocat conf/server.xml defining Connector as follow:
<Connector address="localhost" port="8009" protocol="AJP/1.3"
redirectPort="8443" />
That has effect of tomcat only listening on 127.0.0.1 and not on ::1 at the
same time.
That is maybe why issue is hidden for most users as having connector without
address restriction make it listen on 8009 port on both ip's.
- mod_jk version 1.2.43-1 (frmo ubuntu 18.04 packaging)
with worker defined as:
worker.ajp13_worker.port=8009
worker.ajp13_worker.host=localhost
worker.ajp13_worker.type=ajp13
Looking at native/common/jk_connect.c jk_resolve method on how that prefer_ipv6
which in our case has no effect works seems like:
- call to apr_sockaddr_info_get is expected to sometimes return multiple ip's
(i.e. for hostname 'localhost')
- logic inside jk_resolve implements the preference for ipv4/ipv6 selecting one
of the values
Debugging our our machine (1.( above) shows the apr call to always only return
a single value ::1 already. So prefer_ipv6 has nothing to choose from.
Checking apr header for that apr_sockaddr_info_get shows it being called with
family=APR_UNSPEC
* @param family The address family to use, or APR_UNSPEC if the system should
* decide.
However that function has extra optional flags argument (not used by mod_jk) to
submit ipv4/ipv6 preference to mod_jk:
* @param flags Special processing flags:
* <PRE>
* APR_IPV4_ADDR_OK first query for IPv4 addresses; only look
* for IPv6 addresses if the first query failed;
* only valid if family is APR_UNSPEC and
hostname
* isn't NULL; mutually exclusive with
* APR_IPV6_ADDR_OK
* APR_IPV6_ADDR_OK first query for IPv6 addresses; only look
* for IPv4 addresses if the first query failed;
* only valid if family is APR_UNSPEC and
hostname
* isn't NULL and APR_HAVE_IPV6; mutually
exclusive
* with APR_IPV4_ADDR_OK
* </PRE>
Small patch to pass down prefer_ipv6 value to that flags argument fixes the
problem for me as then the apr-call returns still single ip-address entry but
matching the preference.
As values of prefer_ivp6. Small code needed to translate values to match apr
expectation.
if (prefer_ipv6) {
flags = APR_IPV6_ADDR_OK;
} else {
flags = APR_IPV4_ADDR_OK;
}
That is my first dive to mod_jk/apr sourcecode. So while that small change
seems to fix our wrong behavior not sure about side-effects.
I can produce a clean patch if what i found out so far makes sense to you.
Open questions:
- When exactly that api-call returns ipv4/ipv6 values
- For that case 1.) known difference between working/failing environment is
/etc/hosts content
working when only single entry with 127.0.0.1 for 'localhost'
Failing with 2 entries for the name for both 127.0.0.1 and also ::1
- However that case 2: Randomly failing has is happening inside same system
without and config changes but by restarting Apache several times being enough
to trigger it.
For any missing/unclear details please just let me know. I am also around in
#tomcat for any direct questions.
That case 1. ) 100% failing is custom Ubuntu installer CD which shows the issue
when used i.e. inside Virtualbox. I can share ISO-image or image where issue
can be seen if that is helpful.
Thanks,
Stefan Huehner
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
