Bug 999505 - [AMQP 1.0] qpidd's SASL support does not correctly deal with fully asynchronous interaction
[AMQP 1.0] qpidd's SASL support does not correctly deal with fully asynchrono...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp (Show other bugs)
Development
Unspecified Unspecified
medium Severity unspecified
: 3.0
: ---
Assigned To: Gordon Sim
Ernie
Ernie
: OtherQA
Depends On:
Blocks: 1010399
  Show dependency treegraph
 
Reported: 2013-08-21 08:39 EDT by Gordon Sim
Modified: 2015-01-21 07:55 EST (History)
5 users (show)

See Also:
Fixed In Version: qpid-cpp-0.22-12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-21 07:55:43 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Apache JIRA QPID-5077 None None None Never

  None (edit)
Description Gordon Sim 2013-08-21 08:39:32 EDT
Description of problem:

The SASL implementation in qpidd expects the peer to wait for a SASL-INIT before it sends the SASL_OUTCOME, which isn't necessarily the case.

Version-Release number of selected component (if applicable):

qpid 0.22

How reproducible:

100%, but a little bit involved and requires components outside of product set.

Steps to Reproduce:
1. Start recv example from proton listening on a given port
2. have a qpidd instance connect to that, e.g:
   2a: qpidt create domain other url=<host>:<port> sasl_mechanisms=ANONYMOUS (where <host> and <port> are as used in 1.)
   2b: qpidt create outgoing domain=other source=blah target=amq.fanout
3. send message to amq.fanout

Alternatively use dispatch-router instead of recv in step 1, change outgoing to incoming in step 2b, and in step 3 send a message to dispacth-router with the to filed set to amq.fanout (-P x-amqp-to=amq.fanout for spout or qpid-send). In this case message should then be received by a drain on amq.fanout (established before the message is sent).

Actual results:

The link in 2 is not established and message is not received/

Expected results:

Link is established and message is received.

Additional info:

Though this does not affect product it would be nice for the productised version of the AMQP support to be more widely interoperable with newer component such as proton messenger and dispatch-router.
Comment 1 Gordon Sim 2013-08-21 08:40:18 EDT
Fixed upstream: https://svn.apache.org/r1514465
Comment 2 Ernie 2014-04-02 15:50:41 EDT
Verified RHEL 6.5 32 and 64 bit
with packages from qpid-cpp-0.22-36

qpidt is no longer available, but the functionallity is build into qpid-config

reproducer commands using qpid-config are:
- start c++ broker on port 5672
- qpid-config add queue q
- recv amqp://0.0.0.0:5672/q

in another window
- qpid-config add domain other --argument url=0.0.0.0:5672 --sasl-mechanism=ANONYMOUS
- qpid-config add incoming link --argument domain=other --argument target=q --argument source=q
- spout --content "Passed" q

recv in original window should receive the message

Note You need to log in before you can comment on or make changes to this bug.