Re: Linux ppp + MegaPOP dialup change = mrru related LCP timeout

From: James Carlson (james.d.carlson_at_sun.com)
Date: 01/21/05 

Date: 21 Jan 2005 13:32:36 -0500

Michael Shell <news1@michaelshell.org> writes:

> On 20 Jan 2005 09:21:33 -0500
> James Carlson <james.d.carlson@sun.com> wrote:
>
> > Typically, dial-in servers attempt to detect what protocol the peer is
> > using automatically. If the server sees a carriage return, then it
> > assumes that it's a human at a regular tty, not a machine using PPP.
>
>
> That I can understand, but remember that the ISP in question continued
> to send valid PPP ConfReq requests, but ignored all my PPP ConfAck
> responses. Something is obviously broken on their end.

If I remember correctly, your LCP negotiation started off strangely,
with one side (probably theirs) suggesting an asyncmap (ACCM) of
0xa0000, and the other (probably yours) suggesting 0. That's
technically legal per RFC 1662, but is often in practice a good
indicator of bugs in the peer implementation, and usually results in a
failure to negotiate that's remarkably similar to what you saw.

The fix is to add "asyncmap 0xa0000" to your configuration, after some
obligatory swearing at the people who built the bad implementation.

> There is no text
> based login with their system. The very reason ISPs went to pure PPP login
> and skipped the text based login altogether is because of the difficulties
> of handling tech support for all the other different types of
> login/Login/username, text based configurations.

Sure.

> Going deaf after the first
> CRLF kind of defeats the purpose of the default PPP approach because it is,
> IMHO, unsafe to trust the first few characters after the initial connect -
> there is always the possibility that the client will still be chatting with
> the modem or the modem itself may issue a CR at first connect (I've never
> personally seen this, but it would not surprise me in the least if some
> modems did just that). The PPP protocol was designed to handle all types
> of these kinds of initial missteps.

I'm pretty sure I know something like that.

> > I don't think it's the server that's bad. The chat script was bad.
>
>
> I agree that my end did something that it should not have. However, remember
> that the ISP continued to send valid ConfReq requests - and so this is a
> PPP protocol issue (because it happened within PPP negotiation) and I
> don't think the ISP is allowed to do this according to the PPP standards -
> invalid PPP data should be silently discarded and then one should resume
> scanning for valid PPP config requests - the latter of which was not done.

I'm not sure I understand what you're saying here, and I don't see any
specific error that is directly traceable to a violation of any of the
standards.

If the other side cannot hear your side due to communications errors
(which is what I expect is going on here during the failure scenario),
then it rightly should continue sending the same Configure-Request
messages at each Restart timer expiry until the restart limit is
reached.

There's no way that any of the PPP documents can require the peer to
do what it is unable to do. If the packets are getting garbled in
transit (which I expect is true, given the symptoms), there's not much
the peer can do but allow the connection to fail and hope the human
can fix things.

Now if the peer is switching the ACCM too early (before LCP is in
Opened state) or if the implementor confused the transmit and receive
directions for the escaping logic (altogether *way* too common), then
that's indeed an implementation bug. The real issue, though, is the
lack of interoperability, not the conformance (or lack thereof) with
respect to the standards. 

-- 
James Carlson, IP Systems Group                <james.d.carlson@sun.com>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

Relevant Pages

  • Re: Linux dialup to Netscape.net?
    ... > dial the modem, and letting pppd handle EVERYTHING else. ... > You try again without the short packet, and the peer approves. ... > route to the world through the Ethernet, ... >>modem sync, but then fails the authentication, and simply drops the line ...
    (comp.os.linux.networking)
  • Re: Is there a minimum dialup speed that Vista can cope with?
    ... I no longer ring Eircom ... internet/phone bundle with another ISP, UTV (Eircom just rakes in the line ... I'm keeping modem logs because the line quality fluctuates many times ... hardware/software to fail with this slow connection. ...
    (microsoft.public.windows.vista.networking_sharing)
  • Re: wvdial problems
    ... when connecting to a different ISP. ... OK - that basically rules out the modem. ... Support people) is dropping the connection before the default (? ... I've subscribed to a new ISP where the local dialup number ...
    (comp.os.linux.misc)
  • Re: ppp and LCP ConfReq ignored
    ... shell account on the ISP end, and after you get in, starting an application ... running your own dialin server - the keyword is 'autoppp'. ... person who dials in starts sending ppp frames AS SOON AS THE MODEM ...
    (uk.comp.os.linux)
  • Re: OT: Vonage Internet Phone Service Update
    ... When I set up my VOIP my 911 service requested that I call them to verify that they had the correct info. MaBell needs competition to keep them at the best. ... The only thing I have had to do, which I believe is related to my ISP is occasionally reboot my ISP and telephone modem. ...
    (rec.boats)
Loading