none
C# zur Laufzeit IP-Adressen zu Interface hinzufügen RRS feed

  • Frage

  • Hallo,

    Ich möchte in einer C# .NET 4.0 Applikation zur Laufzeit bei einem Ethernet-Interface IPv4 Adressen hinzufügen/löschen.

    Bei meinen Recherchen zu diesem Thema findet man nur Hinweise, das dieses über WMI bzw. Ausführung von netsh möglich ist.

    Mit beiden Lösungen habe ich allerdings so meine Probleme:

    WMI gibt einem keine Rückmeldung ob der Vorgang erfolgreich war und wenn es fehlschlägt bekommt man keine Info warum. Außerdem kann man das nur machen, wenn die gesamte Applikation als Admin läuft.

    Bei netsh gibt es zum einem das Problem bei der Berechtigung, das man ja mittels Verb="runas" lösen kann. Dann allerdings nimmt man sich die Möglichkeit StandardOutput bzw. StandardError im Fehlerfall auszuwerten. Da "runas" voraussetzt, dass UseShellExecute auf true steht welches einem den Redirect der Ausgabe verbietet.

    Desweiteren beobachte ich bei netsh das Problem, dass die Aktion "interface ip add address" mit ExitCode 0 beendet wird, aber es noch einige Sekunden dauert bis die IP-Adresse auch für Sockets benutzt werden kann. Fehler: "Die angeforderte Adresse ist in diesem Kontext ungültig". Wartet man nach netsh-Aufruf noch ein paar Sekunden (Thread.Sleep() :/), dann funktioniert dies. Nur ist das natürlich keine Lösung! Auch checken ob die IP-Adresse beim Interface auftaucht, hilft leider nicht. Da diese direkt nach dem netsh-Aufruf existiert, aber halt nicht verwendet werden kann.

    Deshalb von mir die Frage, ob jemand einen schöneren Weg kennt mit dem man aus einer Applikation heraus IP-Adressen setzen/löschen kann, mit auslesbaren Fehlercodes/Meldungen und ohne Sleep().

    Grüße und Danke im Vorraus

    Mittwoch, 10. Juni 2015 07:27

Antworten

  • Hi,

    um den Aufruf als Admin wirst Du nicht rumkommen.

    Ich frage mich allerdings, warum man sowas überhaupt in einer normalen Anwendung machen sollte!?

    Wenn Du das unbedingt so machen willst und WMI nicht nutzbar ist, ruf netsh auf und starte anschließend einen Timer (bspw. alle 250ms), mit dem Du prüfst, ob die IP Adresse nutzbar ist. Es geht dabei nicht darum, zu schauen, ob die IP da ist, sondern Du machst letztendlich genau das, was Du später auch machst: Du verwendest die Adresse, allerdings in einem Try Catch Block. Sobald alles Ok ist, kannst Du dann deine weitere Verarbeitung anstoßen.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Mittwoch, 10. Juni 2015 09:04
    Moderator

Alle Antworten

  • Hi,

    um den Aufruf als Admin wirst Du nicht rumkommen.

    Ich frage mich allerdings, warum man sowas überhaupt in einer normalen Anwendung machen sollte!?

    Wenn Du das unbedingt so machen willst und WMI nicht nutzbar ist, ruf netsh auf und starte anschließend einen Timer (bspw. alle 250ms), mit dem Du prüfst, ob die IP Adresse nutzbar ist. Es geht dabei nicht darum, zu schauen, ob die IP da ist, sondern Du machst letztendlich genau das, was Du später auch machst: Du verwendest die Adresse, allerdings in einem Try Catch Block. Sobald alles Ok ist, kannst Du dann deine weitere Verarbeitung anstoßen.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Mittwoch, 10. Juni 2015 09:04
    Moderator
  • Hi,

    Admin ist vollkommen in Ordnung. Allerdings wünschenswert wäre nur das setzen/löschen der IP als Admin laufen zu lassen und nicht die ganze Applikation.

    Der Anwendungsfall ist zu gegeben sehr exotisch und für die Windows-Welt (noch) sehr ungewöhnlich. Es geht bei der Applikation darum SSH-Forwardings zu verwalten. Leider gibt es Programme die eine IP aus 127/8 nicht als Server-Ziel-IP akzeptieren. Daher implementiere ich als Workaround die Möglichkeit sogenannte Mapping-Adressen auf einem Loopback-Interface zu setzen/löschen. Statt auf 127.0.0.1 des Software Loopback Devices wird der Socket halt auf 192.168.0.1 auf einem Microsoft Loopbackadapter geöffnet. Technisch genau das selbe wie ein SSH Local-Forwarding auf 127.0.0.1, nur der Check in den Programmen akzeptiert diesen Socket dann auch als Ziel.

    Der Vorschlag von dir klingt schon mal gut und sollte sich auch einfach als Check einbauen lassen.

    Noch eine Idee wie man trotz "runas" den Output von Stderr und Stdout bekommen kann?

    Grüße

    Mittwoch, 10. Juni 2015 09:19