Fix search response port preservation for name-server (gateway) replies#3781
Merged
kasemir merged 1 commit intoControlSystemStudio:masterfrom Apr 15, 2026
Merged
Conversation
|
kasemir
approved these changes
Apr 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When a name server / gateway returns a search response containing
0.0.0.0:port, theSearchResponseHandler(TCP path) replaced both the IP address and the port with the remote address of the TCP connection. This correctly resolved the wildcard IP, but silently discarded the server's advertised port.In a gateway scenario where the name server listens on port 5175 (plain PVA) but the actual data server listens on TLS port 5075, the response arrived with
0.0.0.0:5075. After the replacement, the client connected to port 5175 (the name server's port) instead of 5075 (the data server's TLS port), causing the connection to fail or land on the wrong service.The UDP handler already handled this case correctly by only replacing the IP when the address is a wildcard, leaving the port untouched.
Fix
Align the TCP search response handler with the UDP handler: when the response address is a wildcard (
0.0.0.0/::), substitute only the IP portion from the remote connection address; preserve the port from the search response.Files Changed
core/pva/src/main/java/org/epics/pva/client/SearchResponseHandler.java