[ Pobierz całość w formacie PDF ]
.The result is that the NCP goes to Opened state, but the external interfaces, rout-ing tables, or name databases have not yet become operational.This causes thefirst few user data packets to be lost.COMMON IMPLEMENTATION ERRORS AND EFFECTS 261There are three possible solutions to this problem in PPP.1.Fix the broken implementation so that it puts negotiation messages at theend of the same queue that is used for the messages between the softwarelayers, and make sure that the software messages are always placed at thefront of the queue.2.Fix the broken implementation so that it disables reception of interruptsfor received data when a layer goes to Opened state, and reenable whenthe next layer changes state.3.If the broken implementation is unfixable, as is often the case with systemsthat are shipped without source code, the correctly functioning implemen-tation may need to have a short delay added after sending Configure-Ackin each layer.In the broken implementations I have seen, 300 millisecondsappears to be adequate.This delay, of course, should be configurable, butmay be enabled automatically if a known broken peer is detected.TheLCP Identification message can be useful for this purpose.For the networking and naming problems, the fixes depend strongly on thenetwork protocol being used, but some suggestions are as follows." Use routing protocols and binding services that can quickly and reliablysynchronize with the establishment of the PPP NCP, and delay sending theNCP Configure-Ack until the changes have been propagated on other links.Note that these protocols may have to propagate the changes to many othersystems before synchronization is achieved." Use static routing and static name binding instead of or in addition todynamic routing protocols and name binding services." Implement a delay of a few seconds after the NCPs go up before data areforwarded to other interfaces.During the delay period, network packetsshould be queued.Parameter Change Race ConditionsThis failure mode is more subtle than LCP-to-NCP-transition race conditions, butthe effects are similar.A well-designed implementation of LCP, in order to be asliberal as possible, should set its receive ACCM when the Configure-Request mes-sage from the peer is seen and should set its transmit ACCM only after waitingfor all output to drain after transitioning LCP to Opened state.(Renegotiation is262 DEBUGGING LINKSa special case, and the receive ACCM should be left unchanged until Configure-Request is seen, but the transmit ACCM should be immediately set back to thedefault of FFFFFFFF.)However, since AHDLC encoding and decoding are byte-intensive opera-tions, and most routers are optimized to operate better on a packet-by-packetbasis, AHDLC handling is often delegated to separate dedicated processors.This means that setting ACCM masks requires a communication betweenthe two CPUs, and this synchronization is an occasional source of failure.Themost common failure occurs when the transmit ACCM is set to the final valueeither before or even during the transmission of the LCP Configure-Ack mes-sage.This causes at least some unescaped characters to be sent, and, if the peeris strict in setting its receive ACCM, the packet will be dropped with a cor-rupt FCS.Following the rules above in order to make an implementation as liberal aspossible in receiving data and as strict as possible in sending it will avoid thisproblem in most cases.Renegotiation FailureMany implementations have trouble with renegotiation of one or more layers.Ifyou want to renegotiate LCP, you must be prepared for the peer to fall apartcompletely.Common responses range from immediate termination to negotia-tion loops (LCP negotiates up, then authentication starts, and LCP restarts).Inparticular, Shiva engineers have noted that both the ShivaRemote and Windows95, which uses code developed at Shiva, will immediately terminate the tele-phone connection if LCP renegotiation is attempted.Compression FailureWhen compression fails due to a corrupted dictionary or to implementationerrors, the most obvious result is strange-looking LCP Protocol-Reject messagesfrom the peer.Some of the compression techniques do not detect data corruptionwell, and the result is a decompressed packet with an illegal protocol numberprepended.This causes the receiver to issue the LCP Protocol-Reject for this ille-gal number and to forward the rest of the bad data.This can be confusingbecause the compressor never appeared to send data that contained this bad pro-tocol number.COMMON IMPLEMENTATION ERRORS AND EFFECTS 263Message Field ValidationNot all implementations validate the various fields of the messages they receive.Some common commercial implementations do not bother to check that the IDfield in the Configure-Ack, -Nak, or -Reject matches the last Configure-Requestsent.Some do not bother to check the various Length fields, and a few will evencrash if presented with bad lengths [ Pobierz całość w formacie PDF ]