qpid-proton mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robbie Gemmell (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PROTON-833) transport can emit frames with an invalid channel number after local session close
Date Thu, 05 Mar 2015 17:14:38 GMT

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

Robbie Gemmell updated PROTON-833:
----------------------------------
    Description: 
The transport can emit frames with an invalid channel number after a local session close is
performed.

A side effect of calling close on the session is that the channel number is unmapped when
the end frame is sent, and the associated field set to the value -1. The transport can subsequently
send frames which then use this -1 value, treating it as channel 65535 when sent to represent
the unsigned channel number. For example, if a local link close(+detach?) call is performed
in response to a remote detach after a local session close is performed, a detach frame can
be emitted with channel 65535. Similarly, I have noticed disposition frames being sent with
channel 65535.

Proton-C appears to protect against thse situations by inspecting whether the channel number
has been set as >= 0.


  was:
The transport can emit detach frames with an invalid channel number if a local link close(+detach?)
call is performed (in response to a remote detach) after a local session close is performed.

When a session is locally closed by a client with open links on it, if the 'broker' sends
detach frames for any of those links then the application might then do a local close on them
in response. The client transport then emits detach 'response' frames as a result of this,
after the session end frame has been sent. A side effect of calling close on the session is
that the channel number is unmapped when the end frame is sent, and the relevant variable
set to the value -1. When the transport sends the detaches outlined above it then uses the
-1 value, which is treated as channel 65535 when sent as the unsigned channel number.



> transport can emit frames with an invalid channel number after local session close
> ----------------------------------------------------------------------------------
>
>                 Key: PROTON-833
>                 URL: https://issues.apache.org/jira/browse/PROTON-833
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: proton-j
>    Affects Versions: 0.8
>            Reporter: Robbie Gemmell
>
> The transport can emit frames with an invalid channel number after a local session close
is performed.
> A side effect of calling close on the session is that the channel number is unmapped
when the end frame is sent, and the associated field set to the value -1. The transport can
subsequently send frames which then use this -1 value, treating it as channel 65535 when sent
to represent the unsigned channel number. For example, if a local link close(+detach?) call
is performed in response to a remote detach after a local session close is performed, a detach
frame can be emitted with channel 65535. Similarly, I have noticed disposition frames being
sent with channel 65535.
> Proton-C appears to protect against thse situations by inspecting whether the channel
number has been set as >= 0.



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

Mime
View raw message