From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/0 Description of problem: After a ppp interface is taken down the ifdown-post script unconditionally removes /etc/ppp/peers/${DEVICE} file. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Create customer peers config like /etc/ppp/peers/ppp0 2. ifup ppp0 3. ifdown ppp0 Actual Results: The /etc/ppp/peers/ppp0 config file is gone. Expected Results: The /etc/ppp/peers/ppp0 config file should still be there. ifup-ppp will create a peers config if one doesn't already exist which contains just the chat command pointing at the chat-${$DEVICE} file. ifdown-post should either not delete the config file at all or only delete it if it knows it created it in the first place. Additional info: Having a custom peers config makes it very easy to create a pptp tunnel that can be manipulated with ifup/ifdown ect just like any other ordinary ppp connection. Since getting pptp to work at all requires installing a custom pptp and kernel package anyway making a small mod to the init scripts is hardly a chore. Still it'd be nice it worked as expected.
Created attachment 67804 [details] sample /etc/ppp/peers/ppp0 for pptp connection
Created attachment 67805 [details] sample /etc/sysconfig/network-scripts/ifcfg-ppp0 file for pptp
Than, do you recall why we remove the peer config?
if i'm not wrong, it was a problem by changing of nickname. If the user changes the nickname (not device name), the ppp peers' config still has the old nickname there. It will fail by next ifup with old argument --chat NICKNAME.
My workaround has been to use the ifup-pre-local script (a hook in ifup) to copy a fresh copy of the configuration to /etc/ppp/peers. Clumsy, bit it works without patching existing scripts. Note: removing the file is just plain wrong. The peers file is well documented in pppd, and removing these files violates whats described there
Closing bugs on older, no longer supported, releases. Apologies for any lack of response. If this persists on a current release, such as Fedora Core 4, please open a new bug.