Bug 671228

Summary: Ability to specify IP and port client should use when connecting to a broker
Product: Red Hat Enterprise MRG Reporter: Andy Goldstein <agoldste>
Component: qpid-cppAssignee: mick <mgoulish>
Status: NEW --- QA Contact: MRG Quality Engineering <mrgqe-bugs>
Severity: unspecified Docs Contact:
Priority: low    
Version: 1.3CC: gsim, jross
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 698367    

Description Andy Goldstein 2011-01-20 19:14:20 UTC 
It would be helpful if we could specify the local IP and port that a client uses when connecting to a broker.  For example, if my client machine has the IPs 192.168.0.1 and 10.0.0.1, I would like to be able to choose which IP and specify a particular port to use, e.g. 192.168.0.1 port 9999 or 10.0.0.1 port 7777.  There could potentially be options that could be given to the Connection such as localInterface and localPort to accomplish this.  If localInterface is not given, continue to function as currently implemented.  If localPort is not given, continue to function as currently implemented.
Comment 1 Gordon Sim 2011-01-24 09:10:46 UTC 
Can you describe the usecase for this enhancement?
Comment 2 Andy Goldstein 2011-01-24 12:58:42 UTC 
Our QA team needs to be able to block access to a particular client at the TCP/IP level (to simulate a connection loss by the client).  The easiest way we could think of to do this was to know the client's local port and eventually block it.
Comment 3 Gordon Sim 2011-01-27 18:01:46 UTC 
As a workaround, are you able to turn on logging of the client's allocated port and then use that to block access?
Comment 4 Andy Goldstein 2011-01-27 19:04:58 UTC 
That really wouldn't work for our QA efforts.  We need to know the port that will be used prior to any connection attempt, so as to be able to control whether or not the connection attempt will be successful.  Also, in order for the workaround suggested to be viable, the port the client uses upon reconnects would need to be the same port all the time.