    TODO                                                                                STATE
    ----------------------------------------------------------------------------------	---------
a)  Employ CT class of key exchange control codes. CT_PING should be issued when        [27/11/2000]
    decryption fails from a peer. If timeout occurs for the CT_PONG then a static key
    key exchange should be attempted with each static key type. CT_PING's should also
    be sent at various intervals if session starts but no packets have been received
    yet

b)  IDEA must be implemented. Encryption "modules" should obviously be employed here    [ON HOLD]
    in order to allow flexible encryption type support. Key length should also be
    parameterized but maybe this is too ambitious...

c)  Rewrite CIPE Daemon in C++                                                          [08/11/2000]

d)  Uninstalling/unloading causes Windows 2000 to reset                                 [13/11/2000]

e)  Rewrite device driver to support "TAP" devices                                      [08/11/2000]

f)  Windows 2000 inf must run cipsrvr to install the service

g)  If adapter is disabled in Windows 2000 with the service running, then shutting      [TESTING]
    the service down (cipsrvr stop) will cause Windows 2000 to crash. Probable cause
    is the closing of a non existent tap device.

h)  Port to Windows 95/98/Me/Xp ?                                                       [PONDERING]

i)  Daemon may be sending double NK requests on threshold instead of one. Peer has to   [OBSERVED]
    generate a new key twice.

j)  Driver may blue screen with MULTIPLE_COMPLETE_IRP_REQUESTS. This implied that       [23/11/2000]
    further serialization of IRP completions was in order.

k)  Add hostname capability to IP address fields (requested by werner.hofer@igs.at)     [01/12/2000]

l)  Driver may bluescreen if CIPE-Win32 is managing multiple adapters and the service   [11/12/2000]
    receives packets immediately on connecting (queued packets). This may be related
    to the way spinlocks are handled in the tap delivery mechanism. This situation is
    currently alleviated by the daemon (I'm a Unix guy !) ignoring synchronously
    obtained packets

m)  Driver may blue screen with IRQ_NOT_LESS_OR_EQUAL. This may be due to a spinlock    [29/03/2001]
    held in a bad place. Some things have been "moved around" and this hasn't
    been seen again...yet

n)  cipsrvr.exe would crash with Invalid Exception for some inexplicable reason. This   [20/12/2000]
    has been alleviated with a 1ms sleep before queuing adapter tap read requests.

    CORRECTION: This, along with m) were determined to have been caused by BUFFERED_IO  [29/3/2001]
    buffer passing. This was corrected by using DIRECT_IO (page locked) parameter
    passing between usermode and kernelmode

o)  cipdrvr.sys would randomly crash with IRQ_NOT_LESS_OR_EQUAL. This was due to a bad  [29/3/2001]
    pointer passed to DbgPrint every now and then. Extraneous DbgPrints were removed
    from the driver.

p)  cipdrvr.sys would crash on some machines with KMODE_EXCEPTION_NOT_HANDLED in        [TESTING]
    AdapterTransmit (thanks to Erik Wallin (erikw@sec.se). This has been addressed by
    changing the memory allocation flags to not require NDIS_MEMORY_NONCACHED and
    NDIS_MEMORY_CONTIGUOUS. Thanks to Jan Olderdissen <jolderdissen@ixiacom.com> for
    pointing this out.

q)  cipdrvr.sys would crash with bad addresses in linked list handling. A potential     [20/4/2001]
    situation for an invalid pointer generation has been addressed and the entire
    linked list mechanism is now protected with exception handling. Yet even more
    thanks to Eric Wallin <erikw@sec.se> for probing my programmer blind spots.

r)  PkCIPE implementation                                                               [PONDERING]

s)  Under some circumstances on Windows 2000, stopping the service could result in      [TESTING]
    a crash. This appears to be a result of the driver queueing packets even though
    no process had opened a descriptor (OK, Handle) on the TAP device. Now the driver
    ignores packets when there is no open handle.

t)  Uninstalling the adapter in Windows 2000 may fail and leave the device entry in an  [INVESTIGATING]
    unremoveable state, permanently. Jan Olderdissen <jolderdissen@ixiacom.com>
    stressed that, on his system, the presence of the flags NDIS_MEMORY_NONCACHED and
    NDIS_MEMORY_CONTIGUOUS, used to allocate memory for the Adapter structure in
    cipdrvr.c, would cause a crash on driver unload. In earlier times, the absence of
    these flags would cause crashes on driver load. As of this release, the absence of
    the flags has not caused either of my systems to crash so here goes... (Thanks, Jan).
    On my systems, disabling or uninstalling a cipe device still causes lockups.

u)  A socket read request in CipeSocketIO.cpp might return WSAECONNRESET if a prior     [TESTING]
    send failed due to ICMP UNREACHABLE. This would cause read failures from the
    tunnel UDP socket. Thanks to Jan Olderdissen <jolderdissen@ixiacom.com>. This
    appears to be a result of Microsoft bug Q283823. The status as currently treated
    as transient and is ignored with a reattempted RecvFrom occurring immediately.
    Thanks to all the guys on cipe-l@inka.de for helping track this one down !

v)  During device removal, The symbolic link for the TAP device was not removed. This   [27/3/2002]
    would prevent suspend/hibernate wakeups from succeeding as the driver would attempt
    to recreate the preexisting symbolic link and fail.

w)  CIPE-Win32 mostly works on WinXP. There are some minor build differences needing    [TESTING]
    resolution. Thanks to Scott Herscher <scott@swampwolf.com> for finding more stupid
    bugs of mine and getting it working on XP.
    ----------------------------------------------------------------------------------	---------

