Http://blog.chinaunix.net/u/21948/showart_506112.html
Telnet is one of the simplest ways to log on to a remote network host, but it is very low in security. For the target board, you must execute the Telnet monitoring program to remotely log on to the target board. At the same time, if you want to remotely log on to other hosts through Telnet from the Development Board, you need to have Telent client.
Telnet tools on Embedded Linux systems include: · Telnet client busybox Telnet client. Busybox is designed for embedded systems. Its Telnet client is simple and easy to use. · The Telnet Server mainly includes telnetd and utelnetd. In terms of file size, utelnetd generates a smaller binary file than telnetd, but utelnetd does not support Internet super-server. Next, let's first look at the Telnet function of busybox. The client is simple. You can use it when you select it, while telnetd is relatively troublesome. Porting telnetd is not troublesome. busybox has already integrated one. However, because of configuration problems at the beginning, it takes some time to ensure stability. (1) telnetd configuration in busybox:
Networking Utilities --->
|
[*] Telnetd [*] Support standalone telnetd (not inetd only) |
The configuration description in this area. telnetd can be started by inetd or standalone. (2) After compilation, because telnetd is part of busybox, I used the dynamic compilation method when compiling busybox, so I only need to put the dynamic library that busybox depends on under/lib, we can ensure that telnetd does not have the problem of finding the dynamic library. Therefore, after make; make install, telnetd is deployed on the Development Board. However, telnetd cannot run normally. Refer to the help section When configuring telnetd:
A daemon for the Telnet protocol, allowing you to log onto the host running the daemon. please keep in mind that the Telnet protocol sends passwords in plain text. if you can't afford the space for an SSH daemon and you trust your network, you may say 'y' here. as a more secure alternative, you shoshould seriously consider installing the very small dropbear SSH daemon instead: Http://matt.ucc.asn.au/dropbear/dropbear.html Note that for busybox telnetd to work you need several things: First of all, your kernel needs: Unix98_ptys = y Devpts_fs = y Next, you need a/dev/PTS directory on your root filesystem: $ LS-LD/dev/PTS Drwxr-XR-x 2 root Root 0 Sep 23 13:21/dev/pts/ Next you need the pseudo do terminal master multiplexer/dev/ptmx: $ LS-La/dev/ptmx CrW-RW-1 root tty 5, 2 Sep 23 13:55/dev/ptmx Any/dev/ttyp [0-9] * files you may have can be removed. Next, you need to mount the devpts filesystem on/dev/PTS using: Mount-T devpts/dev/PTS You need to be sure that busybox has login and feature_suid enabled. And finally, you shoshould make certain that busybox has been installed setuid root: Chown root. Root/bin/busybox Chmod 4755/bin/busybox with all that done, telnetd _ shocould _ work .... |
The Linux Kernel configuration is satisfied by default. My error is mainly caused by mdev initialization. Because I am not familiar with mdev, it is unreasonable to arrange the File Mounting order. I always prompt that/dev/PTS cannot be found. For mdevos, follow the sequence of mdev.txt in the next document.
-------------
MDEV Primer
-------------
For those of us who know how to use mdev, a primer might seem lame. For
everyone else, mdev is a weird black box that they hear is awesome, but can't
seem to get their head around how it works. Thus, a primer.
-----------
Basic Use
-----------
Mdev has two primary uses: initial population and dynamic updates. Both
require sysfs support in the kernel and have it mounted at /sys. For dynamic
updates, you also need to have hotplugging enabled in your kernel.
Here's a typical code snippet from the init script:
[1] mount -t sysfs sysfs /sys
[2] echo /bin/mdev > /proc/sys/kernel/hotplug
[3] mdev -s
Of course, a more "full" setup would entail executing this before the previous
code snippet:
[4] mount -t tmpfs mdev /dev
[5] mkdir /dev/pts
[6] mount -t devpts devpts /dev/pts
The simple explanation here is that [1] you need to have /sys mounted before
executing mdev. Then you [2] instruct the kernel to execute /bin/mdev whenever
a device is added or removed so that the device node can be created or
destroyed. Then you [3] seed /dev with all the device nodes that were created
while the system was booting.
For the "full" setup, you want to [4] make sure /dev is a tmpfs filesystem
(assuming you're running out of flash). Then you want to [5] create the
/dev/pts mount point and finally [6] mount the devpts filesystem on it.
-------------
MDEV Config (/etc/mdev.conf)
-------------
Mdev has an optional config file for controlling ownership/permissions of
device nodes if your system needs something more than the default root/root
660 permissions.
The file has the format:
<device regex> <uid>:<gid> <octal permissions>
For example:
hd[a-z][0-9]* 0:3 660
The config file parsing stops at the first matching line. If no line is
matched, then the default of 0:0 660 is used. To set your own default, simply
create your own total match like so:
.* 1:1 777
If you also enable support for executing your own commands, then the file has
the format:
<device regex> <uid>:<gid> <octal permissions> [<@|$|*> <command>]
The special characters have the meaning:
@ Run after creating the device.
$ Run before removing the device.
* Run both after creating and before removing the device.
The command is executed via the system() function (which means you're giving a
command to the shell), so make sure you have a shell installed at /bin/sh.
For your convenience, the shell env var $MDEV is set to the device name. So if
the device 'hdc' was matched, MDEV would be set to "hdc".
----------
FIRMWARE
----------
Some kernel device drivers need to request firmware at runtime in order to
properly initialize a device. Place all such firmware files into the
/lib/firmware/ directory. At runtime, the kernel will invoke mdev with the
filename of the firmware which mdev will load out of /lib/firmware/ and into
the kernel via the sysfs interface. The exact filename is hardcoded in the
kernel, so look there if you need to want to know what to name the file in
userspace.
|
The modified initialization sequence is as follows:
[root@listentec ~]#cat /etc/fstab
proc /proc proc defaults 0 0
mdev /dev tmpfs defaults 0 0
|
[root@listentec ~]#cat /etc/init.d/rcS
#!/bin/sh
# Initial Environment
# mount /etc/fstab spcified device
/bin/mount -a
# mount devpts in order to use telnetd
/bin/mkdir /dev/pts
/bin/mount -t devpts devpts /dev/pts
# read the busybox docs: mdev.txt
/bin/mount -t sysfs sysfs /sys
/bin/echo /sbin/mdev > /proc/sys/kernel/hotplug
/sbin/mdev -s
# when mdev is mounted, /sys can be umounted
/bin/umount /sys
|
In this way, there is no problem.
[root@listentec ~]#cat /etc/inittab
::sysinit:/etc/init.d/rcS
::respawn:-/bin/login
::restart:/sbin/init
::once:/sbin/telnetd -l /bin/login
::ctrlaltdel:/sbin/reboot
::shutdown:/bin/umount -a -r
::shutdown:/sbin/swapoff -a
|
Currently, it can only be started separately. Inetd cannot be used. After testing, there is no problem. ========================================================== ============================ Run telnetd (and telnet server) then, other sites can log on via Telnet. 1. running telnetd is the same as running other system commands without parameters 2. you can also put it in/etc/init. in D/RCs, the system automatically starts # ------------------------------------- echo "Start telnet_server"
/Sbin/telnetd #-----------------------------------
