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 <[email protected]> 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@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@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@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 [ > ] [email protected] http://www.sandelman.ca/ | ruby on rails > [ > > > > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht https://www.bufferbloat.net/projects/make-wifi-fast _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
