NDIS LWF - Filterneustart und FilterPause

Question

Ich bin neu bei NDIS LWF-Treibern, aber ich musste zu ihnen wechseln, nachdem ich festgestellt hatte, dass WFP unter Win7 meine Anforderungen nicht erfüllen würde.Hoffentlich ist das keine zu grundlegende Frage.

Meine Anforderungen bestehen im Wesentlichen darin, eine ausgewählte Netzwerkkarte auf einem Multi-Netzwerkkarten-System promiskuitiv abhören zu können.Ich habe das LWF-Beispiel geändert, um die Schnittstellen in den promiskuitiven Modus zu versetzen, aber ich bin jetzt nicht mehr sicher, wie der angegebene Adapter eingestellt wird.Mir ist klar, dass LWFS über allen Adaptern sitzen, also ist es nicht wie ein Protokoll, bei dem ich einfach NdisOpenAdapterEx aufrufen könnte, aber ich würde annehmen, dass es einen Filtermechanismus geben muss, um bestimmte Adapter zu ignorieren.

Ich muss in der Lage sein, dem Treiber die ausgewählte (n) MAC-Adresse (n) der Schnittstelle, die mir wichtig ist, zuzuweisen.Ist es möglich, den Treiber zu laden, aber nur den Filter auf bestimmten Schnittstellen auszuführen, oder muss ich einfach Anrufe von anderen ignorieren, die mir in FilterReceiveNetBufferLists egal sind.Es scheint nur so, als wäre es effizienter, den Rückruf von FilterReceiveNetBufferLists nicht zu benötigen, wenn ich für eine bestimmte Schnittstelle nichts damit anfangen würde.

Die Dinge, die mich stolpern, sind die Tatsache, dass FilterRestart beim DriverEntry automatisch aufgerufen wird (über NdisFRegisterFilterDriver) und dass es anscheinend keinen NdisFPauseFilter gibt (aber es gibt einen NdisFRestartFilter).Idealerweise möchte ich in der Lage sein, die erforderlichen Parameter festzulegen, bevor eine Filterung beginnt, und ich möchte die Registrierung während der Treibereingabe nicht verwenden, da ich weiterhin die Möglichkeit benötige, die Aufgabe nach Bedarf dynamisch neu zu erledigen.

Und schließlich, nur zum besseren Verständnis der NDIS-Interna, wird beim Anhalten eines Filtermoduls der gesamte Stapel angehalten oder wird NDIS um das angehaltene Modul herumgeleitet?

Answer 1

Das sind gute Fragen.

Ist es möglich, den Treiber zu laden, aber den Filter nur auf bestimmten Schnittstellen laufen zu lassen

Ja.Sie haben hier drei Möglichkeiten.

1. Deaktivieren Sie die Bindung statisch im Benutzermodus;oder
2. Lehnen Sie die Bindung zur Laufzeit ab.
3. Dynamisches Umgehen und erneutes Aktivieren des Datenpfads.(Dies wird hier nicht detailliert beschrieben, da es bereits auf MSDN beschrieben ist.)

Um die Bindung statisch zu deaktivieren, würden Sie verwenden die INetCfg API um die Bindung zwischen Ihrem Filtertreiber und der Netzwerkkarte zu finden, deaktivieren Sie sie.Das könnte so aussehen:

INetCfg::Initialize
myFilter = INetCfg::FindComponent
myFilter->QueryInterface(INetCfgComponentBindings)
for each binding in bindings
    if binding is to undesirable NIC
        INetCfgBindingPath::Enable(FALSE)

Sie können dies jederzeit tun, sobald Ihr Treiber installiert ist.So kann Ihre Benutzermodus-App beispielsweise entscheiden, Bindungen an bestimmte Netzwerkkarten nur zu aktivieren, wenn die Benutzeroberfläche ausgeführt wird.

Es ist jedoch nicht immer bequem, Benutzermoduscode auszuführen, und wenn Ihr Treiber noch keinen Benutzermodus hat, ist es wahrscheinlich übertrieben, einen zu erstellen, nur um einige Bindungen zu deaktivieren.Hier kommt die zweite Technik zum Tragen.Sie können die Bindungen im Benutzermodus statisch aktiviert lassen, aber die Bindung zur Laufzeit ablehnen.

Wie lehnen Sie es ab, zur Laufzeit zu binden?In vielen Fällen müssen Sie lediglich einen Fehlerstatus von Ihrem zurückgeben FilterAttach Handler.Das reicht aus, um NDIS davon zu überzeugen, dass Ihr Filter nicht an die Netzwerkkarte angeschlossen werden kann (oder wird).Aber - wenn Ihr Filter als markiert ist Obligatorisch (dh der FilterRunType des INF ist 1), dann schlägt Ihr FilterRunType fehl FilterAttach dies führt dazu, dass die Netzwerkkarte funktionsunfähig wird.(Immerhin ist das der springende Punkt obligatorisch zu sein.Wenn Ihr Filter nicht vorhanden ist, wird der Datenpfad darf nicht laufen.) Aber wenn Sie möchten, dass die Netzwerkkarte trotzdem gestartet wird, setzen Sie die NDIS_FILTER_ATTACH_FLAGS_IGNORE_MANDATORY flagge in deinem NDIS_FILTER_ATTACH_PARAMETERS::Flags feld kurz bevor Ihr Filter einen Fehlercode von seinem zurückgibt FilterAttach.

Es scheint nur so, als wäre es effizienter, den Rückruf von FilterReceiveNetBufferLists nicht zu benötigen, wenn ich für eine bestimmte Schnittstelle nichts damit anfangen würde.

Deine Instinkte sind richtig.Es ist ein Aufwand, einen Filter im Datenpfad zu haben, und wenn der Filter nichts tut, werden CPU-Zyklen verschwendet.Aber schreiben Sie diese Option noch nicht ab.In einigen Fällen überwiegt die Einfachheit dieser Option die (relativ geringen) CPU-Kosten.Das heißt, es sei denn, Ihr Zielmarkt zählt jeden CPU-Zyklus, es könnte gut genug sein, einfach mit dieser einfachen Option zu gehen.

Ich möchte mich von der Verwendung der Registrierung während der Treibereingabe fernhalten, da ich weiterhin die Möglichkeit benötige, die Aufgabe nach Bedarf dynamisch neu zu erledigen.

Wie oben erwähnt, Sie können wiederholen Sie die Aufgabe mit Usermode-Code.Jedes Mal, wenn usermode INetCfg::Apply aufruft, ruft NDIS einen beliebigen FilterAttach oder FilterDetach benötigt, um die richtigen Änderungen vorzunehmen.

Es ist nicht wirklich möglich, Aufgaben neu zu erstellen, wenn Sie die zweite Technik verwenden.Wenn Sie eine bestimmte Netzwerkkarte neu zuweisen müssen, sollten Sie entweder die erste oder die dritte Technik verwenden.

wenn ein Filtermodul angehalten wird, wird der gesamte Stapel angehalten oder wird NDIS um das angehaltene Modul herumgeleitet?

Der gesamte Stapel wird angehalten.NDIS "routet" Filter nicht herum.(Wenn Ihr Filter optional ist, wird der Datenverkehr Ihren Filter umgehen, wenn Ihr Filter nicht ausgeführt wird.Solange Ihr Filter jedoch an die Netzwerkkarte angeschlossen ist, durchlaufen NBLs und OIDs Ihren Filter.)