Bug 20798

Summary: pppd takes wrong IP
Product: [Retired] Red Hat Linux Reporter: Need Real Name <i.yushmanov>
Component: pppAssignee: Thomas Woerner <twoerner>
Status: CLOSED NOTABUG QA Contact: Aaron Brown <abrown>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-13 09:25:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2000-11-13 21:08:49 UTC
I've got the following problem running pppd 2.3.10-3 on RedHat 6.1,
Kernel 2.2.12-20 or 2.2.16-21

(Reviewing bugreports I found one more mentioning of the same problem
by peter in bug ID6295, but not answered)

So the problem:

There is a host connected to a LAN/WAN via Ethernet having a modem
(ppp server). It's IP is N.
The remote host connecting via modem line has no other connections
and pretend to use IP M. (M is a legal IP on the same subnet as N
known by DNS and not used by any machine) 

So on server side /etc/ppp/options contains addresses N:M.
On the client side - just the reverse M:N.
(no other options files exist, command line options aren't used)
pppd is suid root, so it can and it does read /etc/ppp/options
(I'm sure it does because other options like debug,proxyarp,
noauth are working)

When I start pppd on server as root - everything works fine.

But if I start pppd on server as ordinary user ppp0 interface
on server is getting IP address N+1 (!!!).
And that cause a trouble on the LAN - it's an IP of other running
machine.

What is the reason? Why it ignores an IP given in options file and use
some other of it's own choice?
Even if setting IPs is a priveleged option (which seems not to be the
case according to man page) it's coming from a priveleged source - it
should work...

Comment 1 Thomas Woerner 2004-08-13 09:25:48 UTC
Please verify this with a newer version of Red Hat Enterprise Linux or Fedora
Core and reopen it against the new version if it still occurs.

Closing as "not a bug" for now.