If you start an rp3 session while already connected, the program correctly
detects the interface. By stracing, I have seen that in this case, the program
accesses /proc/net/devs, where it is probably looking for interfaces. Rp3 does
NOT seem to access (as far as strace can tell me) /proc/net/dev in any way if no
connection is already up when it is launched.

When it detects that the interface is up, however, it won't notice when it goes
down... You can strangely start an rp3 session, use it to connect, start a
second one after the connection is up, and use it to disconnect. You can always
use the first one to connect, and the second one to disconnect. A rather funny
behavior.

If you open the rp3 properties window, click any of the buttons in the "basic"
section, then click the same button again (ie you haven't actually changed 
anything, but the apply button will un-gray as something has been modified),
then OK the properties window, it will "notice" that you've either connected
or disconnected - ie this seems to force the GUI to read the current status of
the network link, and update appropriately.

OK, I'm home now.  Here is the diff:
diff network-functions-5.64 network-functions-5.83

39,41c39,43
<       [ -f $i ] && \
<         kill -SIGIO $i >/dev/null 2>&1 || \
<           rm -f $i >/dev/null 2>&1
---
>       if [ -f $i ]; then
>         OWNER=`ls -l $i | awk '{ print $3 }'`
>         su $OWNER -c "kill -SIGIO $i >/dev/null 2>&1" > /dev/null 2>&1 || \
>            rm -f $i >/dev/null 2>&1
>       fi

After I upgraded from 6.2 to 7.1 I experienced this bug exactly as described.
But I've found (which no-one else has said so far) that if I run the desktop as
root rp3 works perfectly well.

Yes - I found that running as root worked. Strangely, I've now upgraded my
machine (same modem, though), and now rp3 works!?!?

I still have the old machine, if anyone wants me to compare the
working/non-working setup.

Logging in as root does not solve the problem for me, however sometimes when I'm
logged in as myself it works--the little green light is on and the word
"disconnect" shows on mouse-over.  Sometimes it doesn't work.  I have no clue as
to why.  It might be worth noting that my /home directory is on a separate
partition that has not been formatted since redhat 7.0.  Mandrake 8.0 was
briefly installed, and perhaps because I neglected to delete /.orbit-me, my
Gnome prefs were the same as in Redhat 7.0, including the panel icon for rp3
(which wasn't functional).  I have some inconsistencies in my user ID #'s and
haven't gotten around to chown-ing everything.  Well, I hope this helps to
identify the problem.

My cryptic comment from 25-May is a follow up to something I mailed direct to
nalin when I didn't
have bugzilla access.
In essence, the file is /etc/sysconfig/network-scripts/network-functions, and
the version that came
with the initscripts-5.83-1.rpm breaks, but the 5.64 version doesn't - at least
on my setup.
Try the oldpackage and see if the problem gose away.  I saved this earlier file,
but kept the rest of
5.83.

I had a similar problem with rp3. After several days of manual top-down tracing,
I found that the SIGIO argument given to kill in the network-functions file is
not recognized by kill. When I replaced SIGIO by POLL, whose numeric value is
the same, rp3 worked OK. (I also had to remove the i/o redirection arguments -
see below.)

Here is the diff between the old version and my new version of
/etc/sysconfig/network-scripts/network-functions. Hope it helps your problem.

41,42c41,44
<         su $OWNER -c "kill -SIGIO $i >/dev/null 2>&1" > /dev/null 2>&1 || \
<            rm -f $i >/dev/null 2>&1
---
>       ### Note that kill doesn't regognize SIGIO as an argument,
>       ### so we use POLL instead, which kill does recognize and whose
>       ### numeric value is the same.
>         su $OWNER -c "kill -POLL $i" || rm -f $i

This has been fixed in initscripts in Rawhide.

I have applied the fix provided by lberube@netcom.ca on 2001-08-02 22:00:31 and
now my rp3 applet does recoginize it is connected. But now the "Waiting..."
popup does not go away after I connect to my isp (it must be closed manually and
rp3 continues to work fine after this is done).

"Waiting..." popup not disappearing after connection is listed as bug 47738.

Thanks, lberube@netcom.com, for the fix suggestion. I discovered, however, that
you do not need to replace -SIGIO with -POLL. -SIGIO is not an incorrect signal,
it is a syntax error. Replacing this with -IO fixes this problem, so that now it
will bring down ppp every time. This is probably a better solution, in case they
ever reassign the SIGIO and SIGPOLL numbers.

I also found that if rp3 gets confused and thinks that the connection is down
when it is up, restarting rp3 appears to fix the problem (once the fix is
applied to the network-scripts). When I restart when the connection is up and
select the interface, it pops up with the green dot in the button, indicating
that it knows its up. Seems to work for me this way. In other words, if you use
rp3 for one task at a time, it appears to work okay. Any other combination and
its little brain gets addled.

Much of the time when I try to dial my ISP, erols.com, the
dialog box "Waiting to connect" fails to recognize login.
The monitor applet docked on the panel shows the green
light, but the dialog box remains on the screen. Sometimes
the light fails to turn green as well. Clicking the Cancel 
button on the Waiting dialog box will disconnect from the ISP
and the dialog box goes away. But sometimes it all works
fine. Running kppp under KDE works fine as does running
the RH PPP dialer under KDE. If I reboot the system from the
graphical login screen (NOT the Gnome desktop), the 
problem usually disappears. Sometimes, more than one
reboot is necessary. At other times, disconnecting from my
ISP and reconnecting fixes it. If after using rp3, I do 
something else like using Netscape or playing games or 
installing other software, rp3 usually has the same trouble
abain. And again, loggin out of Gnome and rebooting from
the graphical login screen usually fixes the problem.
Hardware is: Pentium 4 at 1.3 GHz, Intel D850gb mother-
board, US Robotics hardware V.90 modem.

I've been hitting this problem with rp3 dialer with
RH 7.{0,1,2}. There are two problems with the code
in do_netreport:

1) The use of "su" with I/O redirection assumes that
$OWNER is using Bourne-shell or equivalent. This fails
if they use tcsh etc instead. The fix is to remove
all I/O redirection executed by "su" and move the "rm"
outside of the "su" command. 

2) The use of kill -SIGIO fails for me: my fix is to
use /bin/kill -s SIGIO instead but I don't know if that
will work on all platforms. Perhaps -POLL is better?

74c74,75
<         su $OWNER -c "kill -SIGIO $i >/dev/null 2>&1 || rm -f $i >/dev/null
2>&1" > /dev/null 2>&1
---
>         su $OWNER -c "/bin/kill -s SIGIO $i" > /dev/null 2>&1 || \
>               rm -f $i >/dev/null 2>&1

I have found a curious bug. This occurred with the fix from mnd@dcs.st-and.ac.uk
installed, but I don't think it is a problem with the fix itself.

rp3 works OK if the login shell is tcsh, but does not work properly if the login
shell is bash. The symptom is that the dialer logs in OK but the indicator
button shows an off-line status. Of course, this causes difficulties when trying
to terminate the connection.

I think this has something to do with the various scripts rather than the fix -
somewhere an assumption must be made that the user's shell is tcsh.

Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Red Hat apologizes that these issues have not been resolved yet. We do
want to make sure that no important bugs slip through the cracks.
Please check if this issue is still present in a current Fedora Core
release. If so, please change the product and version to match, and
check the box indicating that the requested information has been
provided. Note that any bug still open against Red Hat Linux on will be
closed as 'CANTFIX' on September 30, 2006. Thanks again for your help.

Red Hat Linux is no longer supported by Red Hat, Inc. If you are still
running Red Hat Linux, you are strongly advised to upgrade to a
current Fedora Core release or Red Hat Enterprise Linux or comparable.
Some information on which option may be right for you is available at
http://www.redhat.com/rhel/migrate/redhatlinux/.

Closing as CANTFIX.