Xref: utzoo news.software.nn:1181 comp.unix.sysv386:1647 Path: utzoo!utstat!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!icom!xwkg.Icom.Com!andy From: andy@xwkg.Icom.Com (Andrew H. Marrinson) Newsgroups: news.software.nn,comp.unix.sysv386 Subject: Interactive rlogin problem with nn Summary: nn with ISC's rlogin/rlogind loses big due to urgent pointer problems Keywords: nn, rlogin, rlogind, urgent, oob, ISC Message-ID: Date: 29 Oct 90 19:45:14 GMT Sender: news@icom.icom.com (News Feed) Organization: Icom Systems, Inc. Lines: 39 Hello, I am having a very strange problem trying to use nn across an rlogin session under Interactive Systems release 2.0.2. I have nn version 6.4.9. The problem is that whenever I run nn while logged in from another machine via rlogin some output disappears. The problem only occurs when both client and server rlogin are ISC's. The problem goes away when either client or server (or both) are (e.g.) SCO ODT. The problem also does not occur with telnet (including ISC's). It does seem to occur with ISC's new 2.2 Unix (at least as a client). The strange thing is it only happens with nn! No other program does this including rn, emacs, vi, etc. Further investigation with a network analyzer shows that the missing data is always the contents of a packet with the urgent pointer set. The urgent pointer points to the last byte of the packet which contains the value 03H. I have looked at the latest rlogind source, and as far as I can tell, this might happen when input and output are being flushed. Unfortunately, I can't figure out where nn might be doing this. A quick check of term.c shows an ioctl to flush the input, but a quick test program that does that doesn't reproduce the behavior. At this point I am not so much looking for a fix, I'd be happy to find someone who has had similar problems with nn or another program. Also, anyone who has any idea under what circumstances ISC's rlogind would send OOB data as described above would be helpful. The rlogind source I have is almost certainly newer than what ISC based their port on, so it only gives me an idea of what might be happening. This is a real drag. Any help at all would be appreciated. Thanks in advance. -- Andrew H. Marrinson Icom Systems, Inc. Wheeling, IL, USA (andy@icom.icom.com)