# Wlan für Inbetriebnahme



## Monsignore (17 Dezember 2014)

Hi Leute

Da bei Inbetriebnahmen das Netzwerkkabel immer wieder nervt möchte ich gerne Wlan nutzen. Da jeder Kunde andere Netzwerkadressen verwendent wäre für mich interessant ob es hier eine Einstellung gibt wo der Router bzw Accespoint die sich automatisch an das Netzwerk anpasst. Reicht hier die Einstellung Adresse von DHCP beziehen oder ist das etwas komplizierter? Router bzw Accespoint habe ich noch nicht gekauft also fals ihr da noch Empfehlung habt.

Gruß
Andi


----------



## weißnix_ (17 Dezember 2014)

Ich benutze für solche Zwecke einen TP-Link 1043 unter DD-WRT.
DHCP-Server im TP-Link deaktiviert. Adresse des TP-Link passe ich immer manuell an. Die Maschine schließe ich an einem Switchport an. Dann sollte die Adresse des Routers egal sein. Dein Rechner zieht sich jetzt von einem verfügbaren DHCP-Server im Netz seine Adresse und die Kommunikation funzt, da der Router nicht routen muss.

Mit einfachen AP's hab ich schlechte Erfahrungen gemacht, weil oft nicht alle Protokolle transparent durchlaufen (ADS).

Edit: SSID des Wlan bekommt einen provokanten Namen. Router verschwindet im Schaltschrank. Wenn sich jetzt einer aufregt, weißt Du gleich noch, wer so immer mal WLAN's abscannt


----------



## ChristophD (17 Dezember 2014)

die Frage ist doch ob der Kunde zulässt das du WLAN einsetzt, er auch die notwendige Infrastruktur wie DHCP zur Verfügung stellt und ob das in jeder Umgebung auch tadellos funktioniert mit WLAN oder ob du dich dann wieder schwarz ärgerst das ständig die Verbindung abreißt.

Gruß
Christoph


----------



## Monsignore (17 Dezember 2014)

@ weißnix

das ist schnomal eine gute Lösung. Geht  es auch ohne das ich die Adresse des Routers Manuell anpasse? Bin ganz ein bequemer...

Gruß
Andi


----------



## weißnix_ (17 Dezember 2014)

Sollte funzen. Wichtig ist nur, das der Router nicht im Netzwerk mit DHCP dazwischenfunkt. Das gibt auf jeden Fall Ärger mit der IT.

Ich bin auch ein ganz fauler. Mit WLAN kann ich mich etwas aus dem unmittelbaren Maschinenbereich zurückziehen. Aber unbedingt den Hinweis von Christoph beachten. Ich bin nur im eigenen Netzwerk unterwegs und muss nicht so viele Befindlichkeiten berücksichtigen.


----------



## Ralle (17 Dezember 2014)

Ich hab einen AirportExpress von Apple als AP und daran hängt ein Netlink TCP.
Der Netlik an die SPS (wenn MPI oder DP) oder die SPS mit dem Ethernetport des AurportExpress verbunden. 
Dann hänge ich mich an den AP via WLAN und das geht mit Step7 problemlos.

Andere Kollegen nutzen z.Bsp. Dlink-AP, das funktioniert auch gut.


----------



## bike (17 Dezember 2014)

Wenn in einer Halle jeder denkt er könne sein eigenes Netz aufbauen, dann sich die Probleme schon vorprogrammiert.
Ist wirklich zuviel verlangt, ein Kabel mitbringen und das dann anschliessen?
Was ist, wenn es zu echten Problemen kommt und die Maschinen oder Anlagen zum Stillstand kommen, weil beim Umprogrammieren die Verbindung abgeschmiert ist?

Langsam finde ich Pseudowissen von über Netzwerktechnik und Faulheit schlimmer als den Dschihad, obwohl beides schei.. ist.


bike


----------



## Verpolt (17 Dezember 2014)

bike schrieb:


> ...Langsam finde ich Pseudowissen von über Netzwerktechnik und Faulheit schlimmer als den Dschihad, obwohl beides schei.. ist.bike



Was du hier so vergleichst...:shock:

Sollte man bei dir eine Gefahrenanalyse durchführen? 

Das war doch eine normale Frage (Faulheit hin oder her)
War bei Firmen als Gast, in denen mehrere WLAN-Netze in einer Halle in Betrieb sind. Jeder lustige Maschinenteil über Fernwartung zugänglich
saubere Strukturierung und Ausführung vorausgesetzt und dat Ding läuft.


----------



## Ralle (17 Dezember 2014)

bike schrieb:


> Wenn in einer Halle jeder denkt er könne sein eigenes Netz aufbauen, dann sich die Probleme schon vorprogrammiert.
> Ist wirklich zuviel verlangt, ein Kabel mitbringen und das dann anschliessen?
> Was ist, wenn es zu echten Problemen kommt und die Maschinen oder Anlagen zum Stillstand kommen, weil beim Umprogrammieren die Verbindung abgeschmiert ist?
> 
> ...



Na, na, nun übertreib mal nicht.
Vor 5 Wochen war mal ein Admin bei mir, weil er dachte mein AP würde dauernd versuchen, sich in sein Netz einzuwählen, aber er mußte einsehen, dass das Quatsch war.
Reiner AP, kein DHCP, sondern feste IP. Ich programmiere auch nicht gerade an laufenden Maschinen, die bei einem Fehler großen Schaden nehmen, dass sollte man schon abschätzen können.
Nach meiner Erfahrung sind Kabel deutlich anfälliger als WLAN, jeder, der vorbeikommt "latscht" drüber, bleibt hängen usw. Also was willst du? Wenn WLAN nicht untersagt ist, dann kann man es auf nutzen.


----------



## bike (17 Dezember 2014)

Ich habe noch nie erlebt, dass man über Kabel in falsches Netz reinkommt.
Ob es erlaubt oder verboten ist, ist Sache des Kunden.
Mir geht es einfach langsam auf den Zeiger, dass jeder Fachmann für Netzwerktechnik ist und ein eigenes Netz sich zusammenbaut.
Wer garantiert, dass es keine Probleme gibt und wer ist zuständig wenn es einmal knallt?
Meist wissen die Leute ja nicht einmal was DHCP ist und wenn zwei Router sich für  die selbe Subnet entscheiden, kann es da nicht zu Problemen kommen?

Einfach nachdenken bevor man etwas macht ist, das was sinnvoll und richtig ist.

@Ralle du hast genug Wissen und würdest auch nicht so naiv nachfragen. 


bike


----------



## Verpolt (17 Dezember 2014)

bike schrieb:


> Ich habe noch nie erlebt, dass man über Kabel in falsches Netz reinkommt.



Lies doch mal zwischen den Zeilen...

Man sitzt da dämlich vor der elektronischen Tapete und ist über KABEL mit der SPS verbunden. SPS-Download --> Hubwagenrennfahrer/Kaffeeentzugsmitarbeiter/1000gr Hammer -->Kabel rausgerissen, im Arsch, whatever.


----------



## PILZ-CS (17 Dezember 2014)

Das mit dem WLAN in Maschinen oder bei Kunden vor Ort ist immer so ne Sache.

1. Wollen viele Kunden nicht, dass WLAN in eine Maschine kommt, weil nachher treibt damit einer unfug, oder Stören das Firmeneigene WLAN, man muss sich um Updates kümmern (falls mal wieder sowas wie Heartbleed passiert)

2. Manche Kunden wollen nicht, dass man sich in ihr WLAN einwählt

3. Selbst wenn man das Kunden WLAN benutzt ist nicht gesagt dass sie auch einen DHCP am laufen haben, heisst man muss vielleicht doch wieder händisch Einstellungen vornehmen

4. Früher oder später braucht man Strom, dann hängt man eh wieder an einer Strippe

5. Wenn etwas nicht richtig funktioniert weiß man nie ob gerade nur die WLAN Verbindung gestört ist oder ob es ein richtiger Fehler ist

Alles in allem haben wir schon die Erfahrung gemacht dass WLAN eher störend ist als dass es nutzen bringt, darum wird einfach ein Kabel eingestöpselt und man ist auf der sicheren Seite.
Was die Konfiguration des LANs an geht, hier haben sich auf den IBNs immer die Tools NetSetMan und NetProfiles als sehr hilfreich erwiesen.


----------



## bike (17 Dezember 2014)

Verpolt schrieb:


> Lies doch mal zwischen den Zeilen...
> 
> Man sitzt da dämlich vor der elektronischen Tapete und ist über KABEL mit der SPS verbunden. SPS-Download --> Hubwagenrennfahrer/Kaffeeentzugsmitarbeiter/1000gr Hammer -->Kabel rausgerissen, im Arsch, whatever.



Danke, dass du mir aufklärst.
Ich bin ja so neu auf dem Gebiet der Programmierung und Vernetzung  und freue mich, dass du so kompetent mich informierst.


bike


----------



## Ralle (17 Dezember 2014)

Ich empfinde das WLAN an der Maschine (nur zur IBN) als Vorteil.
Ich kann z.Bsp. auf der anderen Seite der Maschine etwas prüfen, den Laptop dabei, HMI dabei, kein Kabel, alles gut.
Früher hab ich an Anlagen mitprogrammiert, die eine ganze Halle füllten. Da hatten wir 50 oder 100 m Programmierkabel, k.A. wie oft da wer rüberfuhr, bis es wieder mal geflickt werden mußte.
Von den Dreckhänden nach dem Aufwickeln mal ganz abgesehen. 
Aber klar, wenn der Kunde das nicht zuläßt, dann stecke ich auch einfach wieder ein Kabel und fertig.

PS: Wenn ein Verbindungsabbruch zur Gefahr wird, dann ist eh was faul und man muß sich mehr Gedanken machen, um auf Nummer Sicher zu gehen.


----------



## Verpolt (17 Dezember 2014)

bike schrieb:


> Danke, dass du mir aufklärst.
> Ich bin ja so neu auf dem Gebiet der Programmierung und Vernetzung  und freue mich, dass du so kompetent mich informierst.
> bike



Bitte sehr.... das du mir bedankst und kompetent mich informierst.


----------



## bike (17 Dezember 2014)

Ralle ich denke wir wissen wovon wir schreiben.
Ich schieb bzw würde nie etwas gegen jemanden sagen / schreiben, der weiß was er tut.
Doch wenn Fertigungslinien in Betrieb genommen werden und drei Techniker die selben IP Adressen verwenden und es dann zu Problemen kommt, dann läuft doch etwas fasch.
Die sollen zuerst sich das notwendige Wissen aneignen.
Darum geht es zuerst meine ich


bike


----------



## weißnix_ (17 Dezember 2014)

@bike: Ich find ja immer Klasse, wie Du gleich mit Volldampf gegen alle (notfalls allein gegen die Welt) vorprescht.

Na klar muss der Inbetriebnehmer/Programmierer wissen was er tut. Im kleinen und überschaubaren Rahmen halte ich die Vorgehensweise mit dem WLAN für extrem hilfreich. Insbesondere wenn es prinzipiell um die Prozessbeobachtung/Fehlersuche/Optimierung im laufenden Betrieb geht. Hier kommen nämlich alle oben genannten Fälle bezüglich Kabelproblemen dazu multipliziert mit einem Programmierer der egal im Weg sitzt.

Im übrigen ging es weniger um richtig oder falsch sondern um MÖGLICH und SINNVOLL.

So: jetzt schlag zu


----------



## weißnix_ (17 Dezember 2014)

PILZ-CS schrieb:


> Das mit dem WLAN in Maschinen oder bei Kunden vor Ort ist immer so ne Sache.
> 
> 1. Wollen viele Kunden nicht, dass WLAN in eine Maschine kommt, weil nachher treibt damit einer unfug, oder Stören das Firmeneigene WLAN, man muss sich um Updates kümmern (falls mal wieder sowas wie Heartbleed passiert)



Wer hat denn gesagt, das das WLAN ausserhalb der Inbetriebnahmetätigkeit in der Maschine verbleibt. Wenn ich mein WLAN mitbringe, dann stelle ich auch sicher, das sich ausser mir kein ungebetener Gast einwählt. Auch bei einer IBN habe ich nur verschlüsseltes WLAN im Einsatz. Ich halte es doch für wenig Wahrscheinlich, das sich ausgerechnet in diesem Augenblick noch ein Hobbycracker in WLAN-Reichweite aufhält.
Wie ich schon schreibselte, bei mir ist das Ding dann im (tempoär) Schaltschrank versteckt. Das schränkt die Reichweite schon stark ein.


----------



## Monsignore (18 Dezember 2014)

Ich möchte das Wlan auch nur in der ersetn Phase der IB nutzen. Das heist zum Signalcheck bzw Sensoren und Aktoren test. Und da ich bei diesem Test oft weiter herum muss möchte ich mir einfach Zeit und Aufwand sparen und in einen guten Wlan Router investieren. Jedoch wird das nicht ganz so einfach...


----------



## ChristophD (18 Dezember 2014)

Hi,

hier mal ne Doku zu dem Thema iWLAN von SIEMENS : http://support.automation.siemens.com/WW/view/de/90880063
Die Scalance W wären die WLAN Lösung von Siemens, kosten dann aber auch entsprechend, wobei im idustriellen Umfeld vermutlich besser geeignet als ein Standard Router.

Gruß
Christoph


----------



## MSB (18 Dezember 2014)

PILZ-CS schrieb:


> 1. Wollen viele Kunden nicht, dass WLAN in eine Maschine kommt, weil nachher treibt damit einer unfug, oder Stören das Firmeneigene WLAN, man muss sich um Updates kümmern (falls mal wieder sowas wie Heartbleed passiert)
> 
> 2. Manche Kunden wollen nicht, dass man sich in ihr WLAN einwählt
> 
> ...


Solch ein Beitrag von einem höchst offiziellen Support ist schon fast schmerzhaft ...

1. Geht es hier um temporäre Anwesenheit vor Ort
2. Das Kunden WLAN (so vorhanden) wird dann schon entsprechend geschützt sein, falls nicht ... dann werden die kaum was dagegen haben können wenn das Scheunentor genutzt wird
3. Ich kann hier jetzt formal keinerlei Unterschied zum Kabelgebundenen Netz des Kunden entdecken (Auch hier muss abgeklärt werden falls das Netz mit ohne DHCP ist, welche IP verwendet werden darf)
3.a. Zu klären wäre auch ob die Maschinensteuerung überhaupt eine Verbindung zum übergeordneten Netz des Kunden hat, weil viele Maschinen haben lediglich ein höchst internes Profinet-Netzwerk (bzw. andere Ethernet-Feldbusse)
4. LaptopAkkus halten allesamt Stunden ... ist also sicherlich kein schnelles Problem
5. Man weiß aber auch nicht ob jetzt gerade irgendwer sein Füße nicht unter Kontrolle hatte und über das Kabel gestolpert ist.

Und jetzt noch eine Anekdote meiner Karriere:
Ich war über Profibus an ner Siemens-CPU (315-2DP -2AG10-), Baustein Beobachten war Aktiv, dann stolpert wer mit großen Füßen übers Kabel ... CPU schmiert ab, Status defekt. (Lief zum Glück nach Spannung weg/dran wieder). Soviel zum Thema Kabel wär sicherer.

Mfg
Manuel


----------



## Krumnix (18 Dezember 2014)

WLAN zur IBN oder Fehlersuche ist ne feine Sache. Aber viele Kunden lehnen das ab, da sie oft Angst um ihr eigenes WLAN haben oder der Meinung sind, das man sich damit was einfängt.
Weiterhin ist natürlich die Qualität einer WLAN-Verbindung zu kabelbezogene Verbindung auch unterschiedlich. Das wissen wir alle. Die eine hat hier Nachteile, die andere da, etc.

Wenn WLAN durch den Kunden nicht verboten ist, sollte man aber diese Möglichkeit zur Unterstützung der IBN nutzen. Wenn es nun so ist, das viele auf der Baustelle der gleichen
Meinung sind, und 10 APs aufgebaut sind, dann habe ich mir immer einen Laptop in den Schaltschrank mit Kabel-Verbindung an die SPS gelegt. Im Laptop dann die Einstellungen so
vergenommen, das dieser WLAN-Verbindungen ohne AP möglich macht. Einen 2. Laptop genommen, die Verbindung zu dem Laptop im Schrank aufgebaut und per Remote auf die
Bedienoberfläche auf dem Laptop im Schrank zugegriffen. 
Wenn nun die Verbindung zusammenbricht, ist nur die Remote-Verbindung weg, alles andere vom PG zur SPS bleibt bestehn. Wenn es dann "schnell" gehen muss, kann man 
immer noch zu dem Laptop im Schaltschrank laufen und dort weitermachen.

Es gibt auch die Möglichkeit diese Verbindung mit Bluetooth umzusetzen. Müssen nur beide Teilnehmer Bluetooth haben und jeweils das Programm für Bluetooth-Remote installieren.
Ist aber nach 4-6m Schluss mit Lustig


----------



## RONIN (20 Februar 2017)

Kann mit jemand ne Empfehlung für nen WLAN-Router machen der bei TIA auch die für die Teilnehmersuche erforderlichen Protokolle (LLDP, etc.) durchroutet.
Mein jetziger, so praktisch der auch ist, ermöglicht eben keine Teilnehmersuche, was bei TIA lästig ist. Irgendwas kompaktes, braucht keine übertriebene Reichweite.


----------



## Fabpicard (21 Februar 2017)

Naja, einer von den runden Klötzchen der UniFi-Reihe sollte das vermutlich können:
https://www.ubnt.com/products/#unifi

Ansonsten, wenn auch Softwareseitig "ein wenig" mit Kannonen auf Spatzen geschossen, einen von denen 3en (je nach Geld und 2,4/5GHz Vorlieben):
http://www.mikrotik-shop.de/End-of-Life/MikroTik-hAP-lite-RB941-2nD::1162.html (25€)
http://www.mikrotik-shop.de/Complete-Systems/MikroTik-hAP-RB951Ui-2nD::1246.html (48€)
http://www.mikrotik-shop.de/Complete-Systems/MikroTik-HAP-ac-lite-Dualband-RB952Ui-5ac2nD::1365.html (53€)

Die Mikrotik können das garantiert, denn die können quasi ALLES 
(Die Software hat den ziemlich gleichen Funktionsumfang wie die Core-Router von Juniper die im DE-CIX in Frankfurt stehen...)
[Allerdings wirst du bei der Ersteinrichtung dir etwas Zeit nehmen müssen, damit du mit den ganzen Funktionen klar kommst    ]

MfG Fabsi


----------



## weißnix_ (21 Februar 2017)

Ich hab für solche Zwecke einen TP-Link 1043ND mit dd-wrt. Der blockt im Gegensatz zur Original-FW erst mal garnix. Allerdings hab ich das mit Siemens noch nicht probiert.


----------



## RONIN (21 Februar 2017)

@Fabpicard: Ja die beiden Marken hatte ich auch am Radar da ich nen Vertreter hab welcher die vertreibt. Wollte mal Fragen was im Einsatz ist und wo man weiß dass das LLDP durchgeht.
@weißnix_: Firmware ändern ist ein Ansatz, wäre mir aber zu umständlich.


----------



## Fabpicard (21 Februar 2017)

Scheinbar sind bei Ubiquiti wenn nur die großen (>250€) zum vollen Support in der Lage 

Bevor du dir aber umständlich auf einen TP-Link ein OpenWRT drauf setzt, was nach Modell wieder gewissen HW-Stände voraussetzt, rate ich die einem Mikrotik-Teil auf dem direkt RouterOS drauf ist 

Und zu "In Verwendung": Ich hab bei uns die kleinen ohne WLan im Einsatz um Maschinen die hinter so doofen VPN-Routern "eingesperrt sind" und nicht demontiert werden können, doch noch im Firmennetz zu haben   Klappt wunderbar, ohne jegliche Einschränkungen.

MfG Fabsi


----------



## RONIN (26 Februar 2017)

Hallo,

Ich hatte jetzt über das WE die Zeit meinem Problem nachzugehen warum ich keine Teilnehmer über WLAN finde.
Zuerst habe ich mal einen anderen Router probiert (OpenWRT) aber das brachte auch keine Verbesserung, egal was ich an dem Ding eingestellt hatte.

Da ich nicht weiter kam hab ich den Wireshark runtergeldaden und meine ersten Gehversuche damit probiert.
Hab das Problem auch anscheinend gefunden, mein WLAN-Adapter tauscht die Packet-Source des "Request"-Packets aus welches von TIA gesendet wird.
Mein LAN-Adapter tut dies nicht. Genaueres wie folgt....

Aufbau: Mein PG(Win10) mit VMware(Win7) und TIA ist entweder per LAN/Kabel oder über den WLAN-Router mit einer Test-1512 verbunden.
Die VM ist eingestellt auf Bridged und "Replicate physical network state" auf den jeweiligen Adpter.

Als erstes hab ich mir die Pakete mal aus der VM heraus angeschaut. Wireshark in der VM und Verbindung via LAN-Kabel. Da geht das Teilnehmer suchen.



Danach habe ich einen anderen PC ins Netzwerk gehängt und mal dort geschaut. Wie erwartet, alles gleich.



Dann hab ich mein PG mit der VM auf WLAN umgebaut und den zweiten PC verwendet um zuzuschauen wie die Pakete aus dem WLAN-Router rauskommen.
Ab hier wird es dann interessant. Das "Ident-Req"-Paket geht problemlos durch den Router durch, aber es kommt mit einer anderen Source heraus.


Es ist aber nicht so dass die geänderte Source die MAC-Adresse des WLAN-Routers hätte, es ist die des phys. WLAN-Adapters des PG.
Beim Weg über Kabel-LAN bleibt die Source unverändert.

Dann habe ich mir noch angeschaut wo die Änderung passiert, anscheinend nicht im Router sondern am PG.
Das folgende Capture läuft am Host-System (Win10) des PG und zeigt dass der WLAN-Adapter die Pakete schon mit der WLAN-MAC als Source raus-sendet. Wie kann das sein?



Wie man sieht wird beim Weg "TIA->VMware-VirtualAdapter->phys.-WLAN-Adapter" die Packet-Source ersetzt. Beim Weg "TIA->VMware-VirtualAdpater->phys.LAN-Adapter" aber nicht.
Ich hab jetzt nur bloß keinen Schimmer woran das liegen könnte. Ist das überhaupt mein Problem?

Hat da irgendjemand Ideen? Bin für jeden Tipp dankbar.


----------



## Fabpicard (27 Februar 2017)

Na das ist ganz logisch, denn bei deinem LAN-Kabel kann am Host die Netzwerkkarte in den "promiscuous mode" geschaltet werden.
vgl.: https://de.wikipedia.org/wiki/Promiskuitiver_Modus

Bei der WLan-Karte geht das nicht wirklich, da hier ja der Host der Karte sagt, mit welchem WLan (SSID) und welcher Authentifizierung sich die Karte verknüpfen soll.
Somit, würde die VM eine extra MAC auf der WLan-Karte nutzen, würde der AP in etwa folgendes sagen "Du? Du kommst hier nicht rein, dich kenn ich ja nicht"

Will man einen VM-Guest, korrekt ins WLan hängen, gibt es dafür mehrere funktionierende Möglichkeiten. (Die ihrerseits mehr oder weniger Windumm als Host unbrauchbar machen  )

Die einfachste: Nimm einen WLan-USB-Nano-Stick, der trägt nicht wirklich dick auf und stelle über den Host diesen dem Guest-System zur Verfügung, damit der seine eigene WLan-Verbindung aufbauen kann...

Alles andere wird komplizierter und ich weis ehrlich gesagt auch nicht, wie man eine Windoof-Host die passenden Tricks dazu beiprügelt, weil mir vieeeel zu Aufwändig das erst mal herauszufinden 
(Mit einem Linux/Unix-Host hast du da schon ganz andere Möglichkeiten, ins Routing einzugreifen und alle möglichen asozialen und IT-Feindlichen (u.a.D/S-NAT-Volltransparent) Schweinereien anzustellen)

MfG Fabsi


----------



## RONIN (27 Februar 2017)

Super, Danke.

Das scheint wirklich das Problem zu sein. So wie du das beschreibst macht das auch durchaus Sinn.
Ich hab heute ein altes PG ausgegraben an dem TIA lokal installiert ist, siehe da, das "Teilnehmer suchen" geht ohne Probleme.

Ich muss das noch mit nem billigeren AP testen ob der verwendete AP nun wirklich egal ist und das Problem wirklich nur die VM war.
Die Idee mit dem Nano-Stick ist auch gut. Die Dinger stören wirklich nicht und die VM hat die NIC für sich.

Ich frage mich nun eher folgendes.. Bin ich der einzige mit dem Problem? Es gibt ja auch andere die VMware einsetzen, da müsste doch der Eine oder Andere schon vor dem selben Problem gestanden sein.


----------



## ChristophD (27 Februar 2017)

Hi,

auf das problem trifft man nur wenn man VMWare + WLAN + ungetaufte Geräte zusammentreffen lässt.
WLAN ist schon selten genug um dieses Problem an vielen Fronten gar nicht auftreten zu lassen.


----------



## RONIN (27 Februar 2017)

Verstehe schon was du meinst. Hast auch Recht.
TIA in VM sollte aber nicht sooo selten sein, auch WLAN auf IBN is nicht besonders High-Tech...

Es sind aber nicht nur die ungetauften Geräte. Über VM-WLAN finde ich gar keine Teilnehmer, auch die nicht die schon getauft sind. Das hieß bis jetzt immer "IP eingeben" wann auch immer mal ein "Erweitert Verbinden"-, "Erweitert Online Laden"-Dialog daherkam. Besonders oft in Verbindung mit Panels und "IP-Adresse auf dem Gerät einstellen". Also sehr oft. Der Suchvorgang nach der Eingabe der IP dauert auch deutlich länger als wenn man den Teilnehmer gleich findet. 

Für mich ist das bis jetzt extrem lästig weil ich mich auf IBN ständig zwischen WLAN-Freiheit und Kabel-Ankettung (dafür schneller und alles geht) entscheiden musste.


----------



## RONIN (28 Februar 2017)

Jo, mit dem Nano-Adapter direkt für die VM geht das Teilnehmer suchen auch über jeden x-beliebigen WLAN-AP den ich rumliegen hatte.
Lange herumgeärgert obwohl die Lösung doch recht einfach war. Danke nochmal @fabpicard.


----------



## logo78 (15 Juli 2018)

RONIN schrieb:


> Super, Danke.
> Ich frage mich nun eher folgendes.. Bin ich der einzige mit dem Problem? Es gibt ja auch andere die VMware einsetzen, da müsste doch der Eine oder Andere schon vor dem selben Problem gestanden sein.


Hi,
bin nun auch darüber gestoßen und musste mich fragen, warum eigentlich so wenig Leute damit ein Problem hatten 
WiFi-Stick ist OK, gibt es eine SW-Möglichkeit VMWare Workstation, bzw Win10 den 'promiscuous' modus für die WiFi Karte beizubringen?

Thx..


----------



## Fabpicard (17 Juli 2018)

logo78 schrieb:


> WiFi-Stick ist OK, gibt es eine SW-Möglichkeit VMWare Workstation, bzw Win10 den 'promiscuous' modus für die WiFi Karte beizubringen?



Das Hauptproblem ist schon einmal die physikalische Grundlage auf denen Kabel-gebundenes Netzwerk und WLan arbeiten.
Beim Kabel "handeln" die Karte und der Switch (die Gegenstelle) untereinander selbständig aus, wer wann Pakete schickt um Kollisionen zu vermeiden.
Greifen jetzt 2 "Programme" (also Host und Guest) auf die Netzwerkkarte zu, geht das dort in den Cache und wir von der Karte selbst entsprechend obiger Regel verarbeitet...

Beim WLan ist der AP der, der eben die Ansagen macht, wer wann was funken darf... Bist du mit deinem Rechner nur der Client, hat sich deine WLan-Karte eben an die Vorgaben vom AP zu halten. Würde jetzt der Guest der WLan-Karte sagen wollen, das diese noch zusätzlich etwas anderes machen soll, bekommt eben diese Karte ein Problem mit den APs, die hier die Ansagen machen...

Es gibt eine Möglichkeit, mit einer WLan-Karte gleichzeitig zu mehr als einem AP eine Verbindung aufzubauen... Aber, mehr wie ein wenig "Research" und spielereien wirst du hier nicht finden (https://www.microsoft.com/en-us/res...ch.microsoft.com/netres/projects/virtualwifi/)
Und das bezieht sich alles noch darauf, das der Host selbst die WLan-Karte vollständig verwaltet und eine Software zwischen 2 "Zugriffen" auf die virtuellen Karten verwaltet.
Da das nicht wirklich optimal ist und in Zeiten von Wlan-AC/MU-MIMO usw. immer schlechter klappt, hat auch keiner angefangen das noch für den Zugriff einer VM aufzubohren 

MfG Fabsi


----------

