Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.More Info on Driver Writing and Debugging
The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
Help please with IMSAMP NDIS_STATUS_WAN_LINE_DOWN
OSR_Community_User
Member Posts: 110,217
in NTDEV
Hi there,
Was wondering if somebody could offer some advise with the suppression of
NDIS_STATUS_WAN_LINE_DOWN status indicator from the NDISWAN to my IMSAMP.
Here's the scenario of my problem:
I am using the IMSAMP driver in a host which will do PPP dialup to a RAS
server. To simulate loss of connection, I off the modem. To preserve
existing TCP sockets (such as FTP or TELNET) from being terminated when I
lost the PPP connection, I would like to suppress the
NDIS_STATUS_WAN_LINE_DOWN from being communicated to the upper TCP layer. I
have modified the CLStatusIndication by adding this line in:
if (GeneralStatus != NDIS_STATUS_WAN_LINE_DOWN).
However, upon redialup (DHCP allocated the same IP address as before
disconnection), I found out that my existing connection is already
terminated. And worse still, I can get any new connectivity (not even Ping
out!) upon redialup. I did netstat before and after disconnection, and
found that my FTP connection disappeared upon disconnection. Upon redialup,
the PPP can be established but I can't even ping out with it (this is with
the suppression of NDIS_STATUS_WAN_LINE_DOWN status indicator in the
CLStatusIndication module)
Would really appreciate if somebody could offer some insights to this
problem or recommend any resources which dealt with similar topic.
Sincerely,
KS
VOID
CLStatusIndication(
IN NDIS_HANDLE ProtocolBindingContext,
IN NDIS_STATUS GeneralStatus,
IN PVOID StatusBuffer,
IN UINT StatusBufferSize
)
/*++
Routine Description:
Called by the NIC via NdisIndicateStatus
--*/
{
PADAPTER Adapter = (PADAPTER)ProtocolBindingContext;
NDIS_STATUS Status;
ULONG ErrorLogData[2];
ImDbgOut(DBG_TRACE, DBG_PROTOCOL, ("(%08X) CLStatusIndication: Status
%08X\n",Adapter, GeneralStatus));
//
// now indicate the status to the upper layer
//
if (GeneralStatus != NDIS_STATUS_WAN_LINE_DOWN)
{
if ( Adapter->IMMPState & ADAPTER_STATE_RUNNING ) {
NdisMIndicateStatus( Adapter->IMNdisHandle, GeneralStatus,
StatusBuffer, StatusBufferSize );
}
}
} // CLStatusIndication
Was wondering if somebody could offer some advise with the suppression of
NDIS_STATUS_WAN_LINE_DOWN status indicator from the NDISWAN to my IMSAMP.
Here's the scenario of my problem:
I am using the IMSAMP driver in a host which will do PPP dialup to a RAS
server. To simulate loss of connection, I off the modem. To preserve
existing TCP sockets (such as FTP or TELNET) from being terminated when I
lost the PPP connection, I would like to suppress the
NDIS_STATUS_WAN_LINE_DOWN from being communicated to the upper TCP layer. I
have modified the CLStatusIndication by adding this line in:
if (GeneralStatus != NDIS_STATUS_WAN_LINE_DOWN).
However, upon redialup (DHCP allocated the same IP address as before
disconnection), I found out that my existing connection is already
terminated. And worse still, I can get any new connectivity (not even Ping
out!) upon redialup. I did netstat before and after disconnection, and
found that my FTP connection disappeared upon disconnection. Upon redialup,
the PPP can be established but I can't even ping out with it (this is with
the suppression of NDIS_STATUS_WAN_LINE_DOWN status indicator in the
CLStatusIndication module)
Would really appreciate if somebody could offer some insights to this
problem or recommend any resources which dealt with similar topic.
Sincerely,
KS
VOID
CLStatusIndication(
IN NDIS_HANDLE ProtocolBindingContext,
IN NDIS_STATUS GeneralStatus,
IN PVOID StatusBuffer,
IN UINT StatusBufferSize
)
/*++
Routine Description:
Called by the NIC via NdisIndicateStatus
--*/
{
PADAPTER Adapter = (PADAPTER)ProtocolBindingContext;
NDIS_STATUS Status;
ULONG ErrorLogData[2];
ImDbgOut(DBG_TRACE, DBG_PROTOCOL, ("(%08X) CLStatusIndication: Status
%08X\n",Adapter, GeneralStatus));
//
// now indicate the status to the upper layer
//
if (GeneralStatus != NDIS_STATUS_WAN_LINE_DOWN)
{
if ( Adapter->IMMPState & ADAPTER_STATE_RUNNING ) {
NdisMIndicateStatus( Adapter->IMNdisHandle, GeneralStatus,
StatusBuffer, StatusBufferSize );
}
}
} // CLStatusIndication
Howdy, Stranger!
| Upcoming OSR Seminars | ||
|---|---|---|
| OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead! | ||
| Internals & Software Drivers | 7 February 2022 | Live, Online |
| Kernel Debugging | 21 March 2022 | Live, Online |
| Developing Minifilters | 23 May 2022 | Live, Online |
| Writing WDF Drivers | 12 September 2022 | Live, Online |
Comments
The PPP link will go down on the remote side (your RAS server). Your FTP or
Telnet session will be down on the remote side. You can not preserve these
sessions by simply suppressing the NDIS_STATUS_WAN_LINE_DOWN on
the local side: you would have to deal with the remote side also.
I do not understand why you want to circumvent the standard link establishment
and tear down. Please elaborate.
Ed Hamlet
[email protected] on 03/08/2000 11:42:00 PM
Please respond to "NT Developers Interest List"
To: "NT Developers Interest List"
cc: (bcc: Edward E Hamlet/USA/Conexant)
Subject: [ntdev] Help please with IMSAMP NDIS_STATUS_WAN_LINE_DOWN
Hi there,
Was wondering if somebody could offer some advise with the suppression of
NDIS_STATUS_WAN_LINE_DOWN status indicator from the NDISWAN to my IMSAMP.
Here's the scenario of my problem:
I am using the IMSAMP driver in a host which will do PPP dialup to a RAS
server. To simulate loss of connection, I off the modem. To preserve
existing TCP sockets (such as FTP or TELNET) from being terminated when I
lost the PPP connection, I would like to suppress the
NDIS_STATUS_WAN_LINE_DOWN from being communicated to the upper TCP layer. I
have modified the CLStatusIndication by adding this line in:
if (GeneralStatus != NDIS_STATUS_WAN_LINE_DOWN).
However, upon redialup (DHCP allocated the same IP address as before
disconnection), I found out that my existing connection is already
terminated. And worse still, I can get any new connectivity (not even Ping
out!) upon redialup. I did netstat before and after disconnection, and
found that my FTP connection disappeared upon disconnection. Upon redialup,
the PPP can be established but I can't even ping out with it (this is with
the suppression of NDIS_STATUS_WAN_LINE_DOWN status indicator in the
CLStatusIndication module)
Would really appreciate if somebody could offer some insights to this
problem or recommend any resources which dealt with similar topic.
Sincerely,
KS
VOID
CLStatusIndication(
IN NDIS_HANDLE ProtocolBindingContext,
IN NDIS_STATUS GeneralStatus,
IN PVOID StatusBuffer,
IN UINT StatusBufferSize
)
/*++
Routine Description:
Called by the NIC via NdisIndicateStatus
--*/
{
PADAPTER Adapter = (PADAPTER)ProtocolBindingContext;
NDIS_STATUS Status;
ULONG ErrorLogData[2];
ImDbgOut(DBG_TRACE, DBG_PROTOCOL, ("(%08X) CLStatusIndication: Status
%08X\n",Adapter, GeneralStatus));
//
// now indicate the status to the upper layer
//
if (GeneralStatus != NDIS_STATUS_WAN_LINE_DOWN)
{
if ( Adapter->IMMPState & ADAPTER_STATE_RUNNING ) {
NdisMIndicateStatus( Adapter->IMNdisHandle, GeneralStatus,
StatusBuffer, StatusBufferSize );
}
}
} // CLStatusIndication
---
You are currently subscribed to ntdev as: [email protected]
To unsubscribe send a blank email to $subst('Email.Unsub')
oriented interface which is broken this way. Above protocol drivers (RasArp,
WanArp) associate context with every connection well documented way. From
MSDN NDIS_WAN_LINE_UP documentation:
NDISWAN uses Ethernet-style address format to communicate with protocols, so
the pair of XxxAddress members of this structure are six-byte addresses,
used as follows:
* NDISWAN uses the RemoteAddress to designate a particular
link-protocol context. At the initial line-up indication for a link, the
protocol should save the RemoteAddress supplied by NDISWAN. Subsequently,
the protocol passes the RemoteAddress value to NDISWAN in calls to NdisSend
for transmissions on this link.
* The protocol uses LocalAddress to set up context for itself in the
low-order four bytes (&LocalAddress[2]) when it receives the initial line-up
indication for a link being established. Subsequently, NDISWAN passes the
LocalAddress to the protocol at receive and status indications. In effect,
NDISWAN uses the given LocalAddress as the destination for incoming receives
and status indications on the link thereafter.
*
In below case the second line up establishes a new connection and existing
TCP sockets use the old one. It is easy to fix but I presume more
hard-to-solve problems.
Best regards,
Michal Vodicka
RKK Informationssysteme s.r.o.
:We support your Future
[WWW: http://www.rkk.cz , http://www.skytale.com]
> ----------
> From: [email protected][SMTP:[email protected]]
> Reply To: NT Developers Interest List
> Sent: Thursday, March 09, 2000 18:43
> To: NT Developers Interest List
> Cc: NT Developers Interest List
> Subject: [ntdev] Re: Help please with IMSAMP
> NDIS_STATUS_WAN_LINE_DOWN
>
> KS,
>
> The PPP link will go down on the remote side (your RAS server). Your FTP
> or
> Telnet session will be down on the remote side. You can not preserve
> these
> sessions by simply suppressing the NDIS_STATUS_WAN_LINE_DOWN on
> the local side: you would have to deal with the remote side also.
>
> I do not understand why you want to circumvent the standard link
> establishment
> and tear down. Please elaborate.
>
> Ed Hamlet
>
>
>
>
> [email protected] on 03/08/2000 11:42:00 PM
>
> Please respond to "NT Developers Interest List" <[email protected]>
>
> To: "NT Developers Interest List" <[email protected]>
> cc: (bcc: Edward E Hamlet/USA/Conexant)
> Subject: [ntdev] Help please with IMSAMP NDIS_STATUS_WAN_LINE_DOWN
>
>
>
> Hi there,
> Was wondering if somebody could offer some advise with the suppression of
> NDIS_STATUS_WAN_LINE_DOWN status indicator from the NDISWAN to my IMSAMP.
> Here's the scenario of my problem:
>
> I am using the IMSAMP driver in a host which will do PPP dialup to a RAS
> server. To simulate loss of connection, I off the modem. To preserve
> existing TCP sockets (such as FTP or TELNET) from being terminated when I
> lost the PPP connection, I would like to suppress the
> NDIS_STATUS_WAN_LINE_DOWN from being communicated to the upper TCP layer.
> I
> have modified the CLStatusIndication by adding this line in:
> if (GeneralStatus != NDIS_STATUS_WAN_LINE_DOWN).
> However, upon redialup (DHCP allocated the same IP address as before
> disconnection), I found out that my existing connection is already
> terminated. And worse still, I can get any new connectivity (not even Ping
> out!) upon redialup. I did netstat before and after disconnection, and
> found that my FTP connection disappeared upon disconnection. Upon
> redialup,
> the PPP can be established but I can't even ping out with it (this is with
> the suppression of NDIS_STATUS_WAN_LINE_DOWN status indicator in the
> CLStatusIndication module)
>
> Would really appreciate if somebody could offer some insights to this
> problem or recommend any resources which dealt with similar topic.
>
> Sincerely,
> KS
>
>
> VOID
> CLStatusIndication(
> IN NDIS_HANDLE ProtocolBindingContext,
> IN NDIS_STATUS GeneralStatus,
> IN PVOID StatusBuffer,
> IN UINT StatusBufferSize
> )
>
> /*++
> Routine Description:
> Called by the NIC via NdisIndicateStatus
> --*/
>
> {
> PADAPTER Adapter = (PADAPTER)ProtocolBindingContext;
> NDIS_STATUS Status;
> ULONG ErrorLogData[2];
>
> ImDbgOut(DBG_TRACE, DBG_PROTOCOL, ("(%08X) CLStatusIndication: Status
> %08X\n",Adapter, GeneralStatus));
>
> //
> // now indicate the status to the upper layer
> //
>
> if (GeneralStatus != NDIS_STATUS_WAN_LINE_DOWN)
> {
> if ( Adapter->IMMPState & ADAPTER_STATE_RUNNING ) {
>
> NdisMIndicateStatus( Adapter->IMNdisHandle, GeneralStatus,
> StatusBuffer, StatusBufferSize );
> }
> }
> } // CLStatusIndication
>
>
>
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
>
>
>
>
>
>
>
>
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
>
Thanks for your reply. Could u provide further info/advise as to how I can
overcome it ? (since u mentioned that it's easy to be done at the end of
your comment) Would really appreciate it.
Thanks in advance for your advise.
Regards,
KS
Thanks for your reply. The main reason for suppression of
NDIS_WAN_STATUS_LINE_DOWN at the Mobile Host side is to prevent existing
TCP socket (ie FTP or telnet), established prior to disconnection, from
being terminated at the Mobile Host side.
Thus, upon PPP redialup, the mobile can continue with the FTP/Telnet
session since the FTP session are still alive at both the Mobile Host and
Fixed Host.
There are 3 entities in my system:
Fixed Host(FTP server) <===> RAS <===> Mobile Host (with suppression of
WAN line down)
I have checked that when PPP link is terminated between Mobile Host and
RAS, the
Linux machine acting as the Fixed Host FTP server still maintain the FTP
session using command 'ps -ajx' which will list all existing TCP sockets at
the Fixed Host side. Thus, I don't quite understand why u said that the FTP
session will be terminated. Note that RAS and the Fixed Host are two
different machines.
Would really appreciate your comments on this matter. Thanks in advance for
your
input...
Regards,
KS
On 03/09/00, "[email protected]" wrote:
> KS,
>
> The PPP link will go down on the remote side (your RAS server). Your FTP or
> Telnet session will be down on the remote side. You can not preserve these
> sessions by simply suppressing the NDIS_STATUS_WAN_LINE_DOWN on
> the local side: you would have to deal with the remote side also.
>
> I do not understand why you want to circumvent the standard link establishment
> and tear down. Please elaborate.
>
> Ed Hamlet
>
>
>
>
> [email protected] on 03/08/2000 11:42:00 PM
>
> Please respond to "NT Developers Interest List"
>
> To: "NT Developers Interest List"
> cc: (bcc: Edward E Hamlet/USA/Conexant)
> Subject: [ntdev] Help please with IMSAMP NDIS_STATUS_WAN_LINE_DOWN
>
>
>
> Hi there,
> Was wondering if somebody could offer some advise with the suppression of
> NDIS_STATUS_WAN_LINE_DOWN status indicator from the NDISWAN to my IMSAMP.
> Here's the scenario of my problem:
>
> I am using the IMSAMP driver in a host which will do PPP dialup to a RAS
> server. To simulate loss of connection, I off the modem. To preserve
> existing TCP sockets (such as FTP or TELNET) from being terminated when I
> lost the PPP connection, I would like to suppress the
> NDIS_STATUS_WAN_LINE_DOWN from being communicated to the upper TCP layer. I
> have modified the CLStatusIndication by adding this line in:
> if (GeneralStatus != NDIS_STATUS_WAN_LINE_DOWN).
> However, upon redialup (DHCP allocated the same IP address as before
> disconnection), I found out that my existing connection is already
> terminated. And worse still, I can get any new connectivity (not even Ping
> out!) upon redialup. I did netstat before and after disconnection, and
> found that my FTP connection disappeared upon disconnection. Upon redialup,
> the PPP can be established but I can't even ping out with it (this is with
> the suppression of NDIS_STATUS_WAN_LINE_DOWN status indicator in the
> CLStatusIndication module)
>
> Would really appreciate if somebody could offer some insights to this
> problem or recommend any resources which dealt with similar topic.
>
> Sincerely,
> KS
>
>
> VOID
> CLStatusIndication(
> IN NDIS_HANDLE ProtocolBindingContext,
> IN NDIS_STATUS GeneralStatus,
> IN PVOID StatusBuffer,
> IN UINT StatusBufferSize
> )
>
> /*++
> Routine Description:
> Called by the NIC via NdisIndicateStatus
> --*/
>
> {
> PADAPTER Adapter = (PADAPTER)ProtocolBindingContext;
> NDIS_STATUS Status;
> ULONG ErrorLogData[2];
>
> ImDbgOut(DBG_TRACE, DBG_PROTOCOL, ("(%08X) CLStatusIndication: Status
> %08X\n",Adapter, GeneralStatus));
>
> //
> // now indicate the status to the upper layer
> //
>
> if (GeneralStatus != NDIS_STATUS_WAN_LINE_DOWN)
> {
> if ( Adapter->IMMPState & ADAPTER_STATE_RUNNING ) {
>
> NdisMIndicateStatus( Adapter->IMNdisHandle, GeneralStatus,
> StatusBuffer, StatusBufferSize );
> }
> }
> } // CLStatusIndication
>
>
>
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
info is there. Just for the case you didn't:
1. NdisWan establishes a connection, creates context for it (NC1), creates
NDIS_WAN_LINE_UP structure and stores its context to RemoteAddress some way
(it seems as a handle on my system but it doesn't matter). Afterwards
indicates line up status to above protocol.
2. Protocol receives lines up, creates its own context (PC1) and stores it
to LocalAddress. Protocol saves NC1 and uses it for next communication with
NdisWan.
3. After status indication return, NdisWan saves PC1 and uses it for all
next indications to protocol (packets, subsequest line ups when multiline
connection is used, line downs etc.)
4. After some time line down occurs. NdisWan fills NDIS_WAN_LINE_DOWN
structure and indicates it to protocol.
5. Protocol cleans all necessary data and destroys PC1.
6. NdisWan finally closes line and destroys NC1.
You tried to stop 4. in your IM driver and avoid 5. It isn't enough because
if next line up occurs, steps 1. - 3. are made and next contexts NC2 and PC2
are created. There are one connection from NdisWan point of view but two for
protocol which is bad and I'm not surprised that it doesn't work. You have
to:
- don't propagate new line up to above protocol. Instead, store PC1
(previously saved, of course) to LocalAddress, save NC2 and return to
NdisWan.
- for every indication from NdisWan to protocol using PC1 and NC2 change NC2
to NC1 because protocol expects it (maybe not quite necessary but should be
done to make things clear)
- for every request from protocol to NdisWan using PC1 and NC1 change NC1 to
NC2 because NdisWan expects it.
The best way how to do it in IM driver is to create own context for every
connection and swap contexts in appropriatte manner in both directions.
Best regards,
Michal Vodicka
RKK Informationssysteme s.r.o.
:We support your Future
[WWW: http://www.rkk.cz , http://www.skytale.com]
> ----------
> From:
> [email protected][SMTP:[email protected]]
> Reply To: NT Developers Interest List
> Sent: Monday, March 13, 2000 5:26 AM
> To: NT Developers Interest List
> Subject: [ntdev] Re: Help please with IMSAMP
> NDIS_STATUS_WAN_LINE_DOWN
>
> Hi Michal,
> Thanks for your reply. Could u provide further info/advise as to how I can
>
> overcome it ? (since u mentioned that it's easy to be done at the end of
> your comment) Would really appreciate it.
>
> Thanks in advance for your advise.
>
> Regards,
> KS
>
> ---
> You are currently subscribed to ntdev as: [email protected]
> To unsubscribe send a blank email to $subst('Email.Unsub')
>