Ich bin neu bei NDIS-LWB-Treibern, musste aber zu ihnen wechseln, nachdem ich festgestellt hatte, dass WFP unter Win7 meine Anforderungen nicht erfüllen würde. Hoffentlich ist dies keine allzu grundlegende Frage.
Meine Anforderungen setzen grundsätzlich voraus, dass ich in der Lage binHören Sie eine ausgewählte Netzwerkkarte auf einem System mit mehreren Netzwerkkarten promisku ab. Ich habe das LWB-Beispiel geändert, um die Schnittstellen in den Promiscuous-Modus zu versetzen, aber ich bin jetzt beim Festlegen des angegebenen Adapters geblieben. Mir ist klar, dass der LWB auf allen Adaptern sitzt, es ist also kein 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 Fahrer das IOCTL zu gebenausgewählte MAC-Adresse (n) der Schnittstelle, die mir wichtig ist. Ist es möglich, den Treiber zu laden, aber nur den Filter auf bestimmten Schnittstellen laufen zu lassen, oder muss ich nur Anrufe ignorieren, die von anderen stammen, die mir in FilterReceiveNetBufferLists egal sind Rückruf der FilterReceiveNetBufferLists, wenn ich für eine bestimmte Schnittstelle nichts damit anfangen möchte.
Die Dinge, die mich auslösen, sind die Tatsachedass FilterRestart während DriverEntry automatisch aufgerufen wird (über NdisFRegisterFilterDriver) und dass es anscheinend keinen NdisFPauseFilter gibt (aber einen NdisFRestartFilter). Idealerweise möchte ich in der Lage sein, die erforderlichen Parameter festzulegen, bevor eine Filterung beginnt, und ich "Ich möchte mich von der Verwendung der Registrierung während DriverEntry fernhalten, da ich immer noch die Fähigkeit benötige, bei Bedarf dynamisch Aufgaben neu auszuführen.
Und zum besseren Verständnis der NDIS-Interna wird der gesamte Stapel angehalten, wenn ein Filtermodul angehalten wird, oder wird NDIS um das angehaltene Modul herumgeführt?
Antworten:
0 für die Antwort № 1Das sind gute Fragen.
Ist es möglich, den Treiber zu laden, aber nur den Filter auf bestimmten Schnittstellen laufen zu lassen?
Ja. Hier haben Sie drei Möglichkeiten.
- Deaktivieren Sie die Bindung statisch im Benutzermodus. oder
- Lehnt die Bindung zur Laufzeit ab.
- Den Datenpfad dynamisch umgehen und wieder aktivieren. (Dies wird hier nicht näher erläutert, da es bereits in MSDN beschrieben ist.)
Um die Bindung statisch zu deaktivieren, verwenden Sie die INetCfg API Um die Bindung zwischen Ihrem Filtertreiber und der Netzwerkkarte zu ermitteln, 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 könnte Ihre Usermode-App beispielsweise entscheiden, Bindungen zu bestimmten NICs nur dann zu aktivieren, wenn ihre GUI ausgeführt wird.
Es ist jedoch nicht immer praktisch, den Benutzermodus auszuführenWenn Ihr Treiber noch keinen Benutzermodus hat, ist es wahrscheinlich übertrieben, einen zu erstellen, um nur ein paar Bindungen zu deaktivieren. Hier bietet sich die zweite Technik an. 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. Dies reicht aus, um NDIS davon zu überzeugen, dass Ihr Filter keine Verbindung zur Netzwerkkarte herstellen kann (oder wird). Aber - wenn Ihr Filter als markiert ist Verpflichtend (d. h., der FilterRunType der INF ist 1) FilterAttach führt dazu, dass die Netzwerkkarte nicht mehr funktioniert. (Immerhin ist das "s der springende Punkt obligatorisch zu sein. Wenn Ihr Filter nicht vorhanden ist, dann der Datenpfad darf nicht run.) Wenn Sie jedoch zulassen möchten, dass die Netzwerkkarte trotzdem ausgeführt wird, legen Sie fest, dass NDIS_FILTER_ATTACH_FLAGS_IGNORE_MANDATORY Flagge in Ihrem NDIS_FILTER_ATTACH_PARAMETERS::Flags Feld kurz vor Ihrem Filter gibt einen Fehlercode von seinem zurück FilterAttach.
Es scheint nur so, als ob es effizienter wäre, den FilterReceiveNetBufferLists-Rückruf nicht zu haben, wenn ich für eine bestimmte Schnittstelle nichts damit anfangen würde.
Ihre Instinkte sind richtig. Ein Filter im Datenpfad ist mit einem Mehraufwand verbunden, und wenn der Filter nichts unternimmt, sind die CPU-Zyklen verschwendet. Schreiben Sie diese Option jedoch 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, ist es möglicherweise gut genug, diese einfache Option zu wählen.
Ich möchte mich von der Verwendung der Registrierung während DriverEntry fernhalten, da ich immer noch die Fähigkeit benötige, bei Bedarf dynamisch Aufgaben neu auszuführen.
Wie oben erwähnt, Sie kann Re-Task mit Usermode-Code. Jedes Mal, wenn der Benutzermodus INetCfg :: Apply aufruft, ruft NDIS any auf FilterAttach oder FilterDetach Notwendig, um die richtigen Veränderungen herbeizuführen.
Wenn Sie die zweite Technik verwenden, ist es nicht wirklich möglich, Aufgaben erneut auszuführen. Wenn Sie eine bestimmte Netzwerkkarte erneut konfigurieren müssen, sollten Sie entweder die erste oder die dritte Methode anwenden.
Wenn ein Filtermodul angehalten wird, wird der gesamte Stapel angehalten, oder wird NDIS um das angehaltene Modul herumgeleitet?
Der gesamte Stapel ist angehalten. NDIS "routet" nicht um Filter herum. (Wenn Ihr Filter optional ist, wird der Datenverkehr um Ihren Filter herum geleitet, wenn Ihr Filter nicht aktiv ist. Solange Ihr Filter an die Netzwerkkarte angeschlossen ist, werden NBLs und OIDs durch Ihre Netzwerkkarte geleitet Filter.)