On 19/02/2019 17:24, Stefan Huehner wrote:
Thanks for the well written email that clearly describes the problem you
are seeing.
> 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.
Note that that behaviour may not be consistent between different
systems. You might want to consider using an IP address rather than a
host name there.
> 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.
Yes, that might explain it. There are also some additional variations
with JVM options for NIO/NIO2 and configuration when using APR/native.
> - 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.
That change looks to be consistent with the intent of prefer_ipv6 to me.
> I can produce a clean patch if what i found out so far makes sense to you.
Yes please. Please open a Bugzilla issue and attach the patch there.
That will ensure the issue is not forgotten.
> 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
ACK. The content of /etc/hosts is where I would have looked first.
> - 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.
Odd. I don't see anything in the JK code that might cause that. Maybe
something in the APR code? Personally, if the above patch fixes it
consistently I don't think this is a question I spent too much time
trying to get to the bottom of.
Thanks,
Mark
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
