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 c...@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>!*
