ppp => Phase: deflink: Already in NETWORK phase
Andrew Konstantinov
abkonstantinov at earthlink.net
Sun Jul 18 22:47:02 PDT 2004
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20040718/09389c54/attachment.bin
More information about the freebsd-current
mailing list