7. FAQ.
This section will (hopefully) solve your problems. If you have any other question, feel free to mail me anytime.
- I get these messages at boot time (or when I load the plip module):
and when I try to set up the link as written above, I get again error messages like:SIOCSIFADDR: No such device SIOCADDRT: Network is unreachable
SIOCSIFADDR: No such device SIOCSIFDSTADDR: No such device SIOCADDRT: Network is unreachable mount clntudp_create: RPC: Port Mapper failure - RPC: Unable to send
- The kernel, for some reason, hasn't PLIP support enabled. This could be
due to:
- You didn't answer yes to "PLIP support? " during kernel configuration.
- You answered yes to "Printer support? " during kernel configuration.
- You compiled PLIP as a module, so you must load it.
- You are addressing the wrong port, i.e. you wrote for instance plip1 instead of plip0.
- The kernel, for some reason, hasn't PLIP support enabled. This could be
due to:
- Is there a way to support both PLIP and LP, beside modules, perhaps with
two parallel ports?
- Yes, so far there are two ways, described in the "Patches to make PLIP
and LP live together":
- You can apply a patch to make the kernel support both.
- You can apply another patch to make the kernel use a parallel port for PLIP and another for LP.
- Yes, so far there are two ways, described in the "Patches to make PLIP
and LP live together":
- I have created the script that connects my 2 computers. I set up the
link automatically in my rc.inet2, where I call a script that creates
the link and enables NFS.
My "two" hosts mounts some "one"'s directories; I have added the
correct entries in "two"'s /etc/fstab.
If I boot "two" when "one" is down, "two" halts for some minutes
on the "mounting remote file systems...".
- This happens because "two" waits to mount the "one" filesystems, but
if "one" is down you must wait until "two" is bored of waiting.
To avoid this, you may:
- Comment out in rc.inet2 the command that mounts the remote filesystems
- Remove the entry in "two"'s /etc/fstab and mount the remote filesystems manually when and if you need.
- A better solution would be for "two" to detect upon booting whether
"one" is up, and mount the filesystem if it is. This can be
accomplished by replacing the mount command in rc.d or whereever
with something like the following:
if ping -c 5 one ; then mount one:/..... fi
- This happens because "two" waits to mount the "one" filesystems, but
if "one" is down you must wait until "two" is bored of waiting.
To avoid this, you may:
- My link is up, but ping fails. I receive the following message from the
kernel:
or similar messages.plip1: timed out (1, 89)- This means that the "your side of the link" is working, your machine
sends the signal, but the "other side" isn't answering or your side is
not waiting at the proper IRQ/IO Address.
This is the most common problem and, alas, has a lot of possible reasons,
usually bad cable or wrong IRQ and/or IO Address. The wrong IRQ is the
source of over 60% of the problems, so it's very likely that changing it
will remove the problem.
Here is a detailed list of possible reasons:
- The cable isn't plugged properly or is broken or is wrong. Check it, if possible, between two Linux hosts which already work with PLIP. If it is not possible, then at least test the cable with a tester. The fact that the cable worked/not worked with DOS/win95 is a good/bad omen but is not a proof.
- The "other side" machine has not PLIP up.
- You are linked with a notebook with a not proper parallel port, see below.
- You have a really cheap parallel port that is a simple "printer" port, so can send and not receive.
- Your parallel port is not set as (at least) bi-directional. Do it in the BIOS configuration. Advanced parallel port settings like EPP or ECP are ok.
- The parallel ports have different irq, so you have to load the plip module (or the lp module) with a different irq. Go back to the chapter "Activate the PLIP link" and choose a different irq.
- Some other device may have shared your irq (which usually is irq 7), it may be a sound card. Do not trust DOS programs like MSD, instead try to load the plip module with a different irq.
- This means that the "your side of the link" is working, your machine
sends the signal, but the "other side" isn't answering or your side is
not waiting at the proper IRQ/IO Address.
This is the most common problem and, alas, has a lot of possible reasons,
usually bad cable or wrong IRQ and/or IO Address. The wrong IRQ is the
source of over 60% of the problems, so it's very likely that changing it
will remove the problem.
Here is a detailed list of possible reasons:
- I put the right IRQ and IO Address, but it still doesn't work. I got the
addresses from the MSD command.
- I got a report from MSD giving wrong port addresses. Try to use this program: http://www.cs.caltech.edu/ huny/para13.zip.
- My link is up, and ping works. I sometimes receive the following message
from the kernel:
or similar messages.plip1: timed out (1, 89)
- This means that the other side has not answered before the timeout. If all is working, you can ignore these messages: usually means that the other side is much slower than yours, either due to older hardware or more load. You can try to tune PLIP with the plipconfig command.
- I have installed the PLIP connection but if I ping I get 100% data loss.
I connected my desktop with a notebook.
- Some notebook's parallel ports aren't good for PLIP, because they are
only "printer ports", i.e. they can only transmit but not receive the
data. So far I don't know if there is a way to make them work.
The only hope is:
- Look at your notebook setup, perhaps there is a way to configure the parallel port as a parallel port instead of a printer port. Usually is called "parallel enhanced mode".
- Try plip mode 0. Alas I don't know how to do it and/or if it works or is still available in the last kernels.
- Some notebook's parallel ports aren't good for PLIP, because they are
only "printer ports", i.e. they can only transmit but not receive the
data. So far I don't know if there is a way to make them work.
The only hope is:
- What speeds can I achieve with PLIP?
- This is an hard question to answer to, because there are MANY factors
that can change deeply your performance:
- The CPU speed on both the sides of the link.
- The parallel port type and settings.
- The system load.
- What do you use PLIP for.
- This is an hard question to answer to, because there are MANY factors
that can change deeply your performance:
- What happens if I need to ifconfig up and ifconfig down many times plip1?
- Seems that you need to add a -arp to the ifconfig command, except for the first time after each boot. I don't need, but perhaps someone does.
- I have read the IP numbers reserved for private networks and your
200.0.0.1 and 200.0.0.2 are not in these ranges. Shouldn't they be changed?
- Yes, they should. But as I underline since the beginning I choose these
IP addresses only because of their simplicity, you are free to change
them as you wish. Here is a cut from the net-2-howto:
RFC1597 has specifically reserved some IP addresses for private networks. You should use these as they prevent anything nasty happening if you accidentally get connected to the Internet. The addresses reserved are: 10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255
- Yes, they should. But as I underline since the beginning I choose these
IP addresses only because of their simplicity, you are free to change
them as you wish. Here is a cut from the net-2-howto:
- Is there a way to fine tune PLIP parameters without editing the source
code?
- Yes, there is. Try the /sbin/plipconfig command. See the man page for more info.
- I'm running Debian GNU/Linux, and under Debian, the files
/etc/rc.d/rc.inet1 and 2 do not exist. Where must I write the plip
configuration commands?
- In Debian GNU/Linux you must edit /etc/init.d/network, where you have to put all the commands that should stay in rc.inet1 and 2.
- I have some problems linking two hosts with PLIP. The first has the
latest kernel, the second still uses the 1.0.x PLIP version: is this a problem?
- Yes, it's much better, where is possible, to have the same PLIP version on both ends. In the plip.c is written that the actual PLIP cannot work with the 1.0.xx PLIP.
- Right now PLIP works with 4 bits, what about the 8 bit PLIP I've read
in the kernel docs? I think is called Mode 1.
- This Mini-HowTo is for configuration, for technical informations please read the /usr/src/linux/drivers/net/README*.PLIP files or contact the author. What I know is only this: the standard PLIP uses "null printer" cables and is the Mode 0 (don't confuse it with plip0, which is the interface name), which uses 4 bits; Mode 1 uses 8 bits and should be available already, but will need an handmade cable and will work only between 2 Linux hosts. I don't know, once you got the cable, how to set up the Mode 1 PLIP link; if somebody does, please let me know.
Next Previous Contents