qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Richardson ...@fourc.eu>
Subject Inter-broker link with SSL
Date Mon, 04 Aug 2014 12:22:28 GMT
Hi,

As you see from the subject I'm trying to set up an SSL link between two
brokers (version 0.28). To cut to the chase, both brokers are able to
communicate locally over SSL - for instance I can use

qpid-stat -b amqps://localhost:5671 -e
and
qpid-stat -b amqps://localhost:5674 -e

(these being my broker SSL ports) to retrieve lists of exchanges. This
works fine.

The problem comes when I attempt to add a route. To simplify, I'm just
trying to add just the link here with
qpid-route -t ssl link add localhost:5673 <hostname>:5671

Note that the destination is using a non-ssl port as per Gordon's
suggestion in this thread
http://qpid.2158936.n2.nabble.com/SSL-between-c-brokers-td7581914.html
and that <hostname> matches the "cn=" part of my ssl-cert's subject. Sadly
that thread related to version 0.14 and culminated in a bug fix related to
that version and did not continue along the same lines as my problem.

Following the addition of the link, the command
qpid-route link list localhost:5673
shows
Host            Port    Transport Durable  State             Last Error
=============================================================================
<hostname>       5671    ssl          N     Waiting           Closed by peer

and the source broker repeatedly reports
[System] error framing-error: Framing version unsupported (AMQPFrame.cpp:93)

I've done some digging into the state of the broker around this area of the
code, specifically in the AMQPFrame::decode method. It seems that the
framing version is derived from a flags byte and should always be zero, but
in this case has a value of 1. The byte stream being decoded is 134 bytes
long and begins (in hex)
 {41 4d 51 50 01 01 00 0a 0f 00 00 7e 00 00 00 00 00 00 00 00 01 01 07 00
00 00 00 3f 00 00 00 0 13 71 70 69 64 2e 66 65 64 65 ... ...}
This appears to be a decrypted version of the frame as it begins "AMQP, 1,
1, 0, 10..." which matches the specification exactly down to the class,
instance and protocol version of the message being received. However, the
flags byte from which the frame version is derived has a value of 41 ie.
appears to be incorrectly read from the "A" of "AMQP"... clearly something
has gone awry! Other packets arriving at the AMQPFrame::decode method
appear to have had the header already removed and begin { 0f ...} (assuming
those flags are set).

At this point I thought it may be time to hand over to someone with a
better understanding of the broker internals. Help... please? :)

/Chris

-- 

*Chris Richardson*, System Architect
cr@fourc.eu


*FourC AS, Vestre Rosten 81, Trekanten, NO-7075 Tiller, Norwaywww.fourc.eu
<http://www.fourc.eu/>*

*Follow us on LinkedIn <http://bit.ly/fourcli>, Facebook
<http://bit.ly/fourcfb>, Google+ <http://bit.ly/fourcgp> and Twitter
<http://bit.ly/fourctw>!*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message