Router – Different behaviour of netcat from telnet when connecting to public route server

netcatquaggaroutertelnet

I have observed a different behaviour between netcat and telnet when connecting to the public route server bgp-view.tvnetwork.hu and issuing the command show ip bgp.

Using Telnet the output (which is normally some tens of thousands lines long) is truncated and in order to view it all you have to press space or enter to continue (like the man pages). When I connect with netcat it just starts dumping all the output and after the first few hundred lines it hangs. Even if I state explicitly that I want to pause after the first 100 lines using the command terminal length 100 netcat doesn't change behaviour.

Do you have any idea why this happens and how it can be resolved?
My OS is ubuntu 10.4 and the route server runs Quagga (version 0.99.5). Same kind of behaviour is also observed with another quagga route server (). With other type of routers (cisco or juniper) that problem doesn't appear.

Thank you.

ps. I also posted this question to stackoverflow but server fault seems more relative.

EDIT:

Wireshark helped me find that the problem is that netcat refuses to negotiate the Window Size option although the server requests "Do Negotiate About Window Size". Netcat has a -t parameter to negotiate telnet options but its behavior is not to accept any options (uses DON'T or WON'T as a default). So the question now is how to make netcat to negotiate window size and send width 80 and height 25 which are the values that telnet sends.

Best Answer

If you connect with telnet and start by giving the command term len 0, it seems to not use pagination.

At a guess, the reason it doesn't do any pagination when using netcat is that it's probably not doing the expected TELNET protocol negotiations for basic terminal characteristics.

Edit: Seems the main problem is that it just plain takes too long to display the full routing table. After leaving a telnet session, with term len 0 and sh ip bgp running, I ended up with:

Vty connection is timed out.
Connection closed by foreign host.

It MAY be that having periodic data sent to the route server (maybe a space character every 45 seconds) may be enough to not trigger the VTY time-out, but I'd need to check the source code to be sure.