Använda Layer 2-filtrering

2025-03-19

Layer 2-filtrering stöds i Windows 8 och senare versioner av Windows.

Den här WFP-funktionen tillåter filtrering på fält i layer 2 MAC-huvudet. Dessa lager anropas per paket för alla paket som skickas eller tas emot av värddatorn. Lagren anropas innan paketet monteras på nytt på den inkommande sökvägen och efter paketfragmenteringen på den utgående sökvägen. Dessa lager är åtkomliga från en NDIS lightweight filter (LWF) drivrutin.

Anteckning

En callout bör inte injicera paket på ett lager om det inte redan finns ett motsvarande filter på det lagret. Inmatningen av de NET_BUFFER_LIST strukturerna ska samordnas med filtertillägget och borttagningen så att injektionen endast utförs när filtret finns i motsvarande lager. Dessutom bör leverantörer inte ta bort filter som tillhör andra leverantörer.

Det här avsnittet innehåller följande avsnitt:

Injicera MAC-ramar
Klassificera länkade nätverksbuffertlistor
WFP Layer 2-lager och fält

Injicera MAC-ramar

En återuppringningsdrivrutin anropar funktionen FwpsInjectMacReceiveAsync0 för att injicera en tidigare absorberad MAC-ram (eller en klon av ramen) tillbaka till den inkommande datasökvägen på lager 2, från vilken den fångades upp, eller för att injicera en påhittad MAC-ram i den inkommande datasökvägen.

En återanropsdrivrutin anropar funktionen FwpsInjectMacSendAsync0 för att återställa en tidigare absorberad MAC-ram (eller en klon av ramen) tillbaka till den utgående datasökvägen layer 2 som den fångades upp från, eller för att mata in en påhittad MAC-ram i den utgående datasökvägen.

Parametern netBufferLists kan vara en NET_BUFFER_LIST kedja. Slutförandefunktionen kan dock anropas flera gånger var och en, vilket slutför ett segment (eller en enda NET_BUFFER_LIST) i kedjan.

Inmatade ramar kan klassificeras igen om paketen matchar samma filter som ursprungligen klassificerades. Precis som med utrop i IP-lager måste också utrop i lager 2 skydda mot oändlig paketinspektion genom att anropa FwpsQueryPacketInjectionState0.

Dessutom måste du ha anvisningar på lagret där du injicerar. Annars kommer din injicerade NET_BUFFER_LIST inte att slutföras av din slutförandefunktion, och NET_BUFFER_LIST kommer att fortsätta uppåt i stacken. I det här fallet är beteendet odefinierat eftersom NDIS försöker skicka den inmatade NET_BUFFER_LIST till nästa komponent i stacken.

NET_BUFFER_LISTStatus fält innehåller statusresultatet för stackinmatningen. Stackinmatningens statusresultat är den status som stacken placerar i NET_BUFFER_LIST efter att en WFP-inmatningsfunktion returnerar STATUS_SUCCESS. Du bör använda makrot NT_SUCCESS för att kontrollera statusen för stackinjektionen i Status fältet. Om värdet Status är STATUS_SUCCESShar injektionen lyckats utan att ge ytterligare information. Status medlemsvärden som är större än STATUS_SUCCESS innebär att injektionen lyckades, men det kan finnas mer information om injektionen som bör övervägas. Status medlemsvärden som är mindre än STATUS_SUCCESS betyder att injektionen misslyckades på grund av den orsak som anges i medlemmen Status.

Klassificera kedjade nätverksbuffertlistor

Som standardinställning kan en callout-drivrutin endast klassificera nätverksbuffertlistor individuellt. En utropsdrivrutin kan dock klassificera NET_BUFFER_LIST kedjor för bättre prestanda, om den gör båda följande:

Anger flaggan FWP_CALLOUT_FLAG_ALLOW_L2_BATCH_CLASSIFY i Flags medlemmen av FWPS_CALLOUT2-strukturen.
Registrerar en classifyFn2-funktion som kan klassificera NET_BUFFER_LIST kedjor.

Varning

Men om en utropsdrivrutin anger flaggan FWP_CALLOUT_FLAG_ALLOW_L2_BATCH_CLASSIFY kan den inte använda följande funktioner för att ändra NET_BUFFER_LISTs.

Med den här flagguppsättningen returnerar FwpsAllocateCloneNetBufferList0 alltid ett INVALID_PARAMETER fel. Detta kan oväntat leda till att en tredjeparts callout-drivrutin misslyckas med hantering av referensantalet för NET_BUFFER_LISTs, vilket gör att sändnings- och mottagningsåtgärder stoppas.