Searched hist:32658 (Results 1 - 9 of 9) sorted by relevance
/freebsd-10.1-release/usr.sbin/ppp/ | ||
H A D | main.h | diff 32658 Tue Jan 20 20:47:48 MST 1998 brian Allow an optional delay when specifying "set openmode active". The delay defaults to 1 sec (as it always has) unless we've done a ~p in interactive mode or we've actually detected a HDLC frame. This is now cleanly implemented (via async timers) so that it is possible for LCP to come up despite the delay if an LCP REQ is received. This will hopefully solve situations with slow servers or slirp scenarios (where ECHO is left on the port for a second or so before the peer enters packet mode). Also, ~p in interactive mode no longer changes the value of the default openmode delay and -dedicated mode enters packet mode in the right state according to the value of openmode. |
H A D | fsm.h | diff 32658 Tue Jan 20 20:47:48 MST 1998 brian Allow an optional delay when specifying "set openmode active". The delay defaults to 1 sec (as it always has) unless we've done a ~p in interactive mode or we've actually detected a HDLC frame. This is now cleanly implemented (via async timers) so that it is possible for LCP to come up despite the delay if an LCP REQ is received. This will hopefully solve situations with slow servers or slirp scenarios (where ECHO is left on the port for a second or so before the peer enters packet mode). Also, ~p in interactive mode no longer changes the value of the default openmode delay and -dedicated mode enters packet mode in the right state according to the value of openmode. |
H A D | fsm.c | diff 32658 Tue Jan 20 20:47:48 MST 1998 brian Allow an optional delay when specifying "set openmode active". The delay defaults to 1 sec (as it always has) unless we've done a ~p in interactive mode or we've actually detected a HDLC frame. This is now cleanly implemented (via async timers) so that it is possible for LCP to come up despite the delay if an LCP REQ is received. This will hopefully solve situations with slow servers or slirp scenarios (where ECHO is left on the port for a second or so before the peer enters packet mode). Also, ~p in interactive mode no longer changes the value of the default openmode delay and -dedicated mode enters packet mode in the right state according to the value of openmode. |
H A D | ccp.c | diff 32658 Tue Jan 20 20:47:48 MST 1998 brian Allow an optional delay when specifying "set openmode active". The delay defaults to 1 sec (as it always has) unless we've done a ~p in interactive mode or we've actually detected a HDLC frame. This is now cleanly implemented (via async timers) so that it is possible for LCP to come up despite the delay if an LCP REQ is received. This will hopefully solve situations with slow servers or slirp scenarios (where ECHO is left on the port for a second or so before the peer enters packet mode). Also, ~p in interactive mode no longer changes the value of the default openmode delay and -dedicated mode enters packet mode in the right state according to the value of openmode. |
H A D | lcp.c | diff 32658 Tue Jan 20 20:47:48 MST 1998 brian Allow an optional delay when specifying "set openmode active". The delay defaults to 1 sec (as it always has) unless we've done a ~p in interactive mode or we've actually detected a HDLC frame. This is now cleanly implemented (via async timers) so that it is possible for LCP to come up despite the delay if an LCP REQ is received. This will hopefully solve situations with slow servers or slirp scenarios (where ECHO is left on the port for a second or so before the peer enters packet mode). Also, ~p in interactive mode no longer changes the value of the default openmode delay and -dedicated mode enters packet mode in the right state according to the value of openmode. |
H A D | ipcp.c | diff 32658 Tue Jan 20 20:47:48 MST 1998 brian Allow an optional delay when specifying "set openmode active". The delay defaults to 1 sec (as it always has) unless we've done a ~p in interactive mode or we've actually detected a HDLC frame. This is now cleanly implemented (via async timers) so that it is possible for LCP to come up despite the delay if an LCP REQ is received. This will hopefully solve situations with slow servers or slirp scenarios (where ECHO is left on the port for a second or so before the peer enters packet mode). Also, ~p in interactive mode no longer changes the value of the default openmode delay and -dedicated mode enters packet mode in the right state according to the value of openmode. |
H A D | main.c | diff 32658 Tue Jan 20 20:47:48 MST 1998 brian Allow an optional delay when specifying "set openmode active". The delay defaults to 1 sec (as it always has) unless we've done a ~p in interactive mode or we've actually detected a HDLC frame. This is now cleanly implemented (via async timers) so that it is possible for LCP to come up despite the delay if an LCP REQ is received. This will hopefully solve situations with slow servers or slirp scenarios (where ECHO is left on the port for a second or so before the peer enters packet mode). Also, ~p in interactive mode no longer changes the value of the default openmode delay and -dedicated mode enters packet mode in the right state according to the value of openmode. |
H A D | command.c | diff 32658 Tue Jan 20 20:47:48 MST 1998 brian Allow an optional delay when specifying "set openmode active". The delay defaults to 1 sec (as it always has) unless we've done a ~p in interactive mode or we've actually detected a HDLC frame. This is now cleanly implemented (via async timers) so that it is possible for LCP to come up despite the delay if an LCP REQ is received. This will hopefully solve situations with slow servers or slirp scenarios (where ECHO is left on the port for a second or so before the peer enters packet mode). Also, ~p in interactive mode no longer changes the value of the default openmode delay and -dedicated mode enters packet mode in the right state according to the value of openmode. |
H A D | ppp.8 | diff 32658 Tue Jan 20 20:47:48 MST 1998 brian Allow an optional delay when specifying "set openmode active". The delay defaults to 1 sec (as it always has) unless we've done a ~p in interactive mode or we've actually detected a HDLC frame. This is now cleanly implemented (via async timers) so that it is possible for LCP to come up despite the delay if an LCP REQ is received. This will hopefully solve situations with slow servers or slirp scenarios (where ECHO is left on the port for a second or so before the peer enters packet mode). Also, ~p in interactive mode no longer changes the value of the default openmode delay and -dedicated mode enters packet mode in the right state according to the value of openmode. |
Completed in 298 milliseconds