ppp => Phase: deflink: Already in NETWORK phase

Hello,

I'm having some difficulties with ppp not being able to renegotiate the
connection properly. I've browsed the ppp logs and came to the conclusion that
"Phase: deflink: Already in NETWORK phase" is the source of the problem. I'm
using ppp to establish/manage my DSL link (PPPoE). Here is the ppp.conf file:

default:
 set server /var/run/internet "" 0177
 set device PPPoE:dc0
 set mtu 1492
 set mru 1492
 set cd 5
 set authname secret
 set authkey secret
 set dial
 set login
 add default HISADDR
 enable dns

PPP is running in the 'ddial' mode.

Whenever the connection is dropped, the following happens:

Phase: deflink: hangup -> opening
Phase: deflink: Enter pause (3) for redialing.
Phase: deflink: Connected!
Phase: deflink: opening -> dial
Phase: deflink: dial -> carrier
Phase: Received NGM_PPPOE_ACNAME (secret)
Phase: Received NGM_PPPOE_SESSIONID
Phase: Received NGM_PPPOE_SUCCESS
Phase: deflink: carrier -> login
Phase: deflink: login -> lcp
Phase: deflink: his = CHAP 0x05, mine = none
Phase: Chap Input: CHALLENGE (secret)
Phase: Chap Output: RESPONSE (secret)
Phase: Chap Input: SUCCESS
Phase: deflink: Already in NETWORK phase
Phase: deflink: lcp -> open
Phase: Clearing choked output queue
Phase: deflink: open -> lcp
Phase: Received NGM_PPPOE_CLOSE
Phase: deflink: Device disconnected
Phase: deflink: Disconnected!
Phase: deflink: lcp -> logout
Phase: deflink: Disconnected!
Phase: deflink: logout -> hangup
Phase: deflink: Connect time: 121 secs: 393 octets in, 114 octets out

The same thing happens every time when the connection drop is followed by ppp's
attempt to renegotiate it. As you can see, it always fails.

On the other hand, if I kill ppp entirely and start the connection setup
process from scratch, everything goes well and link is established properly.
Here is the log:

Phase: PPP Started (ddial mode).
Phase: bundle: Establish
Phase: deflink: closed -> opening
Phase: deflink: Connected!
Phase: deflink: opening -> dial
Phase: deflink: dial -> carrier
Phase: Received NGM_PPPOE_ACNAME (secret)
Phase: Received NGM_PPPOE_SESSIONID
Phase: Received NGM_PPPOE_SUCCESS
Phase: deflink: carrier -> login
Phase: deflink: login -> lcp
Phase: bundle: Authenticate
Phase: deflink: his = CHAP 0x05, mine = none
Phase: Chap Input: CHALLENGE (secret)
Phase: Chap Output: RESPONSE (secret)
Phase: Chap Input: SUCCESS
Phase: deflink: lcp -> open
Phase: bundle: Network

At this point, the link up and I'm able to communicate over it.

If I understood everything correctly, the problem is that when the ppp tries to
renegotiate the connection, it uses old network phase. I guess at this point my
link's peer has already abandoned that old network phase and in order for
renegotiation to succeed, a new network phase has to be setup. But ppp fails to
do that and as a result of that my peer doesn't allow any communication to go
through, which in its turn creates the overflow of the output packet queue.

So if everything said above is correct, then my question is: How would I force
ppp to reestablish that network phase each time my connection is dropped? I've
looked at the ppp/pppctl manual pages but didn't find a solution there.

In case it's needed, here is my uname -a: 

FreeBSD secret 5.2.1-RELEASE-p9 FreeBSD 5.2.1-RELEASE-p9 #0: Sat Jul 10
16:47:35 PDT 2004     root_at_secret:/usr/obj/usr/src/sys/CUSTOM  i386

Any help will be greatly appreciated.

 - Andrew