Re: [jgit-dev] Invalid Channel 117

[Shawn Pearce <spearce@xxxxxxxxxxx>]

On Fri, May 31, 2013 at 9:09 AM, Michael Chletsos <mpchlets@xxxxxxxxxxxx> wrote:
> Thank you - that helps so much, I appreciate the help - and no the C client
> throws no error - shocked me too.

It is very possible this is a bug in JGit, but its also possible its a
bug in the Assembla server. There are a few different permutations of
the push protocol based on capabilities selected. Both JGit client and
Assembla server may have bugs that together cause this error, but
individually don't confuse the protocol. *sigh*


> On Fri, May 31, 2013 at 6:07 AM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:
>> On Fri, May 31, 2013 at 6:59 AM, Michael Chletsos <mpchlets@xxxxxxxxxxxx>
>> wrote:
>> > I work with Assembla and we have noticed that when interacting with
>> > jgit, we
>> > always receive an Invalid Channel 117 - I assume this is a sideband
>> > channel
>> > alert and that jgit is not understanding our response back?
>>
>> Yes. JGit is reading this byte 117 (aka 0x75 aka the letter "u") where
>> it expects to see a sideband channel number. It seems you are sending
>> some data with an invalid pkt-line length header, causing the client
>> to get out of sync with the stream, or just sending an invalid
>> sideband.
>>
>> > This happens anytime you push up to Assembla from jgit.
>>
>> I am surprised this also doesn't happen with the C client.
>> recv_sideband() also fails when it sees a channel such as 117 in the
>> stream.
>>
>> > I am more than happy to fix this on the Assembla side if there is an
>> > issue,
>> > I was hoping that maybe someone here has some insight into what this
>> > error
>> > is and why I am seeing it on every jgit client - otherwise, to the
>> > source
>> > code I go.
>>
>> We don't see this from any other system using JGit, but its possible
>> something Assembla's server has done has caused the JGit
>> SideBandInputStream to become unsynchronized from the stream and fail.
>>
>> A stack trace from the JGit client would help understand better where
>> this is, but I assume its in the status-report parsing on the client
>> side. You may want to start hunting for the bug by modifying the
>> client to print more bytes from the stream when it throws the
>> exception and see if you recognize any of the data.
>
>