TELNET commands?

vining

I'm working on a module to commincate w/ a CISCO switch via a telnet and the first string I get form the device when I IP_CLIENT_OPEN is:

Line      8 (08:27:24)::  J.A.P AXS MOD-1 DEBUG (1): RX DATA STRING- "$FF$FB$01$FF$FB$03$FF$FD$18$FF$FD$1F$0D$0A$0D$0AUser Access Verification$0D$0A$0D$0APassword: " :DEBUG <2107>

The string sent being the stuff between the double quotes. This device also echoes strings I send it 1 char at a time, some times 2 which I can deal with as returned strings but I would prefer not too.

Although I was baffled by the HEX values I ignored them but while in WireShark snooping around the RX & TX during a PC session w/ the device I discoverd that the HEX values are TELNET commands used to determine session parameters. So the HEX values above actually are the device saying:

//Command: Do Echo
//Command: Do Suppress Go Ahead
//Command: Won't Terminal Type
//Command: Won't Negotiate About Window Size

Note: this translation may be different from the string shown.

So after googling I found this: (commented out since I pasted in my code for reference)

//$FF = IAC (interpret as command) or extended options list
//$FE = DON'T
//$FD = DO
//$FC = WON'T
//$FB = WILL
//$FA = START SUB NEGOTIATIONS
//$F0 = END OF SUB NEGOTIATIONS
//$F9 = GO AHEAD SIGNAL
//$F3 = NVT BREAK CHARACTER BRK
//$F2 = DATA MARK
//$F1 = NOP NO OPERATIONS
//$1  = ECHO
//$3  = SUPPRES GO AHEAD
//$18 = TERMINAL TYPE
//$1F = NEGOTIATE WINDOW SIZE
(*
Commands     Dec Hex        Description 
----------------------------------------------------------------
data                     All terminal input/output data. 
End subNeg    240 FO     End of option subnegotiation command. 
No Operation  241 F1     No operation command. 
Data Mark     242 F2     End of urgent data stream. 
Break         243 F3     Operator pressed the Break key or the
			 Attention key. 
Int process   244 F4     Interrupt current process. 
Abort output  245 F5     Cancel output from current process. 
You there?    246 F6     Request acknowledgment. 
Erase char    247 F7     Request that operator erase the previous
			 character. 
Erase line    248 F8     Request that operator erase the previous
			 line. 
Go ahead!     249 F9     End of input for half-duplex connections.
SubNegotiate  250 FA     Begin option subnegotiation. 
Will Use      251 FB     Agreement to use the specified option. 
Won’t Use     252 FC     Reject the proposed option. 
Start use     253 FD     Request to start using specified option. 
Stop Use      254 FE     Demand to stop using specified option. 
IAC           255 FF     Interpret as command. 
*)

So I looked at the responses from the PC during a session and tried to respond in kind via code when I recieved this string modified to shut down the echo but so far no joy. Is this possible via code? Since I'm not sure how the packet is actually framed by the master when it leaves I can't be sure what's actually being sent or how it's formatted.

Anyone ever try this or something similar with success?

true

Question: have you tried no negotiation or minimal negotiation to get the device talking?

Comment: I've never had to manually write code to control something via real telnet. As it is I can't think of the last time I actually talked to a real telnet server.

ericmedley

true wrote: »

Question: have you tried no negotiation or minimal negotiation to get the device talking?

Comment: I've never had to manually write code to control something via real telnet. As it is I can't think of the last time I actually talked to a real telnet server.

For some strange reason, I love doing telnet.

I quite often use it myself. For example: I have a nice little routine that telnets into AMX touch panels when they go astray. I actually wish I could still do my old Netlwork Time module using the old telnet into NIST's ataomic clock. It had the most clever way of dealing with daylight savings time. The current incarnation of Network Time does not.

vining

true wrote:

Question: have you tried no negotiation or minimal negotiation to get the device talking?

Comment: I've never had to manually write code to control something via real telnet. As it is I can't think of the last time I actually talked to a real telnet server.

The device talks very nicely and for the most part everything is working just fine. I'm just trying to tweak the session and eliminate echoes if possible. Also since I was never aware of this negotiating before I figured I'd play with it and waste some time.

jweather

Haven't seen any problems with echo... when I ran into this, it was with a device that wouldn't talk to me until I responded to the telnet negotiations. I had to respond to a $FF, $FB, $01 with $FF, $FB, $1F for it to talk. Everything else got stripped out of the parsing buffer so it didn't interfere with anything. I don't remember where I dug that up, I think it was from a longer protocol document.

vining

jweather wrote:

I had to respond to a $FF, $FB, $01 with $FF, $FB, $1F for it to talk.

That's a command WILL ECHO to which you responded WILL NEGOTIATE WINDOW SIZE.

My string $FF,$FB,$01,$FF,$FB,$03,$FF,$FD,$18,$FF,$FD,$1F" I just responded with $FF,$FE,$01 (don't echo) to which it then relpies $FF,$FC,$01 (won't echo) which is still does and then I send $FF,$F0 (end sub negotiations) which I don't think is needed since I think a sub negotiation is a reply to window size for example where you include a size parameters. I then get another Password: prompt to which I then reply with the password.

So it still echoes and I still just deal with it but responding to the 4 telnet commands in some part did clean up and make the initial login in smoother for some reason. I was getting '% Password: timeout expired!' alot even though the password was sent straight away and obviously faster than I could ever type by hand during a manual connection which I wouldn't get unless I took a really took along time.

jweather

vining wrote: »

That's a command WILL ECHO to which you responded WILL NEGOTIATE WINDOW SIZE.

Hmm... that doesn't make much sense, but I believe it was the window size part that the device (an RSLink temperature probe) needed before it would talk to me.

vining

Well it's not a response to what the device sent but it's still a command to the device and the device doesn't really know or care what it just said. It just gives you options and you reply how ever you like which can include not to respond at all. If the device can comply it will, if not it won't. In my case it just lies and says it won't but still does.