[Win7] Virtuelle Maschine for Beginners

Lokheizer

Moderator im Ruhestand
Themenstarter
Registriert
24 Juli 2013
Beiträge
3.206
Hallo!


Ich hätte ein paar Fragen bezüglich VMs, die ich durch googlen nur unzureichend beantworten konnte (eventuell auch falsch gesucht). Die ganze Nacht habe ich mich damit beschäftigt, bin aber nicht wirklich zu einem Ergebnis gekommen.
Der Hintergrund:
Ich würde gerne eine VM installieren, in der ich Software gefahrlos testen kann weil es einfach mühsam ist, eventuelle Reste dieser Software vom Produktivsystem zu entfernen. Auch würde ich gerne einmal Linux ansehen, der Neugier wegen. Dabei stellen sich mir folgende Fragen:
  • Wenn ich Win7 in der VM installiere, müsste ich dieses ja irgendwann aktivieren lassen. Kann ich dann einfach Win7 neu installieren und ich hab wieder ein wenig Zeit?
  • Belastet eine VM die SSD sehr (allgemein gefragt, damit sind keine aufwändigen Dateioperationen in der VM gemeint)?
  • Ist es sinnvoll eine VM in eine RAMDisk zu installieren?
  • Kann ein Programm aus einer VM ausbrechen (ich hab natürlich nicht vor absichtlich Viren zu installieren, aber die Frage stellt sich trotzdem)
  • Gibt es sonst noch Dinge, die ich unbedingt beachten sollte?

Vielleicht sind die Fragen bescheuert, aber VMs sind Neuland für mich. ;)
 
Was wir brauchen, ist Folgendes:
Zunächst verbindest Du Deinen Laptop mit dem Handy und sorgst dafür, dass die VM Internet hat.
Dann öffenst Du auf dem Host die CMD-Box und gibst "ipconfig /all" ein. Danach kopierst Du das Ergebnis in eine Textbox und postest es hier.
Das gleiche machst Du noch einmal mit dem Pirelli-Access Point, und postest auch dieses Ergebnis.
Anhand der unterschiedlichen IP- und der MAC-Adressen können wir hoffentlich sehen, was da los ist....
Was willst du anhand der IP und Mac-Adressen sehen können?
Das Problem liegt ganz einfach im WLAN Standard, der nur eine Peer-to-Peer Verbindung auf Layer 2 definiert. Damit erlauben standardkonforme Geräte nur eine MAC-Adresse auf der Client-Seite.
Wenn jetzt der Bridge-Mode aktiviert wird, erscheint eine zweite MAC-Adresse auf dieser Verbindung, die MAC-Adresse des (virtuellen) Ethernet-Adapters der VM, welche auch auf Layer 2 "mitspielen" will. DHCP oder Routing hat hiermit nichts zu tun.
Es funktiert oft, da sich viele AcessPoints an dieser Stelle (zum Glück für den Benutzer) an dieser Stelle nicht ganz an den Standard halten und mit mehreren MAC-Adressen umgehen können.
So ist es.
Kriegt euch bitte nicht in die Haare. ;)

Verstanden habe ich das alles eigentlich nicht, was ihr da so ausdiskutiert. Aber anscheinend ist es fakt, dass unser Router Bridged eben nicht will. :confused:
Du könntest es mal mit einem Kabel probieren, aber das wird dein Problem auch nicht dauerhaft lösen können.

Ich selber habe es mit einem TP-Link WR1043D getestet mit OpenWrt.
 
Ich muss schoerg da noch recht geben. Ich weiß nicht, ob think_pad je ausprobiert hat, was er da behauptet. Aber mit Bridging bringt man in keinem Virtualisierer in Standardeinstellung den internen DHCP nach außen. Hier wird viel gefachsimpelt, viel verwirrt und leider ist tatsächlich viel Bullshit dabei.
@think_pad: Bitte probier mal aus was du da behauptest :)
@Lokheizer: Lass dich hier nicht verwirren :)
 
Es geht darum eine VM als einen Rechner ins Netzwerk zu hängen, so dass er von außen erreichbar ist.

Dementsperechend sollten wir auch die Komplexität auf dem selben Niveau halten, zumal das Problem auf dieser zugegeben oberflächlicher Betrachtungsweise durchaus zu lösen ist.

Bei "warum ruckelt die Maus wenn ich dies oder das tue" fange ich auch nicht an mit "wie funktioniert ein Transistor"?
 
Ich muss schoerg da noch recht geben. Ich weiß nicht, ob think_pad je ausprobiert hat, was er da behauptet. Aber mit Bridging bringt man in keinem Virtualisierer in Standardeinstellung den internen DHCP nach außen.

Doch, ich habe das schon oft erlebt, dass sich DHCP-Server selbstständig machen, allerdings mit älteren VM-Versionen. Außerdem behaupte ich auch gar nicht, recht zu haben, sondern es geht um dieses Phänomen, dass ein simplel gestrickter Access Point eines Handys funktioniert, während ein professioneller Pirelli-Router versagt. Der Grund liegt auf MAC- oder IP-Ebene, und der Grund kann durchaus sein, dass sich der Pirelli-Router an eine MAC-Direktive hält, die der Handy-Access-Point ignoriert.

Und für diesen Fehler gibt es eine eindeutige Ursache, die man nur ermitteln kann, in dem man wengistens klar macht, dass sich die IP-Adressen sich gegenseitig nicht behindern. Dazu muss man von allen beteiligten Adaptern die IP-Adresse auslesen und notfalls kreuz und quer pingen, um das auszuschließen. Danach kann man sich dem MAC-Phänomen zuwenden: So spannend kann Bullshit sein! :)
 
Ich halte die Theorie mit amoklaufenden DHCP Server für recht unwahrscheinlich (wenn auch nicht für umöglich). Bei der Installation sucht sich die VM Software ein privates Subnet aus das nicht genutzt wird und macht sich dort mit seinem DHCP Server breit. Nun mag sie zufällig diese ausgesucht haben die in einem anderen Netzwerk doch in Benutzung ist aber diese Chance ist relativ gering.

Adressenkolisionen ließen sich allerdings relativ einfach erkennen. Zu lange her da das selten passiert aber entweder hat sich Windows mit einer Adressenkonfliktmeldung auf sich aufmerksam gemacht oder es war in den Logfiles. Jedenfalls hat mich das Problem nicht zu lange beschäftigt obwohl ich gar nicht darauf vorbereitet war. Üblicherweise sucht man ja bei rätselhaften, da alle paar Jahre auftretenden Problemen ewig nach der Ursache wenn man nicht mit der Nase in die richtige Richtung gedrückt wird.
 
Doch, ich habe das schon oft erlebt, dass sich DHCP-Server selbstständig machen, allerdings mit älteren VM-Versionen.
Das muss allerdings eine recht alte Version sein. Virtualbox erstellt nämlich nicht mal mit NAT einen DHCP-Server auf dem Host.
Außerdem behaupte ich auch gar nicht, recht zu haben, sondern es geht um dieses Phänomen, dass ein simplel gestrickter Access Point eines Handys funktioniert, während ein professioneller Pirelli-Router versagt. Der Grund liegt auf MAC- oder IP-Ebene, und der Grund kann durchaus sein, dass sich der Pirelli-Router an eine MAC-Direktive hält, die der Handy-Access-Point ignoriert.
Professionel würde ich den Pirelli nicht nennen - habe davon schon einige (vorallem die Telekom Austria-Modelle) gesehen. Ein billiger TP-Link mit OpenWrt ist da 10x besser.
 
Bevor ich mich über das VirtualBox-Problem noch mal hermache, muss ich zu meiner Ehrenrettung sagen, dass es tatsächlich einen DHCP-Dienst der (alten) virtuellen Maschinen gibt. Ich habe also auf einem IBM 600x unter WINDOWS 2000 eben noch einmal ein altes VMWare 3.2 frisch installiert und tatsächlich läuft da ganz regulär der DHCP-Dienst, der uns seinerzeit Kopfzerbrechen und den Fehler beschert hat, und der bei falscher Konfiguration den regulären DHCP-Dienst gekillt hat.

vmware32_0.png...vmware32_1.png...vmware32_2_dhcp-service.png ...vmware32_3_adapters.png

-----------------------------
VirtualBox-4.3.6-9 Win läuft absolut problemlos, lässt sich sogar ohne Neustart installieren, nimmt problemlos ein WIN-XP-CD an und installiert diese. Danach gibt es folgende Konfiguration...


VM_VirtualBox Adapter.PNG.....VM_WIN_XP_1.png.....VM_WIN_XP_2.png

Das heißt praktisch Folgendes:

  1. VirtualBox installiert sichtbar nur einen HostOnly-Adapter. In diesem Adapter ist das VirtualBox-Bridged-Protokoll deaktiviert, wie bei einem HostOnly nicht anders zu erwarten. Der Adapter trägt von Hause aus die IP 192.168.56.1; unter Eigenschaften findet man die fest eingetrage Adresse, Der HostOnly-Adapter spielt also den Switch für alle folgenden HostOnly-Adapter kommender VMs. Da HostOnly-Adapter und seine VMs naturgemäß nicht in das Internet gehen, ist er hier bedeutungslos. Wenn man aber nachträglich das Bridge-Protokoll im Adapter aktiviert, wird aus dem HostOnly eine Bridge.
  2. Die probehalber aufgesetzte virtuelle und gebridgte XP-VM-Maschine geht problemlos und ohne jede Voreinstellung in das Internet (Screenshot), damit können wir uns das Pingen sparen. Seine IP heißt 10.0.2.15 und es ist en gewöhnliches C-Subnet. Die MAC-Adresse der VM wird nicht auf dem Access-Point angezeigt, nur der WLAN-Adapter des Hosts, über den der Verkehr letztlich abgewickelt wird.
  3. Überraschenderweise bezieht die VM-Adaptercard aber ihre IP 10.0.2.15 per DHCP, obwohl weder der Access Point dafür verantwortlich ist, noch ein sichtbarer DHCP-Dienst in den Diensten. Der Dienst ist also wie bei VMWare 3.2 sehr wohl vorhanden, aber nicht sichtbar, denn irgendwoher muss der VM-Netcard-Adapter ja seine IP beziehen.

Fazit: Es könnte beim TE rein theoretisch immer noch ein IP-Problem sein, aufgrund der problemlosen Installation ist das aber sehr unwahrscheinlich. Es ist wahrscheinlich wirklich ein MAC-Problem mit dem Access Point und dem WLAN, und da sich MAC-Adressen nun mal nicht anpingen bzw. "anmaccen" lassen, wird das Problem vertagt. Merkwürdig ist auch, dass die MAC-Adresse der internetfähigen VM auf meinem Access Point, einer FritzBox, gar nicht angezeigt wird, sich also vollständig versteckt. VMs unter Hyper-V (WINDOWS 8) werden dagegen angezeigt.

Lösung: ThinkPad per Kabel an den Router hängen, um WLAN-Fehler auszuschließen. DHCP im Access Point abschalten, IP-Adressen probehalber von Hand vergeben: Hat der Router die Adresse 192.168.x.1, bekommt das ThinkPad (Host-Adapter) die 192.168.x.2 und der VM-Network-Adapter 192.168.x.3. Dann sollte es gehen...
 
Zuletzt bearbeitet:
Professionel würde ich den Pirelli nicht nennen - habe davon schon einige (vorallem die Telekom Austria-Modelle) gesehen. Ein billiger TP-Link mit OpenWrt ist da 10x besser.
Es ist ein Telekom-Austria-Modell und es ist absolute Sch**e, da hast du recht. ;)

Du könntest es mal mit einem Kabel probieren, aber das wird dein Problem auch nicht dauerhaft lösen können.
Ich könnte das maximal versuchen, aber eine Dauerlösung kann das nicht sein. Außer meinem Netzkabel hasse ich Kabel am Notebook. Aber wie bereits gesagt, NAT funktioniert hervorragend und reicht aus.

Soll ich den Ipconfig-Auszug jetzt machen?
 
Es wäre schon interessant.

  1. Ein Problem kann das WLAN sein, also Kabel anschließen. Dann muss der virtuelle Adapter natürlich das Kabel als Bridge akzeptieren. Wenn es geht, war das WLAN schuld...
  2. Die IP-Adressen vergeben, wie oben beschrieben. WLAN probieren, dann könnte es gehen, dann waren die IPs schuld.
  3. Variante 2 mit Kabel: Dann muss es gehen, sonst ist etwas oberfaul... :thumbup:
 
Eine kurze Zwischenfrage an die Experten, bevor es mit der Netzwerksache weitergeht:
Ist die Verwendung von VT-d in irgendwie gefährlicher als ohne? Meine Maschine würde das nämlich unterstützen, aber ich frage mich wenn die dann quasi direkt über die I/Os "gemappt" wird kann die dann nicht leichter ausbrechen und meinen Host mit in den Abgrund stürzen? Oder hat das mit dem nix zu tun und es beschleunigt einfach das System?
 
Ist die Verwendung von VT-d in irgendwie gefährlicher als ohne? Meine Maschine würde das nämlich unterstützen, aber ich frage mich wenn die dann quasi direkt über die I/Os "gemappt" wird kann die dann nicht leichter ausbrechen und meinen Host mit in den Abgrund stürzen?

Niemand bricht aus und niemand stürzt in den Abgrund: VT-d kann verschiedene Prozessoren emulieren, was in Deinem Fall aber völlig unerheblich ist.
 
Die MAC-Adresse der VM wird nicht auf dem Access-Point angezeigt, nur der WLAN-Adapter des Hosts, über den der Verkehr letztlich abgewickelt wird.
Überraschenderweise bezieht die VM-Adaptercard aber ihre IP 10.0.2.15 per DHCP, obwohl weder der Access Point dafür verantwortlich ist, noch ein sichtbarer DHCP-Dienst in den Diensten. Der Dienst ist also wie bei VMWare 3.2 sehr wohl vorhanden, aber nicht sichtbar, denn irgendwoher muss der VM-Netcard-Adapter ja seine IP beziehen.
Ja Virtualbox macht das irgendwie, nur nicht mit einem Server der irgendwo auf dem Host lauscht. Ist aber nicht wirklich schlimm.
Ich könnte das maximal versuchen, aber eine Dauerlösung kann das nicht sein. Außer meinem Netzkabel hasse ich Kabel am Notebook. Aber wie bereits gesagt, NAT funktioniert hervorragend und reicht aus.
Musst eh du wissen, finde aber gerade Wlan nicht immer geeignet, allerdings stört mich auch kein Kabel. ;)
 
VT-d kann verschiedene Prozessoren emulieren

Wie kommst Du auf die Idee? Mit Prozessor-Emulation hat dies überhaupt nichts zu tun.
VT-d wird von den derzeit üblichen Virtualisierungslösungen nur für das direkte Durchreichen kompletter PCI-Geräte in die virtuelle Maschine verwendet, was auf Notebooks äußerst selten Sinn macht (und auch nur selten technisch möglich ist).
 
So ist es. Mit dem Emulieren von Prozessoren hat VT-d nichts am Hut. Es ermöglicht das Verwenden von physischer Hardware in virtuellen Maschinen, macht auf einem Laptop also wenig Sinn. AFAIK kann VT-d auch noch die Speicherverwaltung für die virtuellen Maschinen beschleunigen, da hierfür deutlich weniger CPU Zyklen nötig sind. Das wird aber offensichtlich von keinem Virtualisierer genutzt... Du kannst die Funktion anlassen, daraus entsteht grundsätzlich keine zusätzliche Möglichkeit zum Ausbrechen aus der virtuellen Maschine. Schaden tut die Funktion also nicht und vielleicht unterstützen ja früher oder später die Virtualisierer auch die Beschleunigung dadurch, dann nützt sie dir sogar.
 
So ist es. Mit dem Emulieren von Prozessoren hat VT-d nichts am Hut.

Stimmt, ihr habt recht! :)
Das "Durchreichen an Hardware" meinte ich eigentlich! Ich habe es mal unter VM-DOS eine CPU für eine Karte "ge-idelt", deshalb kam ich darauf.
Jedenfalls ist es für den TE egal, ob er es einschaltet...
 
Wie kommst Du auf die Idee? Mit Prozessor-Emulation hat dies überhaupt nichts zu tun.
VT-d wird von den derzeit üblichen Virtualisierungslösungen nur für das direkte Durchreichen kompletter PCI-Geräte in die virtuelle Maschine verwendet, was auf Notebooks äußerst selten Sinn macht (und auch nur selten technisch möglich ist).
Naja, wäre schon cool wenn die K2000M die Grafik-Virtualisierung übernimmt. :cool: Aber das ist wirklich nicht nötig. Ich lass das zeug aus, die VM geht ja eh schon in Echtzeit bei mir.

So, hier Ipconfig /all mit dem Router (VM ist im Bridged-Modus):
Code:
C:\Users\EDT>ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : EDT-W530
   Primäres DNS-Suffix . . . . . . . :
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein
   DNS-Suffixsuchliste . . . . . . . : home

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung 3:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter #
4
   Physikalische Adresse . . . . . . : 24-77-03-D3-FF-7D
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung 2:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter #
3
   Physikalische Adresse . . . . . . : 24-77-03-D3-FF-7D
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Ethernet-Adapter Bluetooth-Netzwerkverbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Bluetooth Device (Personal Area Network)
   Physikalische Adresse . . . . . . : 68-94-23-EA-C4-3A
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung:

   Verbindungsspezifisches DNS-Suffix: home
   Beschreibung. . . . . . . . . . . : Intel(R) Centrino(R) Ultimate-N 6300 AGN
   Physikalische Adresse . . . . . . : 24-77-03-D3-FF-7C
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::205b:6369:6260:a225%13(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 10.0.0.9(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Mittwoch, 26. Februar 2014 17:39:00
   Lease läuft ab. . . . . . . . . . : Donnerstag, 27. Februar 2014 15:20:51
   Standardgateway . . . . . . . . . : 10.0.0.138
   DHCP-Server . . . . . . . . . . . : 10.0.0.138
   DHCPv6-IAID . . . . . . . . . . . : 321156867
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-DB-BF-4E-3C-97-0E-4A-D4-B1

   DNS-Server  . . . . . . . . . . . : 10.0.0.138
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter LAN-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connecti
on
   Physikalische Adresse . . . . . . : 3C-97-0E-4A-D4-B1
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.home:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix: home
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter LAN-Verbindung* 13:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : 2001:0:9d38:6ab8:ec:28b4:f5ff:fff6(Bevorz
ugt)
   Verbindungslokale IPv6-Adresse  . : fe80::ec:28b4:f5ff:fff6%12(Bevorzugt)
   Standardgateway . . . . . . . . . : ::
   NetBIOS über TCP/IP . . . . . . . : Deaktiviert

Tunneladapter isatap.{764572CA-468B-46E0-9C46-4EB5293233F4}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{9A417375-7D89-42EF-8437-80F5C150731B}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #3
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{074A0C02-3100-4CEF-9C9A-F20DDAADFC77}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #4
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{F71F7168-CD1C-42CD-9661-29EF7468653E}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #5
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Hier dasselbe mit dem Handy:
Code:
C:\Users\EDT>ipconfig /all

Windows-IP-Konfiguration

   Hostname  . . . . . . . . . . . . : EDT-W530
   Primäres DNS-Suffix . . . . . . . :
   Knotentyp . . . . . . . . . . . . : Hybrid
   IP-Routing aktiviert  . . . . . . : Nein
   WINS-Proxy aktiviert  . . . . . . : Nein

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung 3:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter #
4
   Physikalische Adresse . . . . . . : 24-77-03-D3-FF-7D
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung 2:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter #
3
   Physikalische Adresse . . . . . . : 24-77-03-D3-FF-7D
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Ethernet-Adapter Bluetooth-Netzwerkverbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Bluetooth Device (Personal Area Network)
   Physikalische Adresse . . . . . . : 68-94-23-EA-C4-3A
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Drahtlos-LAN-Adapter Drahtlosnetzwerkverbindung:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Intel(R) Centrino(R) Ultimate-N 6300 AGN
   Physikalische Adresse . . . . . . : 24-77-03-D3-FF-7C
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   Verbindungslokale IPv6-Adresse  . : fe80::205b:6369:6260:a225%13(Bevorzugt)
   IPv4-Adresse  . . . . . . . . . . : 192.168.43.112(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Lease erhalten. . . . . . . . . . : Mittwoch, 26. Februar 2014 17:45:43
   Lease läuft ab. . . . . . . . . . : Mittwoch, 26. Februar 2014 18:45:43
   Standardgateway . . . . . . . . . : 192.168.43.1
   DHCP-Server . . . . . . . . . . . : 192.168.43.1
   DHCPv6-IAID . . . . . . . . . . . : 321156867
   DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-18-DB-BF-4E-3C-97-0E-4A-D4-B1

   DNS-Server  . . . . . . . . . . . : 192.168.43.1
   NetBIOS über TCP/IP . . . . . . . : Aktiviert

Ethernet-Adapter LAN-Verbindung:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Intel(R) 82579LM Gigabit Network Connecti
on
   Physikalische Adresse . . . . . . : 3C-97-0E-4A-D4-B1
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{AE0288E3-DF02-4541-9B80-721BF14BC7A1}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter LAN-Verbindung* 13:

   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv6-Adresse. . . . . . . . . . . : 2001:0:9d38:6abd:67:2ab:3f57:d48f(Bevorzu
gt)
   Verbindungslokale IPv6-Adresse  . : fe80::67:2ab:3f57:d48f%12(Bevorzugt)
   Standardgateway . . . . . . . . . : ::
   NetBIOS über TCP/IP . . . . . . . : Deaktiviert

Tunneladapter isatap.{764572CA-468B-46E0-9C46-4EB5293233F4}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #2
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{9A417375-7D89-42EF-8437-80F5C150731B}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #3
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{074A0C02-3100-4CEF-9C9A-F20DDAADFC77}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #4
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

Tunneladapter isatap.{F71F7168-CD1C-42CD-9661-29EF7468653E}:

   Medienstatus. . . . . . . . . . . : Medium getrennt
   Verbindungsspezifisches DNS-Suffix:
   Beschreibung. . . . . . . . . . . : Microsoft-ISATAP-Adapter #5
   Physikalische Adresse . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja

C:\Users\EDT>
 
Zuletzt bearbeitet:
  • ok1.de
  • thinkstore24.de
  • ok2.de - Notebook Computer Server
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben