TDI_DISCONNECT_RELEASE problem

Greetings All!!
I have TDI client which just dropped TCP connection when needed
(TDI_DISCONNECT with TDI_DISCONNECT_ABORT flag). But now we want to change
it to graceful disconnect (FIN->,ACK<-,FIN<-,ACK->) I hoped that all I had
to do is to change TDI_DISCONNECT_ABORT -> TDI_DISCONNECT_RELEASE, but it
appears that after such disconnect TransportAddressFile goes to some strange
state… For example subsequent calls to TDI_CONNECT return 0xC000020A
(STATUS_ADDRESS_ALREADY_EXIST) ???
I think maybe I do disconnect wrong?
I prepare disconnect irp like following:

//…

PIRP pirpDisconnect = TdiBuildInternalDeviceControlIrp(
TDI_DISCONNECT,
m_pConnectionFile->DeviceObject,
m_pConnectionFile,
m_CurrentIrp.evntReady, &m_CurrentIrp.IoStatus);

if (!pirpDisconnect)
{
m_status = STATUS_INSUFFICIENT_RESOURCES;
return FALSE;
}

// here I tried to pass either nullified TDI_CONNECTION_INFORMATION or
// fill RemoteAddressLength with remote node’ addr like this:
::RtlZeroMemory(&m_CurrentIrp.TdiConnectionInfo,
sizeof(TDI_CONNECTION_INFORMATION));
m_CurrentIrp.TdiConnectionInfo.RemoteAddressLength = sizeof(TA_IP_ADDRESS);
m_CurrentIrp.TdiConnectionInfo.RemoteAddress = &m_CurrentIrp.taAddress;

LARGE_INTEGER qTimeout;
qTimeout.QuadPart = Int32x32To64(dwTimeout, -10000);

DWORD dwFlags = TDI_DISCONNECT_RELEASE;

TdiBuildDisconnect(
pirpDisconnect, m_pConnectionFile->DeviceObject,
m_pConnectionFile, DisconnectCompletionRoutine, this,
&qTimeout,
&dwFlags, // DDK states it should PULONG, I tried both ULONG and
PULONG - strange, but BOTH work :slight_smile:
&m_CurrentIrp.TdiConnectionInfo, NULL);

m_status = IoCallDriver(m_pConnectionFile->DeviceObject, pirpDisconnect);

if (m_status == STATUS_PENDING && bBlock)
WaitForReady();

//…

Or maybe I should do something special in my TDI_EVENT_DISCONNECT? Now I
just return STATUS_SUCCESS…

Maybe anyone knows whats the problem, or has a clue?..
Please help…
Thanks in advance.

Vladimir


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

You must not close the TCP connection file object till both a) your TDI_DISCONNECT_RELEASE is sent and b)
TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) is called.

TDI_DISCONNECT_RELEASE sends FIN and moves the TCB
ESTABLISHED -> FINWAIT_1.
FIN/ACK arrival moves to FINWAIT_2, the TDI client is not notified on this.

Then your TDI code will need to wait till TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) will be called. This means incoming FIN
arrival, and the TCB will be in TIME_WAIT state. It is fine to close the TCP connection file object in this state.

Or otherwise, if TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) is called first, it moves to CLOSE_WAIT. Then your
TDI_DISCONNECT_RELEASE sends FIN and moves the LAST_ACK, it is OK to close the TCP connection file object in this state. FIN/ACK
arrival will kill the TCB, the TDI client will not be notified on this.

Attempting to close the TCP connection file object while not it LAST_ACK or TIME_WAIT will send TCP RST. So, you must not close it
too early. Lingering close implementation is up to TDI client, TCP will not do this.

Max

----- Original Message -----
From: “Vovkos”
To: “NT Developers Interest List”
Sent: Friday, February 01, 2002 3:18 AM
Subject: [ntdev] TDI_DISCONNECT_RELEASE problem

> Greetings All!!
> I have TDI client which just dropped TCP connection when needed
> (TDI_DISCONNECT with TDI_DISCONNECT_ABORT flag). But now we want to change
> it to graceful disconnect (FIN->,ACK<-,FIN<-,ACK->) I hoped that all I had
> to do is to change TDI_DISCONNECT_ABORT -> TDI_DISCONNECT_RELEASE, but it
> appears that after such disconnect TransportAddressFile goes to some strange
> state… For example subsequent calls to TDI_CONNECT return 0xC000020A
> (STATUS_ADDRESS_ALREADY_EXIST) ???
> I think maybe I do disconnect wrong?
> I prepare disconnect irp like following:
>
> //…
>
> PIRP pirpDisconnect = TdiBuildInternalDeviceControlIrp(
> TDI_DISCONNECT,
> m_pConnectionFile->DeviceObject,
> m_pConnectionFile,
> m_CurrentIrp.evntReady, &m_CurrentIrp.IoStatus);
>
> if (!pirpDisconnect)
> {
> m_status = STATUS_INSUFFICIENT_RESOURCES;
> return FALSE;
> }
>
> // here I tried to pass either nullified TDI_CONNECTION_INFORMATION or
> // fill RemoteAddressLength with remote node’ addr like this:
> ::RtlZeroMemory(&m_CurrentIrp.TdiConnectionInfo,
> sizeof(TDI_CONNECTION_INFORMATION));
> m_CurrentIrp.TdiConnectionInfo.RemoteAddressLength = sizeof(TA_IP_ADDRESS);
> m_CurrentIrp.TdiConnectionInfo.RemoteAddress = &m_CurrentIrp.taAddress;
>
> LARGE_INTEGER qTimeout;
> qTimeout.QuadPart = Int32x32To64(dwTimeout, -10000);
>
> DWORD dwFlags = TDI_DISCONNECT_RELEASE;
>
> TdiBuildDisconnect(
> pirpDisconnect, m_pConnectionFile->DeviceObject,
> m_pConnectionFile, DisconnectCompletionRoutine, this,
> &qTimeout,
> &dwFlags, // DDK states it should PULONG, I tried both ULONG and
> PULONG - strange, but BOTH work :slight_smile:
> &m_CurrentIrp.TdiConnectionInfo, NULL);
>
> m_status = IoCallDriver(m_pConnectionFile->DeviceObject, pirpDisconnect);
>
> if (m_status == STATUS_PENDING && bBlock)
> WaitForReady();
>
> //…
>
> Or maybe I should do something special in my TDI_EVENT_DISCONNECT? Now I
> just return STATUS_SUCCESS…
>
> Maybe anyone knows whats the problem, or has a clue?..
> Please help…
> Thanks in advance.
>
> Vladimir
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Thanks for your reply Max!!

I figured out: that’s not my TDI client fault - I have the same behavior in
usermode. That’s what my usermode test app do:

  1. open tcp socket and BIND it to some port
  2. CONNECT to remote node
  3. do GRACEFUL DISCONNECT with either shutdown(SD_SEND) or closesocket (with
    either SO_DONTLINGER (1) or SO_LINGER (l_onoff = 1, l_linger > 0))

I run this app once, and:
if I run this app during next several minutes I got WSAEADDRINUSE error on
connect - just the same as in my TDI client.
(By the way, bind operation completes successfully)

It appears that after graceful disconnect transport holds address in a limbo
state for some time…
Question - is this by design? If there a way to overcome this behavior?

Thanks in advance.
Vladimir

P.S.
Of course it is not a problem if I had unbinded socket for connection, but
in my case there is no client and server, and both nodes can initiate
connection…

----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Friday, February 01, 2002 10:03 AM
Subject: [ntdev] Re: TDI_DISCONNECT_RELEASE problem

> You must not close the TCP connection file object till both a) your
TDI_DISCONNECT_RELEASE is sent and b)
> TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) is called.
>
> TDI_DISCONNECT_RELEASE sends FIN and moves the TCB
> ESTABLISHED -> FINWAIT_1.
> FIN/ACK arrival moves to FINWAIT_2, the TDI client is not notified on
this.
>
> Then your TDI code will need to wait till
TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) will be called. This means
incoming FIN
> arrival, and the TCB will be in TIME_WAIT state. It is fine to close the
TCP connection file object in this state.
>
> Or otherwise, if TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) is
called first, it moves to CLOSE_WAIT. Then your
> TDI_DISCONNECT_RELEASE sends FIN and moves the LAST_ACK, it is OK to close
the TCP connection file object in this state. FIN/ACK
> arrival will kill the TCB, the TDI client will not be notified on this.
>
> Attempting to close the TCP connection file object while not it LAST_ACK
or TIME_WAIT will send TCP RST. So, you must not close it
> too early. Lingering close implementation is up to TDI client, TCP will
not do this.
>
> Max
>
> ----- Original Message -----
> From: “Vovkos”
> To: “NT Developers Interest List”
> Sent: Friday, February 01, 2002 3:18 AM
> Subject: [ntdev] TDI_DISCONNECT_RELEASE problem
>
>
> > Greetings All!!
> > I have TDI client which just dropped TCP connection when needed
> > (TDI_DISCONNECT with TDI_DISCONNECT_ABORT flag). But now we want to
change
> > it to graceful disconnect (FIN->,ACK<-,FIN<-,ACK->) I hoped that all I
had
> > to do is to change TDI_DISCONNECT_ABORT -> TDI_DISCONNECT_RELEASE, but
it
> > appears that after such disconnect TransportAddressFile goes to some
strange
> > state… For example subsequent calls to TDI_CONNECT return 0xC000020A
> > (STATUS_ADDRESS_ALREADY_EXIST) ???
> > I think maybe I do disconnect wrong?
> > I prepare disconnect irp like following:
> >
> > //…
> >
> > PIRP pirpDisconnect = TdiBuildInternalDeviceControlIrp(
> > TDI_DISCONNECT,
> > m_pConnectionFile->DeviceObject,
> > m_pConnectionFile,
> > m_CurrentIrp.evntReady, &m_CurrentIrp.IoStatus);
> >
> > if (!pirpDisconnect)
> > {
> > m_status = STATUS_INSUFFICIENT_RESOURCES;
> > return FALSE;
> > }
> >
> > // here I tried to pass either nullified TDI_CONNECTION_INFORMATION or
> > // fill RemoteAddressLength with remote node’ addr like this:
> > ::RtlZeroMemory(&m_CurrentIrp.TdiConnectionInfo,
> > sizeof(TDI_CONNECTION_INFORMATION));
> > m_CurrentIrp.TdiConnectionInfo.RemoteAddressLength =
sizeof(TA_IP_ADDRESS);
> > m_CurrentIrp.TdiConnectionInfo.RemoteAddress = &m_CurrentIrp.taAddress;
> >
> > LARGE_INTEGER qTimeout;
> > qTimeout.QuadPart = Int32x32To64(dwTimeout, -10000);
> >
> > DWORD dwFlags = TDI_DISCONNECT_RELEASE;
> >
> > TdiBuildDisconnect(
> > pirpDisconnect, m_pConnectionFile->DeviceObject,
> > m_pConnectionFile, DisconnectCompletionRoutine, this,
> > &qTimeout,
> > &dwFlags, // DDK states it should PULONG, I tried both ULONG and
> > PULONG - strange, but BOTH work :slight_smile:
> > &m_CurrentIrp.TdiConnectionInfo, NULL);
> >
> > m_status = IoCallDriver(m_pConnectionFile->DeviceObject,
pirpDisconnect);
> >
> > if (m_status == STATUS_PENDING && bBlock)
> > WaitForReady();
> >
> > //…
> >
> > Or maybe I should do something special in my TDI_EVENT_DISCONNECT? Now I
> > just return STATUS_SUCCESS…
> >
> > Maybe anyone knows whats the problem, or has a clue?..
> > Please help…
> > Thanks in advance.
> >
> > Vladimir
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@narod.ru
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

> It appears that after graceful disconnect transport holds address in a limbo

state for some time…
Question - is this by design? If there a way to overcome this behavior?

Sorry. Nobody guarantees that you will be able to re-connect the disconnected socket.
This is documented.

Max


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

This is by design - when a TCP connection closes, it enters the TIME_WAIT state for a period of time equal to twice the maximum segment lifetime. You can see the state of TCP connections on your machine by typing “netstat -a -n -p tcp” at a command prompt.

Regards,

Ed lau

MidCore Software, Inc.
900 Straits Tpke
Middlebury, CT 06762

www.midcore.com
----- Original Message -----
From: Vovkos
To: NT Developers Interest List
Sent: Friday, February 01, 2002 10:57 AM
Subject: [ntdev] Re: TDI_DISCONNECT_RELEASE problem

Thanks for your reply Max!!

I figured out: that’s not my TDI client fault - I have the same behavior in
usermode. That’s what my usermode test app do:

  1. open tcp socket and BIND it to some port
  2. CONNECT to remote node
  3. do GRACEFUL DISCONNECT with either shutdown(SD_SEND) or closesocket (with
    either SO_DONTLINGER (1) or SO_LINGER (l_onoff = 1, l_linger > 0))

I run this app once, and:
if I run this app during next several minutes I got WSAEADDRINUSE error on
connect - just the same as in my TDI client.
(By the way, bind operation completes successfully)

It appears that after graceful disconnect transport holds address in a limbo
state for some time…
Question - is this by design? If there a way to overcome this behavior?

Thanks in advance.
Vladimir

P.S.
Of course it is not a problem if I had unbinded socket for connection, but
in my case there is no client and server, and both nodes can initiate
connection…

----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Friday, February 01, 2002 10:03 AM
Subject: [ntdev] Re: TDI_DISCONNECT_RELEASE problem

> You must not close the TCP connection file object till both a) your
TDI_DISCONNECT_RELEASE is sent and b)
> TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) is called.
>
> TDI_DISCONNECT_RELEASE sends FIN and moves the TCB
> ESTABLISHED -> FINWAIT_1.
> FIN/ACK arrival moves to FINWAIT_2, the TDI client is not notified on
this.
>
> Then your TDI code will need to wait till
TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) will be called. This means
incoming FIN
> arrival, and the TCB will be in TIME_WAIT state. It is fine to close the
TCP connection file object in this state.
>
> Or otherwise, if TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) is
called first, it moves to CLOSE_WAIT. Then your
> TDI_DISCONNECT_RELEASE sends FIN and moves the LAST_ACK, it is OK to close
the TCP connection file object in this state. FIN/ACK
> arrival will kill the TCB, the TDI client will not be notified on this.
>
> Attempting to close the TCP connection file object while not it LAST_ACK
or TIME_WAIT will send TCP RST. So, you must not close it
> too early. Lingering close implementation is up to TDI client, TCP will
not do this.
>
> Max
>
> ----- Original Message -----
> From: “Vovkos”
> To: “NT Developers Interest List”
> Sent: Friday, February 01, 2002 3:18 AM
> Subject: [ntdev] TDI_DISCONNECT_RELEASE problem
>
>
> > Greetings All!!
> > I have TDI client which just dropped TCP connection when needed
> > (TDI_DISCONNECT with TDI_DISCONNECT_ABORT flag). But now we want to
change
> > it to graceful disconnect (FIN->,ACK<-,FIN<-,ACK->) I hoped that all I
had
> > to do is to change TDI_DISCONNECT_ABORT -> TDI_DISCONNECT_RELEASE, but
it
> > appears that after such disconnect TransportAddressFile goes to some
strange
> > state… For example subsequent calls to TDI_CONNECT return 0xC000020A
> > (STATUS_ADDRESS_ALREADY_EXIST) ???
> > I think maybe I do disconnect wrong?
> > I prepare disconnect irp like following:
> >
> > //…
> >
> > PIRP pirpDisconnect = TdiBuildInternalDeviceControlIrp(
> > TDI_DISCONNECT,
> > m_pConnectionFile->DeviceObject,
> > m_pConnectionFile,
> > m_CurrentIrp.evntReady, &m_CurrentIrp.IoStatus);
> >
> > if (!pirpDisconnect)
> > {
> > m_status = STATUS_INSUFFICIENT_RESOURCES;
> > return FALSE;
> > }
> >
> > // here I tried to pass either nullified TDI_CONNECTION_INFORMATION or
> > // fill RemoteAddressLength with remote node’ addr like this:
> > ::RtlZeroMemory(&m_CurrentIrp.TdiConnectionInfo,
> > sizeof(TDI_CONNECTION_INFORMATION));
> > m_CurrentIrp.TdiConnectionInfo.RemoteAddressLength =
sizeof(TA_IP_ADDRESS);
> > m_CurrentIrp.TdiConnectionInfo.RemoteAddress = &m_CurrentIrp.taAddress;
> >
> > LARGE_INTEGER qTimeout;
> > qTimeout.QuadPart = Int32x32To64(dwTimeout, -10000);
> >
> > DWORD dwFlags = TDI_DISCONNECT_RELEASE;
> >
> > TdiBuildDisconnect(
> > pirpDisconnect, m_pConnectionFile->DeviceObject,
> > m_pConnectionFile, DisconnectCompletionRoutine, this,
> > &qTimeout,
> > &dwFlags, // DDK states it should PULONG, I tried both ULONG and
> > PULONG - strange, but BOTH work :slight_smile:
> > &m_CurrentIrp.TdiConnectionInfo, NULL);
> >
> > m_status = IoCallDriver(m_pConnectionFile->DeviceObject,
pirpDisconnect);
> >
> > if (m_status == STATUS_PENDING && bBlock)
> > WaitForReady();
> >
> > //…
> >
> > Or maybe I should do something special in my TDI_EVENT_DISCONNECT? Now I
> > just return STATUS_SUCCESS…
> >
> > Maybe anyone knows whats the problem, or has a clue?..
> > Please help…
> > Thanks in advance.
> >
> > Vladimir
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@narod.ru
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>


You are currently subscribed to ntdev as: xxxxx@midcore.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com

Thankx for your replies Ed and Max!
I think I will read specifications more closely from now on :wink:
----- Original Message -----
From: Ed Lau
To: NT Developers Interest List
Sent: Friday, February 01, 2002 8:37 PM
Subject: [ntdev] Re: TDI_DISCONNECT_RELEASE problem

This is by design - when a TCP connection closes, it enters the TIME_WAIT state for a period of time equal to twice the maximum segment lifetime. You can see the state of TCP connections on your machine by typing “netstat -a -n -p tcp” at a command prompt.

Regards,

Ed lau

MidCore Software, Inc.
900 Straits Tpke
Middlebury, CT 06762

www.midcore.com
----- Original Message -----
From: Vovkos
To: NT Developers Interest List
Sent: Friday, February 01, 2002 10:57 AM
Subject: [ntdev] Re: TDI_DISCONNECT_RELEASE problem

Thanks for your reply Max!!

I figured out: that’s not my TDI client fault - I have the same behavior in
usermode. That’s what my usermode test app do:

  1. open tcp socket and BIND it to some port
  2. CONNECT to remote node
  3. do GRACEFUL DISCONNECT with either shutdown(SD_SEND) or closesocket (with
    either SO_DONTLINGER (1) or SO_LINGER (l_onoff = 1, l_linger > 0))

I run this app once, and:
if I run this app during next several minutes I got WSAEADDRINUSE error on
connect - just the same as in my TDI client.
(By the way, bind operation completes successfully)

It appears that after graceful disconnect transport holds address in a limbo
state for some time…
Question - is this by design? If there a way to overcome this behavior?

Thanks in advance.
Vladimir

P.S.
Of course it is not a problem if I had unbinded socket for connection, but
in my case there is no client and server, and both nodes can initiate
connection…

----- Original Message -----
From: “Maxim S. Shatskih”
To: “NT Developers Interest List”
Sent: Friday, February 01, 2002 10:03 AM
Subject: [ntdev] Re: TDI_DISCONNECT_RELEASE problem

> You must not close the TCP connection file object till both a) your
TDI_DISCONNECT_RELEASE is sent and b)
> TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) is called.
>
> TDI_DISCONNECT_RELEASE sends FIN and moves the TCB
> ESTABLISHED -> FINWAIT_1.
> FIN/ACK arrival moves to FINWAIT_2, the TDI client is not notified on
this.
>
> Then your TDI code will need to wait till
TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) will be called. This means
incoming FIN
> arrival, and the TCB will be in TIME_WAIT state. It is fine to close the
TCP connection file object in this state.
>
> Or otherwise, if TdiClientEventDisconnect(TDI_DISCONNECT_RELEASE) is
called first, it moves to CLOSE_WAIT. Then your
> TDI_DISCONNECT_RELEASE sends FIN and moves the LAST_ACK, it is OK to close
the TCP connection file object in this state. FIN/ACK
> arrival will kill the TCB, the TDI client will not be notified on this.
>
> Attempting to close the TCP connection file object while not it LAST_ACK
or TIME_WAIT will send TCP RST. So, you must not close it
> too early. Lingering close implementation is up to TDI client, TCP will
not do this.
>
> Max
>
> ----- Original Message -----
> From: “Vovkos”
> To: “NT Developers Interest List”
> Sent: Friday, February 01, 2002 3:18 AM
> Subject: [ntdev] TDI_DISCONNECT_RELEASE problem
>
>
> > Greetings All!!
> > I have TDI client which just dropped TCP connection when needed
> > (TDI_DISCONNECT with TDI_DISCONNECT_ABORT flag). But now we want to
change
> > it to graceful disconnect (FIN->,ACK<-,FIN<-,ACK->) I hoped that all I
had
> > to do is to change TDI_DISCONNECT_ABORT -> TDI_DISCONNECT_RELEASE, but
it
> > appears that after such disconnect TransportAddressFile goes to some
strange
> > state… For example subsequent calls to TDI_CONNECT return 0xC000020A
> > (STATUS_ADDRESS_ALREADY_EXIST) ???
> > I think maybe I do disconnect wrong?
> > I prepare disconnect irp like following:
> >
> > //…
> >
> > PIRP pirpDisconnect = TdiBuildInternalDeviceControlIrp(
> > TDI_DISCONNECT,
> > m_pConnectionFile->DeviceObject,
> > m_pConnectionFile,
> > m_CurrentIrp.evntReady, &m_CurrentIrp.IoStatus);
> >
> > if (!pirpDisconnect)
> > {
> > m_status = STATUS_INSUFFICIENT_RESOURCES;
> > return FALSE;
> > }
> >
> > // here I tried to pass either nullified TDI_CONNECTION_INFORMATION or
> > // fill RemoteAddressLength with remote node’ addr like this:
> > ::RtlZeroMemory(&m_CurrentIrp.TdiConnectionInfo,
> > sizeof(TDI_CONNECTION_INFORMATION));
> > m_CurrentIrp.TdiConnectionInfo.RemoteAddressLength =
sizeof(TA_IP_ADDRESS);
> > m_CurrentIrp.TdiConnectionInfo.RemoteAddress = &m_CurrentIrp.taAddress;
> >
> > LARGE_INTEGER qTimeout;
> > qTimeout.QuadPart = Int32x32To64(dwTimeout, -10000);
> >
> > DWORD dwFlags = TDI_DISCONNECT_RELEASE;
> >
> > TdiBuildDisconnect(
> > pirpDisconnect, m_pConnectionFile->DeviceObject,
> > m_pConnectionFile, DisconnectCompletionRoutine, this,
> > &qTimeout,
> > &dwFlags, // DDK states it should PULONG, I tried both ULONG and
> > PULONG - strange, but BOTH work :slight_smile:
> > &m_CurrentIrp.TdiConnectionInfo, NULL);
> >
> > m_status = IoCallDriver(m_pConnectionFile->DeviceObject,
pirpDisconnect);
> >
> > if (m_status == STATUS_PENDING && bBlock)
> > WaitForReady();
> >
> > //…
> >
> > Or maybe I should do something special in my TDI_EVENT_DISCONNECT? Now I
> > just return STATUS_SUCCESS…
> >
> > Maybe anyone knows whats the problem, or has a clue?..
> > Please help…
> > Thanks in advance.
> >
> > Vladimir
> >
> >
> > —
> > You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> > To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
> >
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@narod.ru
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
>


You are currently subscribed to ntdev as: xxxxx@midcore.com
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
You are currently subscribed to ntdev as: xxxxx@narod.ru
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com


You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com