+++ This bug was initially created as a clone of Bug #1113194 +++ +++ This bug was initially created as a clone of Bug #1109873 +++ Description of problem: "qpid-stat" tool with "-c" option does not show a name of connected client from Windows machine. Try to compare, please: When the drain client is connected to the broker from a Linux machine, the name of the client is displayed correctly: # qpid-stat -c Connections connection cproc cpid mech auth connected idle msgIn msgOut ============================================================================================================== qpid.10.34.33.251:5672-10.34.33.199:57589 drain 3735 anonymous 2s 0s 0 0 qpid.[::1]:5672-[::1]:60305 qpid-stat 11814 anonymous 0s 0s 1 0 ------------------------------------------------------------------------------- However if the drain client is connected from a Windows machine,the "cproc" column is empty: # qpid-stat -c Connections connection cproc cpid mech auth connected idle msgIn msgOut ============================================================================================================= qpid.10.34.33.251:5672-10.34.74.82:57245 1456 1s 0s 0 0 qpid.[::1]:5672-[::1]:60306 qpid-stat 11843 anonymous 0s 0s 1 0 Version-Release number of selected component (if applicable): qpid-tools-0.22-13.el6.noarch How reproducible: 100% Steps to Reproduce: 1. Unpack and compile qpid-cpp-win packages 2. Start a broker 3. Connect "drain" client from the Windows machine to the broker with a large timeout: drain.exe --broker <hostname>:5672 --timeout 120 amq.topic 4. Run "qpid-stat -c" while the "drain" is connected Actual results: Connection opened by the drain client is displayed without a name of the process. Expected results: Connection opened by the drain client should be displayed with the name of the process. --- Additional comment from Irina Boverman on 2014-06-25 10:51:24 EDT --- --- Additional comment from Irina Boverman on 2014-06-25 11:21:13 EDT --- How to test changes: (1) Change broker config file to this: auth=no (2) Start broker on localhost service qpidd start (3) Use spout to send messages (RHEL): spout -b localhost test0 (4) Use drain (Windows and RHEL): (a) RHEL: drain -b localhost --timeout 120 amq.topic (b) Windows: $ alias rdp='rdesktop -u mrg -g 1024x800 mrg-win-1.ml3.eng.bos.redhat.com' $ rdp User mrg (usual team root password), and a screen geometry that works for you if 1600x1024 doesn't fit. Open up a dos box command prompt. Drain is located at D:\Users\mrg\winsdk\qpid-cpp-x86-VS2010-3.22.41.1\bin\Debug Details (per Chuck's instructions): C:\> C:\>d: D:\>cd Users\mrg\winsdk\qpid-cpp-x86-VS2010-3.22.41.1\bin\debug D:\Users\mrg\winsdk\qpid-cpp-x86-VS2010-3.22.41.1\bin\Debug>drain -b <broker> --timeout 120 amq.topic (5) # qpid-stat -c Result after changes: Connections connection cproc cpid mech auth connected idle msgIn msgOut =================================================================================================================== qpid.10.16.44.229:5672-10.19.176.108:60550 unknown 2320 unknown unknown 1m 2s 1m 1s 0 0 qpid.[::1]:5672-[::1]:37979 drain 27240 unknown anonymous 16s 13s 0 0 qpid.[::1]:5672-[::1]:37981 qpid-stat 27253 unknown anonymous 0s 0s 1 0 There are also bugs in Windows client not passing "cproc" and "auth" fields to the broker, and in both Windows/Linux code not passing "mech" field to the broker.
They do, unless auth=no. The description isn't very helpful here, since all the detaul refers to a different issue.
Lowering severity, since with auth=no only two mechanisms are supported - ANONYMOUS and PLAIN - and you can easily deduce which is in use from the authIdentity. With auth=yes, the mechanism is reported.
Fixed upstream by https://svn.apache.org/r1605511
"qpid-stat" tool shows authentication mechanism used for connection of clients connected from Linux in the "mech" column. Verified on Rhel 6.6-i686 and x86_64 on packages qpid-cpp-0.30-6. --> VERIFIED
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0805.html