Cisco 2621 Terminal Server - Line not working via Telnet

[juandcc2014]

I recently got a cisco 2621 to act as a terminal server, which has a 32-ASYNC NM module attached. I made the configurations on the router to be able to access network devices using an octal cable via telnet [IP address] [port number]. This is the output of `show line`:

Tty Typ Tx/Rx A Modem Roty AccO AccI Uses Noise Overruns Int
* 0 CTY - - - - - 0 0 0/0 -
* 33 TTY 9600/9600 - - - - - 0 93 86/258 -
34 TTY 9600/9600 - - - - - 5 25 0/0 -
35 TTY 9600/9600 - - - - - 0 0 0/0 -
36 TTY 9600/9600 - - - - - 0 0 0/0 -
37 TTY 9600/9600 - - - - - 0 0 0/0 -
38 TTY 9600/9600 - - - - - 0 0 0/0 -
39 TTY 9600/9600 - - - - - 0 0 0/0 -
40 TTY 9600/9600 - - - - - 0 0 0/0 -
41 TTY 9600/9600 - - - - - 0 0 0/0 -
42 TTY 9600/9600 - - - - - 0 0 0/0 -
43 TTY 9600/9600 - - - - - 0 0 0/0 -
44 TTY 9600/9600 - - - - - 0 0 0/0 -
45 TTY 9600/9600 - - - - - 0 0 0/0 -
46 TTY 9600/9600 - - - - - 0 0 0/0 -
47 TTY 9600/9600 - - - - - 0 0 0/0 -
48 TTY 9600/9600 - - - - - 0 0 0/0 -
49 TTY 9600/9600 - - - - - 0 0 0/0 -
50 TTY 9600/9600 - - - - - 0 0 0/0 -
51 TTY 9600/9600 - - - - - 0 0 0/0 -
52 TTY 9600/9600 - - - - - 0 0 0/0 -
53 TTY 9600/9600 - - - - - 0 0 0/0 -
54 TTY 9600/9600 - - - - - 0 0 0/0 -
55 TTY 9600/9600 - - - - - 0 0 0/0 -
56 TTY 9600/9600 - - - - - 0 0 0/0 -
57 TTY 9600/9600 - - - - - 0 0 0/0 -
58 TTY 9600/9600 - - - - - 0 0 0/0 -
59 TTY 9600/9600 - - - - - 0 0 0/0 -
60 TTY 9600/9600 - - - - - 0 0 0/0 -
61 TTY 9600/9600 - - - - - 0 0 0/0 -
62 TTY 9600/9600 - - - - - 0 0 0/0 -
63 TTY 9600/9600 - - - - - 0 0 0/0 -
64 TTY 9600/9600 - - - - - 0 0 0/0 -
65 AUX 9600/9600 - - - - - 0 0 0/0 -
66 VTY - - - - - 0 0 0/0 -
67 VTY - - - - - 0 0 0/0 -
68 VTY - - - - - 0 0 0/0 -
69 VTY - - - - - 0 0 0/0 -
70 VTY - - - - - 0 0 0/0 -

Line(s) not in async mode -or- with no hardware support:
1-32

Now the port number for doing telnet is 2000 + line #. So to use line 34, I'd do on CMD: `telnet 192.168.1.1 2034`

This command gives me the following output when attempting to use line 33:
cmd> telnet 192.168.1.1 2033

Connecting To 192.168.1.1...Could not open connection to the host, on port 2033: Connect failed

However, attempting this on any other line works perfectly. 

I also tried this on another octal cable but still the same results.

I'm just trying to verify whether it's a hardware issue(32-ASYNC NM related or the octal cables themselves) or if it's just the way it works. If it's the latter(just how it works), then is there a way to enable that line?

I performed the following commands on `conf t` mode

`

line 33 65

exec-timeout 0 0

no exect

transport input all

`

[Enes Simnica]

ur setup looks solid, and your approach with the NM-32A and octal cable is correct. The issue with line 33 (port 2033) failing while other lines work fine is unusual, but not uncommon.

From the show line output, line 33 shows activity * and some noise/overruns, which could mean it's stuck or being held open by the router. Also, the message Lines not in async mode or with no hardware support: 1-32 might indicate that async line 1 (mapped to line 33) isn’t fully initialized, possibly due to hardware or IOS limitations.

Try clearing the line with clear line 33  and make sure the config has no exec (not no exect). U can also try connecting from the router using connect 33. If that works, the issue is likely with the reverse Telnet function, not the async line itself.

If none of this helps, it could be a hardware fault on port 1 of the NM-32A or a limitation in your current IOS. Swapping the module or testing another IOS version may be your next best step.

Let me know how it goes. and hope it helps G.

-Enes

[Elliot Dierksen]

I always put "no exec" on lines that I am using for outbound telnet/console servers. Without that, the router will think something is trying to log in if the other side generates any characters. You also need "transport output telnet".

[Jens Albrecht · Accepted solution]

Hello @juandcc2014,

of course, there is a chance that port 1 on your NM-32A could have a problem.
However, the problem can also be due to the hardware or the console config of the connected device on that port.

So you could switch the devices connected to your lines 33 and 34 and then check whether the error remains on line 33 or moves to line 34. Make sure to use the 'clear line 33' command before doing this, in case that line is shown as active by the asterisc.

If the error stays on line 33, then there appears to be a hardware problem with your NM-32A module as you already tested another octal cable.

If the error moves to line 34, then check the console settings on that device. Overruns might indicate a mismatch of the baudrate/flow control settings or the console port of that device has a hardware problem.

HTH!

[Elliot Dierksen · Accepted solution]

@Jens Albrecht makes a good point, but I still think the problem is that the router thinks the port is busy. The "*" in the first character of the "show line" output indicates that the router thinks both the console and line 33 are busy. Apply "no exec" to that line, clear the line, and then try it again.

[juandcc2014]

So a lot happened while I was reading these comments:

- I kept turning on and off the router to see if that was the issue, replacing the octal cables one after another. But one time I booted up the router, I got segV exceptions after every reboot and could not do anything. The bootup process looped around the "Self-decompressing image: ##########" part over and over again. Thus, what I ended up doing was swapping the RAM sticks to each other's slots, installing a smaller image (`c2600-ipbase-mz.123-9C.bin`), entering into password recovery(steps here) and then proceeded to follow the `no exec` steps, and the line 33 seems to work now! I am not sure why I got the segV exceptions though, but it got me swapping RAM sticks, resetting the router, and reinstalling the router image, and that did the trick.

The asterisk(*) on line 33 on `show line` output is not present anymore.

[juandcc2014 · Accepted solution]

So to make it short, reinstalling the IOS fixed this. I wouldn’t have done so if it wasn’t for that segV exception. As for that exception, I believe it was because I unplugged the octal cables while either I had at least one running console session in the octal cable.