Feature request: fixed, non-random trace port for firewall rule

[eostermueller]

#18 (comment)

At the above link, mchr3k gives a good description of the two TCP connections in InTrace.
The 2nd port, the "trace" port, is opened on a random port on the "agent."

In one of our environments, we need to add a firewall rule so the InTrace client can access the trace port.
But we can't do it because a different port is randomly selected on each restart of the agent's JVM.

--Erik

[mchr3k]

This issue has a slightly tricky interaction with multi user cases. I will give this some thought and try to fix this soon.

[eostermueller]

I added this to my agent parameters and it didn't help:
[callbackport-9124

I've got a tcpdump .pcap trace, but don't see any way to upload it to this issue. Any support for attachments anywhere?

--Erik

[eostermueller]

Thanks for the upgraded error message on this.
Below is the latest error.
Instead of 44415, I was hoping to get 9124, because of my agent parameter [callbackport-9124

*** Failed to setup network trace: java.net.ConnectException: Connection timed out: connect
Remote address: myhost/my-ip
Remote port: 44415
*** Latest Settings Received

[mchr3k]

[callbackport causes the Agent to make a reverse Control connection - the Agent connects to a listening port opened by the Client. The Trace connection is then set up normally using a random port.

This callback is used by the Eclipse plugin which launches the program which it wants to trace. The callback allows the plugin to connect to the Agent as soon as the Agent is ready.

[eostermueller]

On my own local copy, I was able to get by this:
I changed the following on about line 97 in AgentHelper.java:

      //networkSocket = new ServerSocket(0);
  networkSocket = new ServerSocket(9124);  //hard coded temporary fix/workaround.