If the peer REJects our MRU REQ, stop REQing it -- *EVEN* if we're

doing PPPoE and the default MRU is therefore too big.

When negotiating with win2k, we ask for MRU 1492 and the win2k box
NAKs us saying ``MRU 1492''.  This doesn't make sense to me.  When
we continue to request MRU 1492, the win2k box eventually REJs our
MRU.  This fix allows negotiations to continue at that point,
bringing the link up and potentially allowing the win2k box to send
us frames that are too large.  AFAICT this is better than failing
to bring the link up.... probably !

I have no idea how to do the equivalent of ``route get'' or
``ifconfig -a'' under win2k, so I can't tell what MTU it actually
ends up using.

I believe the bug is in win2k (it's certainly mis-negotiating).
I'll MFC given the release engineers permission as code freeze
begins on August 1.

PR:		29277
MFC after:	3 days

1 files changed, 1 insertions, 1 deletions

diff --git a/usr.sbin/ppp/lcp.c b/usr.sbin/ppp/lcp.c
index e592e4e..5bdd61d 100644
--- a/usr.sbin/ppp/lcp.c
+++ b/usr.sbin/ppp/lcp.c
@@ -408,7 +408,7 @@ LcpSendConfigReq(struct fsm *fp)
                fp->link->name, lcp->want_mru, maxmru);
     lcp->want_mru = maxmru;
   }
-  if (!REJECTED(lcp, TY_MRU) || lcp->want_mru < DEF_MRU) {
+  if (!REJECTED(lcp, TY_MRU)) {
     ua_htons(&lcp->want_mru, o->data);
     INC_LCP_OPT(TY_MRU, 4, o);
   }