Mark,
On 11/10/25 10:08 AM, Mark Thomas wrote:
On 10/11/2025 15:01, Christopher Schultz wrote:
Mark,
On 11/10/25 9:48 AM, Mark Thomas wrote:
On 10/11/2025 14:15, Christopher Schultz wrote:
All,
I've been looking into this, and I think the problem is that all of
the link-local interfaces detected during this test are not actually
routable:
fe80:0:0:0:2609:93a5:c4ac:15ea%utun7
fe80:0:0:0:926b:f264:7ec7:283e%utun6
fe80:0:0:0:4ab0:1734:75f8:c236%utun5
fe80:0:0:0:edc2:bbe0:ab0e:db71%utun4
fe80:0:0:0:898:f4ff:feb6:6b87%llw0
fe80:0:0:0:898:f4ff:feb6:6b87%awdl0
fe80:0:0:0:ce81:b1c:bd2c:69e%utun3
fe80:0:0:0:96b7:f229:b97f:3887%utun2
fe80:0:0:0:c055:a248:e218:ba6b%utun1
fe80:0:0:0:310c:b555:9669:572a%utun0
So even though Tomcat can bind to them, and you can create a URL to
try to connect, the OS will never route the packets as expected.
When checking all available interfaces on my machine, they all seem
to be IPv6 and all seem to be .. unusable to Tomcat?
If I hard-code the interface "fe80::1%lo0" into the unit test, it
passes immediately and successfully. But when left to its own
devices, the test will randomly pick one of the other interfaces and
hang.
I think the testing environment is being sandboxed by the OS and so
it doesn't even see those other interfaces that I know exist.
Instead, I only see these useless tunneling interfaces. For example,
"lo0" doesn't show up, and "en0" doesn't show up -- the primary
useful interfaces on this machine.
So I wonder if we need some kind of workaround for MacOS.
I think we need a more general work-around. Seeing a number of those
were tunnels reminded me of the change we made to the unlock accept
code to skip point to point interfaces.
Something like:
diff --git a/test/org/apache/catalina/startup/
TestStartupIPv6Connectors.java b/test/org/apache/catalina/startup/
TestStartupIPv6Connectors.java
index c3c4b9a..2212e39 100644
--- a/test/org/apache/catalina/startup/TestStartupIPv6Connectors.java
+++ b/test/org/apache/catalina/startup/TestStartupIPv6Connectors.java
@@ -68,6 +68,9 @@
while (interfaces.hasMoreElements()) {
NetworkInterface interf = interfaces.nextElement();
Enumeration<InetAddress> addresses =
interf.getInetAddresses();
+ if (interf.isPointToPoint()) {
+ continue;
+ }
while (addresses.hasMoreElements()) {
InetAddress address = addresses.nextElement();
if (address instanceof Inet6Address inet6Address) {
+1
This is one of the patches I had considered, but when I started adding
debug code to print stuff out, I had a in it and it wasn't printing
the %en interface (which would work) so I thought it would always fail.
I've fixed it and I think we basically have the same patch at this point.
But it still doesn't work for me, since %lo0 doesn't appear in the
list. %en0 not does appear
This should have been "%en0 DOES appear..."
, but it's not link-local and so it doesn't
get chosen for this. Instead, the test chooses the %awdl0 interface
which is equally as useless for this test.
What is that interface? Is there some characteristic we can use to
filter it out as well? If the test can't find any interfaces, it will
skip the test.
I think awdl0 has something to do with AirPlay.
ChatGPT says that I need to allow Java more privileges -- like "Full
Disk Access" in order to get access to the various real network
interfaces. I was hoping for a solution that didn't require that
because while it will work for me, it won't likely work for anyone
else who just happens to want to run the unit tests.
We might have to implement an allow-list, block-list, etc.
Yuck. I'd much prefer a general solution if we can find one.
I spent some time chatting with AI and it didn't have any better ideas
other than a combination allow-list + deny-list to skip known-bad
interfaces (like %utun*) and include known-good interfaces (like %lo*
and %en*).
I would also very much like to find a better solution.
If I run the test with your patch, the test is skipped. Which is good, I
suppose. But it means the test isn't being run. I will give more
permissions to the JVM and see if it can see all interfaces and,
therefore, allow this test to run.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
