d/freebsd-skq
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Brian Somers 2001-07-30 17:04:39 +00:00
parent cd2b9510b7
commit 5a0827311e
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
usr.sbin/ppp/lcp.c
View File

@ -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);
}