Unfortunately no one can be told what fun_plug is - you have to see it for yourself.
You are not logged in.
Hey guys, I'm unable to su to root once I've ssh'ed in as another user; the shell just hangs but I can ctrl+c to get my user shell back. It happens whether I `su -` or just `su`:
/mnt/HD_a2 $ su
Password:
BusyBox v1.00-pre1 (2006.07.17-10:17+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
Anyone have any ideas as to how I can fix this or what the problem might be?
Thx in advance!
Offline
PP133 wrote:
BusyBox v1.00-pre1 (2006.07.17-10:17+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
Looks like su starts /bin/sh (root's login shell, instead of the funplug shell). Something I forgot to patch... But there are workarounds available, e.g. try:
su -c /mnt/HD_a2/fun_plug.d/bin/sh
(In theory you could also change root's login shell, but I strongly advice against doing this!)
I ran into the busybox 1.00 greeting myself some time ago. See tobyg's reply to my post here:
http://dns323.kood.org/forum/p1686-2007 … html#p1686
Offline
Haha, the work around that tobyg presented actually made me laugh out loud Of course, it worked, but eesh! What's the reasoning behind those numbers? Is that the root password that the manufacturer put into the busybox shell?
Thanks for the help, Fonz! Great work on fun_plug, btw!
While I have your attention, if I still have it, have you ever had any issues with a long delay in attempting to ssh into the dns 323? I've timed the login process twice, using a freedns fqdn and the IP and they both take anywhere between 60 and 63 seconds to connect. Ever seen that?
Offline
PP133 wrote:
have you ever had any issues with a long delay in attempting to ssh into the dns 323? I've timed the login process twice, using a freedns fqdn and the IP and they both take anywhere between 60 and 63 seconds to connect. Ever seen that?
No. 60 seconds is very long. I've seen such delays over very congested paths only.
Offline
fonz wrote:
PP133 wrote:
have you ever had any issues with a long delay in attempting to ssh into the dns 323? I've timed the login process twice, using a freedns fqdn and the IP and they both take anywhere between 60 and 63 seconds to connect. Ever seen that?
No. 60 seconds is very long. I've seen such delays over very congested paths only.
My pings and traceroutes are pretty quick to that server (20-32ms). Also, I can telnet to the dns323 on port 22 in less than a second. There's no dropbear config or anything you can think of that would cause that delay? Maybe something screwed up w/ my home directory and/or the .ssh directory?
Last edited by PP133 (2007-08-18 03:41:08)
Offline
Long delays in connecting to ssh commonly are due to reverse dns resolution.
Having either a "hosts" file setup or a reverse dns pointer should remedy the problem.
-W
Offline
wjessee wrote:
Long delays in connecting to ssh commonly are due to reverse dns resolution.
Having either a "hosts" file setup or a reverse dns pointer should remedy the problem.
-W
You know, I was thinking it was something along these lines...I seem to remember coming across this once before.
However, I think that the problem was the nameservers I had in /etc/resolve.conf. Once I changed them to what they should've been, I get a prompt back super-fast.
Thx again!
Offline
fonz wrote:
PP133 wrote:
BusyBox v1.00-pre1 (2006.07.17-10:17+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.Looks like su starts /bin/sh (root's login shell, instead of the funplug shell). Something I forgot to patch... But there are workarounds available, e.g. try:
Code:
su -c /mnt/HD_a2/fun_plug.d/bin/sh(In theory you could also change root's login shell, but I strongly advice against doing this!)
I ran into the busybox 1.00 greeting myself some time ago. See tobyg's reply to my post here:
http://dns323.kood.org/forum/p1686-2007 … html#p1686
Dude, this command saved my ass. I had enabled telnet to enable password authentication but didn't change the root password first. This command seems to be a work around.
I can run it and my non-root user password to su to root. Seems like a gapping security hole to me
Offline
thejipster wrote:
Code:
su -c /mnt/HD_a2/fun_plug.d/bin/shDude, this command saved my ass. I had enabled telnet to enable password authentication but didn't change the root password first. This command seems to be a work around.
I can run it and my non-root user password to su to root. Seems like a gapping security hole to me
I'm a bit baffled. When I ssh into my dns323 (non-root user) and run the above command, then enter the password of my non-root user, I get:
su: incorrect password
Offline
I have got the same problem like fonz. I first changed the root password in a telnet session and the new password worked only until this session. Then I reboot the box and the password was reset, I heard to an empty one, however I cannot su to root because I got incorrect password message whatever I type.
Any help?
Offline