Enabling telnet on the Foxsat-HD

garynl

Member
I'm stuck.

At first I thought it would be just a matter of putting a script in /etc/init.d to start the busybox telnet daemon, but that didn't seem to work so I looked in the custom firmware available for the Foxsat HDR and the HD-Fox T2. Interestingly neither use the busybox telnetd. The hdr foxsat cf doesnt have it built in but installs utelnet package, the T2 does have it in the firmware.

So I grabbed the utelnet daemon package from http://hummypkg.org.uk/foxsat ; I unpacked it with archive manager. Its very simple: executable and start up script, nothing exciting in the extra configuration scripts. I put the executable in /sbin and the startup script in /etc/init.d I checked that pathnames were consistent. Created an hdf and uploaded it.

It didnt work, it takes some time but it eventually comes back with 'connection closed by remote host'
I use putty as client. I can only attempt to access the foxsat by ip address; in the HDR, HD and T2 firmware, /etc/hostname contains the name HDR-5000 so it cant be being used and the box isnt visible in the network (but pingable by ip address).

I noticed the T2 has /etc/hosts.allow containing ALL:ALL . This shouldn't make any difference since that is the default, but just to be sure I added it. As expected it made no difference.

I noticed that /etc/passwd listed /dev/null as the shell for all users listed, effectively disabling them. I dont think this can be my problem (yet), I am not getting that far, but I changed the shell for root to /bin/sh/ Surprisingly this did make a difference, but not a positive one; putty now instantly returns with closed by remote host.


I didn't expect this to be difficult, but working blind (i.e. change the firmware and try putty, without any access to logging) has proved harder than I thought. All the more reason to get this working.

The daemon is started (I hope) with the command "/sbin/utelnetd -l /bin/sh -p 23 -d"
Could the shell be expecting write access to somewhere? (which would mean I will have to bring forward my next mini-project of mounting a usb disk).
 
If the utelnetd binary is in /sbin then you should have made the two edits shown below to the startup script from the HDR package.
Code:
#!/bin/sh
 
- [ -x /opt/bin/utelnetd ] || exit 0
+ [ -x /sbin/utelnetd ] || exit 0
 
. /lib/lsb/init-functions
. /etc/default/rcS
 
case "$1" in
    start)
-              /opt/bin/utelnetd -l /bin/sh -p 23 -d  >/dev/null 2>&1
+              /sbin/utelnetd -l /bin/sh -p 23 -d  >/dev/null 2>&1
                ;;
    stop)
                killall utelnetd
                ;;
    *)
                exit 1
                ;;
esac
You also need to uncomment these lines in /etc/S02mountvirtfs (if it's the same as on the HDR) to enable TTY.

Code:
#!/bin/sh
 
#TTYGRP=5
#TTYMODE=620
#if [ -f /etc/default/devpts ]; then
#    . /etc/default/devpts
#fi
 
#if [ -d /dev/pts ]; then
#    mount -t devpts devpts /dev/pts -ogid=$TTYGRP,mode=$TTYMODE
#fi
 
yes, the changes I made to the startup script are exactly as you describe.
I have uncommented the lines in /etc/S02mountvirtfs as you suggest, the HD version is the same as the HDR version, but it doesn't make any difference to the behaviour.

putty gives a "Connection closed by remote host" and then a fatal error "Network error: Software caused connection abort" (which I see I neglected to mention in my original post)
 
I noticed that /etc/passwd listed /dev/null as the shell for all users listed, effectively disabling them. I dont think this can be my problem (yet), I am not getting that far, but I changed the shell for root to /bin/sh/ Surprisingly this did make a difference, but not a positive one; putty now instantly returns with closed by remote host.
I'm not sure if this is just a typo. in the message here but it should be '/bin/sh' (no trailing /).
 
I noticed the T2 has /etc/hosts.allow containing ALL:ALL . This shouldn't make any difference since that is the default, but just to be sure I added it. As expected it made no difference.

That isn't relevant. Nothing is compiled with libwrap so that file isn't used.
 
Hmm, only other thing I can think of is the permissions on the telnet binary and script. Anyway, I downloaded the latest HD hdf fom the Humax site, extracted the rootfs and compared it with that of the HDR. Only differences are that the HDR has some extra files under /lib, and has hard disk partitions definined in /etc/fstab. (on the HD these lines are commented out). So, I uncommented these lines and copied over the missing libraries from the HDR, and added the utelnet binary and startup script. Rolled it up into an hdf using the HDR's system ID and flashed my box with it. Booted up and telnetted in, no problem. I've since made an hdf using the HD system ID which contains the original HD files plus telnet. Give this one a try.
 

Attachments

  • Foxsat_HD_with_telnet.zip
    606.9 KB · Views: 11
@xyz321: yes, itś a typo, but thanks for pointing it out, I could just have easily made it in the passwd file.
@af123: ok, one less file to worry about
@raydon: thanks for the file. I will try it out later tonight. Assuming it works, my next task will be to determine for myself the difference between yours and mine.
 
I tried the firmware in the zip file, but it behaves in the same way as the firmware I generated. Just to be sure , I've tried from my laptop and a desktop, with different telnet clients, with and without firewalls. I can telnet to a media player I have which also runs busybox without any problems. If the firmware runs on an HDR could it be that something is expecting to have access to a writable file system which isn't present on the HD?
 
I need to find out whats going on. Has the telnet daemon actually started? I came up with the idea of mounting a USB stick and dumping some data to it to try and work out what happens during boot. I included the following in the firmware and uploaded it to the hummy. Then, before I restarted it, I replaced the USB stick with another I formatted as ext2 and booted.

/etc/init.d/S51dump

Code:
#!/bin/sh
 
mkdir /media/usb
 
mount -t ext2 -o mode=0777 /dev/sda1 /media/usb
 
ps -ax >/media/usb/ps.out
mount >/media/usb/mount.out
ls -al / >/media/usb/ls.out

The problem is I am guessing which device the USB stick will appear as. It doesn't appear to be sda1 (or something else s wrong) because I dont see any data on the stick when I look at it later on my PC.
Any ideas?
 
You can try enabling USB hotplugging via mdev instead of using your init.d script.
Uncomment line 31 in S02mountvirtfs
#/sbin/mdev -s
Then replace existing /etc/mdev/run-and-gun script with the one below.
When you insert a USB stick mdev will trigger an event that runs the run-and-gun script.
Hopefully you will get something written to the stick.
BTW, the busybox ps command doesn't accept -ax arguments.
Code:
#!/bin/sh
 
if ! echo ${MDEV#sd[a-z]} | grep -q '[0-9]' ; then
    exit 0
fi
 
device=/dev/$MDEV
mount_path=/media/$MDEV
 
#Grep USB filesystem type from fdisk output to use with mount command.
if `fdisk -l | grep $device | grep -q "FAT32"` ; then
    type=vfat
else
    type=ext3
fi
 
case "$ACTION" in
    add*)
        mkdir -p $mount_path
        mount -t $type $device $mount_path
        ps > $mount_path/ps.out
        mount > $mount_path/mount.out
        ls -al / > $mount_path/ls.out
        ;;
    remove*)
        umount -l $device
        rm -rf $mount_path
        ;;
    *)
        ;;
esac
 
Thanks Raydon. I have done as you suggested, and judging by the amount of led flashing on the USB sticks (I tried a FAT32 and an ext3 formatted stick) the box is at least trying to mount them., but you have guessed it, no .out files (I just shut down the box by pressing the standby button on the front and when all activity has ceased, I remove the stick and check the contents on my PC). The gods seem to be against me. Other than explicitly specifying it should be mounted rw (which is the default), I cant think of anything else to try.
 
It's a long shot but try changing mount_path to /tmp/$MDEV instead of /media/$MDEV as that is in writable tmpfs also.
 
Yes, I was. I now shut the box down before removing the stick and I see the files I was hoping for (maybe I had been removing the stick before the data had been flushed, I dont know). Anyway, the ps output. There seems to be two telnetd processes, one of which is a zombie

Code:
  186 root            Z  [utelnetd]
  187 root        248 S  /sbin/utelnetd -l /bin/sh -p 23 -d

Why the zombie? I also noticed in the mount output that /dev/pts isn't mounted. This is conditionally mounted in S02mountvirtfs. I removed the if around it so that an attempt is always made to mount it but it makes no difference.

(the attached files are the output after I removed the condition around the mount of /dev/pts)
(and the usb stick is getting mounted twice now in /media and /tmp, but that's the least of my worries)
 
Yes, I was. I now shut the box down before removing the stick and I see the files I was hoping for (maybe I had been removing the stick before the data had been flushed, I dont know). Anyway, the ps output. There seems to be two telnetd processes, one of which is a zombie

Code:
  186 root            Z  [utelnetd]
  187 root        248 S  /sbin/utelnetd -l /bin/sh -p 23 -d

Why the zombie? I also noticed in the mount output that /dev/pts isn't mounted. This is conditionally mounted in S02mountvirtfs. I removed the if around it so that an attempt is always made to mount it but it makes no difference.
I wouldn't worry about the zombie, at least the telnet process is running. It's devpts thats your problem.
(the attached files are the output after I removed the condition around the mount of /dev/pts)
Attached files ??
(and the usb stick is getting mounted twice now in /media and /tmp, but that's the least of my worries)
Set mount_path back to /media/$MDEV

It could be that the kernel was compiled without support for devpts. Try cat /proc/filesystems > $mount_path/fs.out and see if devpts is listed.
You could also try uncommenting devpts in /etc/fstab.
 
fs.out :
Code:
nodev    sysfs
nodev    rootfs
nodev    bdev
nodev    proc
nodev    sockfs
nodev    usbfs
nodev    pipefs
nodev    futexfs
nodev    tmpfs
nodev    eventpollfs
    ext3
    ext2
    squashfs
nodev    ramfs
    msdos
    vfat
    ntfs
nodev    jffs2
nodev    mqueue

No sign of pts, which I assume is bad news. (I tried uploading the output files to the previous post, but despite it saying the upload was successful, they dont appear to be attached.)
 
No sign of pts, which I assume is bad news.
It is indeed, it means no kernel support for devpts. I believe you can make static pty and tty device nodes using the mknod command but it's beyond my experience. Look here for some background information.
You could install tinyftp server as a way into your box as that doesn't need TTY.
Not sure what would happen if you substituted the kernel from an HDR hdf but it may be worth a try.
 
Back
Top