[Enhancement] Add a property to configure Client/Master RMI hostname to prevent callback failures caused by VPN/Virtual fake IPs #6657

Relates to closed issue:#1830: JMeter server doesn't alert the user when the host is defined as a loopback address

1. Description of the Problem

While Issue #1830 successfully addressed the problem of the loopback address (127.0.0.1), modern networking environments (with VPNs, proxy software like Clash/Surge in TUN mode, Docker, and Virtual Machines) introduce a new, very common issue: Fake/Virtual IPs.

Currently, when starting a distributed test, the ClientJMeterEngine (Master/Controller) relies on InetAddress.getLocalHost() to determine its own IP address to embed into the RMI stub. However, getLocalHost() frequently picks up the highest-priority virtual network interface created by VPNs (resulting in fake IPs like 2.0.1.4 or 198.18.0.1).

The consequence:

1. The Master sends the test script along with this "fake IP" stub to the remote jmeter-server (Slave).
2. The Slave finishes the test and attempts to return the results to the Master by connecting to this fake IP.
3. The connection times out (java.rmi.ConnectException: Connection refused to host: 2.0.1.4; nested exception is: java.net.ConnectException: Operation timed out).
4. The Master never receives the test results, and the test hangs or fails silently on the client side.

2. Proposed Solution / Enhancement

Introduce a dedicated JMeter configuration property in jmeter.properties to explicitly define the callback IP for the Master/Client.

Example addition to jmeter.properties:

# Set the IP address or hostname for the Master to receive results from remote servers.
# If not set, JMeter will default to InetAddress.getLocalHost()
#client.rmi.hostname=192.168.1.50

Implementation Idea:
During the early initialization phase of JMeter (before ClientJMeterEngine starts the RMI registry/exports the object), JMeter could read client.rmi.hostname from jmeter.properties. If configured, JMeter explicitly sets the JVM system property programmatically:

3. Expected Benefit

This would greatly improve the user experience for distributed testing. Users would no longer need to battle with undocumented CLI arguments or disable their VPNs/virtual adapters just to run a remote JMeter test. All RMI configurations (ports and hosts) would be centralized within jmeter.properties.

Actual behavior

No response

Steps to reproduce the problem

can't not set current

JMeter Version

5.6.3

Java Version

No response

OS Version

No response