This documentation is archived and is not being maintained.

NDIS_MAC_LINE_UP structure

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 NDIS_MAC_LINE_UP structure contains information associated with a line-up indication made by a WAN miniport driver.


typedef struct _NDIS_MAC_LINE_UP {
  ULONG            LinkSpeed;
  USHORT           SendWindow;
  NDIS_HANDLE      ConnectionWrapperID;
  NDIS_HANDLE      NdisLinkHandle;
  NDIS_HANDLE      NdisLinkContext;



Specifies the speed of the link, in units of 100 bps.

Zero indicates no change from the speed the miniport driver originally returned for the OID_GEN_LINK_SPEED query.


Specifies the quality of service (QoS) of the new line as returned when the protocol called NdisRequest with OID_WAN_QUALITY_OF_SERVICE.


Specifies the number of send packets the miniport driver (or its NIC) can accept at a time, effectively how many NDIS_WAN_PACKET-type send packets the WAN NIC driver queues internally. Zero indicates that NDISWAN should use the value returned for MaxTransmit in response to the OID_WAN_GET_INFO query.


Specifies the handle by which this link (or data channel on a link) will be known to TAPI client(s). This handle must be unique, so the miniport driver uses the htCall handle supplied by NDISTAPI. Before the miniport driver makes the initial line-up indication that establishes such a link (or data channel), it already acquired the NDISTAPI-assigned htCall handle in one of the following ways:

  • For an outbound call, the driver's MiniportQueryInformation function saved the htCall handle that NDISTAPI supplied in a preceding OID_TAPI_MAKE_CALL request.

  • For an incoming call, the miniport driver saved the htCall handle that NDISTAPI returned in ulParam2 of the NDIS_TAPI_EVENT structure that the miniport driver passed to NdisMIndicateStatus with ulMsg set to LINE_NEWCALL.


Specifies the handle, originally supplied by the NIC driver, that is passed down in subsequent calls, such as to MiniportWanSend, to identify a particular link, or to identify a particular channel on a link capable of handling more than one data stream.


Specifies zero when a WAN NIC driver calls NdisMIndicateStatus with this structure to establish a link. On return from NdisMIndicateStatus, this member contains a handle, supplied by NDISWAN, to be used in future calls, such as to indicate receives, for the established link.


A WAN NIC driver calls NdisMIndicateStatus with this type of indication in either of the following conditions:

  • When a link between a local node and a remote node in a wide area network becomes active in the process of establishing the new link, the MiniportQueryInformation function makes this indication in the context of an OID_TAPI_GET_ID request for which ulSelect is set to LINECALLSELECT_CALL.

    When NdisMIndicateStatus returns, the miniport driver must save the NdisLinkContext handle, supplied by NDISWAN, for subsequent calls to NdisMIndicateStatus and NdisWanXxx functions affecting the just established link.

    MiniportQueryInformation also must use the returned NdisLinkContext handle as the value returned to NDISTAPI at DeviceID in the NDIS_TAPI_GET_ID structure.

    If it can handle more than one data channel on a link, a WAN NIC driver's MiniportQueryInformation function is called once with OID_TAPI_GET_ID as each such channel on the link is opened. On such a link, NdisLinkContext handles are channel-specific rather than link-specific.

  • After such a link is established, the NIC driver makes this indication with the given NdisLinkContext handle if line characteristics change, or to dynamically change the value of SendWindow specifying the number of outstanding sends the NIC driver accepts for its internal queue. For example, a miniport driver can make a subsequent line-up indication if the originally specified Quality of the line changes.

Typically, a WAN NIC driver provides a pointer to a driver-allocated control block for each link as NdisLinkHandle. This handle is link-specific or, if the driver manages more than one data stream per link, data-channel-specific. In either case, a WAN miniport driver must set up its NdisLinkHandle at the first NDIS_MAC_LINE_UP indication that the miniport driver makes for each link or data channel.

After NDISWAN has submitted the number of packets specified in SendWindow to MiniportWanSend, NDISWAN holds incoming send packets queued until the miniport driver returns a completed send packet or calls NdisMWanSendComplete with a packet for which it previously returned NDIS_STATUS_PENDING, whichever occurs first. Subsequent NDIS_MAC_LINE_UPs can be indicated if the NIC driver needs to change the SendWindow value dynamically.

Whenever subsequent NDIS_MAC_LINE_UP indications are made, whether to change the SendWindow value or for changes in line characteristics, the NdisLinkHandle member must be filled with the value set in the driver's initial line-up call to NdisMIndicateStatus for the same link.

NDISWAN supplies a unique handle at NdisLinkContext for every initial NDIS_MAC_LINE_UP indication that establishes a new link or channel. The miniport driver must supply the given NdisLinkContext handle when it makes any subsequent NDIS_MAC_LINE_UP, NDIS_MAC_LINE_DOWN, and NDIS_MAC_FRAGMENT indications for the same link or channel.

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



Ndiswan.h (include Ndiswan.h)

See also




Send comments about this topic to Microsoft