qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tin Nguyen (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (QPIDJMS-261) Not possible to connect to IBM's IIB AMQP broker
Date Fri, 29 Sep 2017 00:19:00 GMT

    [ https://issues.apache.org/jira/browse/QPIDJMS-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16185153#comment-16185153

Tin Nguyen commented on QPIDJMS-261:

[~gemmellr] Sorry, didn't see your post earlier.

I did get a response from IBM, they created a hotfix for our server team to deploy. Below
is their response:

Below is the analysis from the MQ Java L3 Support team.  
A code defect has been identified and MQ L2 Support will raise an APAR.
If after reading the update from L3 Support you would like an interim fix, please inform us
of the following:
1. Other than MQV9.0.0.0 on Linux x86 64bit, do you require the interim fix for a Windows
2. Do you require the interim fix for MQV9.0.1 or V9.0.2?
3. Do you have any fixes applied to the MQV9.0.0.0 on Linux x86 64bit? MQV9.0.1 or MQV9.0.2?
 If so, please provide the fix names and/or APAR numbers.
Using our local recreate for the reported problem we have been
performing some analysis on the MQ Server "AMQP" component code and have
identified a product defect that will need to be addressed via an APAR.

After the development of the code fix the authorization issue which for
this PMR was originally raised for:

         "MQRC 2035 MQRC_NOT_AUTHORIZED [condition

We have encountered a secondary issue that is believed to be related to
the Qpid-JMS 0.20.0 client side and not IBM's AMQP implementation. The
issue lies in the way how the peers exchange AMQP OPEN frames.

Open Frame Exchange (Qpid-JMS 0.20.0)
At this point SASL has been done and the client has been authorized with
the Queue Manager.

The AMQP 1.0 spec states that each AMQP connection has to begin with an
exchange of the capabilities and limitation of the peers. This happens
in the following order:

   1. TCP connection established/accepted
   2. Protocol Header has been sent
   3. Each peer sends an OPEN frame (before any other frames)
   4. After receiving it's partners OPEN frame a peer must operate
within mutually acceptable limitations

The OPEN frame is the descriptor of the capabilities and limitation of
the peer that has sent the OPEN frame.

Please note, the AMQP spec does not state the order in which the OPEN
frames must be exchanged (server sends it first/client sends it first).

Section 2.4.1 states:

      "After establishing or accepting a TCP connection and sending the
protocol header, each peer MUST send an open frame before sending any
other frames."


This is where the secondary issue has been discovered. The new
implementation (Qpid-JMS 0.20.0) of the Qpid-JMS client hangs if IBM's
AMQP server sends the OPEN frame first.
Although the user was already authorized, the connection would not get
fully established thus causing the client to time-out. Diagnostics
(trace/WireShark capture) have shown that both peers (client/server)
exchange open frames and then end up waiting for each other, until the
client does not timeout with the following error message:

      "org.apache.qpid.jms.JmsOperationTimedOutException: Request to
open resource AmqpConnection { ID:80aa31d7-b06e-4beb-a64e-d3eb33672aaa:1
} timed out"

Seems like the Qpid-JMS 0.20.0 client completely ignores the OPEN frame
that was sent by the server first and sends a CLOSE frame at timeout.
The older version (Qpid-JMS 0.11.1) works fine, because this is the way
IBM AMQP server has been from the beginning.

Summary of observed behaviour
We managed to alter the behaviour of IBM's AMQP server to send the OPEN
frame only after the clients OPEN frame is received. This seemed to
resolve the issue. However, due to lack of information in the AMQP spec
we are not sure wether the new QPid-JMS client behaves as it should.

1. Qpid-JMS 0.11.0 connects if:
      ** The server sends the OPEN frame first.
      ** The client sends the OPEN frame first.

2. Qpid-JMS 0.20.0 connects only if:
     ** The client sends the OPEN Frame first

Plan of action
L3 will raise a ticket with Apache Support to address the secondary
issue that was detailed in this PMR previously.

I can provide an interim fix for the customer that addresses the
reported authorisation issue.  I suspect, even with an interim fix, the
customer would also experience the client timeout issue that I have
observed (detailed previously) with the Qpid-JMS 0.20.0 client version.

Furthermore, if the customer would like an interim fix after the APAR
has been raised, we would need to know whether it will be required for
Windows or Linux, the maintenance level ( ?) and whether other
interim fixes have been applied

> Not possible to connect to IBM's IIB AMQP broker
> ------------------------------------------------
>                 Key: QPIDJMS-261
>                 URL: https://issues.apache.org/jira/browse/QPIDJMS-261
>             Project: Qpid JMS
>          Issue Type: Bug
>          Components: qpid-jms-client
>    Affects Versions: 0.20.0
>         Environment: Java 1.8
>            Reporter: Tin Nguyen
>         Attachments: qpid.0.11.1.log, qpid.0.11.1.pcapng, qpid.0.20.0.log, qpid.0.20.0.pcapng
> With the latest 0.20 version I'm not able to connect to IBM's Integration Bus running
AMQP implementation (afaik it's just a rip off from qpid).
> Seems like something changed with the way qpid-jms handles SASL authentication? It's
working in 0.11.1 so I tried to look into the changes but there were quite a few.
> I don't have access to the IBM server but the admin told me that my client didn't get
> log output from the qpid client:
> 2348 [AmqpProvider:(1):[amqp://SERVER:5672/TOPIC]] INFO  o.a.q.j.s.SaslMechanismFinder
- Best match for SASL auth was: SASL-PLAIN
> 8120 [AmqpProvider:(1):[amqp://SERVER:5672/TOPIC]] WARN  o.a.q.j.p.a.b.AmqpResourceBuilder
- Open of resource:(JmsConnectionInfo { ID:9088d3b3-0cba-4fb4-bb87-207872077309:1, configuredURI
= amqp://SERVER:5672/TOPIC, connectedURI = null }) failed: AMQXR0041E: A connection was not
authorized for channel SYSTEM.DEF.AMQP received from MQRC 2035 MQRC_NOT_AUTHORIZED
[condition = amqp:unauthorized-access]
> 8121 [AmqpProvider:(1):[amqp://SERVER:5672/TOPIC]] INFO  o.a.q.j.p.a.AmqpProvider - Transport
failed: An existing connection was forcibly closed by the remote host
> Caught exception, exiting.
> javax.jms.JMSSecurityException: AMQXR0041E: A connection was not authorized for channel
SYSTEM.DEF.AMQP received from MQRC 2035 MQRC_NOT_AUTHORIZED [condition = amqp:unauthorized-access]
> LOGS on IBM server
> 01/17/2017 01:40:21 PM - Process(51975.7) User(mqm) Program(java)
>                     Host(SERVER) Installation(Installation1)
>                     VRMF( QMgr(UUFNLB1E)
> AMQ5534: User ID 'hadoop' authentication failed
> The user ID and password supplied by the 'AMQP' program could not be
> authenticated. 
> Additional information: 'N/A'.
> Ensure that the correct user ID and password are provided by the application.
> Ensure that the authentication repository is correctly configured. Look at
> previous error messages for any additional information.
> ----- amqzfuca.c : 4486 -------------------------------------------------------
> 01/17/2017 01:40:21 PM - Process(51975.7) User(mqm) Program(java)
>                     Host(SERVER) Installation(Installation1)
>                     VRMF( QMgr(UUFNLB1E)
> AMQ5542: The failed authentication check was caused by the queue manager
> The user ID 'hadoop' and its password were checked because the queue manager
> connection authority (CONNAUTH) configuration refers to an authentication
> information (AUTHINFO) object named 'SYSTEM.DEFAULT.AUTHINFO.IDPWOS' with
> This message accompanies a previous error to clarify the reason for the user ID
> and password check.
> Refer to the previous error for more information. 
> Ensure that a password is specified by the client application and that the
> password is correct for the user ID. The authentication configuration of the
> queue manager connection determines the user ID repository. For example, the
> local operating system user database or an LDAP server. 
> If the CHCKCLNT setting is OPTIONAL, the authentication check can be avoided by
> not passing a user ID across the channel. For example, by omitting the MQCSP
> structure from the client MQCONNX API call. 
> To avoid the authentication check, you can amend the authentication
> configuration of the queue manager connection, but you should generally not
> allow unauthenticated remote access.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@qpid.apache.org
For additional commands, e-mail: dev-help@qpid.apache.org

View raw message