Searched hist:32381 (Results 1 - 6 of 6) sorted by relevance
| /freebsd-9.3-release/usr.sbin/ppp/ | ||
| H A D | deflate.c | diff 32381 Fri Jan 09 23:55:11 MST 1998 brian Implement Reset{Req,Ack} properly, as per rfc 1962. (I completely mis-read the rfc last time 'round!) This means: o Better CCP/WARN Reset diagnostics. o After we've sent a REQ and before we've received an ACK, we drop incoming compressed data and send another REQ. o Before sending an ACK, re-sequence all pending PRI_NORMAL data in the modem queue so that pending packets won't get to the peer *after* the ResetAck. o Send ACKs with the `identifier' from the REQ frame. o After we've received a correct ACK, duplicate ACKs are ok (and will reset our history). o Incorrect ACKs (not matching the last REQ) are moaned about and dropped. Also, o Calculate the correct FCS after compressing a packet. DEFLATE *may* produce an mbuf with more than a single link in the chain, but HdlcOutput didn't know how to calculate the FCS :-( o Make `struct fsm'::reqid a u_char, not an int. This fix will prevent us from sending id `255' 2,000,000,000 times before wrapping to `0' for another 2,000,000,000 sends :-/ o Bump the version number a little. The end result: DEFLATE now works over an unreliable link layer. I can txfr a 1.5Mb kernel over a (rather bad) null-modem cable at an average of 21679 bytes per second using rcp. Repeat after me: Don't test compression using a loopback ppp/tcp setup as we never lose packets and therefore never have to reset! |
| H A D | fsm.h | diff 32381 Fri Jan 09 23:55:11 MST 1998 brian Implement Reset{Req,Ack} properly, as per rfc 1962. (I completely mis-read the rfc last time 'round!) This means: o Better CCP/WARN Reset diagnostics. o After we've sent a REQ and before we've received an ACK, we drop incoming compressed data and send another REQ. o Before sending an ACK, re-sequence all pending PRI_NORMAL data in the modem queue so that pending packets won't get to the peer *after* the ResetAck. o Send ACKs with the `identifier' from the REQ frame. o After we've received a correct ACK, duplicate ACKs are ok (and will reset our history). o Incorrect ACKs (not matching the last REQ) are moaned about and dropped. Also, o Calculate the correct FCS after compressing a packet. DEFLATE *may* produce an mbuf with more than a single link in the chain, but HdlcOutput didn't know how to calculate the FCS :-( o Make `struct fsm'::reqid a u_char, not an int. This fix will prevent us from sending id `255' 2,000,000,000 times before wrapping to `0' for another 2,000,000,000 sends :-/ o Bump the version number a little. The end result: DEFLATE now works over an unreliable link layer. I can txfr a 1.5Mb kernel over a (rather bad) null-modem cable at an average of 21679 bytes per second using rcp. Repeat after me: Don't test compression using a loopback ppp/tcp setup as we never lose packets and therefore never have to reset! |
| H A D | ccp.h | diff 32381 Fri Jan 09 23:55:11 MST 1998 brian Implement Reset{Req,Ack} properly, as per rfc 1962. (I completely mis-read the rfc last time 'round!) This means: o Better CCP/WARN Reset diagnostics. o After we've sent a REQ and before we've received an ACK, we drop incoming compressed data and send another REQ. o Before sending an ACK, re-sequence all pending PRI_NORMAL data in the modem queue so that pending packets won't get to the peer *after* the ResetAck. o Send ACKs with the `identifier' from the REQ frame. o After we've received a correct ACK, duplicate ACKs are ok (and will reset our history). o Incorrect ACKs (not matching the last REQ) are moaned about and dropped. Also, o Calculate the correct FCS after compressing a packet. DEFLATE *may* produce an mbuf with more than a single link in the chain, but HdlcOutput didn't know how to calculate the FCS :-( o Make `struct fsm'::reqid a u_char, not an int. This fix will prevent us from sending id `255' 2,000,000,000 times before wrapping to `0' for another 2,000,000,000 sends :-/ o Bump the version number a little. The end result: DEFLATE now works over an unreliable link layer. I can txfr a 1.5Mb kernel over a (rather bad) null-modem cable at an average of 21679 bytes per second using rcp. Repeat after me: Don't test compression using a loopback ppp/tcp setup as we never lose packets and therefore never have to reset! |
| H A D | fsm.c | diff 32381 Fri Jan 09 23:55:11 MST 1998 brian Implement Reset{Req,Ack} properly, as per rfc 1962. (I completely mis-read the rfc last time 'round!) This means: o Better CCP/WARN Reset diagnostics. o After we've sent a REQ and before we've received an ACK, we drop incoming compressed data and send another REQ. o Before sending an ACK, re-sequence all pending PRI_NORMAL data in the modem queue so that pending packets won't get to the peer *after* the ResetAck. o Send ACKs with the `identifier' from the REQ frame. o After we've received a correct ACK, duplicate ACKs are ok (and will reset our history). o Incorrect ACKs (not matching the last REQ) are moaned about and dropped. Also, o Calculate the correct FCS after compressing a packet. DEFLATE *may* produce an mbuf with more than a single link in the chain, but HdlcOutput didn't know how to calculate the FCS :-( o Make `struct fsm'::reqid a u_char, not an int. This fix will prevent us from sending id `255' 2,000,000,000 times before wrapping to `0' for another 2,000,000,000 sends :-/ o Bump the version number a little. The end result: DEFLATE now works over an unreliable link layer. I can txfr a 1.5Mb kernel over a (rather bad) null-modem cable at an average of 21679 bytes per second using rcp. Repeat after me: Don't test compression using a loopback ppp/tcp setup as we never lose packets and therefore never have to reset! |
| H A D | hdlc.c | diff 32381 Fri Jan 09 23:55:11 MST 1998 brian Implement Reset{Req,Ack} properly, as per rfc 1962. (I completely mis-read the rfc last time 'round!) This means: o Better CCP/WARN Reset diagnostics. o After we've sent a REQ and before we've received an ACK, we drop incoming compressed data and send another REQ. o Before sending an ACK, re-sequence all pending PRI_NORMAL data in the modem queue so that pending packets won't get to the peer *after* the ResetAck. o Send ACKs with the `identifier' from the REQ frame. o After we've received a correct ACK, duplicate ACKs are ok (and will reset our history). o Incorrect ACKs (not matching the last REQ) are moaned about and dropped. Also, o Calculate the correct FCS after compressing a packet. DEFLATE *may* produce an mbuf with more than a single link in the chain, but HdlcOutput didn't know how to calculate the FCS :-( o Make `struct fsm'::reqid a u_char, not an int. This fix will prevent us from sending id `255' 2,000,000,000 times before wrapping to `0' for another 2,000,000,000 sends :-/ o Bump the version number a little. The end result: DEFLATE now works over an unreliable link layer. I can txfr a 1.5Mb kernel over a (rather bad) null-modem cable at an average of 21679 bytes per second using rcp. Repeat after me: Don't test compression using a loopback ppp/tcp setup as we never lose packets and therefore never have to reset! |
| H A D | ccp.c | diff 32381 Fri Jan 09 23:55:11 MST 1998 brian Implement Reset{Req,Ack} properly, as per rfc 1962. (I completely mis-read the rfc last time 'round!) This means: o Better CCP/WARN Reset diagnostics. o After we've sent a REQ and before we've received an ACK, we drop incoming compressed data and send another REQ. o Before sending an ACK, re-sequence all pending PRI_NORMAL data in the modem queue so that pending packets won't get to the peer *after* the ResetAck. o Send ACKs with the `identifier' from the REQ frame. o After we've received a correct ACK, duplicate ACKs are ok (and will reset our history). o Incorrect ACKs (not matching the last REQ) are moaned about and dropped. Also, o Calculate the correct FCS after compressing a packet. DEFLATE *may* produce an mbuf with more than a single link in the chain, but HdlcOutput didn't know how to calculate the FCS :-( o Make `struct fsm'::reqid a u_char, not an int. This fix will prevent us from sending id `255' 2,000,000,000 times before wrapping to `0' for another 2,000,000,000 sends :-/ o Bump the version number a little. The end result: DEFLATE now works over an unreliable link layer. I can txfr a 1.5Mb kernel over a (rather bad) null-modem cable at an average of 21679 bytes per second using rcp. Repeat after me: Don't test compression using a loopback ppp/tcp setup as we never lose packets and therefore never have to reset! |
Completed in 129 milliseconds