[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch, m0n0wall dash dev at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] PPPoE problems anyone?
 Date:  Thu, 26 Aug 2004 20:56:31 -0700 (PDT)
On Thu, 26 Aug 2004, Manuel Kasper wrote:

> We recently discovered that david me's PPPoE problems (being able to
> connect with m0n0wall 1.0, but not 1.1) were related to two MPD
> options that were introduced after 1.0 and that request the
> primary/secondary DNS servers from the peer. Apparently, with these
> options specified, he wasn't able to connect; removing them solved
> the issue. Looking at MPD code, it seems that MPD shouldn't insist on
> getting the DNS servers if the peer rejects the request, and now
> (once more) it's not clear whether it's MPD or his ISP's PPP server
> that is at fault.

It should be clear whose fault it is by looking at a packet trace.  Or
even the MPD log may sufficient, though it might need the "debug" option
turned on for enough detail.

A proper successful case looks like:

1) Client Configure-Requests the option, with 0.0.0.0 as the value.

2) Server Config-Naks the option, specifying the correct value.

3) Client Configure-Requests the option again, with the correct value.

4) Server Configure-Acks it.

For the proper unsuccessful case:

1) Client Configure-Requests the option, with 0.0.0.0 as the value.

2) Server Config-Rejects the option.

3) Client omits the option from subsequent Configure-Requests.

Note that all packets involved can contain multiple options, so the above
sequence may vary due to handling of other options.  The fully general
sequence is:

1) Initiator Configure-Requests desired options.

2) Responder Configure-Rejects the subset of those options that it
refuses.

3) Initiator Configure-Requests unrejected desired options.

4) Responder Configure-Naks options whose values it wants to change, with
desired new values.

5) Initiator Configure-Requests unrejected desired options, with updated
values.

6) Responder Configure-Acks the option list.

Some steps may be unnecessary, depending on particulars.  Steps 4 and 5
might repeat to "converge" on an acceptable value, but in most cases a
single modification to the request is sufficient.

The entire sequence is done both ways between client and server (hence the
terms "initiator" and "responder" above), since a number of options are
per-direction or per-endpoint.  And of course dropped packets cause
retransmissions.

This whole process happens for each sub-protocol that negotiates options,
first for LCP (for basic link parameters), then for others, e.g. IPCP for
IP.  The DNS IP options are in this latter category.

BTW, out of defensiveness I'd recommend that an implementation treat a
Configure-Nak with a 0.0.0.0 IP address as if it were a Configure-Reject.  
Te peer shouldn't do that, but if it did, handling it "normally" would
cause an infinite loop.

> To -dev: if somebody on this list is looking for something to do/help
> with, investigating this issue would be available. Any takers? It's
> about the "set ipcp enable req-pri-dns" and "set ipcp enable
> req-sec-dns" MPD options. Of course we could just make m0n0wall not
> generate those MPD options if the "Allow DNS server list to be
> overridden by DHCP/PPP on WAN" option is not checked, but maybe
> there's a better solution.

Is there any reason to have those options on in a case where the results
would be ignored, anyway?

					Fred Wright