We have a customer that has Telnet sessions disconnecting overnight. These sessions aren't logging off, they're just disconnecting, presumably from inactivity. But the guy who owns the server says he doesn't have anything set up to do so. One thing we've noticed is that when logging in, we get this message:

/dev/pts/6: Connected to Virtual Machine 'pick0:AIX'.
WARNING: -icrlf ignored. Specify a port when using this option.

I'm assuming this "-icrlf" is coming from AIX, because of the hyphen. But nobody can figure out what command this could be coming from, or if it has any bearing on disconnecting Telnet sessions. Anybody know?
---
Rod

just a guess crlf = carriage return linefeed? or did you already know that

I googled icrlf and did find some items related to terminal i/o

Rich

Rod wrote:

google did return the following
when I search "-icrlf"

http://forums.rainingdata.com/index.php?showtopic=720

Rod wrote:

Interesting that the post in your link got the message from Linux, while my customer is AIX. Must be something pretty generic. The carriage return/line feed is interesting; wonder what the "i" is....

"Richard Wilson" <rwilson (AT) lakeside-systems (DOT) com> wrote

I would assume "i"nsert so the -i means dont, I dont remember which one generic
unix uses but is either cr or lf but not both

Rod wrote:

-icrlf is a switch for the "d3" command which opens a D3 connection in
all *nix platforms. It was previously undocumented in the D3 Ref
Manual but it's in the new v7.5 manual. The text there simply says
"Ignores the linefeed character when sent after a carriage return."
I'm surprised that you're getting this message: "Specify a port when
using this option." I suspect it's a bogus message that RD will patch
if they're notified.

This probably has nothing to do with your disconnections. If your
client telnet session is running through a firewall then chances are
you need a heartbeat between client and server. AccuTerm has a simple
checkbox just for this purpose.

To avoid losing licenses or having the processes in a weird state:
Put this in user-coldstart:
trap dcd exit
Put this in the set of macros executed in all Users file items:
dcd-on
When the connection drops, D3 gets a message that the "data carrier
detect" has dropped. This message is trapped and the exit command is
issued to the port on the server side to wrapup the process. (Someone
with a better clue can explain how DCD works with a TCP-based telnet
protocol, since it was designed for serial connections. I think D3
gets or generates a SIGHUP, not sure.)

If the firewall/heartbeat is not the issue, please tell us more about
the environment. Where is the client in relation to the server?
Which version of AP or D3 are you running? Is this a new problem or
old? Have you contacted RD?

HTH
Tony
TG@ removethisNebula-RnD.com

"Rod" wrote:

Rod wrote:
It stands for "input". The D3 command took as its model the *nix "stty"
command, which doesn't actually have an "icrlf" option, but does have an
"icrnl" option.

Luke

"Tony Gravagno" wrote
<<snip>>

rename /usr/lib/pick/d3 to /usr/lib/pick/d3.orig and craft a shell
script /usr/lib/pick/d3 or name it d3 somewhere else on your users'
PATH string, and have it strip out the offending arg(s) when it invokes
d3.orig, or explicitly mention a port, or something. I love kludges...

"Frank Winans" wrote:
I think that's a little too much of a kludge, Frank. His users login
to AIX and a .profile or some other script is executing which then
puts them into D3. That script probably includes:
d3 -n -icrlf -otheroptions...
Popping that -icrlf might be the easiest fix, though it might have
been put there for a reason too. For all the time that's being spent
on this the end-user could have called RD.

<sidenote>
We're assuming this end-user is on D3/AIX. For all we know this site
is running AP/AIX 6.1 or similar, in which case change 'd3' to 'ap' in
all of the above. Many D3 sites with "slower to change" admins still
use 'ap' to login and for their scripts rather than 'd3', so the
command doesn't indicate the release. I only mention this because
there might have been a valid reason for older releases to have -icrlf
that's no longer present on that system. No clue, no one is paying me
to do the research.
</>

T

Tony,

The USER-COLDSTART does have the TRAP DCD EXIT command, but no users have
the DCD-ON in them. Interestingly, this system had not been rebooted in
some time. They hadn't tried that yet because it's a painfully slow machine
to reboot. But it worked; they don't get the disconnects any more.
---
Rod

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote