Re: SASL / proton-c questions
Hi, Messenger will simply use anonymous if you don't specify a username and password, e.g. amqp://broker/node will result in the client forcing ANONYMOUS. If you do specify a username and password, e.g. amqp://user:pass@broker/node, then messenger will force PLAIN. There is no way to disable SASL entirely. If you're interested in stronger security than PLAIN offers, your best bet is probably to use SSL with client side certificates. --Rafael On Tue, Jan 14, 2014 at 9:05 AM, Andreas Mueller a...@iit.de wrote: Hi, I've looked through the proton-c Messenger API docs but can't find it. Can someone please tell me: 1) How to disable SASL at all to start direct with AMQP? 2) How to force a specific SASL mechanism like PLAIN? Thanks, Andreas -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912
Re: SASL / proton-c questions
Disabling SASL should be an option in proton to connect to simple services that do not provide SASL or just to skip this additional step if SASL is not requires. The other problem was already reported from Sergey. I receive a SASL protocol header and a SASL Init message with mechanism PLAIN from proton. [ProtocolHeader, name=AMQP, id=3, major=1, minor=0, revision=0] [SaslInit mechanism=PLAIN, initialResponse=006775657374006775657374] Then occasionally this error is thrown: ./send -a amqp://guest:guest@127.0.0.1:5672/testqueue Test [0xbe1030:0] ERROR[-2] SASL header mismatch: '\x00\x00\x00\x17\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00D\xc0\x03\x01P\x00AMQP\x03\x01\x00\x00\x00\x00\x00=\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00@\xc0)\x01\xe0\x04\xa3\x05PLAIN\x09ANONYMOUS\x0aDIGEST-MD5\x08CRAM-MD5' My first thought was that this might be caused by using an unsupported mechanisnm but this is not the case as PLAIN is used. I'm getting this with ANONYMOUS too. -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com Am 14.01.2014 um 15:24 schrieb Rafael Schloming r...@alum.mit.edu: Hi, Messenger will simply use anonymous if you don't specify a username and password, e.g. amqp://broker/node will result in the client forcing ANONYMOUS. If you do specify a username and password, e.g. amqp://user:pass@broker/node, then messenger will force PLAIN. There is no way to disable SASL entirely. If you're interested in stronger security than PLAIN offers, your best bet is probably to use SSL with client side certificates. --Rafael On Tue, Jan 14, 2014 at 9:05 AM, Andreas Mueller a...@iit.de wrote: Hi, I've looked through the proton-c Messenger API docs but can't find it. Can someone please tell me: 1) How to disable SASL at all to start direct with AMQP? 2) How to force a specific SASL mechanism like PLAIN? Thanks, Andreas -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912 IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912
Re: [VOTE]: Release Proton 0.6 RC3 as 0.6 final
Adding my +1 for the record. --Rafael On Thu, Jan 2, 2014 at 2:17 PM, Rafael Schloming r...@alum.mit.edu wrote: Hi Everyone, It looks like there haven't been any major issues reported so far with 0.6 RC3, so I guess it's about time to call for a formal vote. Source is here: http://people.apache.org/~rhs/qpid-proton-0.6rc3/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-003/ Please peruse/test and register your vote: [ ] Yes, release 0.6 RC3 as 0.6 final [ ] No, 0.6 RC3 has the following issues... --Rafael
[RESULT] [VOTE]: Release Proton 0.6 RC3 as 0.6 final
The vote carries with 3 binding +1's, 2 non-binding +1's, and no other votes. I'll post the artifacts shortly. --Rafael On Thu, Jan 2, 2014 at 2:17 PM, Rafael Schloming r...@alum.mit.edu wrote: Hi Everyone, It looks like there haven't been any major issues reported so far with 0.6 RC3, so I guess it's about time to call for a formal vote. Source is here: http://people.apache.org/~rhs/qpid-proton-0.6rc3/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-003/ Please peruse/test and register your vote: [ ] Yes, release 0.6 RC3 as 0.6 final [ ] No, 0.6 RC3 has the following issues... --Rafael
Re: SASL / proton-c questions
Am 14.01.2014 um 16:00 schrieb Rafael Schloming r...@alum.mit.edu: The SASL header looks to start where you see the sequence ...AMQP\x03\x01 This either means that proton's internal buffers are getting messed up somehow, or there actually is garbage on the wire. Just checked with iAmqpDecode. It seems the SASL outcome message outruns the protocol header! ;-) That's a bug on my side! Threading issue ... -- Andreas Mueller IIT Software GmbH, Bremen/Germany http://www.swiftmq.com IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912
Re: SASL / proton-c questions
Andreas, are you planning to fix the bug in the future version? Thanks, Sergejs. -- View this message in context: http://qpid.2158936.n2.nabble.com/SASL-proton-c-questions-tp7602690p7602711.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: SASL / proton-c questions
Yes, very soon. Andreas Am 14.01.2014 um 18:34 schrieb serega sergejs.melde...@sap.com: Andreas, are you planning to fix the bug in the future version? Thanks, Sergejs. -- View this message in context: http://qpid.2158936.n2.nabble.com/SASL-proton-c-questions-tp7602690p7602711.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com. IIT Software GmbH Fahrenheitstr. 13, D28359 Bremen, Germany Tel: +49 421 330 46 088, Fax: +49 421 330 46 090 Amtsgericht Bremen, HRB 18624, Geschaeftsfuehrer: Andreas Mueller Steuernummer: 460/118/06404 VAT: DE199945912
Re: Getting -9 when setting blocking to 0 in Perl
On Thu, Jan 09, 2014 at 04:06:38PM -0500, Darryl L. Pierce wrote: On Thu, Jan 09, 2014 at 03:19:52PM -0500, Rafael Schloming wrote: In the case of the C API getting a PN_INPROGRESS error (-9) from recv is expected behaviour if you're in non blocking mode. That just means that there is blocking work that was deferred. Okay, that explains why it didn't start working until bool was properly translated to/from Perl. Now, another issue that's cropped up with the Perl work is that, if pn_messenger_work is called with -1 then Perl never gets a message unless I explicitly kill the sender (I'm using the Python send_async script to interact with the recv_async.pl Perl script). If I set work to timeout then it times out but only gets the late (the die) message. This morning Ted asked whether Perl uses pthreads or not. The Perl binary links against libpthread.so.0 on Linux, so I assume it's using them. I've tried spawning the actual asynchronous process on its own separate thread and still no joy: the call to work(-1) never returns even when messages are prending. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpv9bWQfR1eG.pgp Description: PGP signature
Re: pn_messenger_send return code
It looks like the actual issue has been identified on another thread, but
while this is here...I noticed that the mechanisms are in a different order
between the two snippets below, however the 1.0 spec indicates they are to
be ordered in decreasing level of preference which I would expect to make
it repeatable.
Robbie
On 12 January 2014 03:34, serega sergejs.melde...@sap.com wrote:
I didn't insert the line in the code as was suggested by Rafael
pn_messenger_set_outgoing_window(messenger, N);
With that change I get PN_STATUS_ABORTED = 6 when the link is broken.
I do have another problem though. I get the following errors sometimes..
./send -a amqp://guest:guest@127.0.0.1:5672/testqueue
[0x7fdf48700a10]:ERROR[-2] SASL header mismatch:
'\x00\x00\x00\x17\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00D\xc0\x03\x01P\x00AMQP\x03\x01\x00\x00\x00\x00\x00B\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00@
\xc0.\x01\xe0+\x05\xa3\x04NTLM\x05PLAIN\x09ANONYMOUS\x0aDIGEST-MD5\x08CRAM-MD5'
sergey:Debug sergey$ for i in {1..5000} ; do ./send -a
amqp://guest:guest@127.0.0.1:5672/testqueue; done
[0x7fb0c1406670]:ERROR[-2] SASL header mismatch:
'\x00\x00\x00\x17\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00D\xc0\x03\x01P\x00AMQP\x03\x01\x00\x00\x00\x00\x00B\x02\x01\x00\x00\x00\x80\x00\x00\x00\x00\x00\x00\x00@
\xc0.\x01\xe0+\x05\xa3\x0aDIGEST-MD5\x08CRAM-MD5\x04NTLM\x05PLAIN\x09ANONYMOUS'
The client simply hangs after reporting this error. I stepped in debugger
and found that the call doesn't return from pn_driver_wait().
--
View this message in context:
http://qpid.2158936.n2.nabble.com/pn-messenger-send-return-code-tp7602570p7602616.html
Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
