Bug 36537 - rp3 dials but does not notice when modem has connected
Summary: rp3 dials but does not notice when modem has connected
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rp3   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-04-18 18:56 UTC by Jeremy Sanders
Modified: 2007-04-18 16:32 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-18 14:59:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jeremy Sanders 2001-04-18 18:56:00 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-2 i586)

I'm using a standard V90 modem (worked on RedHat 6.2 with rp3). I've set it
up on rp3-config. The debug option on that program dials the connection

When I connect with rp3 (panel or command-line), the modem dials, it
connects (I can use the network normally), but rp3 doesn't notice. It
doesn't keep track of the connection time or show any signs of activity. If
I click again, it still asks me whether I want to connect again.

To disconnect the connection I have to su and kill off pppd.

Reproducible: Always
Steps to Reproduce:
1. Set up modem with rp3-config
2. Run rp3

Actual Results:  The modem dials, pppd connects. Processes running are:

localhost:~> ps auxw | grep ppp
root       904  0.0  0.0  1348    4 ?        S    19:33   0:00
/sbin/ppp-watch ppp0 ifcfg-ppp0
root       906  0.0  0.4  1824  276 ttyS1    S    19:33   0:00
/usr/sbin/pppd -detach lock modem crtscts asyncmap 00000000 defaultro

However, rp3 doesn't display any activity and still indicates the
connection is disconnected, despite the fact that web, ssh, telnet all work

Expected Results:  rp3 should notice when the modem has connected.

wvdial.conf (password removed):

Modem = /dev/ttyS1
Baud = 115200
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 S11=55 +FCLASS=0

[Dialer Defaults]
Modem = /dev/ttyS1
Baud = 115200
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 S11=55 +FCLASS=0

[Dialer ntlworld]
Username = jeremy.sanders1
Password = xxxxxxxxxxxxx
Phone = 5190100
Area Code = 0800
Inherits = Dialer Defaults
Stupid mode = 0
^ tried switching between 0 and 1 in above line, and no difference.

Comment 1 Alessandro Tommasi 2001-04-23 21:47:01 UTC
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

Comment 2 Need Real Name 2001-05-08 05:18:15 UTC
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.

Comment 3 Allan Duncan 2001-05-25 13:34:44 UTC
OK, I'm home now.  Here is the diff:
diff network-functions-5.64 network-functions-5.83

<       [ -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

Comment 4 Need Real Name 2001-06-26 23:54:41 UTC
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.

Comment 5 Jeremy Sanders 2001-06-27 09:03:42 UTC
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.

Comment 6 Shawn Lindsay 2001-06-30 02:24:06 UTC
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.

Comment 7 Allan Duncan 2001-06-30 12:47:56 UTC
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

Comment 8 Louis Berube 2001-08-03 02:00:31 UTC
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.

<         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

Comment 9 Richard Smith 2001-08-03 05:23:46 UTC
This has been fixed in initscripts in Rawhide.

Comment 10 william hanlon 2001-08-07 14:10:37 UTC
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.

Comment 11 Need Real Name 2001-08-25 13:42:04 UTC
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.

Comment 12 eitelman 2001-10-17 14:23:27 UTC
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.

Comment 13 Martin N Dunstan 2001-11-29 12:09:41 UTC
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?

<         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

Comment 14 Louis Berube 2001-12-20 22:37:00 UTC
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.

Comment 15 Bill Nottingham 2006-08-07 17:55:46 UTC
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

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.

Comment 16 Bill Nottingham 2006-10-18 14:59:35 UTC
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

Closing as CANTFIX.

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