1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Enabling telnet on the Foxsat-HD

Discussion in 'FOXSAT-HD Freesat Receiver' started by garynl, Jul 8, 2012.

  1. garynl

    garynl New 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).
     
  2. raydon

    raydon Well-Known Member

    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
     
  3. garynl

    garynl New Member

    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)
     
  4. xyz321

    xyz321 Well-Known Member

    I'm not sure if this is just a typo. in the message here but it should be '/bin/sh' (no trailing /).
     
  5. af123

    af123 Administrator Staff Member

    That isn't relevant. Nothing is compiled with libwrap so that file isn't used.
     
  6. raydon

    raydon Well-Known Member

    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.
     

    Attached Files:

  7. garynl

    garynl New Member

    @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.
     
  8. garynl

    garynl New Member

    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?
     
  9. raydon

    raydon Well-Known Member

    Can you ping the HD from your PC ?
     
  10. garynl

    garynl New Member

    by ip address, yes, but it's not visible in the network
     
  11. garynl

    garynl New Member

    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?
     
  12. raydon

    raydon Well-Known Member

    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
     
  13. garynl

    garynl New Member

    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.
     
  14. raydon

    raydon Well-Known Member

    It's a long shot but try changing mount_path to /tmp/$MDEV instead of /media/$MDEV as that is in writable tmpfs also.
     
  15. garynl

    garynl New Member

    No, that didnt work either. This is crazy, I must be missing something basic.
     
  16. raydon

    raydon Well-Known Member

    Did you allow the box to fully boot before inserting the USB stick ?
     
  17. garynl

    garynl New Member

    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)
     
  18. raydon

    raydon Well-Known Member

    I wouldn't worry about the zombie, at least the telnet process is running. It's devpts thats your problem.
    Attached files ??
    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.
     
  19. garynl

    garynl New Member

    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.)
     
  20. raydon

    raydon Well-Known Member

    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.