diff options
| author |   brian <brian@openbsd.org> | 1999-03-01 02:52:19 +0000 |
|---|---|---|
| committer | brian <brian@openbsd.org> | 1999-03-01 02:52:19 +0000 |
| commit | 2f5dbb0ecdd26331222d01e91cb3e7b6277f1b2b (patch) | |
| tree | 91832264c8ec3b7886b30896ddc030c5ea2b28b7 /sys/kern/init_main.c | |
| parent | Not present in 1.3.4 (diff) | |
| download | wireguard-openbsd-2f5dbb0ecdd26331222d01e91cb3e7b6277f1b2b.tar.xz wireguard-openbsd-2f5dbb0ecdd26331222d01e91cb3e7b6277f1b2b.zip | |
Comment why we do a TLF when we get a ``Down'' event in state
``closing''.
Pointed out by: archie
Don't do a TLF when we get a ``Catastrphic Protocol Reject'' event
in state ``closed'' or ``stopped''.
Pointed out but not suggested by: archie
This makes no difference in the current implementation as
LcpLayerFinish() does nothing but log the event, but I disagree
in principle because it unbalances the TLF/TLS calls which
(IMHO) doesn't fit with the intentions of the RFC.
Maybe the RFC author had a reason for this. It can only happen
in two circumstances:
- if LCP has already been negotiated then stopped or closed and we
receive a protocol reject, then we must already have done a TLF.
Why do one again and stay in the same state ?
- if LCP hasn't yet been started and we receive an unsolicted
protocol reject, why should we TLF when we haven't done a TLS ?
Diffstat (limited to 'sys/kern/init_main.c')
0 files changed, 0 insertions, 0 deletions