VB (2008/.net but anything really)- Telnet

(Update! This code fixed here:
http://myhead-online.blogspot.com/2009/05/vb-net2008-express-telnet-to-sun.html)

Ok, so I'm still distracted by VB. It's all just so easy to get great results, that's the problem!

Anyhow this week's project is Cisco device output collation into useful stuff. Got some great stuff going for switches to collate MAC/Port/VLAN/ARP/CDP information into a single sheet from multiple (or single) log files of a terminal session but then I thought, why not automate the Telnet portion? So off we go.

Now some things to note:

Telnet is not as simple as we would like
Negotiation of options may be required
Devices I want to access are a hop that requires logon (or more complex operations) away from my client PC, on different networks
I have no control over the clinet PC build and I have to assume nothing.

If you are anything like me then the first thing is to just steam headlong into it and see what breaks. So my approach is to open a socket and start reading/writing as required.

Dim tcpClient As New System.Net.Sockets.TcpClient()
tcpClient.Connect(host_ip.Text, IPport.Text)
Dim networkStream As NetworkStream = tcpClient.GetStream()
Dim sendBytes As [Byte]()
Dim returndata As String
Dim bytes(tcpClient.ReceiveBufferSize) As Byte
If networkStream.CanWrite And networkStream.CanRead Then ' check a ok
' read data
networkStream.Read(bytes, 0, 1)
returndata = Encoding.Unicode.GetString(bytes)
' write data
sendBytes = Encoding.Unicode.GetBytes(command & returndata)
networkStream.Write(sendBytes, 0, sendBytes.Length)
End If
tcpClient.Close()

Great, now I can read and write and do what I want - or so I thought. Actually, no - the code will work with many Cisco type products (and many others) but is unlikely to work with IBM/UNIX/Msoft/anything else, specifically anything that adheres to thet Telnet standard. So we need some tweaks.

Now I stop here to say that Telnet negotiation is an arse and it would be great to just say bugger it and keep away. Unfortunately the Telnet server has a different opinion and will sit waiting for you to negotiate with it if you just ignore the problem. Net result being no session.

So first thing is to take a look at how to negotiate. I'm not going into this but you need to know that every command starts with IAC (chr(255)).

KEYPOINT! Do not encode response as/with ASCII - there aren't enough bits to represent 255. Hence Unicode in code above. ASCII coding will result in a load of CHR(63)'s responding. Took me bloody ages to work that out - couldn't get why I was geting 63s when I was expecting 255s!

So basically we get a whole stream of

IAC - WILL/WONT/DO/DONT - OPTIONS

In text this will show as gibberish but it is critical! What you need to know is the following codes:
251 - WILL
252 - WONT
253 - DO
254 - DONT

Then there are stacks of others for the options. Look elsewhere for these. So what I want to do is to look at what comes in and basically say bugger off, I'm stupid. So comms go:

Server sends Client Sends
DO (option) WONT (option)
DONT (option) WONT (option)
WILL (option) DONT (option)
WONT (option) WONT (option)

But we don't know what we are going to have to negotiate so we need code that will handle any of this. this can all happen multiple times too. Great news is that the commands (at this level) are always sequences of 3 bytes. So basically get three bytes then respond (or as below get any command things, then when we get a non command option, send a response). Some code:

Public IAC As Integer = 255
Public IAC_WILL As Integer = 251
Public IAC_WONT As Integer = 252
Public IAC_DO As Integer = 253
Public IAC_DONT As Integer = 254
Select Case Asc(returndata)
Case IAC_WILL ' will
command = Chr(IAC_DONT)
Case IAC_WONT ' won't
command = Chr(IAC_WONT)
Case IAC_DO ' do
command = Chr(IAC_WONT)
Case IAC_DONT ' don't
command = Chr(IAC_WONT)
Case IAC ' control req.
command = command & Chr(IAC)
Case Else
sendBytes = Encoding.Unicode.GetBytes(command & returndata) ' return sent byte
statusupdate(status_line.Text & "IAC Response sent")
networkStream.Write(sendBytes, 0, sendBytes.Length)
command = ""
End Select

So now we can run a loop with the code in and send 'stupid' responses. Problem I have is that the response being sent is not being understood. A network capture shows that when I say send IAC & IAC_DONT, (option) it may or may not send something but it won't be the net result I want. Not sure whay but otherwise the theory is ok (I think!). Same holds for all bytes I send. Hmmm.....