Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!ginosko!uunet!cbmvax!grr From: grr@cbmvax.UUCP (George Robbins) Newsgroups: comp.unix.ultrix Subject: Re: Ultrix 3.1 vs. LAT Summary: let me count the ways... Message-ID: <7402@cbmvax.UUCP> Date: 22 Jul 89 08:48:33 GMT References: <7399@cbmvax.UUCP> Reply-To: grr@cbmvax.UUCP (George Robbins) Organization: Commodore Technology, West Chester, PA Lines: 47 In article <7399@cbmvax.UUCP> grr@cbmvax.UUCP (George Robbins) writes: > Sigh... > > At first glance, it looks like the ability to do high-speed protocol > based file transfers through an incoming Terminal Server/LAT port is > screwed up even worse than before. Some first level debugging has turned up the following problem: In version of Ultrix prior to 3.1, doing a "stty raw" or the equivalent stty/ioctl calls would automatically switch your terminal server session to "passall" mode for the duration of the period raw mode was set. After applying the Ultrix 3.1 update, this no longer happens; making "binary" transfers thru terminal server ports fail due to such things as "flow control" characters and server local/forward switch characters. I would expect this would also screw up gnu emacs users of the flavor that believe that control/s has something to do with searching, though I haven't investigated this... Example: (make sure you're using "sh", /usr/new/csh mucks with tty modes!) With Ultrix 3.0 (and previous): $ stty raw $ stty sane With Ultrix 3.0 (and previous): $ stty raw this is wrongo! $ stty sane Whatever problems that caused Ultrix 3.0 LAT suport to not work with Kermit/Xmodem/etc. may still be there, I'll have to try some testing after manually doing a "set session passall" on the terminal server and see what else fails. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)