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.