[ previous ] [ next ] [ threads ]
 
 From:  "[|]" <lists at n0t dot net>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  [Fwd: Re: [mpd] m0n0wall pppoe connection]
 Date:  Fri, 20 Aug 2004 12:13:35 -0400
Fred,

Thank you for taking time to look into my problem. Your response helped 
me to understand this a little better.
I have contacted my ISP as well as the mpd developer about this pointing 
them towards this discussion. So far i have not heard back from my ISP 
but received the below email from the mpd developer. According to him 
the behavior is not buggy on the client side.
Does this mean whether I can get this connection going is completely in 
the hands of my ISP?

Thanks in advance

Axel


-------- Original Message --------
Subject: Re: [mpd] m0n0wall pppoe connection
Date: Fri, 20 Aug 2004 10:20:34 -0500 (CDT)
From: Archie Cobbs <archie at dellroad dot org>
To: [|] <a at n0t dot net>
CC: fw at well dot com

  [|] wrote:
> The detailed reply is here:
> http://m0n0.ch/wall/list/?action=show_msg&actionargs[]=80&actionargs[]=60

   ...

> 1) The server is trying to negotiate PPP Multilink, probably uselessly for
> your single-link configuration. Hence the "MP MRRU" and "ENDPOINT DISC"
> options.

Multi-link on a single physical link is not always useless, because
it allows you to send packets larger than the MTU without having to
fragment them at the IP layer (they are fragmented at the PPP layer
instead) so some IP MTU problems are avoided. I.e., it allows the IP
interface to have a "normal" MTU.

> 2) MPD is set up not to use multilink, and thus is rejecting
> that.  However, due to a bug, it's *only* rejecting the "MP MRRU" option
> and not the "ENDPOINT DISC" option.

This behaviour is perfectly legal and this is not a bug. In fact
RFC 1990 explicitly describes this case:

     This option is not required for multilink operation.  If a system
     does not receive the Multilink MRRU option, but does receive the
     Endpoint Discriminator Option, and there is no manual configuration
     providing outside information, the implementation MUST NOT assume
     that multilink operation is being requested on this basis alone.

> 3) The server is refusing to comply with the rejection, I suspect due to
> the apparent acceptance of the "ENDPOINT DISC" option.  Thus, it simply
> keeps trying the same request over and over again, while the client keeps
> rejecting it over and over again.

This is clearly the real problem.

> ISTR another case failing in the other direction, where mon0wall's MPD was
> requesting multilink and not handling the rejection properly (I think that
> one was on PPTP).  Perhaps both bugs are in MPD. :-)

I would be interested in seeing any trace showing MPD doing broken
negotiation.

Cheers,
-Archie

__________________________________________________________________________
Archie Cobbs      *        CTO, Awarix        *      http://www.awarix.com


-- 

[|] a at n0t dot net