telnet disconnects

[Harald]

I work in networking and use telnet frequently. Most switches I telnet have very long configurations (+500 lines) which, in the case of Alcatel, are not divided by pages (like when you get "--MORE--" at the end of each page and hit the spacebar for the next page, just like when you issue the command "<command> | more").
What happens is that when it reaches the line 300-400 aprox. I get disconnected. This happens always, no matter what telnet client I use.
I tried the following telnet clients:

- "telnet" from the console
- "putty" for linux (GUI)
- run "telnet" from cmd within a VM. Tried both VMWare and VirtualBox.

Why this happens?

I can observe (comparing to Windows native) that the configuration is arriving very slow to my system when running ubuntu, as if I was limiting my bandwidth to 4800bps. A configuration of about 500 lines will take about 8-12 seconds to show on my screen, just before it disconnects, when on Windows it will take less than a second.

My ubuntu release:
Description: Ubuntu 7.10
Release: 7.10

Version of telnet I am using:
telnet:
  Installed: 0.17-35ubuntu1
  Candidate: 0.17-35ubuntu1
  Version table:
 *** 0.17-35ubuntu1 0
        500 http://ftp.hosteurope.de gutsy/main Packages
        100 /var/lib/dpkg/status

UPDATE: A few days after performing the packet capture, I had to travel to the place this switch was located. While on site, I had no issues performing telnet on the switch. I therefore assume all this is related to latency--a very small one, as we only have 13ms to this site.

Its been several days since I posted this bug... why haven't I received at least a confirmation that this is being viewed/processed or whatever?

I really need this fixed if I want to keep this OS. Thank you!

UPDATE2: Suspecting this might be related to the video driver (currently using the "ENVY" driver) due to screen refresh or some other screen-related setting, I uninstalled the driver and used the standard low-res default ubuntu driver and I am still experiencing the same issue.

[Harald (haraldboehmecke)]

After performing a packet capture, I realized that I am sending "Zero Window" and "Zero Window Probe" packets, meaning (probably) that my Lenovo T61 (Dual-Core with 3GB of RAM) is "slower" in processing the packets than a simple Telnet session with a Network Switch.
Being the above hard to believe, I ask for guidance on properly diagnosing this issue.

I am attaching the filtered result of the Wireshark session where the ZeroWindow packets are shown. If further info is required, please let me know.
P.S.: My notebook has dual-boot with Windows XP. When booting with Windows XP, this behaviour is not encountered.
KR, Harald.-

[C de-Avillez (hggdh2)]

discussed the issue with Harald on #ubuntu-bugs. This does not sound like a bug on telnet, or TCP/IP, but I will keep it open for further discussions. Leaving it for the moment without a package (since we do not know yet which, if any, would apply).

[C de-Avillez (hggdh2)]

Summary of discussion: Harald will sniff a session to the switch with Windows and with Ubuntu, then will look for differences. Although MTU might be affecting, I am not sure which direction is sending most data (the sniffer snapshot only shows zero-window packets, and it is unclear why they are being sent; there is a suggestion of single-byte packets from the switch -- port 3268 is the switch; the seq/ack values are sort of weird...).

[Harald (haraldboehmecke)]

--FROM UBUNTU USERS MAILING LIST--

> I can understand why you presented a png of a filtered pcap. I
> agree it looks strange but there's not enough information for
> analysis.
>
> I use this T61 on routers and switches all the time, and mostly
> under X rather than text mode, but the switches and routers I
> talk to are mostly Ciscos and set up to "more" at the end of
> each page.
>
> It sounds like you suspect your T61 of not being able to display
> the text as fast as the switch can send it. This is very likely
> as displaying text in a font under X windows is a lot more work
> then displaying text in text mode. Try the telnet from a text
> mode console for comparison. (Usually ctrl-alt-F1 will get you
> to a text console and ctrl-alt-F7 will get you back into X).
>
> --Mike Bird
>

--MY REPLY--

Hi Mike,

First of all thank you for mail.

I also thought it was related to display speed! But this doesn't seem to be the issue. I tried from the the TTYs Ctrl+Alt+F1-F6 and the issue is still the same. I get disconnected.

CPU doesn't spike while displaying the configuration, and my T61 comes with a 512MB nVidia (probably like yours does) and I... I am really confused :~

While operating with CISCO switches I don't have any problems whatsoever--surely related to the --MORE-- at the end of each page. I can hold down the spacebar so that it 'kinda' drops the config all at once and I still remain online with the switch.

I know the PNG with the filtered pcap doesn't seem that complete, but Bertelsmann has a very strict policy about data privacy, so I am unable to post the complete pcap.

If someone would have a public Alcatel switch where I could connect to, I'd be more than happy to post the complete pcap.

To be honest, we took a look at the complete pcap with my networking colleagues (real gurus) and found nothing suspicious.

If there is something else, anything, I can collaborate with, please let me know!

KR, Harald

[Harald (haraldboehmecke)]

Hello, I have tried with several MTU settings, starting at 1500 going down by 10s to 1300, then going down by 50s to 600. The issue is still persistent. I am trying to reproduce the issue on a private network. as soon as I have further information I will post accordingly. KR, Harald

[Harald (haraldboehmecke)]

Hi guys,

I've been working all day on getting this reproduced on a lab. I encountered one big problem. I am unable to recreate a 10-15ms delay from my ubuntu laptop to the Alcatel switch.

So it was a failure, because I created a +1500 line config on the Alcatel Switch and display it over and over again without getting disconnected.

I KNOW Alcatel switches aren't that popular, but CISCO ARE. And here is what I found out:

When connecting directly to a CISCO 6509 and executing "sh tech" (technical-information of the switch, including config blahblahblah...) the configuration was shown blasting fast, just like it should be. sh tech doesn't show the information with page breaks like sh config would (--MORE-- at the end of each page).

When connecting remotely to another switch that is 11.3ms away, and executing "sh tech", the technical-information was shown in "chunks". What I mean is, 50-80 lines are shown... 5 sec pause... 50-80 lines more... 5-10 sec pause... 50-80 lines more... 8 sec pause.... etc--but it does not disconnect!

I know lots of you guys administer CISCO switches and should be able to test this. REMEMBER it has to be +10ms away, if not, the issue does not reproduce.

The difference with Alcatel is that these above mentioned 'pauses' cause the connection to drop.

On the same laptop where I am running the tests, I have a windows partition, and I can view the configurations with no problems.

Any help on diagnosing this issue is appreciated!

KR, Harald

PS: As soon as I am able to reproduce the issue on my lab, I will post a complete pcap. Any help on how to simulate the 10-20ms delay is also appreciated!

[Harald (haraldboehmecke)]

echo 0 > /proc/sys/net/ipv4/tcp_window_scaling

The above command as root solved the issue. It is still unclear if this is related to a networking problem or a local problem, as I was unable to reproduce the issue on a lab test.

(Special thanks to the ubuntu mailing list members for their help)

KR, Harald

[C de-Avillez (hggdh2)]

OK, rejecting the bug.

So the captures were *not* identical... TCP window scaling is used by default on current Ubuntu -- and, if I remember the Microsoft KB entry about that correctly -- should also be the default on current Windows (Vista, I guess, I do not think it made it in XP).

But this then means you should open a bug report at Alcatel: their router is clearly in error.

Thank you for opening the bug, and please feel free to report any other bugs you find on Ubuntu.