uC/OS-II with a TCP/IP stack that basically had the standard sockets API.
That was tough enough. If your implementation of lwIP/TCP-IP is running
in the state-machine mode, then that will be MUCH tougher.
Ed
--
Ed Sutter
Alcatel-Lucent Technologies -- Bell Laboratories
Phone: 908-582-2351
Email
Hi,
I'm using dropbear in an embedded linux application pulled in with
buildroot.
In normal situations it appears to be working fine.
For my project though, I need to run a custom shell that only provides
the user
with VERY minimal access to the system all through builtins. When I set up a
data.
Keepalive is usually implemented by sending SSH_MSG_IGNORE,
but there isn't any requirement for that.
It hasn't hit some edge case of the circular buffer in
the channel handling code has it?
Cheers,
Matt
On Thu, Apr 25, 2013 at 04:23:49PM -0400, Ed Sutter wrote:
Hi,
I noticed that I'm
could eliminate any lower level issues.
Good luck.
--
http://www.realthought.net/
El 26/04/2013 05:02, Ed Sutter ed.sut...@alcatel-lucent.com
mailto:ed.sut...@alcatel-lucent.com escribió:
Hi,
I have a modified version of the dropbear ssh server running in
a multitasking RTOS
to rekey every 8 hours or 1GB data.
Keepalive is usually implemented by sending SSH_MSG_IGNORE,
but there isn't any requirement for that.
It hasn't hit some edge case of the circular buffer in
the channel handling code has it?
Cheers,
Matt
On Thu, Apr 25, 2013 at 04:23:49PM -0400, Ed Sutter wrote
hours or 1GB data.
Keepalive is usually implemented by sending SSH_MSG_IGNORE,
but there isn't any requirement for that.
It hasn't hit some edge case of the circular buffer in
the channel handling code has it?
Cheers,
Matt
On Thu, Apr 25, 2013 at 04:23:49PM -0400, Ed Sutter wrote:
Hi,
I noticed
Hi,
I have a modified version of the dropbear ssh server running in
a multitasking RTOS environment that is not POSIX compliant.
In almost all cases it is running perfectly...
I run load tests on it by just using a simple expect script
that spawns an ssh client and sends commands and expects
Hi,
I noticed that I'm not doing any re-keying...
Will this cause a typical SSH client to quit?
Ed
Hi,
I have a modified version of the dropbear ssh server running in
a multitasking RTOS environment that is not POSIX compliant.
In almost all cases it is running perfectly...
I run load tests on
15, 2013 at 5:30 PM, Ed Sutter
ed.sut...@alcatel-lucent.com mailto:ed.sut...@alcatel-lucent.com
wrote:
One correction...
I realized that I reported my high-water mark with my allocator
in 'trace' mode. This significantly screws up the allocation sizes in
runtime. After
Hi,
I now have the dropbearkey code integrated into my embedded stuff.
I assume the idea is to call this function each time the server starts up.
Then each time the server starts, future client connections will reject the
server connection until $HOME/.ssh/known_hosts is purged of that server's
Matt,
Answers embedded...
Ed
Hi,
I'm pretty sure there'd be interest in such a port, even if
there are no immediate takers. I guess it depends how much
effort you want to put in - a separate tarball (or hg
branch ease of merging future versions) might be enough for other
people to get going. It
Ok, more information...
I see that if I use an ssh client that connects to an ssh server, I do
get the expected
fingerprints. I also see that if I use the dbclient with the db server
I get the
expected fingerprint. The problem occurs when I try to use the ssh
client to connect
to the db
Found the problem...
In my energetic effort to reduce the size of the server,
I had #undef DROPBEAR_MD5_HMAC
in my options.h file.
With that defined, the fingerprints now match.
All better now.
Sorry for the noise!
Ed
Ok, more information...
I see that if I use an ssh client that connects to an
Hi,
I've got what I think is a reasonably stable version of dropbear's SSH
server working
in a non-posix, thread-based embedded system. I'd like to review the
changes I
made for anyone that may be considering doing this, but also to see if
any flags
get raised by the folks that have been
Hi,
Just to put a few things in perspective regarding the likelihood of this
working in a really small embedded system...
Regarding memory...
It really depends on just how small you need to be...
One session looks like it uses upwards of 2100 malloc calls. Long term
fragmentation from one
Hi,
I started digging into the possibility of reducing the number of malloc/free
calls (by replacing small/quick fixed-size allocations with stack arrays),
and I think I found one that makes a substantial difference...
The call to mp_div_2d() in a loop inside the function
One correction...
I realized that I reported my high-water mark with my allocator
in 'trace' mode. This significantly screws up the allocation sizes in
runtime. After rebuilding with that turned off, the high-water mark
that I get is around 77K.
Hi,
Just to put a few things in perspective
Great explanation Rob,
Thanks much..
Ed
On 04/11/2013 04:56:54 PM, Ed Sutter wrote:
Hi,
I managed to get dropbear-ssh running under a uC/OS-II thread.
Obviously had to do a lot of hacking to make this work, and
I'm sure its not the most efficient way of doing it.
Not being an ssh/cryptography
Hi,
Not sure, but I think I stumbled on what may be a problem with the
session_identification() function...
Shouldn't the strncmp() at the bottom of the function only be executed
if the done flag is true? Seems to me that this could cause a crash because
ses.remoteident may be NULL.
Ed
On 4/12/2013 4:05 PM, Ed Sutter wrote:
Hi,
Not sure, but I think I stumbled on what may be a problem with the
session_identification() function...
Shouldn't the strncmp() at the bottom of the function only be executed
if the done flag is true? Seems to me that this could cause a crash
because
Hi,
I managed to get dropbear-ssh running under a uC/OS-II thread.
Obviously had to do a lot of hacking to make this work, and
I'm sure its not the most efficient way of doing it.
Not being an ssh/cryptography wizard by any stretch of the
imagination, I have two questions that may be trivial...
Hi,
I'm taking a shot at porting the ssh server portion of this
package to a non-posix multitasking RTOS on a CPU running ~500Mhz.
I've made reasonable progress, but now I'm stumbling on an error
coming out of gen_kexdh_vals()...
The call to mp_exptmod() does not return MP_OKAY; hence
22 matches
Mail list logo
