20 replies to this topic

[Omar (OZ)]

Could I send commands to the netduino via telnet? I did this: cmd.exe typed "telnet" typed "open 192.168.1.40 80" // means connect to ip 192.168.1.40 on port 80. and I get no response. It would be awesome to have a .NET MF telnet server. micro-telnet hehe cute names already. But in all seriousness does anyone know how this could be done?

[greg]

Could I send commands to the netduino via telnet? I did this:
cmd.exe
typed "telnet"
typed "open 192.168.1.40 80" // means connect to ip 192.168.1.40 on port 80.


and I get no response.

It would be awesome to have a .NET MF telnet server. micro-telnet hehe cute names already. But in all seriousness does anyone know how this could be done?

Just open a socket on port 23 and listen I would imagine. There's no protocol to telnet, it's just like an async connection over serial.

Not sure why you'd want to use telnet rather than a bitpacked command set - be a lot easier.

[freds]

Just open a socket on port 23 and listen I would imagine. There's no protocol to telnet, it's just like an async connection over serial.

Not sure why you'd want to use telnet rather than a bitpacked command set - be a lot easier.

Ah contraire! It can be sticky wicket; depending on what you are trying to do. Anyway yes at its simplest it assumed that the client will echo locally any characters typed and a transaction is simply type some text and hit enter.

Where it gets a bit more complicated is; how do you handle the backspace?

Anyway more telnet sessions begin with a flurry of negotiations; where the negotiations are hidden from the end user. Most telnet commands start with an <IAC> character which is 0xFF and have arcane leadin’s like will, wont, do and don’t, etc, options like echo, binary, linemode, etc.

Not difficult just need a state table and desired goals in mind for the interface. I.E. do you support type ahead, etc.

[Chris Seto]

Telnet can be used for raw communications. I use it all the time to simulate HTTP requests when I am testing webservers.

[greg]

Ah contraire! It can be sticky wicket; depending on what you are trying to do. Anyway yes at its simplest it assumed that the client will echo locally any characters typed and a transaction is simply type some text and hit enter.

Where it gets a bit more complicated is; how do you handle the backspace?

Anyway more telnet sessions begin with a flurry of negotiations; where the negotiations are hidden from the end user. Most telnet commands start with an <IAC> character which is 0xFF and have arcane leadin’s like will, wont, do and don’t, etc, options like echo, binary, linemode, etc.

Not difficult just need a state table and desired goals in mind for the interface. I.E. do you support type ahead, etc.

@freds - backspace is handled by the shell you are using and the terminal emulator - not telnet. And those negotiations are again a function of the terminal - NOT telnet. Telnet is raw communication.

@Chris - Oz was asking if he could get the netduino to be a telnet server which is why I was questioning him. Sure, I use telnet all the time to check if services are up - doesn't mean I want to run a telnet server on all of them.

[Omar (OZ)]

Telnet can be used for raw communications. I use it all the time to simulate HTTP requests when I am testing webservers.

How do you do that[simulate http requests]?

[greg]

How do you do that[simulate http requests]?

Telnet to the port the webserver is on and type in some HTTP requests. It can be as simple as "GET /". Just have to know how the protocols work.

[avword]

Just open a socket on port 23 and listen I would imagine. There's no protocol to telnet, it's just like an async connection over serial.

Not sure why you'd want to use telnet rather than a bitpacked command set - be a lot easier.

I wonder if you could give me a little more info about what you mean by "bitpacked command set" - I've not heard that term before, but I am interested to learn more.

[greg]

Bitpacking is just a way to cram more data into fewer bytes. It's generally used where space is at a premium. With the microcontrollers we have you could get away with a more flexible and human readable format though. Just an idea!

[Charles]

Just open a socket on port 23 and listen I would imagine. There's no protocol to telnet, it's just like an async connection over serial.

Not sure why you'd want to use telnet rather than a bitpacked command set - be a lot easier.

No promises, but I'm messing around with some Telnet-like code that I will post if it ever makes it out of the pre-Alpha stage.

[Charles]

Development has gone well over the weekend! I will post working Telnet example code under the Apache license in a new thread shortly... Stay tuned!

[Chris Walker]

Development has gone well over the weekend!

I will post working Telnet example code under the Apache license in a new thread shortly... Stay tuned!

[the anticipation builds]

[Charles]

Just open a socket on port 23 and listen I would imagine. There's no protocol to telnet, it's just like an async connection over serial.

Not sure why you'd want to use telnet rather than a bitpacked command set - be a lot easier.

Easy to implement for the programmer, in the Netduino Plus, yes... But if you do that, you'll need a custom piece of software to do the bit packing on any computer that wishes to communicate with the device! And that custom piece of software will need to work with countless operating systems, drivers, and variations on hardware - Not an easy programming task on the computer side.

Telnet, along with HTTP, are two great ways to communicate with a device if you need a way to access it without a custom piece of client software. The beauty of these protocols is that there are many clients available that have already been through the ringer on just about every OS/Driver/Hardware combination imaginable! Why re-invent the wheel if you don't have to?

[greg]

Easy to implement for the programmer, in the Netduino Plus, yes... But if you do that, you'll need a custom piece of software to do the bit packing on any computer that wishes to communicate with the device! And that custom piece of software will need to work with countless operating systems, drivers, and variations on hardware - Not an easy programming task on the computer side.

Telnet, along with HTTP, are two great ways to communicate with a device if you need a way to access it without a custom piece of client software. The beauty of these protocols is that there are many clients available that have already been through the ringer on just about every OS/Driver/Hardware combination imaginable! Why re-invent the wheel if you don't have to?

Bitpacking is just a means of encoding data so anyone can do it. Is it "easier" for a human to transmit data in human readable form? Absolutely. Is it the most effeicient? Not necessarily. Depends on what you're trying to do.

I think people are forgetting that telnet is just an open socket similar to an async connection. There's nothing special to it (ie, there's no "telnet protocol"). HTTP is, however, a protocol that requires formatting of requests and responses. Still pretty simple and you have the advantage of a front end on every computer you can think of.

If you're writing a client/server application though you have a number of options - HTTP, SOAP, etc. Heck you could even use gopher if you really wanted to.

The point is to use what makes the most sense for your specific use. If you want to be able to just open a telnet connection to your netduino then a simple command/response system works well. If you want to be able to use a browser - obviously HTTP. Use what your comfortable with and what gives you the features and performance you are looking for.

[Charles]

I can agree with that. I misunderstood bitpacking - Thought you meant writing an interface around a custom, mostly machine-readable-only protocol. With telnet, you are correct in saying that as a protocol it is only an open socket, but it can be more than that. Telnet can be used to construct a simple user interface that can be easily adapted for use on the a serial connection as well. It does have a power in this sense that an HTTP server lacks. But, like you said... Comfort in programming and feature matching is what it's all about. That's one reason why there are so many options.

[Charles]

Ah contraire! It can be sticky wicket; depending on what you are trying to do. Anyway yes at its simplest it assumed that the client will echo locally any characters typed and a transaction is simply type some text and hit enter.

Where it gets a bit more complicated is; how do you handle the backspace?

Anyway more telnet sessions begin with a flurry of negotiations; where the negotiations are hidden from the end user. Most telnet commands start with an <IAC> character which is 0xFF and have arcane leadin’s like will, wont, do and don’t, etc, options like echo, binary, linemode, etc.

Not difficult just need a state table and desired goals in mind for the interface. I.E. do you support type ahead, etc.

Of course, the beauty of writing your own telnet server is that you don't have to implement the options you don't want to... I posted a really nice Telnet server example in the Netduino Plus forum that should help shed some light on the situation, especially the backspace question.

[freds]

Of course, the beauty of writing your own telnet server is that you don't have to implement the options you don't want to... I posted a really nice Telnet server example in the Netduino Plus forum that should help shed some light on the situation, especially the backspace question.

Hi Charles

True confession I write communications software for a living (www.crystalpoint.com) so tend to tilt towards the most complexity to be handled so that I cater to the largest audience (please throw money I can always put it to use (minor plug)).

You came up with a very good solution for handling single character key strokes to trigger commands.

My first inclination would be something more along the lines of the various LCD solutions that have been posted; that are expanded to handle remote user input.

Given the network aspects of the netduino plus why constrict yourself to
four lineby forty display? When most full function terminal emulations can support up 132x50, etc?

A telnet object/server would have the following attributes in my priority:

1. Ability to clear the screen
2. Cursor addressing
3. Color or attribute settings for the ink to write new text with
4. Multi-connection support, first come would had control, others have observer status, etc.

Given the above you need to have the server request terminal negotiation and looking for a terminal type that begins with either "vt", "ansi" or "xterm" (except vt52) as they would all support common escape sequences for desire control operations.

Other desirable options are remote echo, binary and for the few clients that support it line mode negotiation(very low priority).

I am an extreme fan of code reusability to the extent that looking at others code you can see if the pit falls that they dodged and consider if they are relevant to you.

In that line if I had spare development cycles I would look at recycling the telnet work done in
http://www.wheelmud.net/ project that is hosted on codeplex.

They seemed to have covered most of telnet’s complexities in easily understandable code that can be cut down to
the micro framework environment easily and a license that permits you to do that.

To the layout of the LCD examples I would add the following with an event or mode structure:

1. Receive single keystrokes
2. Receive line input (back space editing transparent to hosting code)
3. Sub mode for numeric input only

The real question is can it be constructed to fit the available resources on the netduino plus and still leave enough code and ram space for reasonable complexity of a targeted solution. My hunch is yes, but no real world experience, just lots of desire so to speak to leave graffiti on the wall that is reused (grin).

The question is what is the most appropiate remote network client?

1. Telnet
2. General html
3. Custom xml/wsdl contracts
4. Remote console GUI

Thank you for your contribution to our common interest.

Fred

[Charles]

Sure, if I was to write a full-featured telnet server, I would want all that. Consider this though... There is no console, command line, bash prompt, etc. in a N+ unless we write it. A full-featured telnet server would be a better fit if this was for use on a system that already contained things that required all the features, but this one doesn't. In fact it only has what we give it. So, when writing the telnet server for the N+, my considerations are: Non-blocking - Netduino Plus can still be used for other things Small memory footprint Easy remote functionality with an off-the-shelf client Elegant and simple code wherever possible What this is supposed to be is a template that anyone can easily update to provide the ability to control pins and read their state remotely. The interface I'm going for at the moment is similar to that of a Cisco router, not a Bash prompt. Let's be realistic here... Just like the Netduino Plus isn't cut out to be a full-scale web server, complete with MySQL backend and PHP interpreter, it isn't cut out to be a complete telnet server with all the bells and whistles you mention above. By the way, a new version is coming soon... I'm implementing proper telnet option and command processing as per RFC854 and later.

[Charles]

The options implementation is complex... Some telnet clients absolutely can't wait to tell you what they can and can't do, what their capabilities are, etc. Others, (line the Windows Telnet client) Don't tell you anything. They just sit there and expect you to guess what they can do. And whomever created the whole protocol didn't bother to make all the options the same length so you've got to check the option you're getting first and then decide if there is more to it or that is all. Very annoying. I thought using some source code from other projects, but all the ones I found are huge and do everything under the sun. I am going for a light-weight, application-specific implementation that doesn't eat the entire processor for breakfast just to turn an LED on or off. I'm getting close though... I have a mostly working implementation now but there are still some odd glitches to work out before posting.

[freds]

The options implementation is complex...

Some telnet clients absolutely can't wait to tell you what they can and can't do, what their capabilities are, etc.

Others, (line the Windows Telnet client) Don't tell you anything. They just sit there and expect you to guess what they can do.

And whomever created the whole protocol didn't bother to make all the options the same length so you've got to check the option you're getting first and then decide if there is more to it or that is all. Very annoying.

I thought using some source code from other projects, but all the ones I found are huge and do everything under the sun. I am going for a light-weight, application-specific implementation that doesn't eat the entire processor for breakfast just to turn an LED on or off.

I'm getting close though... I have a mostly working implementation now but there are still some odd glitches to work out before posting.

Hi Charles

It's generally the server that starts the negotiation phase, unless the client desires an option that
the server doesn't initiate. A connection data trace generally has a small storm of packets going back
and forth until the two sides agree.

In your case I would suggest a do binary and don't echo. Have your server perform the keystroke echoing
with two input modes, single character and line input. On line input look for DEL or Backspace characters 0x7f
and 0x08. When ever you see one delete the last character in the line input buffer and send a BS,SPACE,BS to
the remote client. Also terminate line input on either a LF or CR, 0x0a and 0x0d. When you terminate input mode
automatically send a CR,LF to the remote host. This will work with lots of different emulation types.