[jira] [Commented] (PROTON-1998) [Proton-J] Add SASL protocol trace
[
https://issues.apache.org/jira/browse/PROTON-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763974#comment-16763974
]
ASF GitHub Bot commented on PROTON-1998:
gemmellr commented on issue #30: PROTON-1998: Add SASL protocol trace
URL: https://github.com/apache/qpid-proton-j/pull/30#issuecomment-461987694
I'm not seeing the updates, did you push it?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [Proton-J] Add SASL protocol trace
> --
>
> Key: PROTON-1998
> URL: https://issues.apache.org/jira/browse/PROTON-1998
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Reporter: Keith Wall
>Priority: Minor
>
> Unlike Proton, Proton-J does not provide SASL frame trace if environment
> variable PN_TRACE_FRM is set. It would be useful if Proton-J had this
> ability too to help diagnose SASL negotiation problem.
> Proton's SASL frame trace looks like this:
> {code:java}
> [0x7fc112c03a00]: -> SASL
> [0x7fc112c03a00]: <- SASL
> [0x7fc112c03a00]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x7fc112c03a00]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"guest@Oslo.local"]
> [0x7fc112c03a00]:0 <- @sasl-outcome(68) [code=0]
> [0x7fc112c03a00]: -> AMQP
> [0x7fc112c03a00]:0 -> @open(16)
> [container-id="be777c26-af6e-4935-a6be-316cc8bbdb35", hostname="127.0.0.1",
> channel-max=32767]{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] gemmellr commented on issue #30: PROTON-1998: Add SASL protocol trace
gemmellr commented on issue #30: PROTON-1998: Add SASL protocol trace URL: https://github.com/apache/qpid-proton-j/pull/30#issuecomment-461987694 I'm not seeing the updates, did you push it? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1998) [Proton-J] Add SASL protocol trace
[
https://issues.apache.org/jira/browse/PROTON-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763912#comment-16763912
]
ASF GitHub Bot commented on PROTON-1998:
k-wall commented on issue #30: PROTON-1998: Add SASL protocol trace
URL: https://github.com/apache/qpid-proton-j/pull/30#issuecomment-461957965
The patch is revised to avoid the introduction of generics and the changes
to TransportFrame.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> [Proton-J] Add SASL protocol trace
> --
>
> Key: PROTON-1998
> URL: https://issues.apache.org/jira/browse/PROTON-1998
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-j
>Reporter: Keith Wall
>Priority: Minor
>
> Unlike Proton, Proton-J does not provide SASL frame trace if environment
> variable PN_TRACE_FRM is set. It would be useful if Proton-J had this
> ability too to help diagnose SASL negotiation problem.
> Proton's SASL frame trace looks like this:
> {code:java}
> [0x7fc112c03a00]: -> SASL
> [0x7fc112c03a00]: <- SASL
> [0x7fc112c03a00]:0 <- @sasl-mechanisms(64)
> [sasl-server-mechanisms=@PN_SYMBOL[:ANONYMOUS]]
> [0x7fc112c03a00]:0 -> @sasl-init(65) [mechanism=:ANONYMOUS,
> initial-response=b"guest@Oslo.local"]
> [0x7fc112c03a00]:0 <- @sasl-outcome(68) [code=0]
> [0x7fc112c03a00]: -> AMQP
> [0x7fc112c03a00]:0 -> @open(16)
> [container-id="be777c26-af6e-4935-a6be-316cc8bbdb35", hostname="127.0.0.1",
> channel-max=32767]{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] k-wall commented on issue #30: PROTON-1998: Add SASL protocol trace
k-wall commented on issue #30: PROTON-1998: Add SASL protocol trace URL: https://github.com/apache/qpid-proton-j/pull/30#issuecomment-461957965 The patch is revised to avoid the introduction of generics and the changes to TransportFrame. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1267) Bad_configuration test fails intermittently
[ https://issues.apache.org/jira/browse/DISPATCH-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763759#comment-16763759 ] ASF subversion and git services commented on DISPATCH-1267: --- Commit 9b45cb98bbccb070a285eb5e25ca32d363517c37 in qpid-dispatch's branch refs/heads/master from Charles E. Rolke [ https://gitbox.apache.org/repos/asf?p=qpid-dispatch.git;h=9b45cb9 ] DISPATCH-1267: increase timeout for failed address resolution > Bad_configuration test fails intermittently > --- > > Key: DISPATCH-1267 > URL: https://issues.apache.org/jira/browse/DISPATCH-1267 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.5.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.6.0 > > > Five seconds elpased time is too short for bad address resolution. Bump it up. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-1267) Bad_configuration test fails intermittently
[ https://issues.apache.org/jira/browse/DISPATCH-1267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chuck Rolke resolved DISPATCH-1267. --- Resolution: Fixed Fixed at Commit 9b45cb9 > Bad_configuration test fails intermittently > --- > > Key: DISPATCH-1267 > URL: https://issues.apache.org/jira/browse/DISPATCH-1267 > Project: Qpid Dispatch > Issue Type: Bug > Components: Tests >Affects Versions: 1.5.0 >Reporter: Chuck Rolke >Assignee: Chuck Rolke >Priority: Major > Fix For: 1.6.0 > > > Five seconds elpased time is too short for bad address resolution. Bump it up. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1267) Bad_configuration test fails intermittently
Chuck Rolke created DISPATCH-1267: - Summary: Bad_configuration test fails intermittently Key: DISPATCH-1267 URL: https://issues.apache.org/jira/browse/DISPATCH-1267 Project: Qpid Dispatch Issue Type: Bug Components: Tests Affects Versions: 1.5.0 Reporter: Chuck Rolke Assignee: Chuck Rolke Fix For: 1.6.0 Five seconds elpased time is too short for bad address resolution. Bump it up. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-1265) Delivery_abort test causes inter-router session error
[ https://issues.apache.org/jira/browse/DISPATCH-1265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763753#comment-16763753 ] Chuck Rolke commented on DISPATCH-1265: --- See https://issues.apache.org/jira/browse/PROTON-2005 The issue appears to be aborting a transfer when proton has buffered data for the transfer in session outgoing bytes. After the abort all of the outgoing bytes are flushed to the wire in a number of transfer frames. All the frames have abort=true and all but the last have more=true. Dispatch code does not abort the transfer and then keep sending bytes for that transfer. After calling abort then dispatch code starts sending the next delivery through a new transfer stream. > Delivery_abort test causes inter-router session error > - > > Key: DISPATCH-1265 > URL: https://issues.apache.org/jira/browse/DISPATCH-1265 > Project: Qpid Dispatch > Issue Type: Bug > Components: Router Node >Affects Versions: 1.5.0 > Environment: Fedora 29, Python 3. > branch DISPATCH-1264#a5aab9 > ctest -VV -R system_tests_delivery_abort >Reporter: Chuck Rolke >Assignee: Ganesh Murthy >Priority: Critical > Fix For: 1.6.0 > > Attachments: DISPATCH-1265_ctest-log.txt, > DISPATCH-1265_scraped-logs-timeout.html > > > Inter-router connection closes with: > error :"amqp:session:invalid-field" "sequencing error, expected delivery-id > 24, got 23" -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (DISPATCH-472) Default value of authenticatePeer parameter in listener configuration
[
https://issues.apache.org/jira/browse/DISPATCH-472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ted Ross updated DISPATCH-472:
--
Fix Version/s: (was: Backlog)
1.6.0
> Default value of authenticatePeer parameter in listener configuration
> -
>
> Key: DISPATCH-472
> URL: https://issues.apache.org/jira/browse/DISPATCH-472
> Project: Qpid Dispatch
> Issue Type: Improvement
>Reporter: Jakub Scholz
>Priority: Major
> Fix For: 1.6.0
>
>
> The authenticatePeer parameter in listener configuration has currently
> default value "no". I believe this can lead to misunderstandings causing
> security issues. Consider listener configured as this:
> {code}
> listener {
> role: normal
> host: 0.0.0.0
> port: amqp
> saslMechanisms: PLAIN DIGEST-MD5 CRAM-MD5
> }
> {code}
> It has configured SASL authentication using username and password and on a
> first look one might believe that such listener is configured properly.
> However, because of missing "authenticatePeer: yes" parameter, it is still
> possible to connect anonymously without the SASL layer.
> I believe it would be much better to have either set authenticatePeer
> parameter to yes by default all the time or at least when SASL is configured.
> Please have a look at the related discussion from the mailing list:
> http://qpid.2158936.n2.nabble.com/Dispatch-Default-value-of-authenticatePeer-td7648676.html
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-2005) [proton-c] AMQP error if delivery is aborted with session_outgoing bytes > 0
[
https://issues.apache.org/jira/browse/PROTON-2005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763533#comment-16763533
]
Robbie Gemmell commented on PROTON-2005:
I agree there shouldn't be any more transfers after one indicating 'aborted'.
The 'aborted' and 'more' flags also "SHOULD NOT" both be set according to the
spec, with aborted taking precedence if they are.
> [proton-c] AMQP error if delivery is aborted with session_outgoing bytes > 0
>
>
> Key: PROTON-2005
> URL: https://issues.apache.org/jira/browse/PROTON-2005
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.26.0, proton-c-0.27.0
>Reporter: Chuck Rolke
>Priority: Critical
>
> Running the test case in https://issues.apache.org/jira/browse/DISPATCH-1265
> The self test is a two-router network with a test sender sending to router A
> and a test receiver receiving from router B. The test sender is sending some
> number of bytes and then aborting the delivery. In the observations here
> router A is transmitting incorrect AMQP over the interrouter link to router B
> in response to the abort.
> * A 400K byte message is being transmitted. 320K bytes have already gone
> over the wire
> * The message is aborted. with session_outgoing 84992
> * Over the wire six transfers send the 84992 bytes with the same delivery-id
> and with abort=true
> A dispatch log scraper trace of router A for the interrouter link to router B:
>
> {{ delivery 21 is in progress}}
> {{2019-02-08 05:07:41.140975 A0#1480 A [A0_4] -> [B0_1] B transfer [0,10]
> (21) more transfer_93 - 16346 bytes (pending)}}
> {{2019-02-08 05:07:41.141066 A0#1486 A [A0_4] -> [B0_1] B transfer [0,10]
> (21) more transfer_99 - 16346 bytes (pending)}}
> {{2019-02-08 05:07:41.141087 A0#1488 A [A0_4] -> [B0_1] B transfer [0,10]
> (21) more transfer_102 - 228 bytes (pending)}}
> {{2019-02-08 05:07:41.141169 A0#1492 A [A0_4] <- [B0_1] B flow [0,10]
> (14,250)}}
> {{ delivery 21 is aborted with session_outgoing 84992}}
> {{ over the wire the session bytes are bled down with multiple transfers
> that have both 'more' and 'aborted' set true}}
> {{2019-02-08 05:07:41.141514 A0#1513 A [A0_4] -> [B0_1] B transfer [0,10]
> (21) settled more aborted transfer_93 - 16342 bytes transfer presettled}}
> {{2019-02-08 05:07:41.141538 A0#1514 A [A0_4] -> [B0_1] B transfer [0,10]
> (21) settled more aborted transfer_94 - 16342 bytes transfer presettled}}
> {{2019-02-08 05:07:41.141564 A0#1517 A [A0_4] -> [B0_1] B transfer [0,10]
> (21) settled more aborted transfer_96 - 16342 bytes transfer presettled}}
> {{2019-02-08 05:07:41.141603 A0#1521 A [A0_4] -> [B0_1] B transfer [0,10]
> (21) settled more aborted transfer_99 - 16342 bytes transfer presettled}}
> {{2019-02-08 05:07:41.141669 A0#1527 A [A0_4] -> [B0_1] B transfer [0,10]
> (21) settled more aborted transfer_92 - 16342 bytes transfer presettled}}
> {{2019-02-08 05:07:41.141722 A0#1531 A [A0_4] -> [B0_1] B transfer [0,10]
> (21) settled aborted transfer_93 - 13522 bytes transfer presettled}}
> {{ delivery 22 is started}}
> {{2019-02-08 05:07:41.142542 A0#1576 A [A0_4] -> [B0_1] B transfer [0,10]
> (22) more transfer_107 - 16346 bytes (pending)}}
> {{2019-02-08 05:07:41.142578 A0#1579 A [A0_4] -> [B0_1] B transfer [0,10]
> (22) more transfer_108 - 16346 bytes (pending)}}
> {{2019-02-08 05:07:41.142608 A0#1581 A [A0_4] -> [B0_1] B transfer [0,10]
> (22) more transfer_109 - 16346 bytes (pending) ...}}
> {{ eventually peer router B closes the connection}}
> {{2019-02-08 05:07:41.144746 A0#1730 A [A0_4] <- [B0_1] B close [0] error
> :"amqp:session:invalid-field" "sequencing error, expected delivery-id 22, got
> 21"}}
> {{2019-02-08 05:07:41.144767 A0#1732 A [A0_4] <- [B0_1] B EOS}}
> The transfer at 05:07:41.141514 settles the delivery and the next transfer is
> an AMQP protocol violation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2005) [proton-c] AMQP error if delivery is aborted with session_outgoing bytes > 0
Chuck Rolke created PROTON-2005:
---
Summary: [proton-c] AMQP error if delivery is aborted with
session_outgoing bytes > 0
Key: PROTON-2005
URL: https://issues.apache.org/jira/browse/PROTON-2005
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: proton-c-0.26.0, proton-c-0.27.0
Reporter: Chuck Rolke
Running the test case in https://issues.apache.org/jira/browse/DISPATCH-1265
The self test is a two-router network with a test sender sending to router A
and a test receiver receiving from router B. The test sender is sending some
number of bytes and then aborting the delivery. In the observations here router
A is transmitting incorrect AMQP over the interrouter link to router B in
response to the abort.
* A 400K byte message is being transmitted. 320K bytes have already gone over
the wire
* The message is aborted. with session_outgoing 84992
* Over the wire six transfers send the 84992 bytes with the same delivery-id
and with abort=true
A dispatch log scraper trace of router A for the interrouter link to router B:
{{ delivery 21 is in progress}}
{{2019-02-08 05:07:41.140975 A0#1480 A [A0_4] -> [B0_1] B transfer [0,10] (21)
more transfer_93 - 16346 bytes (pending)}}
{{2019-02-08 05:07:41.141066 A0#1486 A [A0_4] -> [B0_1] B transfer [0,10] (21)
more transfer_99 - 16346 bytes (pending)}}
{{2019-02-08 05:07:41.141087 A0#1488 A [A0_4] -> [B0_1] B transfer [0,10] (21)
more transfer_102 - 228 bytes (pending)}}
{{2019-02-08 05:07:41.141169 A0#1492 A [A0_4] <- [B0_1] B flow [0,10] (14,250)}}
{{ delivery 21 is aborted with session_outgoing 84992}}
{{ over the wire the session bytes are bled down with multiple transfers that
have both 'more' and 'aborted' set true}}
{{2019-02-08 05:07:41.141514 A0#1513 A [A0_4] -> [B0_1] B transfer [0,10] (21)
settled more aborted transfer_93 - 16342 bytes transfer presettled}}
{{2019-02-08 05:07:41.141538 A0#1514 A [A0_4] -> [B0_1] B transfer [0,10] (21)
settled more aborted transfer_94 - 16342 bytes transfer presettled}}
{{2019-02-08 05:07:41.141564 A0#1517 A [A0_4] -> [B0_1] B transfer [0,10] (21)
settled more aborted transfer_96 - 16342 bytes transfer presettled}}
{{2019-02-08 05:07:41.141603 A0#1521 A [A0_4] -> [B0_1] B transfer [0,10] (21)
settled more aborted transfer_99 - 16342 bytes transfer presettled}}
{{2019-02-08 05:07:41.141669 A0#1527 A [A0_4] -> [B0_1] B transfer [0,10] (21)
settled more aborted transfer_92 - 16342 bytes transfer presettled}}
{{2019-02-08 05:07:41.141722 A0#1531 A [A0_4] -> [B0_1] B transfer [0,10] (21)
settled aborted transfer_93 - 13522 bytes transfer presettled}}
{{ delivery 22 is started}}
{{2019-02-08 05:07:41.142542 A0#1576 A [A0_4] -> [B0_1] B transfer [0,10] (22)
more transfer_107 - 16346 bytes (pending)}}
{{2019-02-08 05:07:41.142578 A0#1579 A [A0_4] -> [B0_1] B transfer [0,10] (22)
more transfer_108 - 16346 bytes (pending)}}
{{2019-02-08 05:07:41.142608 A0#1581 A [A0_4] -> [B0_1] B transfer [0,10] (22)
more transfer_109 - 16346 bytes (pending) ...}}
{{ eventually peer router B closes the connection}}
{{2019-02-08 05:07:41.144746 A0#1730 A [A0_4] <- [B0_1] B close [0] error
:"amqp:session:invalid-field" "sequencing error, expected delivery-id 22, got
21"}}
{{2019-02-08 05:07:41.144767 A0#1732 A [A0_4] <- [B0_1] B EOS}}
The transfer at 05:07:41.141514 settles the delivery and the next transfer is
an AMQP protocol violation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
