[Cerowrt-devel] dropbear stops working

[Dave Taht]

It is highly likely you ran out of flash space. As best as I recall,
babel then was logging to flash, which we fixed somewhere around
feburary.

You might be able to get somewhere by deleting that log file.

On Mon, Jan 13, 2014 at 2:20 AM, Michael Richardson <mcr at sandelman.ca> wrote:
>
> Hi, I was running 3.8 until two weeks ago.  I had a problem that had
> developed where by dropbear (ssh daemon) simply stopped being willing to
> accept logins.  I still had access through the web ui, but it's hard to
> investigate problems that way...
>
> I flashed a new 3800 with 3.10 back on Dec. 25th, and all was well.
> I could ssh in, no problem.  I went to ssh today, and I get the same
> problem as before... My experience from before was that a reboot did *not*
> solve the problem.
>
> ssh -v gives me:
>
> obiwan-[~/galaxy/orlando/r6743] mcr 10015 %ssh -v root at budmgmt
> OpenSSH_6.0p1 Debian-4, OpenSSL 1.0.1e 11 Feb 2013
> debug1: Reading configuration data /home/mcr/.ssh/config
> debug1: /home/mcr/.ssh/config line 170: Applying options for *
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug1: Connecting to budmgmt [172.30.42.1] port 22.
> debug1: Connection established.
> debug1: identity file /home/mcr/.ssh/id_rsa type 1
> debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
> debug1: identity file /home/mcr/.ssh/id_rsa-cert type -1
> debug1: identity file /home/mcr/.ssh/id_dsa type 2
> debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-2048
> debug1: Checking blacklist file /etc/ssh/blacklist.DSA-2048
> debug1: identity file /home/mcr/.ssh/id_dsa-cert type -1
> debug1: identity file /home/mcr/.ssh/id_ecdsa type -1
> debug1: identity file /home/mcr/.ssh/id_ecdsa-cert type -1
> ssh_exchange_identification: Connection closed by remote host
> [2]    17811 exit 255   ssh -v root at budmgmt
>
> I typically operate with about 6 private keys loaded into ssh-agent on my
> desktop.  On a whim I tried unset SSH_AUTH_SOCK in a fresh shell, but
> that didn't change things, nor did combinations after that of things like:
>
> %ssh -i ~/.ssh/id_dsa -v root at budmgmt
>
> on the "budmgmt" IP (the 172.30.42.1 untagged on 3800), I should even be able
> to login with a password, but it never gets to that point.  I'm thinking that
> either something has filled up in a way that survives reboots.
>
> When I had this problem before, I tried starting a new copy of dropbear
> From the Network/Fireall/Custom Rules file, since that is a shell
> script I can hack:
>        dropbear -p 2221 &
>
> but that didn't work (nothing listening on port 2221).
> I can see nothing in the logs (which also come via UDP/syslog to my desktop).
>
> I'm looking for any advice on how to:
>   a) restore my ssh access.
>   b) get better diagnostics from dropbear.
>
> Failing this, I'll upgrade the other unit, restore my settings, and test
> things daily.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht

https://www.bufferbloat.net/projects/make-wifi-fast