Bug 98781 - Failed to activate ppp0 with error 28
Failed to activate ppp0 with error 28
Status: CLOSED DUPLICATE of bug 97845
Product: Red Hat Linux
Classification: Retired
Component: redhat-config-network (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
:
: 98786 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-08 14:56 EDT by John Reiser
Modified: 2007-04-18 12:55 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:56:58 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
strace -f usernetctl <provider> up (161.41 KB, text/plain)
2003-07-09 11:35 EDT, John Reiser
no flags Details
strace -f ifup <provider> (235.92 KB, text/plain)
2003-07-09 11:36 EDT, John Reiser
no flags Details
ls -l of files where EACCES = access(file, X_OK) (1.12 KB, text/plain)
2003-07-09 11:39 EDT, John Reiser
no flags Details
cd /etc; find . -name '*<provider>*' (161 bytes, text/plain)
2003-07-09 11:46 EDT, John Reiser
no flags Details
contents of files with <provider> in filename (584 bytes, text/plain)
2003-07-09 11:48 EDT, John Reiser
no flags Details
sh -x /sbin/ifup <provider> (2.55 KB, text/plain)
2003-07-09 11:54 EDT, John Reiser
no flags Details
sh -x /etc/sysconfig/network-scripts/ifup-ppp /etc/sysconfig/networking/profiles/default/ifcfg-Olympus (1.75 KB, text/plain)
2003-07-09 12:14 EDT, John Reiser
no flags Details

  None (edit)
Description John Reiser 2003-07-08 14:56:05 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529

Description of problem:
After configuring a new modem connection (USB modem on /dev/input/ttyACM0),
attempting to activate it gives "Cannot activate newtork device <provider_name>!
 Failed to activate ppp0 with error 28".
There is no user-level documentation on this error, not even via google
or google/groups.

Version-Release number of selected component (if applicable):
redhat-config-network-1.2.13-1

How reproducible:
Always

Steps to Reproduce:
1.Configure USB modem connection: /dev/input/ttyACM0 [ignore warning of "No
modem was found on your system"], 115200 baud, CRTSCTS flow control; enter phone
number, provider, login, password, ask for auto IP and auto DNS; save.
2.Attempt to activate: fails.
3.Reboot; attempt to activate: still fails.
    

Actual Results:  "Cannot activate network device <provider_name>!  Failed to
activate ppp0 with error 28".

Expected Results:  Modem should dial provider, and activate network upon connection.

Additional info:

Partial workaround: su, then manually invoke "wvdial <provider_name>".
Modem dials phone, connection is established, wvdial invokes pppd.  But there is
no DNS, so you must use numerical addresses.
Comment 1 Harald Hoyer 2003-07-09 04:21:19 EDT
does a 
# usernetctl <provider_name> up
work?
or a 
# /sbin/ifup <provider_name>
?? both as root..
Comment 2 Harald Hoyer 2003-07-09 04:30:10 EDT
the initscripts call wvdial like this:
/usr/bin/wvdial --remotename <providername> <providername>
and later on pppd calls:
/etc/ppp/ip-up which then uses $LOGDEVICE (which is the remotename) to determine
the config script. Then ifup-post does the DNS setting... in your case
$LOGDEVICE is not set to providername, thus the setting fails. you can either
rename the <providername> device to ppp0 by changing its Nickname in
redhat-config-network or we debug, why ifup/usrnetctl does not work.
Comment 3 Harald Hoyer 2003-07-09 04:31:23 EDT
*** Bug 98786 has been marked as a duplicate of this bug. ***
Comment 4 John Reiser 2003-07-09 11:35:57 EDT
Created attachment 92835 [details]
strace -f usernetctl <provider> up

Done while logged-in as root.
Comment 5 John Reiser 2003-07-09 11:36:48 EDT
Created attachment 92836 [details]
strace -f ifup <provider>

Done while logged-in as root.
Comment 6 John Reiser 2003-07-09 11:39:22 EDT
Created attachment 92837 [details]
ls -l of files where EACCES = access(file, X_OK)

/etc/bashrc, /etc/sysconfig/init, /etc/sysconfig/i18n are present and readable
by anybody, but do not have execute permission, hence testing for X_OK fails,
although the shell will still execute them.
Comment 7 Harald Hoyer 2003-07-09 11:41:56 EDT
err... 
# sh -x ifup <provider>
would be more readable :)
Comment 8 Harald Hoyer 2003-07-09 11:42:22 EDT
or
# sh -x /sbin/ifup <provider>
Comment 9 John Reiser 2003-07-09 11:46:01 EDT
Created attachment 92838 [details]
cd /etc; find . -name '*<provider>*'

All the files in /etc or below with <provider> in the filename.
Comment 10 John Reiser 2003-07-09 11:48:29 EDT
Created attachment 92839 [details]
contents of files with <provider> in filename

All the ifcfg-<provider> files are hard-linked to each other.
Comment 11 John Reiser 2003-07-09 11:54:00 EDT
Created attachment 92840 [details]
sh -x /sbin/ifup <provider>

Still fails:
+ exec /etc/sysconfig/network-scripts/ifup-ppp
../networking/profiles/default/ifcfg-Olympus
Failed to activate ppp0 with error 28
Comment 12 Harald Hoyer 2003-07-09 11:57:40 EDT
# sh -x /etc/sysconfig/network-scripts/ifup-ppp
../networking/profiles/default/ifcfg-Olympus
Comment 13 John Reiser 2003-07-09 12:14:03 EDT
Created attachment 92843 [details]
sh -x /etc/sysconfig/network-scripts/ifup-ppp /etc/sysconfig/networking/profiles/default/ifcfg-Olympus

Still fails:
+ exec /sbin/ppp-watch ppp0 ''
Failed to activate ppp0 with error 28
Comment 14 John Reiser 2003-07-09 13:08:29 EDT
The suggested workaround: "wvdial --remotename <provider> <provider>" FAILS to
set DNS.  [Note <provider> appears twice, once for --remotename, and once more.]
 I still have to copy the DNS server settings manually from /var/log/messages to
the Network Configuration > DNS tab, then File > Save, and then DNS works.

Comment 15 Bill Nottingham 2003-08-02 01:21:45 EDT

*** This bug has been marked as a duplicate of 97845 ***
Comment 16 Red Hat Bugzilla 2006-02-21 13:56:58 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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