[ 
https://issues.apache.org/jira/browse/PROTON-923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ken Giusti resolved PROTON-923.
-------------------------------
    Resolution: Fixed

Re-tested with 0.10 Beta1 and concur - the TRANSPORT_ERROR event is now 
properly posted.

> [SASL] PN_TRANSPORT_ERROR event not raised
> ------------------------------------------
>
>                 Key: PROTON-923
>                 URL: https://issues.apache.org/jira/browse/PROTON-923
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-c, python-binding
>    Affects Versions: 0.10
>            Reporter: Ken Giusti
>            Assignee: Andrew Stitcher
>            Priority: Blocker
>             Fix For: 0.10
>
>
> I have a pyngus test that exercises the case where the client and server do 
> not share compatible mechanisms.  The purpose of the test is to check pyngus 
> handling of this misconfiguration.
> At a high level, the SASL configuration is:
>             server_props = {'x-server': True,
>                             'x-sasl-mechs': 'PLAIN'}
>             client_props = {'x-server': False,
>                             'x-sasl-mechs': 'ANONYMOUS'}
> (these x- values are used to set the corresponding properties in proton's 
> connection and sasl objects)
> When this test executes, I do not get a PN_TRANSPORT_ERROR proton event on 
> the client side, although the outcome is set to indicate a failure occurred.
> Below is the debug output from the test.  C1 is the server connection, C2 is 
> the client.  Note that C1 gets the PN_TRANSPORT_EVENT failure, but C2 does 
> not:
> $ ./test-runner unit_tests.connection.APITest.test_sasl_callbacks
> unit_tests.connection.APITest.test_sasl_callbacks 
> ...........................................................................................
>  start
>   2015-06-26 10:03:15,292 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl 
> outcome: None)
>   2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl 
> outcome: None)
>   2015-06-26 10:03:15,293 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl 
> outcome: None)
> [0x26e5650]:sasl error: SASL(-1): generic failure: Client mechanism not in 
> mechanism inclusion list.
>   2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl 
> outcome: 1)
>   2015-06-26 10:03:15,294 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl 
> outcome: None)
>   2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c1 (sasl 
> outcome: 1)
>   2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_TAIL_CLOSED c1 
> (sasl outcome: 1)
>   2015-06-26 10:03:15,295 ERROR Connection TRANSPORT_ERROR: c1 (sasl outcome: 
> 1)
>   2015-06-26 10:03:15,295 DEBUG Connection failed: 
> Condition('amqp:connection:framing-error', 'connection aborted')
>   2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_HEAD_CLOSED c1 
> (sasl outcome: 1)
>   2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT_CLOSED c1 
> (sasl outcome: 1)
>   2015-06-26 10:03:15,295 DEBUG Connection EVENT: PN_TRANSPORT c2 (sasl 
> outcome: 1)
> unit_tests.connection.APITest.test_sasl_callbacks 
> ...........................................................................................
>  fail
> I suspect the PN_TRANSPORT_FAILURE event that is posted is not coming from 
> the SASL failure itself, but rather from a framing error occuring on the 
> server (which in itself is suspect, but that's a matter for a different JIRA)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to