mbb@trotter.usma.edu (MAJ Mark B. Bilodeau) (10/15/88)
A number of indivduals responded to my resent request for help by email. I've summarized the basic points in what follows. The basic point was that the telnetd is not totally transparent, i.e. it expunges 0xff bytes. There are a number of ways around this problem ranging from using the SYSV TLI/TLIS protocols to modifying uucico. I decided to modify uucico by 1) creating a uucicod at port address 2000, and 2) changing uucico to call port 2000. This solved the problem and has been working well for the last week. the only non- obvious glitch was that tcplisten sets SIGCLD to SIG_IGN which causes a wait(2) call to wait for all children to terminate and then return a -1. This showed up as uuxqt being unable to post mail using rmail! If anyone is interested in the mods to the uucp sources, I can provide a patch file. Thanks, Mark
hedrick@geneva.rutgers.edu (Charles Hedrick) (10/19/88)
>The basic point was that the telnetd is not totally transparent, i.e. >it expunges 0xff bytes. There are a number of ways around this Telnet is a protocol. It allows transparent connections. It sounds like your problem is that you're trying to talk with telnetd without following the telnet protocol. 0xff is used by telnet as an escape. That is 0xff followed by another character is a special function. But 0xff 0xff turns into a real 0xff. Thus you can send any character over a telnet connection. We successfully do both UUCP and xmodem over telnet. However with our cisco terminal servers, the user has to issue a command "term download" in order to get CR handling that is completely transparent. As I recall, here's what you have to do in order to get transparent behavior with telnet: when sending: 0377 --> 0377 0377 015 --> 015 000 when receiving 0377 0377 --> 0377 0377 other things: see the telnet spec. You may be able to get away with ignoring them, but you're really supposed to respond to these special codes. If you want to try ignoring them, you're likely to have to skip 2 bytes after that 0377. 015 000 -> 015 015 012 -> depends upon your telnetd. Probably can stay 015 012, but you should check. Could need to get turned into bare 012. Note that Berkeley UUCP already supports telnet over TCP connections, so you really should ask your vendor to support uucpd. If you're going to do your own, try to use the same protocol on the same port number (but do pick a different port number if you're not sure you are compatible).