In article <[EMAIL PROTECTED]>, Tim Seifert
<[EMAIL PROTECTED]> wrote:
> Hi,
>
> Trying to reconnect to one my ISP, without using the quick reconnect feature,
> results in at failing at the NCP stage, and the ISP hanging up on me pretty
> damn quickly.
>
> MiamiDx produces this message:
>
> "Miami Deluxe is unable to configure the link level protocol. This might be
> due to a faulty line or an invalid configuration at your Internet service
> provider."
>
> I am curious as to what the ISP has NOT done, and what MiamiDx has done up
> until this stage (what does NCP, LCP(?) etc actually mean), and if there's
> anything I can tell my ISP to fix up. I think I'd be a little overwhelmed by
> the absolute nitty gritty (of what those stages are), but what's basically
> going on (passwords, finding IPs, etc)?
PPP configuration is done in two stages:
The first stage is to negotiate physical and link-level parameters, such
as packet size, framing, and to specify some of the higher-level protocols
that are to be used later (authentication, callback etc.). The protocol
to negotiate all this is called "Link Control Protocol" (LCP). It is the
lowest layer of PPP and its configuration always has to be completed before
anything else can be sent across the PPP link.
Once LCP configuration is finished several other protocols are configured
in parallel. This includes authentication (PAP/CHAP/MS-CHAP), callback
(CBCP), compression/encryption (CCP) and at least one "Network Control
Protocol" (NCP), which configures the parameters that are needed
specifically for the network layer. If the network layer is IP (as always
with a TCP/IP stack) then the corresponding Network Control Protocol is
"IPCP", and it configures IP addresses, DNS servers and VJC header
compression.
Typically within this second stage PPP servers requires the authentication
to be completed first, before any other protocols of that stage are
configured. MiamiDx supports that and if the server requested
authentication then it delays other protocols until authentication is
finished, i.e. the order then is: first LCP, then authentication, finally
IPCP and all other remaining protocols. Delaying those other protocols
is required by some buggy Microsoft servers that otherwise just hang up
the line. MiamiDx displays "NCP" as soon as LCP is finished, so you will
see "NCP" for everything that happens after LCP.
After both stages are finished the PPP link is "up" and can exchange
IP packets. At that time DNS verification, host name lookup, DHCP etc.
occur ("finding IP addresses"), and eventually the interface goes fully
online.
As for reconnect:
In an ideal world "quick reconnect" would not be necessary. The point is:
after rebooting, the client no longer knows which parameters have been
negotiated for the various PPP protocols. The correct solution to this
problem is for the client to take the PPP finite state machines down
again and simply go through the negotiation of all stages one more time,
in the same way as if it had just connected. According to the PPP specs
servers are SUPPOSED to support that, but some don't (most notably
Microsoft servers), and instead just hang up the line at some time
during the renegotiation.
The workaround is for Miami to remember all parameters that have been
negotiated, and when going online again to skip the renegotiation and
just take all of its local PPP FSMs into the state they would be if
negotiation had been completed with the stored parameters. This way the
server never knows that the client has rebooted at all. That feature is
called "Quick Reconnect" in Miami.
It's a hack though and has its limitations. One is that it cannot work
with PPP protocols which very frequently change their state, e.g. any
kind of compression and encryption protocols that keep histories, change
encryption keys etc., count packets etc. So far MiamiDx has not
supported compression or encryption at the PPP level, so this was not an
issue. The next version will though, for PPTP/VPN support, and then
Quick Reconnect won't work if those features are enabled. (Of course
from a security point of view the fact that Quick Reconnect does not
work with encryption could be considered a feature, because it makes
physical line take-overs more difficult, and thus the link more secure.)
As to precisely when the other side hangs up during a failing (non-
quick) reconnect: from my experience Microsoft's servers hang up during
LCP. This may have changed recently though, because Microsoft has
started to implement at least a partial support for renegotiation in
recent NT and Win-2000 versions in order to support some proxying
mechanisms needed for L2TP/PPTP-based VPNs. It is very well possible
that because of that LCP now completes during a renegotiation, but
higher levels still don't. That would explain a hangup during NCP. It
is also possible that you are connecting to a non-Microsoft PPP server
which has renegotiation limitations that are different from those in
Microsoft servers.
--
Holger Kruse [EMAIL PROTECTED]
http://www.nordicglobal.com
--
To unsubscribe send "unsubscribe miamidx-talk-ml" to
"[EMAIL PROTECTED]". For help on list commands send "help" to
"[EMAIL PROTECTED]".
