avalon@coombs.anu.edu.au (Darren Reed) (06/30/91)
G'day, I'm trying to write a program which will run on a port and is accessed by telnetting to that port. All the socket stuff is ok (binds, listens, accepts, forks, etc) but it seemed that something was missing when everything i typed appeared twice. Now it seems that telet always ECHOs you input unless you tell it to turn off (and various other modes too) and this is done using OOB data. fine, so i grabbed telnet/telnetd source code to have a look at how OOB data is done...yuck. I tried to implement something to send some OOB commands for telnet but doing this only locked up the telnet session. :-/ What is the correct way to use send() and OOB ? I did something like this: int fd; char oob_cmd, buffer[any_size_you_like]; ... setsockopt(fd, SOL_SOCKET, SO_OOBINLINE, 1, sizeof(int)); ... send(fd, buffer, strlen(buffer), 0); send(fd, &oob_cmd, 1, MSG_OOB); Also, if i use OOB data, will OOB commands sent back to me from telnet stop other data from flowing until the OOB data has been cleared ? There is very little info about this in the manuals save a few references to OOB data in recv(2), send(2) and various other places where its an option or something. Does anybody know how I should be going about telling telnet *not* to ECHO, etc ? thanks, -avalon
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (07/01/91)
In article <avalon.678295705@coombs> avalon@coombs.anu.edu.au (Darren Reed) writes: > Does anybody know how I should be going about telling telnet *not* > to ECHO, etc ? telnet implements the TELNET protocol. If you want to talk to telnet, you have to speak TELNET too. Anything else is an invitation to disaster. Can you guarantee that telnet won't receive keyboard signals? Do you know what you have to do with an \0xff over a TELNET connection? The echo you're seeing is the normal echo from your tty. You can turn that off with stty, ioctl(), or from the telnet command line, but unless your server groks TELNET you should expect a continuing series of interoperability problems. For a straight TCP connector without any weird protocols in the middle, you can use tcpclient and tcpserver in my clientserver package, just posted to alt.sources. One advantage of this is that you'll be able to use exactly the same code on top of undomclient and undomserver, or npipeclient and npipeserver for System V, or the forthcoming krb5client and krb5server, or any other set written to the same interface. In any case, you can set up a server like this: servermachine% tcpserver 0 <portnumber> <server to run> & and connect to it like this: clientmachine% tcpclient servermachine <portnumber> <client to run> & and stop it like this: servermachine% tcpkiller 0 <portnumber> That's it. No privileges required to compile and run the tcp toolset. The client and server get environment variables showing who they're talking to, so you can add security if you want. In this case, it sounds like you want to turn off echo, maybe run some full-screen application; <client to run> can do the appropriate stty or ioctl(). ---Dan
mycroft@kropotki.gnu.ai.mit.edu (Charles Hannum) (07/01/91)
In article <21071.Jun3021.48.4291@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > telnet implements the TELNET protocol. If you want to talk to telnet, > you have to speak TELNET too. Anything else is an invitation to > disaster. Can you guarantee that telnet won't receive keyboard signals? > Do you know what you have to do with an \0xff over a TELNET connection? > > The echo you're seeing is the normal echo from your tty. You can turn > that off with stty, ioctl(), or from the telnet command line, but unless > your server groks TELNET you should expect a continuing series of > interoperability problems. Good so far. RFCs 854 and 856 (which I mentioned in my *last* article about two minutes ago) would come in handy here. > For a straight TCP connector without any weird protocols in the middle, > you can use tcpclient and tcpserver in my clientserver package, just > posted to alt.sources. One advantage of this is that you'll be able to > use exactly the same code on top of undomclient and undomserver, or > npipeclient and npipeserver for System V, or the forthcoming krb5client > and krb5server, or any other set written to the same interface. In any > case, you can set up a server like this: (More product announcement than information...) Not so good. Some times we need to stop pushing our product, step back, and take a good look at the situation. My impression was that he wants J. Random Luser to be able to connect via telnet, not some random client that they have to compile themselves. To do this, his only option is to teach his server telnet, a very messy and unpleasant business, but one that more people should start thinking about.