m_certValidator is defined bellow:
private Connection.CertificateChainValidator m_certValidator;
and Connection.CertificateChainValidator is a delegate defined bellow:
private delegate bool CertificateChainValidator(byte* cert, uint
certLen,
uint flags);
cert = pointer to byte array containing the certificate
certlen = length of byte array
flags = certificate flags
I am using CF.NET 1.0 SP3.
Stéphane
:
You don't know what m_certValidator is though. Might be a 'pointer'
to a
native routine in the .NET CF run-time. What version of .NET CF are
you
using?
Paul T.
Humm... That's odd. If you take a look at
System.Net.Connection.setValidateCertOption() you will see that in
the
CF.NET System.dll they are doing that exactly.
private Connection.CertificateChainValidator m_certValidator;
private void setValidateCertOption()
{
int num1;
int num2 = SSLSOCK.ioctlsocket(this.m_socket.handle, (uint)
0x90730008, this.m_certValidator, 4, (byte[]) null, 0, out num1);
if (num2 != 0)
{
throw new SocketException(num2);
}
}
internal class SSLSOCK
{
// Methods
public SSLSOCK();
[DllImport("mscoree", EntryPoint="@309")]
public static extern int ioctlsocket(int s, uint controlCode,
byte[]
inBuffer, int inBufferLen, byte[] outBuffer, int outBufferLen, out
int
outBytesWritten);
[DllImport("mscoree", EntryPoint="@309")]
public static extern int ioctlsocket(int s, uint controlCode,
object
inBuffer, int inBufferLen, byte[] outBuffer, int outBufferLen, out
int
outBytesWritten);
}
I was hopping to be able to re-use this strategy.
Stéphane
:
You aren't going to be able to pass a callback function from
managed
code,
anyway, are you? It might be significantly easier to create a
native
DLL
with an exported function like: EstablishSSLConnection( SOCKET s ),
after
setting up the socket in secure mode, etc. in managed code. The
native
function would set the callback to another function in the DLL and
then
return to managed code to allow the connection itself to be
attempted.
You'd probably need a CleanupSSLConnection( SOCKET s ) call in the
DLL,
also, to undo the callback setting.
Paul T.
I'm trying to enable SSL on my socket by following this
article ->
http://msdn.microsoft.com/library/d...50conImplementingaSecureSocket.asp?frame=true
The only way to achieve this is to call ->
public static extern int ioctlsocket(int s, uint controlCode,
object
inBuffer, int inBufferLen, byte[] outBuffer, int outBufferLen,
out
int
outBytesWritten);
I need to pass a Delegate for the certificate verification, and
the
current
Socket.IOControl implementation does not allow that to occur.
The CF.NET has a internal implementation of what I'm trying to
access,
so
I
know it "can" be done. It's located in
System.Net.Sockets.SSLSOCK.
Stéphane
:
What exactly are you trying to accomplish? I don't think that
you
should
have to call ioctlsocket() directly; it should already be
wrapped
in
the
..NET CF socket class. That is, what's wrong with the existing
implementation that you can't use it?
Paul T.
Peter,
I'm attempting to call ioctlsocket based from WINSOCK.H.
WINSOCK.H has ioctlsocket defined as:
int WINSOCKAPI ioctlsocket (SOCKET s, long cmd, u_long
*argp);
The native System.Net.Sockets.Socket.IOControl in CF.NET has:
public int IOControl(int ioControlCode, byte[] optionInValue,
byte[]
optionOutValue);
DllImport ->
public static extern int ioctlsocket(int s, uint controlCode,
byte[]
inBuffer, int inBufferLen, byte[] outBuffer, int outBufferLen,
out
int
outBytesWritten);
but I need to pass different parameters to the ioctlsocket.
DllImport ->
public static extern int ioctlsocket(int s, uint controlCode,
object
inBuffer, int inBufferLen, byte[] outBuffer, int outBufferLen,
out
int
outBytesWritten);
Any thoughts, on another way?
Stéphane
:
Which particular winsock functions do you need? I've wrapped
a
few
of
them
in the process of building the Bluetooth library
(
www.peterfoot.net/Bluetoothv14.aspx)
I believe that Sockets are the exception to the rule that
Alex
described -
System.Net.Sockets wraps the Winsock APIs and the Handle
exposed
is
actually
a valid socket handle. What I think may be wrong in your case
is
your
P/Invoke definition - under XP you would use ws2_32.dll,
under
CE
you
should
use "ws2.dll". As I said you may want to refer to some of the
P/Invokes
in
the Bluetooth library code, or post back with more details
and
I'll
try
and
help.
Peter
--
Peter Foot
Windows Embedded MVP
http://www.inthehand.com |
http://www.peterfoot.net |
http://www.opennetcf.org
message
I need to call additional winsock functions that are not
available
through
the .NET framework and planned to do so through P/Invoke
calls.
In theory using the System.Net.Sockets.Socket.Handle I
should
be
able
to
then call external winsock functions. Unfortunately this
does
not
seem
to
work from CF.NET. I can create a new socket using the
winsock
socket
function, but I can't access an existing CF.NET socket with
the
winsock
call
using the Socket.Handle property.
I am using the following DllImport statement to access the
winsock
calls.
[DllImport("winsock.dll", SetLastError=true)]
I can perform the exact same thing in C# in a Windows
Application
accessing
the ws2_32.dll
I can post more information if required. I was just
wondering
if
there
is
a
documented issue with calling native winsock P/Invoke
functions
from
CF.NET
before I kept banging my head against the wall.
