On Wed, Mar 27, 2013 at 11:47 AM, Matt Johnston wrote:
> If the network cable has been pulled out, shouldn't the OS send a TCP RST
> packet eventually after some traffic and close the connection?
That tends to be an application-level concern. You could imagine that
a protocol can tolerate a day-lo
Hi,
I'm seeing a difference in how dbclient handles EOF on input compared
to openssh client. openssh client propagates input EOF to the remote
command, but continues pumping command stdout. dbclient seems to abort
before flushing the stdout buffer.
In the following examples, 1.2.3.4 is an openwrt
) || channel->errfd == FD_CLOSED)
&& !channel->sent_close
&& close_allowed
On Sat, Jul 13, 2013 at 12:31 PM, Catalin Patulea wrote:
> Hi,
>
> I'm seeing a difference in how dbclient handles EOF on input compared
> to openssh client. openssh client prop
_msg_channel_close 0x1f78660
TRACE (31787) 1374079900.330549: enter cli_tty_cleanup
TRACE (31787) 1374079900.330560: leave cli_tty_cleanup: not in raw mode
TRACE (31787) 1374079900.330606: CLOSE some fd 0
TRACE (31787) 1374079900.330618: CLOSE some fd 2
On Sat, Jul 13, 2013 at 12:51 PM, Catalin
Attached patch should fix both, and use hard tabs so should apply easily.
Rather than replacing readfd with writefd, *both* are checked for
FD_CLOSED before closing the entire channel. Then each direction can
be initially closed independently.
On Wed, Jul 17, 2013 at 7:57 PM, Catalin Patulea
Hm, that broke channel-close-by-child-exit. One more try, where we
check for the child exiting and close writefd as a result. If writefd
is the last remaining open pipe to the child, then we also close the
channel as a whole.
On Wed, Jul 17, 2013 at 3:25 PM, Catalin Patulea wrote:
> Attac
e...@openssh.com is an extension that allows EPIPE to propagate through
SSH sessions. For example:
ssh localhost cat /dev/urandom | /bin/true
will very quickly exit because /bin/true does not consume its stdin.
The mechanism is:
- /bin/true calls exit(0), closing the last remaining ref to its stdi
. The patch
dropbear-eow.patch fixes this.
But all this to say that vanilla OpenSSH cannot be used to test this
feature because it won't send e...@openssh.com. OpenSSH would need to
be patched to include dropbear in the whitelist for testing.
On Wed, Jul 24, 2013 at 9:21 PM, Catalin Patul
ping?
On Fri, Jul 26, 2013 at 9:31 PM, Matt Johnston wrote:
> Hi Catalin,
>
> Thanks for looking at that - the last patch looks sensible, I'll give it a
> good test. There are a lot of subtle scenarios in channel closing (and
> variations between OSes).
>
> Cheers,
You could always write a small wrapper script that adds whatever
command-line arguments you need, and pass *that* to autossh.
#!/bin/sh
exec path/to/dropbear -y "$@"
On Fri, Oct 4, 2013 at 12:31 PM, Steve Newcomb wrote:
> I'm using OpenWRT. My router, whose IP address changes unpredictably,
> m
Thanks to Lluís Batlle i Rossell and Arnaud Mouiche for patches
>
> - Avoid reading too much from /proc/net/rt_cache since that causes
> system slowness.
>
> - Improve EOF handling for half-closed connections
> Thanks to Catalin Patulea
>
> - Send a banner message to r
Signed-off-by: Catalin Patulea
---
package/network/services/dropbear/Makefile |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/package/network/services/dropbear/Makefile
b/package/network/services/dropbear/Makefile
index f025c4d..02be761 100644
--- a/package/network
I noticed that dropbear sets IPTOS_LOWDELAY on all sockets:
https://secure.ucc.asn.au/hg/dropbear/file/14342451d3df/dbutil.c#l190
This is great for interactive sessions, but not ideal for bulk
transfer sessions like scp or sftp. Many networks ignore the TOS byte,
but on my local network I respect
On Sat, Nov 23, 2013 at 4:26 PM, Dave Taht wrote:
> While obsolete (don't use it!) , wondershaper was the root of all
> these systems a decade ago, and is a lot easier to study and
> understand than these successors.
Thanks for the pointers. Indeed, I use a simplified variant of
wondershaper at my
On Sat, Nov 23, 2013 at 9:11 PM, Matt Johnston wrote:
> Catalin Patulea wrote:
>>Matt, would you accept a patch that keys the TOS setting off
>> PTY requests?
> Yes, I've been meaning to look at that.
Heads up, client and server TCP port forwards use the same utility
funct
Signed-off-by: Catalin Patulea
---
cli-chansession.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/cli-chansession.c b/cli-chansession.c
index ed80453..0ee3e85 100644
--- a/cli-chansession.c
+++ b/cli-chansession.c
@@ -398,6 +398,7 @@ void cli_send_netcat_request
On Sun, Nov 24, 2013 at 1:58 AM, Catalin Patulea wrote:
> Heads up, client and server TCP port forwards use the same utility
> function, connect_remote, so changes in this area will also affect
> those connections.
>
> It seems sensible to me that they be downgraded to default TOS
Signed-off-by: Catalin Patulea
---
cli-chansession.c | 1 +
dbutil.c | 29 +
dbutil.h | 2 ++
includes.h| 4
svr-chansession.c | 2 ++
5 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/cli-chansession.c b/cli
# HG changeset patch
# User Catalin Patulea
# Date 1391936210 18000
# Sun Feb 09 03:56:50 2014 -0500
# Branch ecdsareadme
# Node ID 5342b5a69bfdf342f89ee5e3eb26c358669ea821
# Parent d50c17fe57d77da37744911a9bd18d9f3fede45b
README: fix ecdsa key generation command
diff -r d50c17fe57d7 -r
Going back to February 2013:
https://secure.ucc.asn.au/hg/dropbear/rev/80af450dae76
https://secure.ucc.asn.au/hg/dropbear/rev/aa689d140928
Matt, at the time you had called out a potential issue with
connections doing only port forwarding staying on IPTOS_LOWDELAY. Now
I'm actually running into tha
On Tue, Jul 8, 2014 at 9:44 AM, Matt Johnston wrote:
> I'm not really sure how to resolve it though. Maybe as a
> tradeoff the refcounting could just switch between LOWDELAY
> and no-tos-flags if there are TCP forwards going on, then
> BULK if there aren't TCP forwards?
Ok, so if I'm understanding
dropbear-skip-bad-key.patch
Description: Binary data
Years ago, I attempted to fix an issue that sounds a lot like this:
https://hg.ucc.asn.au/dropbear/rev/35183e8a7851
I believe the right way this works it that:
- ssh client closes session
- dropbear closes the read end of command's stdout pipe
- next time command writes to pipe, it receives SIGPIP
23 matches
Mail list logo
