Hi.

Could someone who already installed a telnet server on his empeg write a HOWTO or make a tar-ball with the necessary files available? I would like to have a telnet server on my empegs, but I simply don't have the time currently to work out how to do it resp. which files are needed.

cu,
sven

Here is a telnet daemon I downloaded long time ago but I cannot find where (sorry).

It is a debian package I haven't tested because I dont have Debian distro but you can extract it with alien on a Linux Box.

I think you just have to add it in your init scripts.

That package depends on a couple of other packages, whos content (or equivalents) might not be available on the empeg by default, forcing you to go hunt down those packages too - and those might have dependencies of their own...

Meaning it (probably) isn't just to drop in the telnet binary and go telnetting...
Therefore (at least that'd be the reason I would ask I if were to set up telnet) the request for a tar-ball with the needed stuff, or a description of what's needed, instead of working through the dependencies again.

/Michael

I installed that telnet package today. But it didn't work. I'm pretty sure the problem has something to do with the fact that there isn't a /etc/passwd file, or login and tty binaries on there.

I'm no expert, but that's just my 2 cents

-B

Okay. Here's a 5 minute hack to do a telnet server. It doesn't work quite 100% at the moment because I'm not dealing with a lot of the TTY bits.

You'll need to turn on new linemode if the display is odd looking. I've only got SCRT so I can't tell you how to do it in anything else.

YMMV

I'll finish it off later on.

- Trevor

quick hack:

setup debian as per riocar.org faq
adduser username
setup dns (add "nameserver x.x.x.x" to chroot'd /etc/resolv.conf)
apt-get update
apt-get install telnetd
apt-get install rsh-server (if wanted)
/usr/sbin/inetd (probably should add to init.d properly so it gets started on reboot)

Hi.

Getting telnetd (and other) to work properly is exactly what I am after, but I wont to keep the overall memory footprint as low as possible, so I hoped to be able to path a telnetd to be standalone (not using inetd) and dynamically linked (which the debian probably is). But moreover, I was hoping to get it to work with minimal extra files (such as /bin/login, /etc/passwd, /etc/group,...), preferably with username/password set by config.ini options instead. But I guess that won't be doable without major hacking on the telnetd sources (which seem to be pretty hard to get, by the way).
These are all steps on my way to the creation of a custom .upgrade image which installs some add-on software on the empeg and will, most notably, make installation and updating of custom apps even more easy than it is now thanks to marks HiJack kernel and the pre-init/custom-init scripts.

cu,
sven

Hi.

Would you mind releasing your sources?

cu,
sven

PS: I am using SCRT as well, most of the time.

Sure. It's only a quick hack at the moment until I can get around to doing it properly.

It's not actually using a pty/tty at the moment so it's going a little bizarre. I'm a bit overloaded with work at the moment.

- Trevor

Anyone know what it would take to get this telnet app to output properly formatted lines? I am quite impressed with it so far!

Maybe Mark could add this to hijack?

I second that notion. Smashing good app. Cant' wait to V.2.

If someone produces (or finds) a telnetd that fits in say 100-200 lines of C, uses PTYs, and has a low memory footprint.. then yes!

Since you mentioned elsewhere that you thought you saw a small telnetd implementation in an early BSD release, I went looking. The earliest BSD I could find that had a telnetd is 2.10BSD. 2.9BSD might have it, but I can't find the source for it easily, and 2.8BSD didn't have one. Anyway, the source is about 1200 lines of C and uses a lot of old sgttyb-type stuff that I'm pretty sure Linux no longer supports. It should be possible to port it, but I, honestly, don't really feel like it.

For anyone who's interested, here's a copy of the 2.10BSD source. 2.9BSD is there, as well, but it's not in an easy-to-get-at form. And here's a BSD Family Tree if anyone wants to try to find a different one. (IIRC, most of the 3/4.xBSD trunk was not freely available. Most of the changes in them were ported over to the 2.xBSD trunk, which were free. Then, starting with 4.3BSD, the free versions started being something else. The last free version was 4.4BSD Lite. But they all have enormous telnet servers anyway.)

Mmm... maybe it was a Minix server I saw.. or perhaps just something from one of R.Stevens' books..

? -ml

Would a properly compiled Minix server work on empeg?

Yes, it should.

-ml

This busybox implementation is the smallest I've found (4kB source)
ftp://ftp.simtreas.ru/pub/my/bb/ports/telnetd.c.gz

Okay, I've compiled the busybox implementation of telnetd.
Works quite well with the preinit utility.

It is incredibly slow when the player is running though! Pause the player if you want to do anything. I'll see if I can get around this

To install:
Upload the attached file to the empeg
Untar it (tar zxvf emptelnetd.tar.gz)
Run the devs file
You can delete the devs file and the emptelnetd.tar.gz files from your empeg now.

And finally run telnetd

YMMV

- Trevor

Nice! Thanks a bunch, this will make life easier.

nice seemed to make it more responsive with the player running:

nice -10 telnetd

Not sure if it really helped since even without it telnetd sometimes responded well.

Cheers,

Rex.

Great work tman. Properly formatted lines and the whole bit!

True, nice will raise the priority of the telnetd but as long as it's still scheduled with the default scheduling policy, it may still be sluggish. I'm at work so I haven't tried it yet but if telnet speed while the player is running is really important to you, you'll want to add code to change the sched policy.

Or maybe modify the code so that it does not give up its timeslice so easily.

Or maybe modify the code so that it does not give up its timeslice so easily.

Give up its timeslice? Other than sched_yield (which I don't see in the code) or blocking I/O, I don't know of any other way user programs "give up" their timeslice... Is there something in the telnetd source that isn't right?

That's pretty much it -- any syscall() to the kernel, particularly blocking I/O, or page faults, can result in giving up the timeslice. One trick to writing fast code is to structure it so that such occurances are contained and minimized.

Don't ask me to dig through this code, though. I'd rather just write a simple replacement for it.. and I'm not even doing that.

Cheers

Don't ask me to dig through this code, though. I'd rather just write a simple replacement for it.. and I'm not even doing that.

Wasn't even thinking of asking you for that, especially when it's already a user app... You know I have (*cough* disk writing) other things (*cough* mmap display buffer) that I would (*cough* multiple overlay apps running simultaneously) much rather you spent your time on.

I was just curious since it sounded to me like you saw something obvious in the telnetd code that I couldn't find. That stuff looks pretty lean 'n' mean to me.

Hmm...maybe it's nearly time for me to learn the intracacies of socket programming and kernel threading...surely this thing could be integrated into khttpd/kftpd somehow?

I could change the daemons scheduling algorithm but I really don't want to do that.

The main loop in the daemon continually does syscalls to read/write the sockets. Which is why I guess it's not getting much CPU time as the player seems to be running at a higher priority.

I may just leave it as is though. How many times do most people need ethernet shell access to the player really? If necessary just pause it?

Anybody got any good arguments for changing this?

- Trevor

I think it's fine as-is for its purpose...haven't really noticed the speed issue myself.

Probably not a big deal. I was just mentioning it because someone said it was running real slow. If it's too slow then going to realtime scheduling would help, and as long as the priority wasn't too high, wouldn't interfere with player operation. A couple of the things I've wrote are using round-robin scheduling and the speed difference was very noticable, but they're doing more complex things than a telnetd would be doing.

So, leave it as is.

Well. I was the person originally that said it was quite slow. This was to basially stop any people asking if they've broken it or not installed it properly

But I do agree with you, for a telnet daemon it's just not worth it

- Trevor

Does this daemon need to be run from a terminal login(serial) every time you want to be able to telnet in via ethernet?

Nope. If you install Bitt Faulk's preinit utility then you can start up the telnet daemon every time the empeg reboots. That's what I'm using to do it anyway.

- Trevor

ok, sorry if i'm seeming like i'm needing a walkthrough, but I can't seem to find any docs on this preinit. I installed it (I think, per windows/DOS instructions). Now what?

nevermind, I found the old post about VNCserver describing it's use

thanks

ok so I have installed telnetd into /empeg/bin
I installed preinit
and I created a script calle N10telnetd that looks like
#!/bin/sh
/empeg/bin/telnetd

I tried to run it at mount with M10telnetd

But no luck. if I run telnetd from the shell I can get it to work.

It just won't automatically start.

Make sure your script has exec privs.

chmod +x N10telnetd

Make sure your script doesn't have windows line feeds, use TextPad or something similar to create the file.

Tom

Actually, it doesn't need to be set executable. Doesn't hurt if it is, though. The CR/LFs are probably the problem. To test, you could run ``/bin/sh /etc/preinit.d/N10telnetd'' and see if that works. If it doesn't, then the problem is with the script.

It is set to executable, and running it via
``/bin/sh /etc/preinit.d/N10telnetd'' works

but it still does not run at boot time

Hmmm.

Do you have other startup scripts? Do they work? Can you see preinit starting on boot at the serial console? Try adding some echo lines in the N10telnetd startup script and see if they get printed out.

Hmm Perhaps preinit didn't get installed correctly?

What should we see on the serial if preinit starts correctly?

empeg-preinit starting...

and

empeg-preinit complete

Along with some other things if errors occur.

Okay, I've compiled the busybox implementation of telnetd. Works quite well with the preinit utility.It is incredibly slow when the player is running though! Pause the player if you want to do anything.
To install:
Upload the attached file to the empeg
Untar it (tar zxvf emptelnetd.tar.gz)
Run the devs file
You can delete the devs file and the emptelnetd.tar.gz files from your empeg now.


How exactly does one "Run the devs file"
I imagine it involves hyperterminal, which I can do,
I've uploaded emptelnetd.tar.gz
I've done the tar zxvf emptelnetd.tar.gz
This is where I get stuck...
I just can't seem to figure out how to "Run the devs file"
from there I think I can swing it,
I was able to get the viewer running at boot time last night.

Not having played with the package in question, so I might be wrong, but:

from the comand prompt and in the directory where you placed the devs file:
#make it executable
chmod 755 devs
#run it
./devs

/Michael

Yep. What you said

- Trevor

Okay, I've compiled the busybox implementation of telnetd.

Sorry to resurrect an old thread, but does anybody know if it is possible to get this to require authentication? I don't want to do the whole login/password file deal, but a single hardcoded password like hijack can use for kftpd would be nice for when my empeg is on the company network.

-Mike

Haven't looked to find out. But it'd be nice.

Actually, telnetd in kernel space would be nice

Sure. It shouldn't be hard to change it to do that. It's either revert it back to the original method where it executes /bin/login or I suppose I could hack it into the telnet daemon directly. I'll have to think about it. On one side it's easier to write but ont he other it means having to deal with more than one file.

- Trevor

There is no /etc/passwd, and IIRC no /bin/login either on the empeg.
The ideal thing to do (from the users' perspective) would be to use a config.ini password, but you might have a problem trying to read config.ini at that time - hijack and the player app are already fighting over it.

Yeah I know. I'm just saying that originally the busybox telnet daemon would run /bin/login to do the username and password checking then finally run the shell.

I would write a empeg specific login. Or I could change the telnet daemon to do the authentication itself. Not sure.

Okay, it's not optimal about disk access but if I just make it read config.ini each time it receives a connection then it shouldn't have to worry about problems with accessing config.ini. Or it could cache the password the first time it's needed. This last option could be confusing for users though.

- Trevor

There are NO issues with lots of apps trying to read the same file at the same time, not even config.ini (in Hijack v309).

Cheers

Ok, I mis-read or mis-understood something somewhere. I'm glad that you've corrected me as I couldn't understand why there should be any issues.

Well, there may (or not) have been a conflict in earlier Hijack versions with config.ini, buy not now.

Cheers

Did you ever get this working? I found that I needed to place telnetd into a directory that was seen at boot time. I was having problems when telnetd was in /drive0/var/..., but when I moved it to /bin it works no problem.