Hello, I am trying to get a PLIP connection working and have had no luck in doing so. Pings never seem to resolve. Has anyone successfully used it recently? The null parallel cable used is the same as what's listed in the source file src:/drivers/net/plip/plip.c except pin 17 is not connected, but I'm under the impression it's not actually needed, so it doesn't matter. Both computers are set to use ECP,IRQ7,DMA3 in their BIOS, but EPP and Bi-Directional modes were also tried.

This output is from one computer, the other is the same other than host and remote IP addresses being swapped.


# ip a
5: plip0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 10
link/ether fc:fc:c0:a8:4d:01 peer ff:ff:ff:ff:ff:ff permaddr fc:fc:fc:fc:fc:fc
inet 192.168.77.1 peer 192.168.77.2/32 scope global plip0
valid_lft forever preferred_lft forever
inet6 fe80::fefc:c0ff:fea8:4d01/64 scope link
valid_lft forever preferred_lft forever


# ip l
6: plip0: <POINTOPOINT,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN mode DEFAULT group default qlen 10
link/ether fc:fc:c0:a8:4d:01 peer ff:ff:ff:ff:ff:ff permaddr fc:fc:fc:fc:fc:fc


# ip r
127.0.0.0/8 dev lo scope link
192.168.77.2 dev plip0 proto kernel scope link src 192.168.77.1

How old is the hardware? Why not usb?

PLIP was the parallel port interface. All the fixed I/O and fixed IRQs were displaced in favour of P&P & dnyamically assigned stuff. There may be some form of revised drivers on life support in the kernel somewhere but you could check that yourself. Has the kernel Documentation anything on it?

The last place these sort of things survived were in 'Industrial PCs' which kept old industrial equipment creaking along. Machinery on the factory floor can be up to 20 years behind the curve, but today's emphasis on productivity without downtime meant that the places with old junk were usually closed down.

Not sure if this will be of any help, but.....

https://docs.kernel.org/networking/plip.html

Hmm, I should have been more specific.
I have already read all the Linux documentation I could find, which seems to be oriented towards older use of 'ifconfig' and 'route' usage and earlier kernels in the 2.x range. I have not found any examples of people using it recently with the 'iproute2' tools. Therefore, I'm curious if anyone in recent years has evidence that it still works?

It's still in the kernel and has seen code changes in recent years.
https://git.kernel.org/pub/scm/linux...p.c?h=v5.15.79

The most useful post I could find was this one:
https://www.linuxquestions.org/quest...1/#post1307001

IIRC, the kernel went from 2.x.x to 3.x.x around 2004, and we stopped getting forced to use gcc-2.95-3 for building kernels shortly after. Kernel 3.x.x phased out support for all fixed I/O & irq, although software skullduggery kept some (notably serial ports) alive.

I had a digital oscilloscope using PLIP which spent 3 months going backward & forwards before they got the digital levels tweaked so it went high and low. I had to put my 'real' oscilloscope on it, to find it wasn't going below 1.2V or somesuch because the impedance was too low for the lousy digital chips of the day.

If your hardware is ancient (you haven't given details), I'm not surprised it doesn't work.

One side is a T23 Thinkpad, the other is a system from 2008, so post Y2K. The T23 has ability to set to: Output Only, Bi-Directional, EPP, and ECP. The IRQ can also be specified (5 or 7) and ECP allows to select DMA of 1, 2, or 3. The 2008 computer has the same options but also has an additional parallel mode listed as "ECP+EPP".

I've looked at 'lsirq' and 'irqtop', and the parport driver has IRQ counts, so it would appear that interrupts are being triggered in some manner.

My understanding is the kernel modules have a dependency structure like so:
parport <- parport_pc <- plip

Kernel message output looks like this:
Nov 26 02:56:26 hostname kernel: parport_pc 00:03: activated
Nov 26 02:56:26 hostname kernel: parport_pc 00:03: reported by Plug and Play ACPI
Nov 26 02:56:26 hostname kernel: parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Nov 26 02:56:26 hostname kernel: ppdev: user-space parallel port driver
Nov 26 02:58:07 hostname kernel: NET3 PLIP version 2.4-parport gniibe@mri.co.jp
Nov 26 02:58:07 hostname kernel: plip0: Parallel port at 0x378, using IRQ 7.

So I upped the /proc/sys/kernel/printk level to 8, to get more kernel debug output and can see that after setting machine A up with plip, that it outputs debug:
plip0: transmit timeout(1,7f)

After setting up machine B and bringing the plip interface up, machine A outputs debug:
plip0: receive timeout(2,c7)

This would indicate to me that there is some limited communication occurring, at least enough for machine A to transmit to machine B, but gets stuck in the timeout waiting to receive. I'm looking at the driver source code to see if I can figure out where it's getting stuck.

Get a 'scope on the parallel ports & check the levels. If the parts are TTL, You need

• Under 0.8V for low
• Over 2.0V for high
• Basically zero time between those levels

If the parts are CMOS, the levels are completely different.