|Summary:||PLIP doesn't work on RedHat 5.2 (or 5.1) as shipped|
|Product:||[Retired] Red Hat Linux||Reporter:||Red Hat Bugzilla <bugzilla>|
|Component:||netcfg||Assignee:||David Lawrence <dkl>|
|Status:||CLOSED DUPLICATE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||1999-01-06 23:25:51 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Red Hat Bugzilla 1999-01-06 00:37:42 UTC
This bug affects both linuxconf and netcfg. If you try to configure RedHat Linux 5.1 or 5.2 (and probably 5.0 as well) to do PLIP, you will get the following error messages when you try to start it up with "ifup plip0": SIOCSIFADDR: Operation not supported by device plip0: unknown interface SIOCSIFDSTADDR: Operation not supported by device plip0: unknown interface netmask: No address associated with name All except the last message are trivial to fix. Many PC's do not really have a "/dev/lp0" device. The first parallel port is usually "/dev/lp1". That makes the first PLIP device interface "plip1" There is currently no way to tell RedHat to use the "plip1" DEVICE for the first (ie 0) PLIP configuration. The workaround is to create two PLIP configurations (plip0 and plip1), then delete plip0 and set plip1 up the way you want it. If you do this, it still won't work, but all except the last message above will go away. The last message is caused by a bug in Red Hat's plip configuration code. The /etc/sysconfig/network-scripts/ifcfg-plip1 file needs to contain a "NETWORK=" entry which is expected by the ifup-plip script. If you manually add a line with the appropriate network number (e.g. "NETWORK=192.168.1.0"), then "ifup plip1" should work fine. BUT NOTE THAT IF YOU EVER CHANGE THE PARAMETERS OF PLIP1 USING EITHER LINUXCONF OR REDHAT'S NETCFG, YOU WILL HAVE TO REMEMBER TO RESTORE THE "NETWORK" LINE THAT THE TOOL DELETED.
Comment 1 Red Hat Bugzilla 1999-01-06 00:50:59 UTC
Oops, sorry about the duplicate bug ... I just noticed that it is reporting the same problems as #301 reports about linuxconf. The same problems exist in both places, but if netcfg is being phased out, I guess it doesn't matter unless an Errata update gets released.