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
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.
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
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?
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.
(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.
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
(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.
(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.
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.
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.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.