Sending Packets From a CoNDIS WAN Miniport Driver (NDIS 5.1)
Note NDIS 5. x has been deprecated and is superseded by NDIS 6. x. For new NDIS driver development, see Network Drivers Starting with Windows Vista. For information about porting NDIS 5. x drivers to NDIS 6. x, see Porting NDIS 5.x Drivers to NDIS 6.0.
An upper-layer driver calls NdisCoSendPacketsto send packets to an underlying CoNDIS WAN miniport driver. The NDISWAN intermediate driver forwards those packets from the upper-layer driver. NDISWAN repackages the packets before sending them. NDISWAN forwards packets as new NDIS_PACKETstructures.
The NDISWAN intermediate driver calls NDIS to forward packets, NDIS calls the WAN miniport driver's MiniportCoSendPacketsfunction. For more information about how a CoNDIS WAN miniport driver sends packets, see Sending Packets on a VC.
The CoNDIS WAN miniport driver owns both the packet descriptor and the packet data until the send completes, regardless of whether the send completes synchronously or asynchronously. If the miniport driver does not immediately complete the send request, it returns NDIS_STATUS_PENDING from MiniportCoSendPacketsand must later call NdisMCoSendCompleteto complete the send request.
A completion call does not necessarily indicate that a packet has been transmitted; however with the exception of intelligent NICs, the packet usually has been transmitted. A completion call does however, indicate that the miniport driver is ready to release ownership of the packet.
If the CoNDIS WAN miniport driver returns a status other than NDIS_STATUS_PENDING, the send operation is considered to be complete, and ownership of the packet immediately reverts to the caller.
After the CoNDIS WAN miniport driver receives a packet, it should send the packet out on an active virtual connection (VC).
Unlike non-WAN connectionless miniport drivers, a WAN miniport driver cannot return a status of NDIS_STATUS_RESOURCES to indicate that it does not have enough resources currently available to process the transmission of packets. Instead, the WAN miniport driver should queue the send internally for a later time and perhaps lower the send-window value on the connection. The send-window value is the number of outstanding packets that the WAN miniport driver can handle per connection. The miniport driver specifies the send-window value to an upper-layer driver.
A CoNDIS WAN miniport driver specifies the number of outstanding packets that it can have per VC in the MaxSendWindow member of the NDIS_WAN_CO_INFO structure. The miniport driver provides this structure when the miniport driver responds to the OID_WAN_CO_GET_INFOrequest from the protocol driver. However, the miniport driver can adjust this number dynamically and on a per-VC basis using the SendWindowmember in the WAN_CO_LINKPARAMSstructure. The miniport driver passes this structure to the NdisMCoIndicateStatusfunction. NDISWAN uses the current SendWindowvalue as its limit on outstanding sends. The miniport driver can set the value of the SendWindowmember to zero to specify that it cannot handle any outstanding packets. That is, if the SendWindowmember is set to zero, the send window is shut down and NDISWAN stops sending packets for the particular VC.
Note CoNDIS WAN miniport drivers never call the NdisMSendResourcesAvailable function.
Packets that a WAN miniport driver sends contain simple HDLC PPP framing if PPP framing is set. For SLIP or RAS framing, packets contain only the data portion with no framing whatsoever. For more information about WAN packet framing, see WAN Packet Framing.
A WAN miniport driver must not attempt to provide software loopback or promiscuous-mode loopback. Both of these loopback types are fully supported by the NDISWAN driver.