The following chart summarizes the OIDs used to get or set operational characteristics for NDIS drivers and WAN NICs.
|
Length |
Q |
S |
Name |
|
6 |
M |
OID_WAN_PERMANENT_ADDRESS | |
|
6 |
M |
OID_WAN_CURRENT_ADDRESS | |
|
4 |
M |
OID_WAN_QUALITY_OF_SERVICE | |
|
1 or 6 |
M |
OID_WAN_PROTOCOL_TYPE | |
|
4 |
M |
OID_WAN_MEDIUM_SUBTYPE | |
|
4 |
M |
OID_WAN_HEADER_FORMAT | |
|
4 |
M |
|
OID_WAN_GET_INFO |
|
4 |
M |
OID_WAN_GET_LINK_INFO | |
|
4 |
M |
OID_WAN_SET_LINK_INFO | |
|
4 |
M |
OID_WAN_LINE_COUNT | |
|
50 |
O |
OID_WAN_GET_COMP_INFO | |
|
50 |
O |
OID_WAN_SET_COMP_INFO | |
|
60 |
O |
OID_WAN_GET_STATS_INFO |
The following describes each of the OID_XXX listed in the preceding chart more fully.
The OID_WAN_GET_BRIDGE_INFO and OID_WAN_SET_BRIDGE_INFO codes are reserved.
This OID requests the miniport to return the address encoded in the hardware of the NIC.
This OID requests the miniport to return the address that the NIC currently is using.
The miniport should return a unique address for the target NIC. NDISWAN presents the returned value, formatted as an Ethernet address, to higher-level protocols. Consequently, the least-significant bit must not be set in such a returned NIC-specific address to prevent it from being interpreted as an Ethernet multicast address.
The driver of a NIC manufactured by a vendor with an assigned Ethernet ID should use that ID as part of the address it returns for this OID. This prevents conflicts with other vendors’ assigned Ethernet address ranges.
This OID requests the miniport to return the quality of service that it supports.
The quality of service returned for this query should be a worst-case estimate, specified as one of the following system-defined values:
When a NIC driver calls NdisMIndicateStatus with a line-up indication, it provides QOS information for a specified link.
This OID informs the underlying driver of a bound protocol’s type, as a single-byte network-level protocol identifier (NLPID).
Alternatively, a protocol can specify a 6-byte Sub-Network Access Protocol (SNAP) NLPID, with 0x80-0x00-0x00-0x00 for the first four bytes and an Ethertype for the last two bytes.
This OID requests the miniport to return a list of the media subtypes that it can support as a proper subset of the following system-defined values:
The NdisWanMediumAtm value is reserved.
This OID requests the miniport to return or to set the address-header format used, as either of the following system-defined values:
For a query, the miniport returns a list of the address formats that the NIC driver supports. For a set, the miniport subsequently uses the given type to format headers for this binding.
If an underlying NDIS driver does not support a header format that a protocol recognizes, that protocol’s attempt to bind to the underlying driver fails. A NIC driver is not required to support both address types of header format but should if it can.
This OID requests the miniport to return information about its or the NIC’s capabilities, formatted as an NDIS_WAN_INFO structure, defined as follows:
typedef struct _NDIS_WAN_INFO {
OUT ULONG MaxFrameSize;
OUT ULONG MaxTransmit;
OUT ULONG HeaderPadding;
OUT ULONG TailPadding;
OUT ULONG Endpoints;
OUT UINT MemoryFlags;
OUT NDIS_PHYSICAL_ADDRESS HighestAcceptableAddress;
OUT ULONG FramingBits;
OUT ULONG DesiredACCM;
} NDIS_WAN_INFO, *PNDIS_WAN_INFO;
The members of this structure contain the following information:
However, all WAN miniports should use an internal MaxFrameSize that is
32 bytes larger than the value they return for this OID. For example, a WAN
miniport that returns 1500 for this OID should internally accept and send up
to 1532. Such a miniport can readily support future bridging and additional
protocols.
NDISWAN uses the value of this member as a default throttle on how many send requests it submits to the driver’s MiniportWanSend function before NDISWAN holds incoming sends queued until the miniport completes an outstanding send. A miniport can adjust this value dynamically and on a per-link basis using the SendWindow member in the NDIS_MAC_LINE_UP structure that the driver passes to NdisMIndicateStatus. NDISWAN uses the current line-up SendWindow value as its throttle on outstanding sends unless the miniport sets SendWindow to zero for an indication, whereupon NDISWAN reverts to using the driver-set MaxTransmit value.
Since a WAN NIC driver must queue packets internally, the value of MaxTransmit is theoretically max(ULONG). However, this miniport-determined value should reflect the link speed or hardware capabilities of the NIC.
For example, if its NIC always has room for at least four frames, a miniport
would set MaxTransmit to four so that any incoming packet to
MiniportWanSend can be placed on the hardware immediately.
For example, if its NIC requires just a flag byte preceding the frame, the
miniport would set this member to one.
For example, if its NIC requires three bytes at the end of each net packet for
the Frame Checksum Sequence (CRC check) and the flag byte, a miniport would
set this member to three.
For example, a miniport would set this member to two for an ISDN card with two
channels. It would set this member to ten for an X.25 card that can accept up
to ten virtual circuits.
Otherwise, set this to the type of memory to be allocated for the NIC, that
is, NDIS_MEMORY_NONCACHED and/or NDIS_MEMORY_CONTIGUOUS. Subsequently, memory
of the specified type will be allocated for all packets to be transmitted by
the WAN adapter.
Otherwise, if the NIC can use 24-bit addresses, set this value to
NDIS_PHYSICAL_ADDRESS_CONST (0x1000000, 0). Subsequently, memory within the
specified range will be allocated for all packets to be transmitted by the
NIC. Thus, memory can just be DMAed directly to the NIC instead of having to
be double-buffered through a CPU-memory copy.
NDISWAN will remove the address and control field if this LCP option is
negotiated. Some WAN medium types, such as X.25, do not support this option.
NDISWAN will remove one byte from the protocol field when applicable if this
LCP option is negotiated.
Asynchronous media need not write any code to support VJ header compression.
NDISWAN will take care of it.
NIC drivers must be in the default PPP framing mode until each driver receives an NDIS_WAN_SET_LINK_INFO call. The NIC driver must auto-detect any framing that it claims to support.
For example, drivers that support old RAS framing must autodetect RAS framing from PPP framing. If a driver detects a framing scheme other than the default, that driver should automatically switch its framing into the newly detected framing.
A subsequent query with OID_WAN_GET_LINK_INFO should indicate the detected framing. If no framing is yet detected, the FramingBits should be zero in the returned NDIS_WAN_GET_LINK_INFO information.
If the WAN miniport is called subsequently with OID_WAN_SET_LINK_INFO
in which the FramingBits member is zero, the driver should attempt to
autodetect the framing upon reception of each frame.
This OID requests the miniport to return information about the current state of a link formatted as an NDIS_WAN_GET_LINK_INFO structure, defined as follows:
typedef struct _NDIS_WAN_GET_LINK_INFO {
IN NDIS_HANDLE NdisLinkHandle;
OUT ULONG MaxSendFrameSize;
OUT ULONG MaxRecvFrameSize;
OUT ULONG HeaderPadding;
OUT ULONG TailPadding;
OUT ULONG SendFramingBits;
OUT ULONG RecvFramingBits;
OUT ULONG SendCompressionBits;
OUT ULONG RecvCompressionBits;
OUT ULONG SendACCM;
OUT ULONG RecvACCM;
} NDIS_WAN_GET_LINK_INFO, *PNDIS_WAN_GET_LINK_INFO;
The members of this structure contain the following information:
The proper NLPID and framing format should be used based on the framing bits
wherever applicable.
Possible values for SendFramingBits and RecvFramingBits include any the driver returned in response to the OID_WAN_GET_INFO query.
This OID requests the miniport to set information for an established link. The protocol-supplied information is formatted as an NDIS_WAN_SET_LINK_INFO structure, defined as follows:
typedef struct _NDIS_WAN_SET_LINK_INFO {
IN NDIS_HANDLE NdisLinkHandle;
IN ULONG MaxSendFrameSize;
IN ULONG MaxRecvFrameSize;
IN ULONG HeaderPadding;
IN ULONG TailPadding;
IN ULONG SendFramingBits;
IN ULONG RecvFramingBits;
IN ULONG SendCompressionBits;
IN ULONG RecvCompressionBits;
IN ULONG SendACCM;
IN ULONG RecvACCM;
} NDIS_WAN_SET_LINK_INFO, *PNDIS_WAN_SET_LINK_INFO;
The members of this structure contain the following information:
From this, both PreamblePadding and PostamblePadding can be calculated, along
with the framing bits and ACCM. The driver’s MiniportWanSend function can
reject any send packets submitted for this link that are larger than this
value.
The proper NLPID and framing format should be used based on the framing bits
wherever applicable.
Possible values for SendFramingBits and RecvFramingBits include any the underlying driver returned in response to the OID_WAN_GET_INFO query.
This OID requests the miniport to return the total number of lines (endpoints) it exposes.
This OID requests the miniport to return information about the capabilities of the NIC or of its driver, in particular whether either supports compression. If so, the values returned are used to negotiate compression with the Point-to-Point Protocol (PPP) Compression Control Protocol. The protocol subsequently negotiates a compression scheme with an OID_WAN_SET_COMP_INFO request.
Compression information is returned in an NDIS_WAN_GET_COMP_INFO structure, defined as follows:
typedef struct _NDIS_WAN_GET_COMP_INFO {
IN NDIS_HANDLE NdisLinkHandle;
OUT NDIS_WAN_COMPRESS_INFO SendCapabilities;
OUT NDIS_WAN_COMPRESS_INFO RecvCapabilities;
} NDIS_WAN_GET_COMP_INFO, *PNDIS_WAN_GET_COMP_INFO;
The members of this structure contain the following information:
The NDIS_WAN_COMPRESS_INFO structure is defined as follows:
typedef struct _NDIS_WAN_COMPRESS_INFO {
UCHAR SessionKey[8];
ULONG MSCompType;
// Members above reserved to indicate NDISWAN capabilities.
// Members below indicate NIC-specific capabilities.
UCHAR CompType;
USHORT CompLength;
union {
struct {
UCHAR CompOUI[3];
UCHAR CompSubType;
UCHAR CompValues[32];
} Proprietary;
struct {
UCHAR CompValues[32];
} Public;
};
} NDIS_WAN_COMPRESS_INFO;
The members of this structure contain the following information:
This OID notifies the miniport of the compression scheme selected by a protocol to which the miniport already returned information in OID_WAN_GET_COMP_INFO.
The protocol supplies a specification for the compression scheme it selected in an NDIS_WAN_SET_COMP_INFO structure, defined as follows:
typedef struct _NDIS_WAN_SET_COMP_INFO {
IN NDIS_HANDLE NdisLinkHandle;
IN NDIS_WAN_COMPRESS_INFO SendCapabilities;
IN NDIS_WAN_COMPRESS_INFO RecvCapabilities;
} NDIS_WAN_SET_COMP_INFO, *PNDIS_WAN_SET_COMP_INFO;
The members of this structure contain the following information:
For specifics of the NDIS_WAN_COMPRESS_INFO structure, see the preceding OID_WAN_GET_COMP_INFO.
This OID requests the miniport to return statistics information. A WAN NIC driver is expected to keep statistics and to return these statistics for this OID in an NDIS_WAN_GET_STATS_INFO structure, defined as follows:
typedef struct _NDIS_WAN_GET_STATS_INFO {
IN NDIS_HANDLE NdisLinkHandle;
OUT ULONG BytesSent;
OUT ULONG BytesRcvd;
OUT ULONG FramesSent;
OUT ULONG FramesRcvd;
OUT ULONG CRCErrors;
OUT ULONG TimeoutErrors;
OUT ULONG AlignmentErrors;
OUT ULONG SerialOverrunErrors;
OUT ULONG FramingErrors;
OUT ULONG BufferOverrunErrors;
OUT ULONG BytesTransmittedUncompressed;
OUT ULONG BytesReceivedUncompressed;
OUT ULONG BytesTransmittedCompressed;
OUT ULONG BytesReceivedCompressed;
} NDIS_WAN_GET_STATS_INFO, *PNDIS_WAN_GET_STATS_INFO;
The members of this structure contain the following information:
If the underlying driver or its NIC does not support compression, the driver returns zero for the Bytes..Uncompressed/Compressed members.