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, 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.
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
