Bug 27069

Summary:

ppp links may not be up before natd is started, causing natd to fail

Product:

Base System

Reporter:

matt

Component:

bin

Assignee:

freebsd-bugs (Nobody) <bugs>

Status:

Closed FIXED

Severity:

Affects Only Me

Priority:

Normal

Version:

4.3-STABLE

Hardware:

Any

OS:

Any

Attachments:

Description	Flags
file.diff	none

Description matt 2001-05-04 00:10:03 UTC

	In certain situations, /sbin/natd must be used instead of ppp's built-in
	nat.  If a ppp link is being started from rc.network (via ppp_enable),
	it may not be up and have IPs assigned before natd is started.  This
	causes natd to abort, and forces an admin to start natd by hand.

	This is especially important for PPPoE links, which are usually up
	quick enough to not cause this problem, but the odd time can be slow
	and cause this problem to manifest.

Fix: Add a parameter called ppp_delay, which is set to an appropriate delay.
This will allow ppp to fully init the interface before natd is started.

Suggested value of ppp_delay for etc/defaults/rc.conf: 5 seconds?
(Adequate for PPPoE links, would need to be upped to 30/45/60 for dialup)
How-To-Repeat: 
	Configure rc.conf with a ppp link (ppp_enable, ppp_mode, ppp_profile)
	Enable NAT with natd_interface=tun0.

	When the machine is booted, if the ppp link is slow to init, then natd
	will fail to initialize.

Comment 1 Brian Somers freebsd_committer

2001-05-04 11:02:18 UTC

State Changed
From-To: open->closed

I don't believe the suggested fix is appropriate. 

I would suggest setting ppp_mode=background in ppp.conf and adding 
a ``set mode auto'' (or whatever) to your ppp config instead.  You 
may also need to muck about with ``set redial''. 

The thing that concerns me is why you say it's sometimes necessary 
to use natd instead of ppp's -nat switch (or ``nat enable yes''). 
Under what circumstances is this necessary ?