Forum: PC Hard- und Software Keine DHCP-Adressvergabe in VM an WLAN-AP


von Reinhard S. (rezz)


Lesenswert?

Hallo zusammen,

hier mal ein kurioses Problem.

Ich hab hier auf einem Linux-Laptop (Mint 19.2) eine VM mit Windows 7 
laufen, mit "Bridged"-Netzwerk, sprich die VM bekommt genauso eine IP 
via DHCP wie das Linux. Direkt im WLAN & LAN der FritzBox 4040 (die auch 
DHCP macht) funktioniert das auch alles.

Nun hab ich mir aber mal wieder testhalber einen AP an die FritzBox 
gehängt (via LAN), einen alten Funkwerk wi2065n. Dort via WLAN 
eingebucht bekommt zwar mein Linux via DHCP eine IP, nicht aber die VM. 
Die rennt da in einen Timeout und gibt sich dann selbst eine 169.254...

Stell ich die IP in der VM dann manuell auf eine passende IP 
funktioniert alles, es scheitert also nur am DHCP.

Was könnte da der Fehler sein? Timingprobleme? Die Logs vom wi2065n 
geben dazu genau gar nichts her.

: Bearbeitet durch User
von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Reinhard S. schrieb:
> Nun hab ich mir aber mal wieder testhalber einen AP an die FritzBox
> gehängt (via LAN), einen alten Funkwerk wi2065n. Dort via WLAN
> eingebucht bekommt zwar mein Linux via DHCP eine IP, nicht aber die VM.

Die VM wird beim AP mit der MAC wie der Host ankommen und der AP wird 
somit verhindern, dass dasselbe Gerät noch eine zweite IP zugeteilt 
bekommt.

Ich verwende bei sowas eigentlich den Host als NAT und jede VM bekommt 
eine interne IP zugeteilt. Nach außen hin tritt nur der Host in 
Erscheinung. So gibt es auch leine probleme bei mehreren VM die 
gleichzeitig laufen und diese können so auch untereinander kommunizieren 
ohne auf dem Netzwerk nach außen in erscheinung zu treten.

von (prx) A. K. (prx)


Lesenswert?

Irgend W. schrieb:
> Die VM wird beim AP mit der MAC wie der Host ankommen und der AP wird
> somit verhindern, dass dasselbe Gerät noch eine zweite IP zugeteilt
> bekommt.

Üblicherweise erhält jeder virtuelle Ethernet-Adapter jeder VM eine 
separate MAC-Adresse. Sonst wärs ja unmöglich, damit zu netzwerken.

: Bearbeitet durch User
von (prx) A. K. (prx)


Lesenswert?

Reinhard S. schrieb:
> wi2065n

Dessen Datasheet legt nahe, der könne recht viel, nicht nur einfachen 
Bridge-Betrieb, sondern auch DHCP-Server, Routing etc. Wie ist der bei 
dir konfiguriert?

von Manfred (Gast)


Lesenswert?

Reinhard S. schrieb:
> Was könnte da der Fehler sein? Timingprobleme? Die Logs vom wi2065n
> geben dazu genau gar nichts her.

Steht der transparent auf bridging oder macht er selbst DHCP?

Auf den AP müsste ein bintec-BOSS laufen. Dort die debug-Ausgabe auf 
"all" setzen und per UDP auf Port 514 per syslog ausgeben lassen, 
liefert alles, was das Ding macht. Aufzeichnen lässt sich das mit einem 
syslog-client, der ist in den DIME-Tools enthalten.

von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

(prx) A. K. schrieb:
> Üblicherweise erhält jeder virtuelle Ethernet-Adapter jeder VM eine
> separate MAC-Adresse.

Das ja, aber die ist nur intern in der VM und dem Host sichtbar und 
nicht auf der NIC des Host nach außen hin. Diese NIC nimmt dafür ihre 
eigene MAC zur Kommunikation übers LAN. Wenn man sowas real separat will 
und nicht nur virtuell kenne ich das nur das man auch entsprechend viele 
phys. NIC in den Host einbaut und diese dann exklusiv den einzelne VM 
zuordnet. Kenn das von Servern wo extra vier Karten zu je vier Ports 
zusätzlich zu denen für Management und Host verbaut sind um darüber die 
VM anzubinden. Und diese ggf. noch an unterschiedlichen Hub/Routern/VPN 
usw.

von (prx) A. K. (prx)


Lesenswert?

Irgend W. schrieb:
> Das ja, aber die ist nur intern in der VM und dem Host sichtbar und
> nicht auf der NIC des Host nach außen hin.

Wenn ein Hypervisor VMs im Bridging-Mode unterstützt, dann muss diese 
MAC auch im LAN sichtbar sein. Für VMware Workstation+ESXi kann ich das 
auch bestätigen, ebenso für VirtualBox.

Falls dich das irritiert: Die Netzwerkkarte muss das natürlich können, 
aber das ist durchaus üblich. Das war schon in der LAN-Frühzeit bei Koax 
und Software-Bridges nötig, nicht erst heute. 
https://en.m.wikipedia.org/wiki/Promiscuous_mode

> Wenn man sowas real separat will und nicht nur virtuell kenne ich das
> nur das man auch entsprechend viele phys. NIC in den Host einbaut

100 Ethernet Ports in einem 1HE Virtualisierungshost, eine pro VM, das 
wäre schon rein kabeltechnisch ein bizarrer Anblick. ;-)

: Bearbeitet durch User
von Reinhard S. (rezz)


Lesenswert?

(prx) A. K. schrieb:
> Reinhard S. schrieb:
>> wi2065n
>
> Dessen Datasheet legt nahe, der könne recht viel, nicht nur einfachen
> Bridge-Betrieb, sondern auch DHCP-Server, Routing etc. Wie ist der bei
> dir konfiguriert?

Simpler AP. DHCP macht weiterhin die FritzBox.

von c-hater (Gast)


Lesenswert?

(prx) A. K. schrieb:

> Üblicherweise erhält jeder virtuelle Ethernet-Adapter jeder VM eine
> separate MAC-Adresse. Sonst wärs ja unmöglich, damit zu netzwerken.

Das hängt von der Konfiguration des virtuellen Netzwerks ab. Es ist 
definitiv möglich, eine VM unter der MAC-Flagge des Host-Adapters segeln 
zu lassen. Macht nur in allen üblichen Anwendungen keinen Sinn, wie du 
richtig angemerkt hast.

Und sowas kann hier auch nicht das Problem sein, da DHCP ja ohne diese 
Funkwerk-Teil funktioniert, wie es sollte.

Ich würde jedenfalls defintiv einfach auf dem Host der VM Wireshark 
laufen lassen, da sieht man dann schon, was das Problem ist.

Übrigens hatte ich in meinem Leben erst ein einziges Mal mit 
Funkwerk-Produkten zu tun. Und ich kann nicht behaupten, dass die mich 
damals überzeugt hätten. Für die geringe Zahl Features waren die Dinger 
unwahrscheinlich schwierig zu konfigurieren. Das ist, woran ich mich 
erinnere.

von Reinhard S. (rezz)


Lesenswert?

c-hater schrieb:
> Übrigens hatte ich in meinem Leben erst ein einziges Mal mit
> Funkwerk-Produkten zu tun. Und ich kann nicht behaupten, dass die mich
> damals überzeugt hätten. Für die geringe Zahl Features waren die Dinger
> unwahrscheinlich schwierig zu konfigurieren. Das ist, woran ich mich
> erinnere.

Die sind ja vor einiger Zeit via Teldat in bintec-elmeg aufgegangen und 
deren aktuelles Produkt be.IP scheint nicht völlig schlecht zu sein.

Die Konfig meines wi2065n ist aber in der Tat etwas gewöhnungsbedürftig, 
andererseits komm ich halt auch von FritzBoxen...

Zum Thema: Ich hab in einem ersten Versuch bei mir einen Syslog-Server 
installiert (bzw. den vorhandenen übers Netzwerk erreichbar gemacht), 
aber das hat noch nicht so wirklich den Durchbruch gebracht. Ist aber 
auch nicht so einfach, zwischen den Meldungen des eigenen Systems und 
denen vom wi2065n die Übersicht zu behalten.

von Manfred (Gast)


Lesenswert?

c-hater schrieb:
> Übrigens hatte ich in meinem Leben erst ein einziges Mal mit
> Funkwerk-Produkten zu tun. Und ich kann nicht behaupten, dass die mich
> damals überzeugt hätten. Für die geringe Zahl Features waren die Dinger
> unwahrscheinlich schwierig zu konfigurieren.

Die Router und Accesspoints können deutlich mehr als der übliche 
Heimwerkerkram. Von wegen "schwierig zu konfigurieren" sagt mir der 
IT-Mann, dass sie noch zu den einfacheren gehören, im Vergleich zu z.B. 
Cisco.

Ich nuß aber zugeben, dass ich zu Anfang Unterstützung von bintec hatte, 
sonst wäre ich da wohl auch dran verzweifelt.

Das sind eben keine Fritzchen und können erheblich mehr, die adressieren 
einen anderen Markt.

Reinhard S. schrieb:
> Die sind ja vor einiger Zeit via Teldat in bintec-elmeg aufgegangen und
> deren aktuelles Produkt be.IP scheint nicht völlig schlecht zu sein.

Hier läuft eine be.IP plus und führt mehrere Netze samt Routingregeln. 
Leider haben sie die setup-Funktion per Telent oder Konsole entfernt, 
das Webinterface ist an vielen Stellen unlogisch strukturiert.

> Die Konfig meines wi2065n ist aber in der Tat etwas gewöhnungsbedürftig,
> andererseits komm ich halt auch von FritzBoxen...

Nach vielen Jahren bintec- / Funkwerk-Router kam hier eine Fritz!7560 
an, weil der vorhandene kein VDSL kann. Da fehlt ja so ziemlich alles, 
was für ein richtiges Netzwerk notwendig ist. Wurde nach ein paar Tagen 
ins Regal gelegt, nachdem bintec-elmeg geliefert hat.

> Zum Thema: Ich hab in einem ersten Versuch bei mir einen Syslog-Server
> installiert (bzw. den vorhandenen übers Netzwerk erreichbar gemacht),
> aber das hat noch nicht so wirklich den Durchbruch gebracht. Ist aber
> auch nicht so einfach, zwischen den Meldungen des eigenen Systems und
> denen vom wi2065n die Übersicht zu behalten.

Den 2065 kenne ich nicht, er läuft aber offenbar mit der gleichen 
Software wie z.B. der W1002n, den ich hier habe. Fasse das Ding per 
Telnet an, oder besser noch mit einer Terminalsoftware per RS232. Nach 
Anmeldung "setup", da sollte es ein simples Menü geben.

Dort lässt sich Syslog auf einen beliebigen Port setzen, dann zeigt der 
Syslog-Server nur die AP-Meldungen. Syslog schicke ich hier per UDP an 
192.168.177.255, damit kann jeder PC im .177 die Meldungen sehen.

Ich befürchte allerdings, dass Du nichts shen wirst, weil das Problem in 
Deiner VM-Konfiguration liegen dürfte.

von Reinhard S. (rezz)


Lesenswert?

Manfred schrieb:
> Ich befürchte allerdings, dass Du nichts shen wirst, weil das Problem in
> Deiner VM-Konfiguration liegen dürfte.

Weil? Die VM macht ein VMware Workstation 15 Player.

von c-hater (Gast)


Lesenswert?

Reinhard S. schrieb:

> Zum Thema: Ich hab in einem ersten Versuch bei mir einen Syslog-Server
> installiert (bzw. den vorhandenen übers Netzwerk erreichbar gemacht),
> aber das hat noch nicht so wirklich den Durchbruch gebracht. Ist aber
> auch nicht so einfach, zwischen den Meldungen des eigenen Systems und
> denen vom wi2065n die Übersicht zu behalten.

Wie schon gesagt: Warum läßt du nicht erst mal einfach Wireshark auf dem 
Host der VM laufen, um zu sehen, was tatsächlich passiert?

Ohne diese Information nützt doch das syslog herzlich wenig, denn das 
ist naturgemäß sehr unvollständig. Kein Mensch läßt jedes verschissene 
Paket im syslog aufschlagen, da wäre ja der Log-Traffic weitaus fetter 
als der Payload Netzes.

von c-hater (Gast)


Lesenswert?

c-hater schrieb:

> als der Payload Netzes.

des Netzes.

sollte das heißen.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.