This documentation is archived and is not being maintained.

MiniportWanSend callback function

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.

The MiniportWanSend function is required if the driver controls a WAN NIC. Such a driver does not have a MiniportSendPackets or MiniportSend function.


NDIS_STATUS MiniportWanSend(
  _In_ NDIS_HANDLE      MiniportAdapterContext,
  _In_ NDIS_HANDLE      NdisLinkHandle,


MiniportAdapterContext [in]

Specifies the handle, originally input to MiniportInitialize, identifying the miniport driver and WAN NIC it controls.

NdisLinkHandle [in]

Specifies the handle to a miniport driver-allocated context area for this link. The driver previously returned this handle in an NDIS_MAC_LINE_UP indication when the link was established.

WanPacket [in]

Pointer to an NDIS_WAN_PACKET structure, specifying the data to be transmitted. This structure specifies the virtual range for a buffer with guaranteed padding at the beginning and end. The driver can manipulate the data in this buffer in any way.

Return value

MiniportWanSend can return one of the following:

Return codeDescription

The driver (or its NIC) has accepted the packet data for transmission, so MiniportWanSend is returning the packet.


The driver will complete the packet asynchronously with a call to NdisMWanSendComplete.


The given packet was invalid or unacceptable to the NIC.



When MiniportWanSend is called, ownership of both the packet descriptor and the packet data is transferred to the driver until it completes the given packet, either synchronously or asynchronously. If MiniportWanSend returns a status other than NDIS_STATUS_PENDING, the request is considered complete and ownership of the packet immediately reverts to the initiator of the send request. If MiniportWanSend returns NDIS_STATUS_PENDING, the miniport driver subsequently must call NdisMWanSendComplete with the packet to indicate completion of the transmit request.

MiniportWanSend can use both the MacReservedx and WanPacketQueue areas within the NDIS_WAN_PACKET structure. However, the miniport driver cannot access the ProtocolReservedx members.

Any NDIS intermediate driver that binds itself to an underlying WAN miniport driver is responsible for providing a fresh NDIS_WAN_PACKET structure to the underlying driver's MiniportWanSend function. Before such an intermediate driver calls NdisSend, it must repackage the send packet given to its MiniportWanSend function so the underlying driver will have MacReservedx and WanPacketQueue areas of its own to use.

The available header padding within a given packet can be calculated as ( CurrentBuffer- StartBuffer), the available tail padding as ( EndBuffer- ( CurrentBuffer+ CurrentLength)). The header and tail padding is guaranteed to be at least the length that the miniport driver requested in response to a preceding OID_WAN_GET_INFO query. The header and/or tail padding for any packet given to MiniportWanSend can be more than the length that was requested.

MiniportWanSend can neither return NDIS_STATUS_RESOURCES for an input packet nor call NdisMSendResourcesAvailable. Instead, the miniport driver must queue incoming send packets internally for subsequent transmission. The miniport driver controls how many packets NDIS will submit to MiniportWanSend when the NIC driver sets the SendWindow value in the driver's NDIS_MAC_LINE_UP indication to establish the given link. NDISWAN uses this value as an upper bound on uncompleted sends submitted to MiniportWanSend, so the miniport's internal queue cannot be overrun, and the miniport driver can adjust the SendWindow dynamically with subsequent line-up indications for established links. If the miniport driver set the SendWindow to zero when it called NdisMIndicateStatus with a particular line-up indication, NDISWAN uses the MaxTransmit value that the driver originally set in response to the OID_WAN_GET_INFO query as its limit on submitted but uncompleted send packets.

Each packet passed to MiniportWanSend is set up according to one of the flags that the miniport driver set in the FramingBits member in response to the OID_WAN_GET_INFO query. It will contain simple HDLC PPP framing if the driver claimed to support PPP. For SLIP or RAS framing, such a packet contains only the data portion with no framing whatsoever.

For more information about system-defined WAN and TAPI OIDs, see WAN Objects and TAPI Objects.

A WAN driver cannot manage software loopback or promiscuous mode loopback internally. NDISWAN supplies this loopback support for WAN drivers.

MiniportWanSend can be preempted by an interrupt.

The MiniportWanSend function of a deserialized miniport driver can be called at any IRQL <= DISPATCH_LEVEL. The MiniportWanSend function of a deserialized driver is responsible for synchronizing access to its internal queues of packet descriptors with the driver's other MiniportXxx functions that also access the same queues.

The MiniportWanSend function of a serialized miniport driver runs at IRQL = DISPATCH_LEVEL.


Target platform



Not supported for NDIS 6.0 drivers in Windows Vista. Supported for NDIS 5.1 drivers in Windows Vista and Microsoft Windows XP.


Ndis.h (include Ndis.h)


<= DISPATCH_LEVEL (see Remarks section)

See also




Send comments about this topic to Microsoft