[BusyBox] Scriptable telnet?

[Rob Landley]

On Saturday 10 January 2004 17:56, Csaba Henk wrote:
> > > >
> > > > You can also use nc instead.
> > >
> > > The situation is that I want to script a telnet session. The best beast
> > > for communicating with a telnet server is a telnet client, ain't it?
> > > Using nc would mean writing a telnet client in shell... that's not what
> > > I want.
> >
> > I don't think so.  What are you trying to do?
>
> I want to make shfs (
>
> http://shfs.sourceforge.net
>
>  -- it is a shell based network filesystem) work with busybox as mounter
> and/or host. Currenlty shfs may use ssh and rsh for getting a remote
> shell. As busybox has client+server only for telnet, I thought the
> best/funniest solution would be porting shfs to telnet. Using busybox nc +
> a shell wrapper as telnet client is a possibility, of course.

It would be worth a try.

Also somebody's been proposing the integration of the "dropbear" ssh server 
into busybox.  I dunno if that has a ssh client as well, I'd check the list 
archives or the dropbear website...

> > Nc is basically telnet without the terminal control features.  It doesn't
> > do things like negotiate with the telnet server to propogate environment
> > variables, and other such complexity.  It just connects stdin an stdout
> > to a remote socket through the network.  Exactly what you want for
> > scripting purposes.
>
> If I want to connect to a telnet server, I do have to negotiate with it.
> I didn't really succeed in it... I tried
> "echo -en 'ls\r\0' | nc <host> <port>" and many similar commands, with
> busybox and inetutils telnet servers. With bb telnetd, sometimes the
> output of the command came back, sometimes didn't, it was very rhapsodic,
> I don't know what it depended on.

It's a race condition depending on whether or not EOF from stdin and the 
resulting close of the network conection was registered before the result 
came back from the far end.  When it works, the sequence is:

1) Read data from stdin.
2) Write data to network.
3) Read data from network.
4) Write data to stdout.
5) Read EOF from stdin.
6) Close and exit.

The write in step 2 causes a schedule, and if you aren't scheduled back fast 
enough there's already data waiting for step 3.

When there isn't, steps 5 and 6 happen immediately, so even though there's 
data waiting it doesn't get it.

I fixed this in my copy of nc.  If busybox's has this problem, I'll fix it in 
busybox.

> With inetutils telnetd, I had no success
> at all. Any hints are welcome on how to get it working.

It needs to use shutdown instead of close.  Here, I attached my old version so 
you can see what I did.  Mine isn't really optimized for anything, it was a 
quick hack to do what I wanted.  It doesn't even look up the destination 
address by name (needs an IP address), but it DOES get 'echo "GET /" | nc 
1.2.3.4 80' right.

> Csaba

Rob
-------------- next part --------------
A non-text attachment was scrubbed...
Name: netcat.c
Type: text/x-csrc
Size: 3941 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/busybox/attachments/20040112/169bb1f6/attachment.c