Bug 15275 - Improper network startup sequence with PCMCIA network cards
Improper network startup sequence with PCMCIA network cards
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: initscripts (Show other bugs)
6.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
: 11546 18054 18355 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-08-03 13:36 EDT by d_rosky
Modified: 2014-03-16 22:15 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-08-03 13:36:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description d_rosky 2000-08-03 13:36:00 EDT
I had a problem running the FrameMaker Linux beta on my laptop that appears
to be a problem with the way the network is initialized on laptops with
PCMCIA network cards.

FrameMaker needs to register some RPC services when it initializes and
these RPC registration requests were failing.  The message in the log was:

Aug  2 17:40:12 gvpc8 portmap[1954]: connect from 192.168.241.8 to
set(1587530356): request from non-local host

What appears to be happening is that the network services are not being
initialized in the proper order.    My laptop has a PCMCIA ethernet card. 
For PCMCIA cards, the network is started by the PCMCIA daemon, not the
"network" script.  What was happening was that the portmapper (S11portmap)
was initializing before the PCMCIA daemon (S45pcmcia) had brought up the
eth0 interface, so portmapper didn't know about it.  Later on, when Frame
tries to register new RPC services, those requests come from the eth0 IP
address, which the portmapper thinks is foreign (since eth0 wasn't up when
portmapper initialized).  As a result, the requests fail.

For me, the temporary solution to this problem was to modify the init
scripts in the following way so that the network card comes up before the
network services (such as portmapper):

1. I put the pcmcia script before the network services (portmap and NFS in
particular).

2. I added some delay in the pcmcia script after the PCMCIA daemon is
started so that it waits for any possible network cards to initialize
before it returns to allow the init sequence to continue ("sleep 6" worked
fine for me, but this may be machine dependent).

There may be a better way to fix this problem (such as having the port
mapper notice when a new network interface comes up), but these changes
worked fine for me.
Comment 1 Bill Nottingham 2000-08-06 02:24:03 EDT
At this point, we aren't planning on moving pcmcia startup;
it needs to be after various other things (syslog, etc.)
that force it to be later in the startup sequence.
Comment 2 d_rosky 2000-08-06 20:39:39 EDT
Actually, I should have been a little more specific.  I didn't actually
move pcmcia, I moved portmap and NFS after the existing  location
of pcmcia.  I'm not intimately familiar with init, and perhaps there are
cases where you can't do this, but I haven't noticed any negative
side effects (in fact, I can start both portmap and nfs completely after bootup
with no problems, which is how I discovered the problem).

Would a more acceptable fix be to modify portmap to monitor network interface
ups and downs, or to have the pcmcia daemon restart portmap when
it brings up or down a network interface?  If so, shoud I make a report
on those components?

The problem with the FrameMaker beta not running on laptops has been an issue
on the FrameMaker discussion forum for a couple of months now, and we
just resolved it.  Once Adobe releases the final version, this will become a 
bigger issue if it's not resolved in some fashion.

Regards
Comment 3 Bill Nottingham 2000-08-07 01:13:02 EDT
*** Bug 11546 has been marked as a duplicate of this bug. ***
Comment 4 Bill Nottingham 2000-10-02 17:15:53 EDT
*** Bug 18054 has been marked as a duplicate of this bug. ***
Comment 5 Bill Nottingham 2000-10-04 15:54:15 EDT
*** Bug 18355 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.