telnetd don't honour baud rate?

[John Fjeldberg]

Greetings all,
We have an in-house developed application running on our HPUX server. As our application supports client applications running over serial communication from local PC's, we use Cisco 2511 serial access servers to telnet to our server for the users.

Recently we upgraded our old servers from PA HPUX 10.20 to PA HPUX 11.11, and we noticed some performance issues.

After a long investigation we discovered that while the telnetd on the 10.20 box seems to honour the 9600 bps request in a speed test, as requested by the access server in the initial telnet setup messages (SB 32 0 [9600,9600]) the new 11.11 box seem to have no limits and was clocked at sending data at around 600k bps to the access server.

The result is now that the telnet client in the access server gets flooded and seems to panic and our client applications locks up as no data gets sent to it. The configuration of the access server remains unchanged.

I have applied the following patches without any result:
PHNE35508 Telnet, Telnetd
PHNE35351 cumulative ARPA Transport patch

Our application uses “termio.h”, normal open(“/dev/tty” and sets the parameters using ioctl() for the tty interface. The same settings are both being used on the old system and the new.

I’m fairly new on this, and I’m sure I have overlooked something, but any suggestions why the “telnetd” don’t seem to behave in the same way on the new box as on the old box would be much appreciated. Let me know if you need any more details, log, etc.

Thanks in advance!

[Steven E. Protter]

Shalom,

swlist -l fileset
swlist -l product

You have taken a find the exact patch I need approach. This sometimes deals with specific problems. My approach to HP-UX is to stay within 12 months of current on bi-annual patch sets.

These are big and deal with many performance problems. The first thing I would do is get of the last two bi-annual's on the system. The problem may be related to inetd or other issues that have not been dealt with yet.

Don't forget to take an Ignite backup before patching.

SEP

[Joelmel Roche]

HI,
Try this..

man telnetd:

When a TELNET session is started up, telnetd sends TELNET options to
the client side, indicating a willingness to do remote echo of
characters, to suppress go ahead, and to receive terminal speed and
terminal type information from the remote client.

The terminal speed option permits applications running on a remote
host to obtain the terminal speed of the local host session using
either ioctl or stty.

-y Set the behavior for stty 0 to instruct telnetd to
close the connection on the shell command stty 0
or whenever the telnet client communicates with
telnetd to arrive upon 0 baud rate for
TELOPT_TERMSPEED.

[John Fjeldberg]

Hi,
the -y option appears to work as specified by closing the connection to terminal if I set the speed to 0 bps (stty 0), however, it still don't seem to make the telnetd honoring the speed, as I still clock it to over 500k bps, when it was suppose to be 9600 bps.

I will attempt the annual patches as suggested tomorrow, thanks for you support so far!

Cheers!

[Bill Hassell]

The Cisco box appears to be a serial to LAN adapter, taking serial connections and turning the characters into the telnet protocol. telnet has no connection to the Cisco settings unless you have a special driver installed. It just handles the packets as they are presented by the Cisco box. Now if you can use termio system calls to set the baud rate and other parameters, carefully look at the release notes for 11.00 *and* 11.11 for changes to the termio code. Also compare the man pages from both systems. 10.20 to 11.11 is a major jump so the interface to termio may have changed.

[John Fjeldberg]

To clarify, the Cisco box does actually implement a full Telnet client for each of the serial adapters. The result is that you can have a e.g. VT100 capable terminal client without telnet capabilities (e.g. Hyperterminal)and still access the system via your serial port.

The core of the problem here is that the HPUX telnetd does not seem to honour RFC1079, despite in its setup conversation with with the Cisco box are saying so (see attachment).

[John Fjeldberg]

I've now also ensured that the "BUNDLE11i_B.11.11.0306.1.depot" patch bundle has been applied, which I think is the latest, but it don't seem to make any change. I really don't want to upgrade the system to 11v3 over something this small...

[Joelmel Roche]

Hi John,

I think you need to check the network parameter on cisco.

Pls attach the syslog.log

[John Fjeldberg]

I can't find any warning messages related to telnet startup, or when the user logs in in the syslog.log. I know the settings on the Cisco box are correct as they have been verified with the 10.20 box, and if you look in the log file I attached previously you will see they are negotiating the speed successfully, and as I have verified by measuring the telnet stream. Anyway, I've attached a snipped of the syslog.log from the inetd was restarted if it is of any interest.

Thanks for you help anyway! I might log a call with HP in the end anyway.

[Joelmel Roche]

Hi, Check this..

Patch info file PHNE_31807.text
Local online retrieval by getcattext.pl version : 2.00 $ on 290807

--------------------------------------------------------------------------------

Patch Name: PHNE_31807

Patch Description: s700_800 11.11 telnet kernel, telnetd(1M), telnet(1) patch

Creation Date: 04/10/06

Post Date: 04/10/06

Hardware Platforms - OS Releases:
s700: 11.11
s800: 11.11

Products: N/A

Filesets:
Networking.NET2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP
Networking.NET2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP
InternetSrvcs.INETSVCS-RUN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP
InternetSrvcs.INET-ENG-A-MAN,fr=B.11.11,fa=HP-UX_B.11.11_32/64,v=HP

Automatic Reboot?: Yes

Status: Beta Release

Critical:
Yes
PHNE_31807: HANG PANIC
PHNE_28841: ABORT
PHNE_24829: MEMORY_LEAK
PHNE_24131: MEMORY_LEAK
Memory leak in telnetd

Category Tags:
defect_repair enhancement trial_patch critical panic
halts_system memory_leak manual_dependencies

Path Name: /hp-ux_patches/s700_800/11.X/PHNE_31807

Symptoms:
PHNE_31807:
SR 8606292872 / CR JAGae56622
1. Data flow hangs in kernel telnet sometimes.

SR 8606367869 / CR JAGaf28433
2. System may panic with the following stack trace when
telnetd is used with -z and -s options :

freeb+0x3b8
tcp_rput+0x28b4
puthere+0xc8
tcp_rput_context_check+0x1c4
tcp_rput+0x328
str_spu_sw_isr+0x1a0
sw_service+0x100
mp_ext_interrupt+0x14c
ihandler+0x90c

PHNE_30672:
SR 8606354753 / CR JAGaf15516
1. telnet client receives some unwanted characters in
response to the "send ec" command.

PHNE_28841:
SR 8606199877 / CR JAGad69063
1. telnet, in the Secure Internet Services environment,
fails to forward credentials when KDC is Windows 2000,
and the user is a member of a large number of groups in
the KDC. In some cases, telnet may dump core when the
credential size is large.

SR 8606267498 / CR JAGae31740
2. telnetd replies to TELNET NOP sequence.

SR 8606224447 / CR JAGad93535
3. In Secure Internet Services(SIS) environment, telnet
does not read default SIS options specified in the
[appdefaults] section of krb5.conf file.

SR 8606224214 / CR JAGad93309
4. In Secure Internet Services(SIS) environment, telnet
does not use normal authentication if Kerberos
authentication with the remote server fails.

SR 8606248696 / CR JAGae15094
5. telnetd exits when the telnet client sends an IAC
sequence (authentication option) with NULL authentication
type.

SR 8606224774 / CR JAGad93862
6. Credential cache file created by PAM Kerberos is not
cleaned up when telnetd exits.

PHNE_24829:
SR 8606212875 / CR JAGad82062
1. Buffer handling in telnetd needs to be enhanced.

SR 8606212874 / CR JAGad82061
2. Telnetd has a service issue.

SR 8606220839 / CR JAGad89975
3. Incorrect records might be written into /etc/utmpx
by telnetd when it exits.

SR 8606230839 / CR JAGae00077
4. Credential forwarding to telnetd fails in DCE
environment.

SR 8606238651 / CR JAGae07675
5. If telnet is invoked with the "-f" or "-F" option or
using the TACACS mechanism, the TERM environment variable
may not be set.

SR 8606232804 / CR JAGae02032
6. Provide a command line option in telnetd to close the
telnet connection when "stty 0" command is executed.

SR 8606231734 / CR JAGae00970
7. IPv6 connection might be closed by telnetd(1M).

SR 8606236626 / CR JAGae05679
8. Memory leak in telnet multiplexor.

SR 8606261511 / CR JAGae25830
9. Use of malloc(3C) in telnetd signal handler.

PHNE_24131:
SR 8606182980 / CR JAGad52196
1. telnetd does not close the connection when stty 0 is
executed.

SR 8606176054 / CR JAGad45294
2. Memory leak as telnetd does not manage telnet queues
properly.

SR 8606157405 / CR JAGad26736
3. telnet daemon sets the pty speed to 0 if the telnet
client speed is > 38400

SR 8606114446 / CR JAGac29210
4. telnet hangs with "Reflection1", a terminal emulation
software used by Windows telnet client when displaying
large files.

SR 8606188928 / CR JAGad58144
5. While transferring huge amount of data at
high speed, telnetd adds extra null characters to the
byte stream thereby breaking the application.

SR 8606174421 / CR JAGad43667
6. Enhancement to telnet to work in IPv6 environment.

Defect Description:
PHNE_31807:
SR 8606292872 / CR JAGae56622
1. Description: Data flow hangs in kernel telnet sometimes
because of out-of-order processing of flow-control
messages in kernel telnet.
Resolution: Now the flow-control messages are processed in
order.

SR 8606367869 / CR JAGaf28433
2. Description: The telnet multiplexor does not handle the
message buffer used for -z and -s options properly.
Resolution: The telnet multiplexor has been modified to
work properly when -z and -s options are set in telnetd.

PHNE_30672:
SR 8606354753 / CR JAGaf15516
1. Description: When telnetd receives "IAC EC" from the
telnet client as a result of the "send ec" command, it
should send the erase character to the slave pty but
telnetd incorrectly sends some unwanted characters along
with the erase character. These unwanted characters are
sent to the telnet client.
Resolution: telnetd sends only the erase character to the
slave pty.

PHNE_28841:
SR 8606199877 / CR JAGad69063
1. Description: When the user is a member of a large number
of groups in KDC, the user's credentials will be large.
When the size of the user's credentials exceeds 1024
bytes, telnet fails to forward these credentials. A large
credential size could also lead to failure of the
Kerberos authentication.
Resolution:
Now telnet handles credentials with size upto 4096 bytes.
If the credential size exceeds 4096 bytes it will be
truncated to 4096 bytes and if authentication debugging
(toggle authdebug) is enabled on the telnet client, the
following message will be displayed :

Kerberos credentials exceeded buffer size, truncating...

SR 8606267498 / CR JAGae31740
2. Description: telnetd does not handle the TELNET NOP
sequence properly.
Resolution: telnetd now handles the TELNET NOP sequence
properly.

SR 8606224447 / CR JAGad93535
3. Description: In Secure Internet Services(SIS)
environment, telnet does not read default SIS options
specified in the [appdefaults] section of krb5.conf file.
Resolution: telnet now reads the default SIS options
specified in the [appdefaults] section in the krb5.conf
file.

SR 8606224214 / CR JAGad93309
4. Description: telnet does not fall back to normal
authentication if Kerberos authentication with remote
server fails.
Resolution: If the "fallback" option is set to "true" in
the [appdefaults] section in the krb5.conf file, telnet
uses normal authentication if the Kerberos
authentication fails.

SR 8606248696 / CR JAGae15094
5. Description: telnetd does not fall back to normal
authentication mode when the client sends an IAC
sequence with NULL authentication type.
Resolution: If the "-f" option is specified with telnetd in
/etc/inetd.conf file, telnetd uses normal authentication
on receiving an IAC sequence with NULL authentication
type from the client.

SR 8606224774 / CR JAGad93862
6. Description: If the system is configured to use
PAM Kerberos for authentication, a credential cache file
will be created. This cache file is not cleaned up when
telnetd exits.
Resolution: Now telnetd cleans up the credential cache file
before exiting.

PHNE_24829:
SR 8606212875 / CR JAGad82062
1. Description: Buffer handling in telnetd needs to be
enhanced.
Resolution:
Code changes have been made to fix it.

SR 8606212874 / CR JAGad82061
2. Description: Telnetd has a service issue.
Resolution:
Code changes have been made to fix it.

SR 8606220839 / CR JAGad89975
3. Description: telnetd might write a duplicate record
into /etc/utmpx when the _pututline() API is interrupted
by a signal.
Resolution:
Signals are blocked before calling _pututline() and
enabled after it returns.

SR 8606230839 / CR JAGae00077
4. Description: k5dcelogin expects the environment variable
KRB5CCNAME to be set by telnetd. But telnetd passes the
KRB5CCNAME variable only in the argument list of the
execl(2) and not in the environment list.
Resolution: KRB5CCNAME is now passed in the environment
list, in addition to the argument list, thereby
forwarding the credentials properly.

SR 8606238651 / CR JAGae07675
5. Description: telnetd execs login with improperly ordered
arguments due to which the TERM environment variable, if
present, is ignored by login.
Resolution: The arguments are now passed in the correct
order.

SR 8606232804 / CR JAGae02032:
6. Description: Provide a command line option in telnetd to
close the telnet connection when "stty 0" command is
executed.
Resolution: A command line option, "-y", has been provided
in telnetd to close the telnet connection when "stty 0"
command is executed. Refer to man page telnetd(1M) for
more information.

SR 8606231734 / CR JAGae00970
7. Description: IPv6 enabled telnetd closes the connection
if the IPv6 client negotiates for environment option.
Resolution: Now it would not close the connection, but
flash an appropriate error message.

SR 8606236626 / CR JAGae05679:
8. Description: Only the first message block of the STREAMS
message was freed in telnet multiplexor. The remaining
message blocks in the STREAMS message cause a memory
leak.
Resolution: All the message blocks of the STREAMS message
are now freed.

SR 8606261511 / CR JAGae25830
9. Description: malloc(3C) is called inside a signal
handler in telnetd.
Resolution: Calls to malloc(3C) have been removed from the
signal handler.

PHNE_24131:
SR 8606182980 / CR JAGad52196
1. Setting stty 0 results in zero byte msgblk which was
ignored.
Resolution:
stty 0 results in zero byte msgblk which is now processed
to close the telnet connection.

SR 8606176054 / CR JAGad45294
2. If the connection is closed while telnet is doing option
negotiation, memory is not freed.
Resolution:
Code has been modified to free memory whenever connection
is closed.

SR 8606157405 / CR JAGad26736
3. If any telnet client requests for baud rate > 38400,
the telnet daemon resets the baud rate value to zero.
Resolution:
If any request for Baud rate is received, which is
greater than the maximum, i.e 38400, then the telnet
daemon resets the Baud rate value to the default value
instead of setting it to zero.

SR 8606114446 / CR JAGac29210
4. While displaying large files using "Reflection1",
a terminal emulation software, the telnet connection
hangs.
Resolution:
Flow control has been properly enabled which solved
this problem.

SR 8606188928 / CR JAGad58144
5. While transferring the byte stream at a high speed,
the character 0x0d which is not followed by 0x0a is
appended with multiple 0x0 characters.
Resolution:
Handling of flow control has been modified to
solve this problem.

SR 8606174421 / CR JAGad43667
6. Enhancements to telnet to work in the IPv6
environment.
Resolution:
telnetd and telnet code has been enhanced so that
they will work in the IPv6 environment.

Enhancement:
No (superseded patches contained enhancements)
PHNE_24131:
This patch contains IPv6 enhancements for telnet and
telnetd.

SR:
8606182980 8606176054 8606157405 8606114446 8606188928
8606174421 8606212875 8606212874 8606220839 8606230839
8606238651 8606232804 8606231734 8606236626 8606261511
8606199877 8606267498 8606224447 8606224214 8606248696
8606224774 8606354753 8606292872 8606367869

Patch Files:

Networking.NET2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
/usr/conf/lib/libtelnet.a

Networking.NET2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
/usr/conf/lib/libtelnet.a

InternetSrvcs.INETSVCS-RUN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
/usr/lbin/telnetd
/usr/bin/telnet

InternetSrvcs.INET-ENG-A-MAN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
/usr/share/man/man1m.Z/telnetd.1m
/usr/share/man/man1.Z/telnet.1

what(1) Output:

Networking.NET2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
/usr/conf/lib/libtelnet.a:
str_telnet.c: PHNE_31807

Networking.NET2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
/usr/conf/lib/libtelnet.a:
str_telnet.c: PHNE_31807

InternetSrvcs.INETSVCS-RUN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
/usr/lbin/telnetd:
Copyright (c) 1983, 1986 Regents of the University o
f California.
Patch ID: PHNE_30672

InternetSrvcs.INETSVCS-RUN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
/usr/bin/telnet:
Revision 1.1.214.3 PHNE_28841 Tue Feb 24 11:01:55 GM
T 2004
Copyright (c) 1988 Regents of the University of Cali
fornia.

InternetSrvcs.INET-ENG-A-MAN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
/usr/share/man/man1m.Z/telnetd.1m:
None

InternetSrvcs.INET-ENG-A-MAN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
/usr/share/man/man1.Z/telnet.1:
None

cksum(1) Output:

Networking.NET2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_32,v=HP:
3143006766 35700 /usr/conf/lib/libtelnet.a

Networking.NET2-KRN,fr=B.11.11,fa=HP-UX_B.11.11_64,v=HP:
1143391945 65890 /usr/conf/lib/libtelnet.a

InternetSrvcs.INETSVCS-RUN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
3053506564 98304 /usr/lbin/telnetd

InternetSrvcs.INETSVCS-RUN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
2143699622 110592 /usr/bin/telnet

InternetSrvcs.INET-ENG-A-MAN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
3296623510 6406 /usr/share/man/man1m.Z/telnetd.1m

InternetSrvcs.INET-ENG-A-MAN,fr=B.11.11,
fa=HP-UX_B.11.11_32/64,v=HP:
284894807 9352 /usr/share/man/man1.Z/telnet.1

Patch Conflicts: None

Patch Dependencies: None

Hardware Dependencies: None

Other Dependencies:
The defect fixes for SR 8606224774 (JAGad93862), SR
8606224214 (JAGad93309) and SR 8606224447 (JAGad93535)
require that the Web release version of "PAM-Kerberos
and Kerberos Support for HP-UX and DCE" Product Bundle
(J5849AA - revision B.11.11.13 or later) be installed with
this patch.

The Web release version of "PAM-Kerberos and Kerberos
Support for HP-UX and DCE" Product Bundle (J5849AA) is
available from:

http://www.software.hp.com/


The solution to SR 8606174421 / CR JAGad43667 will
work only when IPv6 stack is installed.

Supersedes:
PHNE_24131 PHNE_24829 PHNE_28841 PHNE_30672

Equivalent Patches:
PHNE_31733:
s700: 11.23
s800: 11.23

Patch Package Size: 200 KBytes

Installation Instructions:
Please review all instructions and the Hewlett-Packard
SupportLine User Guide or your Hewlett-Packard support terms
and conditions for precautions, scope of license,
restrictions, and, limitation of liability and warranties,
before installing this patch.
------------------------------------------------------------
1. Back up your system before installing a patch.

2. Login as root.

3. Copy the patch to the /tmp directory.

4. Move to the /tmp directory and unshar the patch:

cd /tmp
sh PHNE_31807

5. Run swinstall to install the patch:

swinstall -x autoreboot=true -x patch_match_target=true \
-s /tmp/PHNE_31807.depot

By default swinstall will archive the original software in
/var/adm/sw/save/PHNE_31807. If you do not wish to retain a
copy of the original software, include the patch_save_files
option in the swinstall command above:

-x patch_save_files=false

WARNING: If patch_save_files is false when a patch is installed,
the patch cannot be deinstalled. Please be careful
when using this feature.

For future reference, the contents of the PHNE_31807.text file is
available in the product readme:

swlist -l product -a readme -d @ /tmp/PHNE_31807.depot

To put this patch on a magnetic tape and install from the
tape drive, use the command:

dd if=/tmp/PHNE_31807.depot of=/dev/rmt/0m bs=2k

Special Installation Instructions:
PHNE_24829 contains a fix for the telnetd code defect
described in SR: 8606220839 (JAGad89975) - telnetd writes
to the wrong entry in /etc/utmpx on logout.

Although the SR: 8606220839 (JAGad89975) fix will prevent
any further corruption of /etc/utmpx(4), installing
PHNE_24829 will not correct any existing corruption in the
/etc/utmp(4) or /etc/utmpx(4) files.

Therefore if you are installing PHNE_24829 to fix the SR:
8606220839 (JAGad89975) defect, to completely resolve the
problem you must also ensure that the /etc/utmp and
/etc/utmpx files are cleared of any previous corruption
caused by this defect.

The /etc/utmp and /etc/utmpx files may be cleared using the
following procedure:

Before installing PHNE_24829 insert two lines into the
/etc/inittab(4) file as follows, then save /etc/inittab and
continue the PHNE_24829 patch installation.

init:3:initdefault:
utm1::sysinit:> /etc/utmp # clear current logon \
accounting files
utm2::sysinit:> /etc/utmpx # clear current login \
accounting files

After PHNE_24829 is installed and the system rebooted, you
may delete the above two entries from /etc/inittab or retain
them. In the latter case, /etc/utmp and /etc/utmpx will be
cleared every time the system is rebooted.

NOTE: The above steps are only required if the problem
described in SR: 8606220839 (JAGad89975) exists on
the system where PHNE_24829 is being installed.

[John Fjeldberg]

Thanks again, but I can't seem to find that patch (perhaps as it is a beta?), but I suspect it has been super seeded by 35508 anyway.

[Dennis Handly]

>Joelmel:Patch info file PHNE_31807.text

Since this is awfully long, why not post a link to it?

Unfortunately there is no such thing as PHNE_31807? I do find the latest is PHNE_35508.

[Jim Keeble]

John, I think you are mistaken about what the telnet speed negotiation actually does.

It does not slow the transmission rate over the tcp connection. That data it sent as fast as the wire can carry it. The data will stop as soon as the TCP receive buffer is full on the Cisco end, which is when the Cisco will advertise it's TCP window size of 0. As the terminal is able to take more data, the window size will increase and more data will flow acros the TCP connection.

I don't know if that behaviour is different in 10.20 vs. 11.x, but I would be surprised if it is.

I would expect the flow control between the serial port and the terminal device to be responsible for throttling the data there using X-on/X-off or hardware flow control.

Maybe the difference is in how flow control from the terminal is handled. Is it possible that the Cisco end passes the ^S and ^Q (X-on and X-off) characters all the way back to the HP ?? If so, That's where I would suspect a difference between 11.x and 10.20.

If you have traces to compare between the 2 OS's, that should tell the tale.

[Bill Hassell]

The RFC 1079 spec does indeed define a baud rate negotiation and your first log does point to that style of negotiation. I don't know any way to troubleshoot this (not many people use this feature) except to use nettl (on HP-UX) or WinPcap on a PC and Wireshark to decode the results. Trace a connection to the 10.20 box and the 11.11 box to see the exact details.

[John Fjeldberg]

Thanks for all your response so far guys! I just though I would explain how I came up with the numbers earlier. As I was not aware of any tools to measure the data on the stream between the HPUX boxes and the Cisco box, I wrote my own small service that I ran the stream through and logged and time stamped what was sent. The output where it says "Host said" are decimal value of each byte sent. First I measured the stream from the 10.20 box:

Timestamp 1188362484 sec 218668 usec
Host said: 0 4 0 0 8
Timestamp 1188362484 sec 222283 usec
Host said: 2 0
Timestamp 1188362484 sec 226253 usec
Host said: 13 0 0 0
Timestamp 1188362484 sec 229987 usec
Host said: 31 13 0 0 0 31
Timestamp 1188362484 sec 234287 usec
Host said: 13 0 0 0
Timestamp 1188362484 sec 238155 usec
Host said: 13 0 3 0

Which gives 24 bytes (192 bits) over 19500 usec (238155 - 218668) whitch is 9846 bps, or close enough to the expected 9600 bps when we are looking at this small dataset. Here's a snippet of the log of the stream from the 11.11 box:

Timestamp 1188361805 sec 547052 usec
Host said: 0 0 0 0
Timestamp 1188361805 sec 547123 usec
Host said: 0 0 0 0
Timestamp 1188361805 sec 547194 usec
Host said: 0 0 0 0
Timestamp 1188361805 sec 547266 usec
Host said: 0 0 0 0
Timestamp 1188361805 sec 547337 usec
Host said: 0 0 0 0
Timestamp 1188361805 sec 547409 usec
Host said: 0 0 0 0


32 bytes (256 bit) over 357 usec, which if you crunch the numbers is equivilant to approx 717.000 bps.


My understanding of RFC1079 is that it not controlling the speed on the Ethernet link or wire", but more "pacing" the data so it matches the speed of the "dumb" terminal screen on the client. If have traced and diff'ed critical points where my original problem is occurring, and I know that both the 10.20 & 11.11 are transmitting the exact same bytes.

As Bill points out, this is probably a rarely used feature nowadays, and I suspect it hasn't bothered many, but I think I will be logging a fault based on this.

[Bill Hassell]

Download a copy of Wireshark and you'll have all the details you need:

http://www.wireshark.org/

This is the world's most popular protocol decoder and analyzer. It already knows all the major RFC protocols and will decode each packet into it's components. Since you are porting to 11.11, HP will be able to help with the differences and the Wireshark traces will be invaluable. Wireshark is a decoder/analyzer so it needs a source file with the data. For PCs, the program is called WinPcap, but Wireshark can also analyze nettl traces from HP-UX as well as some 400+ other trace formats.

[Rob Leadbeater]

Hi,

Another thing that you might want to investigate is the version of IOS on your Cisco boxes... It might be this which is interacting differently with the TCP/IP stack in 11.11.

Hope this helps,

Regards,

Rob

[John Fjeldberg]

Hi All
after some further investigation it appears that RFC1079 is not meant to "pace" the telnetd. It is for advising application behind it what terminal speed it's to expect, and thus can set limits on e.g. how much gfx to use.

There was another RFC, 2217, which promised what I was looking for, however, it appears not to have been implemented.

Also, if you look into the man page for "ldterm" for both the 10.20 and 11.11 box, they explicitly states in the man pages: "it does not perform the low-level device control functionsspecified by the c_cflag". In other words, neither telnetd or the line driver controls the pace, and it is actually uncontrolled.

What has happened for us is that the new servers are so much quicker than the old ones that they are able to push data much quicker through our application and flood our old Cisco boxes.

I am surprised there are no mechanism for this, but I guess that's why RFC2217 was proposed. However, I will either have to do something about the Cisco boxes or implement my own mechanism in our application to break the flood of data.

I will keep the thread open for a couple of days just in case anyone has a comment, distribute the points and close it.

Thanks again for everyone who has participated to this thread!

[John Fjeldberg]

See above