linux-kernel - Re: Network Virtual Terminal

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20110105152313.GC3937@enneenne.com>
Date:	Wed, 5 Jan 2011 16:23:13 +0100
From:	Rodolfo Giometti <giometti@...eenne.com>
To:	Hans-Peter Jansen <hpj@...la.net>
Cc:	linux-kernel@...r.kernel.org, Russell Coker <russell@...er.com.au>,
	Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: Network Virtual Terminal

On Tue, Jan 04, 2011 at 06:13:46PM +0100, Hans-Peter Jansen wrote:
> Dear Rodolfo,
> 
> On Monday 03 January 2011, 16:15:34 Rodolfo Giometti wrote:
> > Hello,
> >
> > here my implementation of Network Virtual terminals (NVT tty)
> > according to RFC 854 and RFC 2217... actually this is the client side
> > part since as remote server I used sredird
> > (http://freshmeat.net/projects/sredird/).
> 
> Sounds interesting. Could you outline the limits a bit? In one of my use 
> cases, I need to support 1200 baud with a rather esoteric 7E2 serial 
> setup. (Needless to say, the client is a butt ugly win app to control 
> gasoline pumps, running inself in a VMware WS setup. I'm supporting 
> this since ten years now, where VMware took about 4 years to get the 
> serial setup right finally...) Being able to redirect the serial data 
> over network (in an inexpensive, but reliable way) would make my life 
> significant easier in this respect.

My code is just one halve of the game... to solve your problem you
need a server on the machine where the serial port is installed and
you need that the server itself can manage it.

Here a simple schema of the whole game (it's my testing environment
but it can explain the situation anyway):

        ------------------+
             +---------+  |
             | minicom |  |
             +---------+  |
                  |       | local PC with no
                  v       | serial ports
             /dev/nvtty0  |
                  |       |
        ------------------+
                  |
                  v
             /\/\/\/\/\
            | network |
             \/\/\/\/\/
                  |
        ------------------+
                  |       |
                  v       |
             +---------+  |
             | sredird |  |
             +---------+  | remote PC with
                  |       | serial ports
                  v       |
             /dev/ttyS0   |
                  |       |
        ------------------+
                  |
                  v
         embedded PC with
         a serial console

As you can see the program sredird
(http://freshmeat.net/projects/sredird/) manages the real serial port
according to the commands received from nvtty0 device and it
sends/receives the serial data to/from it and the userland application
(minicom in this example) doesn't see any difference from working on a
real serial port.

Hope this is useful to you.

Ciao,

Rodolfo

-- 

GNU/Linux Solutions                  e-mail: giometti@...eenne.com
Linux Device Driver                          giometti@...ux.it
Embedded Systems                     phone:  +39 349 2432127
UNIX programming                     skype:  rodolfo.giometti
Freelance ICT Italia - Consulente ICT Italia - www.consulenti-ict.it
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/