Implement Serial over Ethernet using RFC 2217 standard

Hi all!!

I want to implement Serial over Ethernet using the RFC-2217 specification. Now someone have some code about this? only about the set-up of the RFC because after there do not so difficult, almost if we do not encrypt the sockets.

I found the original spec from CISCO: http://www.faqs.org/rfcs/rfc2217.html#b

If the code is basic will be better so I can test is in some VB

Best Regards Frank

I want to implement Serial over Ethernet using the RFC-2217 specification.
Now someone have some code about this?

So, what you really mean is that you hope that someone else has implemented Serial over Ethernet.

On an arduino?

Rfc2217 pretty much came into existence right about the time that serial ports were disappearing in favor of high density digital modems (Cisco AS5x00), so it was never very widely implemented or debugged. Even the Cisco version didn't work very well... There were assorted conflicts between the is-defined behavior of signals, and the protocol wanting to deal with the same signals. You're better off with straight telnet, unless you really need a particular function that the older options didn't provide.

Yeap, In some cases like these is more easy write your-own-protocol that code a existing one. What is not clear is what the set the port parameters, like speed or control lines. And other issue is how to detect data from control commands.

In the mayor cases I think that is better use two ports, one for raw data and other for control, this is like re-invent the wheel because the serial port use this idea.

It's strange that cisco's note, because if you use binary data and not only text how you will decode if is a data control packet or raw data?.

I'm go to use to different ports and ready! I will apply the less-effort-law!!!

Best Regards! Frank

It's strange that cisco's note

IIRC, the author was actually at Telebit when he designed the protocol. Cisco acquired Telebit in 1996, and then wasted most of them :-(

because if you use binary data and not only text how you will decode if is a data control packet or raw data?.

Oh, that's well established. RFC2217 is a telnet option, and telnet defines how to send binary data while still having in-stream commands (essentially, the command lead-in character gets doubled if you want to send it as data.) RFC2217 doesn't actually add a lot that wasn't already implemented; the main thing being the reading and setting of the extra serial signals. (There are other telnet options for flow control and bitrate.) Having separate tcp connections for commands and data might make sense, depending the the relative cost of a second connection vs having to scan every byte in the data stream. Which is very ambiguous, since one of those tends to be an OS-internal cost, and one is a user-program cost.

The main purpose of the RFC2217 "comport" protocol is to permit a PC-like system to manipulate a remotely (internet) connected com port as if it were local. So you could do an AVR or PIC serial-port bit-banging device programmer through an expensive terminal server port instead of your cheap local port, or something. As if the indeterminate timing of ... everything ... wouldn't actually matter. Hmmph.

Aside from serial ports disappearing, digtial modems being all the rage, and people suddenly switching to things like ssh for better security, I think there was a feeling that people who needed this sort of functionality would pay for it.

There were several open source "Comm Server" projects, designed to turn an old pc into a dialup server based on linux or similar, sort of the way there were similar projects to implement router. I'd be surprised if there weren't ANY open-source implementations that implement this.

How about: http://sourceforge.net/projects/telnetcpcd/