Misunderstanfding WINDDK MUX code.

Hi,

Weird code in MUX driver(for me at least)

I compiled MUX driver with VELAN support and as NDIS 5.1 driver.

I installed driver. All worked fine.
I add miniport(consequently second connection was created). Everything ok.
I enable second connection. In a second I got crash in RealTek network
card driver.

Why?

It is explanation

NDIS_STATUS
PtReceive(
IN NDIS_HANDLE ProtocolBindingContext,
IN NDIS_HANDLE MacReceiveContext, <- LOOK HERE
IN PVOID HeaderBuffer,
IN UINT HeaderBufferSize,
IN PVOID LookAheadBuffer,
IN UINT LookAheadBufferSize,
IN UINT PacketSize
)
[… skipped]
for (p = pAdapt->VElanList.Flink;
p != &pAdapt->VElanList;
p = p->Flink)
{
[… skipped]
if (Packet != NULL)
{
… skipped Realtek network driver will not step here!
}
else
{
// The miniport below us uses the old-style (not packet)
// receive indication. Fall through.
// ***********************
// our branch
// ***********************
}

… skipped
#if IEEE_VLAN_SUPPORT
[… skipped]
MuxRcvContext.MacRcvContext = MacReceiveContext;
//**************************************************
//we remember context of network card(adapter)
// in our context. It is ok
//**************************************************

// In order not to change the code a lot
//**************************************************
// Strange comment…
// Which perfectly explains situation…
//**************************************************

MacReceiveContext = &MuxRcvContext; <— LOOK HERE
//**************************************************
// we overwrite Realtek context with Mux context
//
// if we’ll execute this cycle more than one time we
// get exception in the realtek driver, because second
// time realtek driver get WRONG context of Mux.
//**************************************************
#endif

MUX_INCR_STATISTICS64(&pVElan->GoodReceives);
//
// Indicate receive using the non-packet API.
//
NdisMEthIndicateReceive(pVElan->MiniportAdapterHandle,
MacReceiveContext,
HeaderBuffer,
HeaderBufferSize,
LookAheadBuffer,
LookAheadBufferSize,
PacketSize);

DBGPRINT( MUX_WARN, (“***: processed!!!\n”));
MUX_DECR_PENDING_RECEIVES(pVElan);

} // for (each VELAN)

I understand that with IEEE_VLAN_SUPPORT enabled we could not have
more than one enabled virtual connection per physical miniport(sorry for
terminology). Was it intended? Or it is just error? Or something else?


Best regards,
Sergey mailto:kipnis@wp.pl