Bug 8654 - PLIP assigns the same fake MAC address to source/dest packet fields
PLIP assigns the same fake MAC address to source/dest packet fields
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Michael K. Johnson
: 8523 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2000-01-20 08:30 EST by vigna
Modified: 2009-03-13 16:34 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-05-14 05:31:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description vigna 2000-01-20 08:30:52 EST
In the last week-end I've spent many hours trying to get PLIP working
between two out-of-the-box RedHat 6.1 machines. It took a while to
understand (at least partially) what wasn't working, so here is my
diagnosis (which applies also to bug 8523):
apparently the PLIP driver was written thinking that the
fake MAC addresses and ARP are completely useless to connections
between Linux machines, and are to be implemented only for
compatibility with Windows. This is _not true_. Not only PLIP won't
work without ARP (and you must specify it calling ifconfig, as by
default it is turned of by the initialization code), but the PLIP code
is broken and generates the same MAC address for the source and the
target fake ethernet card under certain conditions. The guilty code is
in plip_open() around line 1000 (my source version is 2.2.12):

      struct in_ifaddr *ifa=in_dev->ifa_list;
      if (ifa != NULL) {
         memcpy(dev->dev_addr+2, &ifa->ifa_local, 4);
         memcpy(dev->broadcast+2, &ifa->ifa_address, 4);

I don't know the details of the ifa_addr structure, but in my case
(and at least in another case I discovered on the news) ifa_local and
ifa_address are equal (to the IP address of the interface). Since PLIP
uses dev->dev_broadcast to keep the receiver MAC address, the packets
are sent around with the same source and destination MAC address: as a
result, they travel but they are not seen by inetd.

I patched the kernels of the two machines forcing the last byte of
dev->broadcast to be the right one (i.e., the last byte of the IP
address of the _other_ machine), and everything works fine. Of course,
due to my lack of knowledge of the internals of the networking system
I could be fixing the problem in the wrong place...

All in all, I suggest two fixes:

1) In plip_init_dev(), do NOT set IFF_NOARP
2) Fix the code above so to create correct fake MAC addresses (I
   suppose someone can guess how to do it right)

There are also some other problems. The PLIP.txt file in the
Documentation directory claims that PLIP is able to transfer data with
the port set in "bidirectional" mode. Unfortunately the docs does not
claim _which_ type of bidirectional port (PS/2? EPP? ECP?). From the
suggested cabling it seems like it's not ECP. In any case, no such
support appears in plip.c, so probably it should be eliminated from
the docs, too. BTW it's a pity, because ECP would be 10x faster than
the current implementation.
Comment 1 Bill Nottingham 2000-03-02 12:08:59 EST
*** Bug 8523 has been marked as a duplicate of this bug. ***
Comment 2 fred-m 2000-05-14 05:31:59 EDT
Not sure if my comment has to do with the diagnostic above, but PLIP
is working again on Red Hat 6.2. More specifically, it works on the
2.2.15 "standard" kernel and also on the 2.2.14 kernel on 6.2 (which has a
patch for PLIP). Please notice that PLIP does not work on the "standard"
2.2.14 kernel (which causes Bug 8523).
Comment 3 David Lawrence 2009-03-13 16:34:54 EDT
*** Bug 8523 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.