N. Albert via plug on 13 Jan 2025 17:55:13 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] Parallel port with Debian 12


On 1/13/2025 8:36 PM, Michael Lazin via plug wrote:
I know a lot of businesses use unsupported legacy software but Window server 2008 sounds scary for a production system. This is long out of date and dangerous to run in production. I realize this is a Linux group but I couldn't help but say this for starters.

This is running at home and I'm the only one responsible for it, so I'm comfortable with it. Same with the Windows 7 PC on which I'm typing this. If Microsoft still made good software, things would be different, but that's not the world we live in anymore. (In any case, that's a separate issue I had, not actually pertinent to the parallel port issue.)

  I don't think you can write to the parallel port with bash directly.  I have had a little bit of experience playing around with an arduino, I tried unsuccessfully to turn it into a web server and it required C programming which I am a rank novice at.  I think that writing to the parallel port is just like the arduino, you have to use a compiled language and have some knowledge of how drivers work.

Hmm, from some research I did initially, it seemed like it should be possible - for example, this thread has an example of sending data to /dev/lp0: https://www.linuxquestions.org/questions/linux-newbie-8/send-data-using-parallel-port-651992/ Of course, not everything online is true :) - but I did find a few different examples doing something similar.

I actually did write a basic C program as well, and that also didn't work. I tried a few variants of:
outb(val, 0x378);

I tried a few different memory addresses for the parallel port, like x278 and a few others, but none of them worked.

I could not get my arduino web server working because I could not successfully write a driver for the attached storage.  I agree that CUPS has bloat but you will find that Debian has alternatives.

The reason I said "CUPS is bloat" is because I don't need anything more than the ability to write raw bytes directly to the device file (e.g. /dev/lp0) or the device address (e.g. 0x378). I'm not looking to share a printer, or format what I'm printing, and as far as the computer is concerned, it doesn't even know what I've connected is a printer.

NA

On Mon, Jan 13, 2025 at 8:21 PM N. Albert via plug <plug@lists.phillylinux.org <mailto:plug@lists.phillylinux.org>> wrote:

    I've had some problems with Debian 12 for a while, and I'd be
    interested
    to know if anyone else has experienced a similar issue.

    A while back, I was hooking a POS (point of sale, it works fine)
    printer
    for printing alarm logs, and I intended to connect it to a Debian
    server
    to send jobs to it, since Linux is more conducive to automation. I
    couldn't use it locally, since it was connected to my one tower
    server
    without a parallel port. Hardware was your typical friendly OptiPlex
    mini tower. It didn't work, and going through dmesg at the time and
    putzing with various pp drivers and the like, I was seeing some
    parport-related stuff but not everything you'd expect to see on a
    working system, and I couldn't get it working successfully.

    Note that I was not using CUPS (which for this, I would consider
    to be
    unwanted/unneeded printer bloat), so there were theoretically fewer
    things that could go wrong. My plan was to write directly to the
    parallel port device, and even that did not work. From my notes, here
    are some of the oddities I uncovered:

    # lspci -v | grep "arallel"
    # (No output... there should be though)

    # dmesg | grep "parport"
    [   17.617561] parport_pc 00:03: reported by Plug and Play ACPI
    [   17.617644] parport0: PC-style at 0x378 (0x778), irq 7
    [PCSPP,TRISTATE,EPP]
    [  617.160115] lp0: using parport0 (interrupt-driven).
    # (Some output from dmesg... but there should be more)

    # echo "test" > /dev/lp0 # Succeeds, but does nothing
    # echo "test" > /dev/parport0
    -bash: echo: write error: Invalid argument

    I later had another driver-related issue with Debian 12 not
    installing
    successfully in HyperV on Server 2008 R2, but the Debian 11 installer
    worked (the issue appears to be purely with the installer). After
    this,
    I suspected driver regressions in Debian 12 that may have broken the
    parallel port. I reported that driver issue[1] to the Debian team,
    but
    not my parallel port issues since at the time I didn't feel I had
    enough
    evidence.

    The hardware (OptiPlex 745 MT) should work just fine. At the time, I
    moved the connection to a Windows server on similar hardware
    (OptiPlex
    980 MT), and unsurprisingly, it works perfectly fine in Windows.
    Unfortunately, I wanted to send jobs to it from a Linux machine, and
    Windows doesn't natively have the ability to run a simple TCP print
    server on port 9100. I couldn't even find any working software for
    Windows that would allow me to simply send jobs to a TCP port and
    have
    them print, and I don't have much of a Windows development background
    either so I gave up on that approach. I ended up having to set up a
    service user to spool jobs to LPT locally and use smbclient to submit
    print jobs from the original Linux server that needed to print
    jobs, to
    the Windows server. Clunky, but this actually worked fine:

    echo "Hello world 123" | smbclient //$SERVER/$PRINTER -U
    $DOMAIN/$USERNAME%$PASSWORD -c "print -" # worked

    Fast forward to recently, I ended up finally disabling NTLM
    completely
    in Active Directory, and with a few exceptions, everything is working
    fine... except now I can't print to the Windows Server anymore
    since the
    Linux server isn't domain joined (and I don't want to join it) so it
    can't use Kerberos. It's not working even with exceptions for both
    hosts
    involved, so I think this is my cue that my original workaround was
    silly from the beginning and I should try to get it working the way I
    wanted to originally, using the parallel port... under Linux. It
    would
    be a lot simpler, and I wouldn't have to deal with Active
    Directory either.

    It's a bit difficult for me to test, since every other machine I have
    with a parallel port is running either Windows or Windows Server, and
    this server is also doing other things. Before I try downgrading the
    server to Debian 11 to see if that helps, I wanted to see if
    anyone had
    any datapoints that either support or contradict my experiences thus
    far. Is *anyone* using the parallel port under Debian 12 (or another
    version), on any hardware, with success?

    [1]
    https://www.mail-archive.com/debian-bugs-dist%40lists.debian.org/msg2006966.html
    ___________________________________________________________________________
    Philadelphia Linux Users Group         -- http://www.phillylinux.org
    Announcements -
    http://lists.phillylinux.org/mailman/listinfo/plug-announce
    General Discussion  --
    http://lists.phillylinux.org/mailman/listinfo/plug



___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug


___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug