<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: Dmitry Basko <dbasko,AT,rainbow,DOT,by>
Subject: Re: CIPE-Win32, WIN2K, VC7 (sources, BSOD,encryption)
From: "Damion K. Wilson" <dwilson,AT,ibl,DOT,bm>
Date: Thu, 5 Jun 2003 10:25:44 -0300
Cc: cipe-l,AT,inka,DOT,de
In-reply-to: <1826278375.20030605111551@rainbow.by>
References: <20030604152719.53878.qmail@web13902.mail.yahoo.com> <200306041702.26703.dwilson@ibl.bm> <1826278375.20030605111551@rainbow.by>
Reply-to: dwilson,AT,ibl,DOT,bm

2) There is a registry fix for that. Check the mailing list archives. It'll 
be 
included in the next release.

3) Good God ! You're right ! And VC compiles it, too.

4) There's something more going on here, I suspect. I've had multiple 
CIPE-Win32 instances chatting away merrily without this problem.

5) Hmm. I can try that. I default to INVALID_OID for my unhandled ID's which 
should have been enough. I hadn't seen anything about power management for 
legacy drivers in the DDK help, but I'll look harder this time.

DKW

On Thursday 05 June 2003 05:15 am, Dmitry Basko wrote:
> Hello,
> 1) I'd like to add two words about it also. I started to work with the
> project only several days ago (WIN2K, VC7) and noticed that there is
> a problem with includes. In my case, I just put winsock2.h
> before windows.h, because winsock2.h has following definition inside:
> /*
>  * Pull in WINDOWS.H if necessary
>  */
> #ifndef _INC_WINDOWS
> #include <windows.h>
> #endif /* _INC_WINDOWS */
> Alternative way could be not include windows.h after winsock2.h at
> all.
> Way with _WINSOCKAPI_ will also work, because it excludes winsock.h from
> the list of includes, existed in windows.h
> MSDN samples includes different scenarios of including winsock2.h
>
> 2) I strongly believe that problem with automatic service start
> depends on the time and place of the service (driver) in the "start tree"
> of other services (drivers) and could be mend with putting correct info
> into the registry . If this is not done yet, I will check it later.
>
> 3) file CIPESocketIO.cpp, function CipeSocketIO::HandlePeerEvent (...)
> looks a little bit strange (at least for me). I mean
> switch ()
> {
> case NK_DATA:
> ...
> case NK_ACK:
> CT_DUMMY:
> ...
> CT_KILL:
> }
> It looks like word "case" was missing, because  NK_ACK and  CT_DUMMY
> are members of the same enum.
>
> 4) Blowfish encryption. Two WIN2K can not agree about the dynamic key. I
> should investigate it deeper, but what I see now is:
>
> 1 [PC] (receiver):
> ----------- Before decryption   <CipeSocketIO::CompleteAsyncReceive()>
> 00000   16 7a 06 ea 72 f4 88 99 64 25 03 d5 50 b7 8e 1e    .z..r...d%..P...
> 00010   3d 0f 05 f6 b0 6d a1 75 89 c0 01 e8 37 7f 1f 5c    =....m.u....7..\
> 00020   41 fb 41 2f 07 74 7c dd 00 00 00 00 00 00 00 00    A.A/.t|.........
>
> Decryption CRC. CRC=[14ea0ab9] ::
> [14ea0ab9]<CipeBlowfishEncryptor::Decrypt>
>
> ----------- after decryption    <CipeSocketIO::CompleteAsyncReceive()>
> 00000   03 54 da c9 c3 af a1 e2 a7 cc a1 74    .....T.........t
> 00010   96 ef d3 9f 53 e2 89 f3 42 3c ca 52 b9 0a ea 14    ....S...B<.R....
> 00020   fc 6f d2 56 00 00 00 00 00 00 00 00 00 00 00 00    .o.V............
>
> received and decrypted key and CRC (last DWORD)
> <CipeSocketIO::HandlePeerEvent> :: case NK_IND:
> 00000   03 54 da c9 c3 af a1 e2 a7 cc a1 74 96 ef d3 9f    .T.........t....
> 00010   53 e2 89 f3 00 00 00 00 00 00 00 00 00 00 00 00    S...............
>
> [PC1] NK_IND: BAD CRC of key for decryption. NK_ACK will not be send.
>  attached CRC=f389e253, calculated CRC=3d57e253
>
> [PC2] (sender):
> Original key and CRC (last DWORD)
> ------------------ Before encryption <CipeSocketIO::Send>
> 00000   03 54 da c9 c3 af a1 e2 a7 cc a1 74 96 ef d3 9f    .T.........t....
> 00010   53 e2 57 3d 00 00 00 00 00 00 00 00 00 00 00 00    S.W=............
>
>  ----------------- After encryption  <CipeSocketIO::Send>
> 00000   16 7a 06 ea 72 f4 88 99 64 25 03 d5 50 b7 8e 1e    .z..r...d%..P...
> 00010   3d 0f 05 f6 b0 6d a1 75 89 c0 01 e8 37 7f 1f 5c    =....m.u....7..\
> 00020   41 fb 41 2f 07 74 7c dd 00 00 00 00 00 00 00 00    A.A/.t|.........
>
>
>
> Conclusion: packet was received correctly (at least it was not
> modified during transmission),in this case I am
> interested in .nk.ind.keydata + CRC (size of (DWORD)) part,
> but last two bytes of CRC were changed,( attached CRC=f389e253,
> calculated CRC=3d57e253) therefore this key was rejected by PC1
> (receiver). I suspect that there is something wrong with "encrypt
> - decrypt" procedure.
>
> 5). BSOD during changing state of WIN2K. My modest experience in
> development of kernel drivers tells me that there is a big probability
> that the driver has track System power state and behaves itself
> accordingly (change its internal state and report about it properly to the
> Power Manager) or reports that it is not  power management-aware
> driver.(for
> example return NDIS_STATUS_UNSUPPORTED to query of
> OID_PNP_CAPABILITIES). Quick look at the AdapterQuery function (I
> recompiled driver with VC7 but did not worked with it yet, just added
> several diagnostic messages) shows that in case of receiving
> OID_PNP_CAPABILITIES driver returns NDIS_STATUS_INVALID_OID..
> Additional info can be found in DDK (Power Management for Legacy Miniport
> Drivers) If I have more time (and if it is really necessary) I can try to
> correct this problem later.
>
> I work with CIPE-Win32-2.0-pre15, everything, written above may not be
> applicable for other versions of CIPE.
>
> Thanks for your patience.


<< | Thread Index | >> ]    [ << | Date Index | >> ]