LCDproc development and user support list

Text archives Help

[lcdproc] Current developpement question...

Chronological Thread 
  • From: dglaude AT (David Glaude)
  • Subject: [lcdproc] Current developpement question...
  • Date: Sat, 16 Sep 2000 16:09:49 +0200

>From: Matt
>[mailto:madmatt AT]
>Sent: Saturday, September 16, 2000 2:58 AM
>To: LCDproc mailing list
>Subject: RE: [lcdproc] Current developpement question...
>That would be a complete an utter fudge! I can see all the hd447870 people
>queuing up to complain that their hardware is foobar'd now... Transmitting
>parallel port timings over a network connection, eurgh!

Why eurgh?
You just say "between this caracter and the next one you need to wait 40
It is up to the PC(?) connected to the parallel port to implement the right

So you think this idea does not apply to HD447870.
But I still believe it might be very nice for serial based LCD.

>A much better idea is too keep the transmissions in a higher language, and
>let the TCP code talk via a driver to the hardware. That way, we don't
>have to write different protocols.

That seems to be required for parallel attach LCD, not for serial one.
If you consider serial, then we don't need any protocol...
Just open the TCP connection (no authentication) and write into the pipe
what you would have send into the serial port once open.

>In the case of the Cisco hardware, that would be taken care of a cisco
>driver, supplied with the address of the cisco box as an argument.

It is not related to cisco hardware,
just they provide a way to transport serial communication transparently
accross a TCP connection.
The reason why "I DON'T WANT A SPECIAL DRIVER" is because it will be a
Matrix or Cristal LCD
attach to the AUX (assync serial) port of the cisco box or access server or
PC running linux or windows.
So the driver is the same as the serial one... just another way to open the
device and write the bytes.

>Ditto for HP LaserJets...

HP LaserJets (if we find the way to talk to those) need their own driver for
Just because they will have their own protocol. Different protocol require
different driver.

>Perhaps an idea would be to have master and slave LCDd's? One master LCDd
>that doesn't have any displays transmits to some slave LCDd's that all
>have various bits of hardware connected.

This could be very nice indeed, but in the cisco/access server/...
For the solution I am talking about,
you don't write any special software
on the cisco/access server/... side (just not possible).

You don't need any special inteligence on the LCD side.
All the processing is done on the LCDd side.

It is like your master slave LCDd but the slave is a very thin client. ;-)

>But until we get this challenge authentication in place for network
>we're opening up more and more potential security holes every time we
suggest sticking something
>over a network connection.

There no security issue in what I propose.
LCDd is not made less secure because it send it's output accross a TCP
Of course the information we transport could be sniff by someone on the
network (and see what we display).
Of course the cisco device need to protect itself so that only the server
running LCDd will
be accepted to talk to the serial port.
If there are any security issue, it is not on the LCDd side and the only
harmfull thing
we can do to LCDd are the same we could do by connecting to the serial port
(in place of the LCD).

>No offense, but the 0.4 series has some fairly exploitable holes,
>and I'm fairly sure we'll become the bane of Cisco
>admins the world over if we start writing serial data left, right, and
>centre over the network directly to their hardware.

Their hardware are just a way to transport the information from LCDd to the
physical LCD.
If they plan to have an LCD connected to their box in order to display
things in a wiring closet,
it is up to them to secure the thing the way they want.


We don't understand each other because I am talking about serial and you are
thinking about parallel.
Isn't it?

To unsubscribe from this list send a blank message to
lcdproc-unsubscribe AT

Archive powered by MHonArc 2.6.18.

Top of page