>> Here is a more practical example which demonstrates the problem:
>>
>> $ echo false | dbclient -T r...@host.example.com
>> $ echo $?
>> 0
>
> I think this should now _really_ be fixed with
> https://secure.ucc.asn.au/hg/dropbear/rev/79eef94ccea9
>
> dbclient was ignoring all packets for
Il 14/11/18 16:13, Matt Johnston ha scritto:
I'm not keen on changing dbclient, the current implementation saves a network
roundtrip. It's perfectly reasonable according to the spec. If you have Cisco
support could you report it to them?
Unfortunately I don't have Cisco support.
I think
On Wed, Nov 14, 2018 at 06:20:59PM +0300, Konstantin Tokarev wrote:
> Note that OpenSSH enables a couple of workarounds for Cisco-1.*
>
> https://github.com/openssh/openssh-portable/blob/master/compat.c#L88
The tricky thing is that dbclient can't do anything to work around
it here. We haven't
14.11.2018, 18:16, "Matt Johnston" :
> Hi Nik,
>
>> dbclient sends "SSH-2.0-dropbear_2018.76\r\n" and kexinit
>> cisco sends "SSH-2.0-Cisco-1.25\r\n"
>> then cisco waits "ip ssh time-out" seconds and then closes the TCP socket.
>>
>> my conjecture is that cisco empties its receive buffer
Hi Nik,
>
> dbclient sends "SSH-2.0-dropbear_2018.76\r\n" and kexinit
> cisco sends "SSH-2.0-Cisco-1.25\r\n"
> then cisco waits "ip ssh time-out" seconds and then closes the TCP socket.
>
> my conjecture is that cisco empties its receive buffer after sendind the
> identification string and
Hi Mike,
> On Sat 10/11/2018, at 12:52 am, W. Michael Petullo wrote:
>
>
> Here is a more practical example which demonstrates the problem:
>
> $ echo false | dbclient -T r...@host.example.com
> $ echo $?
> 0
I think this should now _really_ be fixed with
