dfx hat geschrieben:das ist genau das problem, welches
hier beschrieben und gelöst wird. es liegt an den fli4l developern, diesen patch oder äquivalentes zu implementieren.
Sorry, wenn ich nochmal nachfragen muß: Der hier referenzierte Patch sorgt dafür, daß der pptp-client jedes Paket akzeptiert unabhängig von der Sequenznummer, sehe ich das richtig?
Das verstößt doch aber eigentlich gegen den
rfc 2637, der explizit verbietet (
MUST not), Pakete, die out of sequence sind (eine sequenznummer haben, die kleiner ist als eine bereits eingetroffene), weiterzuleiten:
4.3. Out-of-sequence Packets
Occasionally packets lose their sequencing across a complicated internetwork. Say, for example that a PNS sends packets 0 to 5 to a PAC. Because of rerouting in the internetwork, packet 4 arrives at the PAC before packet 3. The PAC acknowledges packet 4, and may assume packet 3 is lost. This acknowledgment grants window credit beyond packet 4.
When the PAC does receive packet 3, it MUST not attempt to transmit it to the corresponding PPP client. To do so could cause problems, as proper PPP protocol operation is premised upon receiving packets in sequence. PPP does properly deal with the loss of packets, but not with reordering so out of sequence packets between the PNS and PAC MUST be silently discarded, or they may be reordered by the receiver. When packet 5 comes in, it is acknowledged by the PAC since it has a higher sequence number than 4, which was the last highest packet acknowledged by the PAC. Packets with duplicate sequence numbers should never occur since the PAC and PNS never retransmit GRE packets. A robust implementation will silently discard duplicate GRE packets, should it receive any.
Wenn ich diesen Punkt lese, würde ich schlußfolgern, daß der inode ansatz falsch ist (hier würden pakete mit niedrigerer Sequenznummer und duplizierte Pakete weitergereicht) und der pptp-client-Ansatz mit lokalem puffern und reordern zulässig ist.
Wo ist mein Denkfehler?
MfG,
Marvin
PS: Nachdem ich jetzt die Quellen und den Sinn dahinter doch etwas besser verstehe: Der pptp-client kann auf ungepufferten Betrieb geschaltet werden, allerdings sieht die Logik dafür rrfc konform aus:
- Code: Alles auswählen
/* check for expected sequence number */
if ( first || (seq == seq_recv + 1)) { /* wrap-around safe */
// ... accept ...
/* out of order, check if the number is too low and discard the packet. */
} else if ( seq < seq_recv + 1 || WRAPPED(seq_recv, seq) ) {
// discard
/* sequence number too high, is it reasonably close? */
} else if ( seq < seq_recv + MISSING_WINDOW ||
WRAPPED(seq, seq_recv + MISSING_WINDOW) ) {
if ( disable_buffer ) {
// accept
} else {
// buffer
}
/* no, packet must be discarded */
} else {
...
}
das macht genau das im rfc beschriebene ... Und immer noch die Frage, wo ist der Denkfehler?
MfG,
Marvin
