51
Täglicher Netzwerkausfall
Hallo zusammen,
ich habe folgendes Problem:
Wir betreiben ein WLAN in unserem Lager. Dort sind AccessPoints von Cisco installiert. Diese werden mittels PoE mit Strom und Daten versorgt. Das WLAN wird durch unsere MDEs (Datalogic Kyman) genutzt.
Nun haben wir seit geraumer Zeit das Problem, dass täglich um ca. 13 Uhr das WLAN zusammenbricht. Die MDEs verlieren die WLAN Verbindung. Nach ca. 2 - 5 Minuten ist die Verbindung wieder da. Das Netzwerk ist an unserem Serverraum via Glasfaser angebunden. Wir benutzen nicht managebare Switche von Netgear.
Was ich bisher getan habe:
1. Switche getauscht
2. Medienkonverter für Glasfaser / Ethernet getauscht
3. USV für Switche eingebaut
So allmählich weiß ich nicht mehr weiter, woran das noch liegen kann. Habt ihr Ideen bzw. Anregungen wie wir dem Fehler auf die Spur kommen?
Viele Grüße
Torsten
ich habe folgendes Problem:
Wir betreiben ein WLAN in unserem Lager. Dort sind AccessPoints von Cisco installiert. Diese werden mittels PoE mit Strom und Daten versorgt. Das WLAN wird durch unsere MDEs (Datalogic Kyman) genutzt.
Nun haben wir seit geraumer Zeit das Problem, dass täglich um ca. 13 Uhr das WLAN zusammenbricht. Die MDEs verlieren die WLAN Verbindung. Nach ca. 2 - 5 Minuten ist die Verbindung wieder da. Das Netzwerk ist an unserem Serverraum via Glasfaser angebunden. Wir benutzen nicht managebare Switche von Netgear.
Was ich bisher getan habe:
1. Switche getauscht
2. Medienkonverter für Glasfaser / Ethernet getauscht
3. USV für Switche eingebaut
So allmählich weiß ich nicht mehr weiter, woran das noch liegen kann. Habt ihr Ideen bzw. Anregungen wie wir dem Fehler auf die Spur kommen?
Viele Grüße
Torsten
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 241581
Url: https://administrator.de/contentid/241581
Ausgedruckt am: 22.11.2024 um 11:11 Uhr
51 Kommentare
Neuester Kommentar
Hi torte79,
passiert das auch bei normalen WLAN Clients oder nur bei den MDE's?
Ist überall die aktuellste Firmware installiert?
Was zeigen die Logs der AP's? und Welche AP's sind es?
Gruß
passiert das auch bei normalen WLAN Clients oder nur bei den MDE's?
Ist überall die aktuellste Firmware installiert?
Was zeigen die Logs der AP's? und Welche AP's sind es?
Gruß
Hallo,
was sagt das Logfile von Cisco?
Gruß
MksMlr
was sagt das Logfile von Cisco?
Gruß
MksMlr
Hallo,
was für ein Modell ist der AP von Cisco?
Was mir eventuell in den Sinn kommt, wäre das die Geräte vll. zu warm werden.
Gruß
Max
was für ein Modell ist der AP von Cisco?
Was mir eventuell in den Sinn kommt, wäre das die Geräte vll. zu warm werden.
Gruß
Max
13:00 = mittag --> Mikrowelle ?? 
2
3. USV für Switche eingebaut
Hängen da nur die Switche dran oder auch die APs? Evtl. passiert irgendwas nach (?) der Mittagspause was eine Spannungsspitze hervorruft und die APs durcheinander bringt. Dazu müsstest du aber was in den Logs der APs finden wie schon mehrfach angesprochen.
Ansonsten würde mir vielleicht noch ein geplanter Reboot der APs einfallen. Vielleicht wollte den jemand auf 01:00 legen und hat aber AM/PM verwechselt.
Wenn es ja immer ungefähr zur gleichen Zeit passiert wäre ich um die Zeit mal mit meinem Notebook oder Smartphone vor Ort um per WLAN-Scanner zu beobachten was das WLAN dann genau macht.
Tach auch
Kannst du schon eingrenzen ob es nur die AP´s sind welche nicht erreichbar sind oder nur die Scanner?
Wir hatten einen ähnlichen Fall. Zu bestimmten Zeiten brach Das Wlan zu den Scannern ab. Schuld war ein Gabelstapler mit einer WLAN
Kamera on-board. Der störte das Signal so extrem. Das Wlan war nur aktiv solange die Kamera lief.
Mfg
-s-v-o-
Kannst du schon eingrenzen ob es nur die AP´s sind welche nicht erreichbar sind oder nur die Scanner?
Wir hatten einen ähnlichen Fall. Zu bestimmten Zeiten brach Das Wlan zu den Scannern ab. Schuld war ein Gabelstapler mit einer WLAN
Kamera on-board. Der störte das Signal so extrem. Das Wlan war nur aktiv solange die Kamera lief.
Mfg
-s-v-o-
Hallo,
Wie viele?
Gruß,
Peter
Wie viele?
von Cisco installiert.
Die haben auch ein Log. Was steht dort drin?Nun haben wir seit geraumer Zeit das Problem, dass täglich um ca. 13 Uhr das WLAN zusammenbricht.
Bricht tatsächlich nur dein WLAN zusammen? Nur an einen AP? An mehreren (nicht allen)? An allen gleichzeitig? Was steht in den Logs der einzelnen AP's drin? Ist es eventuell deine LAn Verbindung zu den APs die sich verabschiedet? Was sagt ein Ping zu den APs aus? Was sagt ein Ping zu den APs innerhalb des WLANS selbst aus (Laptop oder sonst ein gerät dort mal jinstellen)? Was sagt z.B. INSSIDer zum fraglichen Zeitpunkt aus? Was sagt ein Kabelhai aus (die APs müssen ja irgendwie per LAN....)?Wir benutzen nicht managebare Switche von Netgear.
Rächt sich jetzt....1. Switche getauscht
Gegen neue oder gebrauchte oder anderen Hersteller und Modell oder gegen eine Currywurst?2. Medienkonverter für Glasfaser / Ethernet getauscht
3. USV für Switche eingebaut
Switche? Mehrzahl? Wie viele APs sind es denn?3. USV für Switche eingebaut
Gruß,
Peter
Hallo killtec, also wir haben auch einen mobilen Rechner dort. Der verliert auch die Verbindung... Die Cisco Logfiles geben m.E. nicht wirklich viel her. Die Antennen zeigen an, dass sie schon lange aktiv sind... Also keine Ausfälle vom Strom her. Mehr kann ich nicht wirklich daraus lesen.
Viele Grüße
Torsten
Viele Grüße
Torsten
Kannst du die Log hier mal posten?
Hallo zusammen,
heiß gemacht.
die Mails checken wollen und die ganze WLAN Struktur das nicht
abfängt.
wenn es vorher funktioniert hat und man dort auch nichts
einstellen kann, sollte das eigentlich egal sein wer der Hersteller ist.
Zeiten in denen das WLAN funktionierte und man Mittags keinen
Ärger bekam?
Gruß
Dobby
P.S.
13:00 = mittag --> Mikrowelle ?? face-wink
War auch mein erster Gedanke! Kleines 5 Minuten Süppchenheiß gemacht.
Wir betreiben ein WLAN in unserem Lager.
Kann es sein das in der Mittagspause alle Mitarbeiter mal ebendie Mails checken wollen und die ganze WLAN Struktur das nicht
abfängt.
Das Netzwerk ist an unserem Serverraum via Glasfaser angebunden.
Wir benutzen nicht managebare Switche von Netgear.
Dann sollten die ja fast nicht der Knackpunkt sein, dennWir benutzen nicht managebare Switche von Netgear.
wenn es vorher funktioniert hat und man dort auch nichts
einstellen kann, sollte das eigentlich egal sein wer der Hersteller ist.
Was ich bisher getan habe:
Ist der zustand denn schon immer so gewesen, oder gab es auchZeiten in denen das WLAN funktionierte und man Mittags keinen
Ärger bekam?
1. Switche getauscht
Gegen welche denn?2. Medienkonverter für Glasfaser / Ethernet getauscht
Ok.3. USV für Switche eingebaut
Ok.Habt ihr Ideen bzw. Anregungen wie wir dem Fehler auf die Spur kommen?
Nach einer Mikrowelle mit einer defekten "Gummilippe" im Betrieb suchen.Gruß
Dobby
P.S.
Mehr kann ich nicht wirklich daraus lesen.
"Schmeiß" mal den WireShark an und protokolliere alles mit.
Das ist ein Log von heute aus der fraglichen Zeit:
Jun 23 12:22:56.723: %DOT11-6-ROAMED: Station 0017.2305.4eb4 Roamed to 0022.be90.f7a0
Jun 23 12:22:56.723: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4eb4 Reason: Sending station has left the BSS
Jun 23 12:23:04.875: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2313.2b9c Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:25:10.708: %DOT11-6-ROAMED: Station 0017.2313.2b9c Roamed to 0022.be90.f7a0
Jun 23 12:25:10.708: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2313.2b9c Reason: Sending station has left the BSS
Jun 23 12:26:13.359: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4eb4 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:26:23.406: %DOT11-6-ROAMED: Station 0017.2305.4eb4 Roamed to 0022.be90.fa80
Jun 23 12:26:23.406: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4eb4 Reason: Sending station has left the BSS
Jun 23 12:26:23.966: %DOT11-6-ROAMED: Station 0017.2305.4cb4 Roamed to 0022.be90.f870
Jun 23 12:26:23.966: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4cb4 Reason: Sending station has left the BSS
Jun 23 12:26:47.554: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4a90 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:26:57.470: %DOT11-6-ROAMED: Station 0017.2305.4a90 Roamed to 0022.be90.fa80
Jun 23 12:26:57.470: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4a90 Reason: Sending station has left the BSS
Jun 23 12:28:15.256: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4eb4 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:28:35.335: %DOT11-6-ROAMED: Station 0017.2305.4eb4 Roamed to 0022.be90.f7a0
Jun 23 12:28:35.335: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4eb4 Reason: Sending station has left the BSS
Jun 23 12:28:46.323: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4a90 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:29:06.375: %DOT11-6-ROAMED: Station 0017.2305.4a90 Roamed to 0022.be90.f7a0
Jun 23 12:29:06.375: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4a90 Reason: Sending station has left the BSS
Jun 23 12:33:30.049: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4c39 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:33:54.132: %DOT11-6-ROAMED: Station 0017.2305.4c39 Roamed to 0022.be90.fa80
Jun 23 12:33:54.132: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4c39 Reason: Sending station has left the BSS
Jun 23 12:35:42.790: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4bd3 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:38:34.578: %DOT11-6-ROAMED: Station 0017.2305.4bd3 Roamed to 0022.be90.f870
Jun 23 12:38:34.578: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4bd3 Reason: Sending station has left the BSS
Jun 23 12:42:48.424: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4bd3 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:43:47.394: %DOT11-6-ROAMED: Station 0017.2305.4bd3 Roamed to 0022.be90.f870
Jun 23 12:43:47.398: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4bd3 Reason: Sending station has left the BSS
Jun 23 12:44:26.342: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4eb4 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:44:46.409: %DOT11-6-ROAMED: Station 0017.2305.4eb4 Roamed to 0022.be90.f7a0
Jun 23 12:44:46.409: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4eb4 Reason: Sending station has left the BSS
Jun 23 12:45:30.521: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2313.2b9c Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:45:49.456: %DOT11-6-ROAMED: Station 0017.2313.2b9c Roamed to 0022.be90.fa80
Jun 23 12:45:49.456: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2313.2b9c Reason: Sending station has left the BSS
Jun 23 12:47:32.258: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2313.2b9c Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:47:49.261: %DOT11-6-ROAMED: Station 0017.2313.2b9c Roamed to 0022.be90.f7a0
Jun 23 12:47:49.261: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2313.2b9c Reason: Sending station has left the BSS
Jun 23 12:49:30.175: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4bfd Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:49:40.151: %DOT11-6-ROAMED: Station 0017.2305.4bfd Roamed to 0022.be90.f870
Jun 23 12:49:40.151: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4bfd Reason: Sending station has left the BSS
Jun 23 12:50:52.137: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4bfd Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:51:55.075: %DOT11-6-ROAMED: Station 0017.2305.4bfd Roamed to 0022.0d45.2c90
Jun 23 12:51:55.075: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4bfd Reason: Sending station has left the BSS
Jun 23 12:55:54.878: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4c39 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:56:23.829: %DOT11-6-ROAMED: Station 0017.2305.4c39 Roamed to 0022.be90.f870
Jun 23 12:56:23.829: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4c39 Reason: Sending station has left the BSS
Jun 23 12:59:27.567: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4c39 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:59:48.635: %DOT11-6-ROAMED: Station 0017.2305.4c39 Roamed to 0022.be90.f970
Jun 23 12:59:48.635: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4c39 Reason: Sending station has left the BSS
Jun 23 13:16:03.909: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2313.d8f0 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 13:16:30.624: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2313.2b9c Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:22:56.723: %DOT11-6-ROAMED: Station 0017.2305.4eb4 Roamed to 0022.be90.f7a0
Jun 23 12:22:56.723: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4eb4 Reason: Sending station has left the BSS
Jun 23 12:23:04.875: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2313.2b9c Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:25:10.708: %DOT11-6-ROAMED: Station 0017.2313.2b9c Roamed to 0022.be90.f7a0
Jun 23 12:25:10.708: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2313.2b9c Reason: Sending station has left the BSS
Jun 23 12:26:13.359: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4eb4 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:26:23.406: %DOT11-6-ROAMED: Station 0017.2305.4eb4 Roamed to 0022.be90.fa80
Jun 23 12:26:23.406: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4eb4 Reason: Sending station has left the BSS
Jun 23 12:26:23.966: %DOT11-6-ROAMED: Station 0017.2305.4cb4 Roamed to 0022.be90.f870
Jun 23 12:26:23.966: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4cb4 Reason: Sending station has left the BSS
Jun 23 12:26:47.554: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4a90 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:26:57.470: %DOT11-6-ROAMED: Station 0017.2305.4a90 Roamed to 0022.be90.fa80
Jun 23 12:26:57.470: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4a90 Reason: Sending station has left the BSS
Jun 23 12:28:15.256: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4eb4 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:28:35.335: %DOT11-6-ROAMED: Station 0017.2305.4eb4 Roamed to 0022.be90.f7a0
Jun 23 12:28:35.335: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4eb4 Reason: Sending station has left the BSS
Jun 23 12:28:46.323: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4a90 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:29:06.375: %DOT11-6-ROAMED: Station 0017.2305.4a90 Roamed to 0022.be90.f7a0
Jun 23 12:29:06.375: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4a90 Reason: Sending station has left the BSS
Jun 23 12:33:30.049: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4c39 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:33:54.132: %DOT11-6-ROAMED: Station 0017.2305.4c39 Roamed to 0022.be90.fa80
Jun 23 12:33:54.132: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4c39 Reason: Sending station has left the BSS
Jun 23 12:35:42.790: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4bd3 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:38:34.578: %DOT11-6-ROAMED: Station 0017.2305.4bd3 Roamed to 0022.be90.f870
Jun 23 12:38:34.578: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4bd3 Reason: Sending station has left the BSS
Jun 23 12:42:48.424: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4bd3 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:43:47.394: %DOT11-6-ROAMED: Station 0017.2305.4bd3 Roamed to 0022.be90.f870
Jun 23 12:43:47.398: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4bd3 Reason: Sending station has left the BSS
Jun 23 12:44:26.342: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4eb4 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:44:46.409: %DOT11-6-ROAMED: Station 0017.2305.4eb4 Roamed to 0022.be90.f7a0
Jun 23 12:44:46.409: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4eb4 Reason: Sending station has left the BSS
Jun 23 12:45:30.521: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2313.2b9c Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:45:49.456: %DOT11-6-ROAMED: Station 0017.2313.2b9c Roamed to 0022.be90.fa80
Jun 23 12:45:49.456: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2313.2b9c Reason: Sending station has left the BSS
Jun 23 12:47:32.258: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2313.2b9c Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:47:49.261: %DOT11-6-ROAMED: Station 0017.2313.2b9c Roamed to 0022.be90.f7a0
Jun 23 12:47:49.261: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2313.2b9c Reason: Sending station has left the BSS
Jun 23 12:49:30.175: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4bfd Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:49:40.151: %DOT11-6-ROAMED: Station 0017.2305.4bfd Roamed to 0022.be90.f870
Jun 23 12:49:40.151: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4bfd Reason: Sending station has left the BSS
Jun 23 12:50:52.137: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4bfd Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:51:55.075: %DOT11-6-ROAMED: Station 0017.2305.4bfd Roamed to 0022.0d45.2c90
Jun 23 12:51:55.075: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4bfd Reason: Sending station has left the BSS
Jun 23 12:55:54.878: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4c39 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:56:23.829: %DOT11-6-ROAMED: Station 0017.2305.4c39 Roamed to 0022.be90.f870
Jun 23 12:56:23.829: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4c39 Reason: Sending station has left the BSS
Jun 23 12:59:27.567: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2305.4c39 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 12:59:48.635: %DOT11-6-ROAMED: Station 0017.2305.4c39 Roamed to 0022.be90.f970
Jun 23 12:59:48.635: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating Station 0017.2305.4c39 Reason: Sending station has left the BSS
Jun 23 13:16:03.909: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2313.d8f0 Reassociated KEY_MGMT[WPAv2 PSK]
Jun 23 13:16:30.624: %DOT11-6-ASSOC: Interface Dot11Radio0, Station 0017.2313.2b9c Reassociated KEY_MGMT[WPAv2 PSK]
wie diese hier: Packet to client 0017.23a5.1461 reached max
retries, removing the client
Was ist das für ein Klient? Hast Du mal den einen Tag ohneretries, removing the client
diesen Klienten das Netzwerk betrieben? Passiert dann immer
noch etwas?
Die zeitlich aber nicht unbedingt zum Ausfall passen.
Die Warnung kommt ja eben auch vorher dazu!Kann sein das damit gemeint ist das DHCP und DNS Einträge
ja zum Cachen gespeichert werden müssen und das nun der
Cache voll läuft und daher die Warnung ausgegeben wird.
Ne Currywurst wäre mir aber lieber gewesen, da das Ziel ja
nicht erreicht ist.
Ja ne klar das verstehe ich schon, nur wollte ich eher darauf hinausnicht erreicht ist.
ob das auch wieder Netgear Switche oder andere gewesen sind,
um die Switche selber als Störquelle auszuschließen.
Gruß
Dobby
Hallo zusammen,
irgendwie bin ich auch zu doof das Board zu bedienen
habe gerade meinen Antwort-Beitrag gelöscht. Also nochmal als Zusammenfassung auf die vielen Kommentare:
1. Wir haben insgesamt 9 APs im Einsatz. 8 AP 1240 und einen AP 1600 Diese werden über ja einen Powerinjektor mit Strom und Datenversorgt. alle hängen auf einer USV.
2. Cisco Log habe ich bereits gepostet. Steht leider nicht viel drin. Wireshark und inSSIDer teste ich morgen. Pingtests habe ich von einem Rechner aus mittels fping bereits auf einige APs gemacht. Bisher ohne Erkenntnisse. Pings von einem AP zum anderen werde ich morgen auch mit testen.
3. die alten Netgear Switche habe ich gegen neue Netgear Switche getauscht. die neuen sind auch nicht managebar...
4. die Kollegen im Lager haben Mittagspause bis 12:30 Uhr. Also arbeiten so zur Ausfallzeit schon eine halbe Stunde...
erstmal vielen Dank für eure Antworten. Ich hoffe, dass ich Morgen mehr sagen kann.
Vielen Dank und viele Grüße
Torsten
irgendwie bin ich auch zu doof das Board zu bedienen
habe gerade meinen Antwort-Beitrag gelöscht. Also nochmal als Zusammenfassung auf die vielen Kommentare:1. Wir haben insgesamt 9 APs im Einsatz. 8 AP 1240 und einen AP 1600 Diese werden über ja einen Powerinjektor mit Strom und Datenversorgt. alle hängen auf einer USV.
2. Cisco Log habe ich bereits gepostet. Steht leider nicht viel drin. Wireshark und inSSIDer teste ich morgen. Pingtests habe ich von einem Rechner aus mittels fping bereits auf einige APs gemacht. Bisher ohne Erkenntnisse. Pings von einem AP zum anderen werde ich morgen auch mit testen.
3. die alten Netgear Switche habe ich gegen neue Netgear Switche getauscht. die neuen sind auch nicht managebar...
4. die Kollegen im Lager haben Mittagspause bis 12:30 Uhr. Also arbeiten so zur Ausfallzeit schon eine halbe Stunde...
erstmal vielen Dank für eure Antworten. Ich hoffe, dass ich Morgen mehr sagen kann.
Vielen Dank und viele Grüße
Torsten
hallo -s-v-o-,
das ist nochmal ein interessanter Ansatz. Wir haben auch nen neuen Stapler bekommen. Ich checke den mal...
Viele Grüße
Torsten
das ist nochmal ein interessanter Ansatz. Wir haben auch nen neuen Stapler bekommen. Ich checke den mal...
Viele Grüße
Torsten
Hallo Dobby,
die Mac-Adresse ist von einem MDE. Der hat aber kein DHCP. Unser Scannersystem läuft ausschließlich mit IP-Adresse. DNS Auflösung sollte daher nicht das Problem sein.
Viele Grüße
Torsten
die Mac-Adresse ist von einem MDE. Der hat aber kein DHCP. Unser Scannersystem läuft ausschließlich mit IP-Adresse. DNS Auflösung sollte daher nicht das Problem sein.
Viele Grüße
Torsten
Unser Scannersystem läuft ausschließlich
Kann es sein das dort dann eine größere Ladung ankommt oderim Ausgang abgeht und dort recht schnell und vor allem recht viele
Packstücke gescannt werden!?
Gruß
Dobby
Hallo,
OK.
Was hat man dir vom Arzt verschrieben?
Du meinst deine MDEs haben alle feste IPs bekommen und das ein Auflösen von URLS durch euren DNS sauber beantwortet wird, oder?
Gruß,
Peter
OK.
Der hat aber kein DHCP.
Seltenst hat ein MDE Scanner einen DHCP (Server) Unser Scannersystem läuft ausschließlich mit IP-Adresse.
Womit sollen die denn sonst laufen? Diesel?DNS Auflösung sollte daher nicht das Problem sein.
Und schon wieder ein ganz ganz ganz anderes Thema.Was hat man dir vom Arzt verschrieben?
Du meinst deine MDEs haben alle feste IPs bekommen und das ein Auflösen von URLS durch euren DNS sauber beantwortet wird, oder?
Gruß,
Peter
Hallo Peter,
du fässt all meine umständlichen Beschreibungen in einen kurzen Satz zusammen...! Welch Talent in dir schlummert...
Nee im Ernst, genauso ist das.
Viele Grüße
Torsten
du fässt all meine umständlichen Beschreibungen in einen kurzen Satz zusammen...! Welch Talent in dir schlummert
...Nee im Ernst, genauso ist das.
Viele Grüße
Torsten
Hallo Dobby,
nein die MDEs werden zur Kommissionierung und zum Ein- sowie Auslagern genutzt. So dass immer ein recht konstante Last entsteht. So zumindest die Theorie... Aber ich werde mir das unter deinem Gesichtspunkt nochmal genauer anschauen. ich will da nichts unversucht lassen.
Viele Grüße
Torsten
nein die MDEs werden zur Kommissionierung und zum Ein- sowie Auslagern genutzt. So dass immer ein recht konstante Last entsteht. So zumindest die Theorie... Aber ich werde mir das unter deinem Gesichtspunkt nochmal genauer anschauen. ich will da nichts unversucht lassen.
Viele Grüße
Torsten
und die vielen Handys der Mitarbeiter in der Pause - Überlast?
Und die Mikrowelle kann nicht nur im Pausenraum stören, auch die Profigeräte aus der Kantine sind gute Strahlungsquellen.
Gruß
Netman
Und die Mikrowelle kann nicht nur im Pausenraum stören, auch die Profigeräte aus der Kantine sind gute Strahlungsquellen.
Gruß
Netman
So dass immer ein recht konstante Last entsteht.
Ich sage es mal so wie es bei uns ist.12:00 Uhr und Mittagspause und wer eine Tour angefangen hat
zu scannen muss eben diese auch zu ende scannen! Und dann
legen die Jungs eben los damit sie auch schnell in die Pause
können und dann läuft eventuell der Puffer vom Scanner voll
oder aber die Daten können dann eben nicht mehr vom WLAN
erfasst und/oder transportiert werden. Allerdings bricht bei uns
nichts zusammen denn wir nutzen eben auch einen WLAN
Controller und verwaltbare (managed) Switche die die Last
auch abfangen können.
Gruß
Dobby
Hallo Mr. Netman,
die Pause ist bei uns von 12 bis 12:30 Uhr... Die Kollegen arbeiten also schon ne halbe Stunde... Die Handys haben bei uns keinen Zugang ins WLAN. Störungen können dennoch auftreten, aber wie gesagt passt nicht so wirklich in die Zeit...
Viele Grüße
Torsten
die Pause ist bei uns von 12 bis 12:30 Uhr... Die Kollegen arbeiten also schon ne halbe Stunde... Die Handys haben bei uns keinen Zugang ins WLAN. Störungen können dennoch auftreten, aber wie gesagt passt nicht so wirklich in die Zeit...
Viele Grüße
Torsten
Hallo Dobby,
definitiv interessant. Bei uns können die Kollegen die Aufträge pausieren. Daher sollte sowas nicht entstehen. Aber ausschließen will ich nichts mehr.
Viele Grüße
Torsten
definitiv interessant. Bei uns können die Kollegen die Aufträge pausieren. Daher sollte sowas nicht entstehen. Aber ausschließen will ich nichts mehr.
Viele Grüße
Torsten
Hier, im Log, steht drin, dass in dem WLAN zum fraglichen Zeitpunkt viel los ist. Die Stationen roamen und verlasen die Funkzellen. Verlassen der Funkzellen, so wie es hier im Log steht, bedeute schon auch, eine verrübergehende Nichterreichbarkeit.
.. Deauthenticating Station 0017.2305.4bd3 Reason: Sending station has left the BSS .... ist der häufigst gebrauchte Text. Das dürfte im normalen Betrieb anders sein.
Wenn Clients das WLAN verlassen kann das heißen, dass sie ausgeschatet oder auch gestört sind.
nur als Gedankenmodell.
Deutet immer noch auf etwas Systematisches hin. Mikrowelle, NFC, oder andere Labels.
Netman
.. Deauthenticating Station 0017.2305.4bd3 Reason: Sending station has left the BSS .... ist der häufigst gebrauchte Text. Das dürfte im normalen Betrieb anders sein.
Wenn Clients das WLAN verlassen kann das heißen, dass sie ausgeschatet oder auch gestört sind.
nur als Gedankenmodell.
Deutet immer noch auf etwas Systematisches hin. Mikrowelle, NFC, oder andere Labels.
Netman
Hallo Netman,
soweit ich das überblicken müssen die Endgeräte sich ja an den Stationen an- und wieder abmelden. Die Kollegen sind ja im Lager mobil. Daher kommen auch die endlosen Ab- und Anmeldungen zustande.
Mirkowelle gibt es bei uns den Pausenräumen, die sind räumlich sehr weit von den Accesspoints entfernt. Wie groß kann denn der Einfluß von Mobiltelefonen mit WLAN und NFC auf ein WLAN sein, auch wenn sich die Geräte nicht einwählen könnnen?
Viele Grüße
Torsten
soweit ich das überblicken müssen die Endgeräte sich ja an den Stationen an- und wieder abmelden. Die Kollegen sind ja im Lager mobil. Daher kommen auch die endlosen Ab- und Anmeldungen zustande.
Mirkowelle gibt es bei uns den Pausenräumen, die sind räumlich sehr weit von den Accesspoints entfernt. Wie groß kann denn der Einfluß von Mobiltelefonen mit WLAN und NFC auf ein WLAN sein, auch wenn sich die Geräte nicht einwählen könnnen?
Viele Grüße
Torsten
Ich habe erlebt, dass Mikrowellensysteme, das sind Öfen und auch Labelingsysteme WLAN gestört hat. Wenn im Pausenraum drei Mikrowellenöfen stehen ist die Leistung noch höher. Profesionelle, also welche für Großküchen haben noch mehr Leistung. Und die Strahlung ist dann auch meist höher. Weiters gibt es Bluetooth, wo die älteren Varianten keine Rücksicht auf WLAN genommen haben.
Du kannst das vermessen oder einfach im Betrieb nachsehen, was sich in der fraglichen Zeit so alles abspielt. Manchmal sieht man das direkt... Ein Spaziergang zur rechten Zeit kann Wunder wirken
Du kannst das vermessen oder einfach im Betrieb nachsehen, was sich in der fraglichen Zeit so alles abspielt. Manchmal sieht man das direkt... Ein Spaziergang zur rechten Zeit kann Wunder wirken
hallo zusammen,
es ist wieder 13 Uhr und wir hatten wieder diesen Ausfall
Ich habe mit Wireshark die Daten mitgeschnitten. Was mir aufgefallen ist, vorab gab es eine Flut von Multicast Listener Reports über das ICMPv6 Protokoll. Alle Antennen waren während der Zeit pingbar. Aber es kamen die Leute zu mir, dass es keinen WLAN Empfang gab. Jemand eine Idee was es mit den Multicast Listener Reports auf sich haben kann oder kann man das als Fehlerquelle ausschließen?
viele Grüße
Torsten
es ist wieder 13 Uhr und wir hatten wieder diesen Ausfall
Ich habe mit Wireshark die Daten mitgeschnitten. Was mir aufgefallen ist, vorab gab es eine Flut von Multicast Listener Reports über das ICMPv6 Protokoll. Alle Antennen waren während der Zeit pingbar. Aber es kamen die Leute zu mir, dass es keinen WLAN Empfang gab. Jemand eine Idee was es mit den Multicast Listener Reports auf sich haben kann oder kann man das als Fehlerquelle ausschließen?
viele Grüße
Torsten
Hallo,
Melden die MDE einen Lock-H oder Lock-B ?
Gruß
deichvogt
Melden die MDE einen Lock-H oder Lock-B ?
Gruß
deichvogt
Hallo,
OK.
http://packetpushers.net/good-nics-bad-things-blast-ipv6-multicast-list ...
http://www.ietf.org/rfc/rfc3810.txt
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_lsm/configurat ...
http://social.technet.microsoft.com/Forums/windows/en-US/945125a7-035f- ...
http://community.spiceworks.com/topic/422869-dell-optiplex-9020-blastin ...
Gruß,
Peter
OK.
vorab gab es eine Flut von Multicast Listener Reports
Überall? Nur bestimmte Access Points? Nur switche? Wir wissen nicht wie und wo du was mitgeschnitten hast.über das ICMPv6 Protokoll.
Absender ist wer (auch der hat eine MAC)?Alle Antennen waren während der Zeit pingbar.
Solche Antennen will ich auch haben Aber es kamen die Leute zu mir, dass es keinen WLAN Empfang gab.
Was sagte INSSIDer zu den Status der einzelnen Sender?Jemand eine Idee was es mit den Multicast Listener Reports auf sich haben kann
Defekte NIC? Wer und was hat bei dir alles IPv6 und welche netze sind davon betroffen (vermutlich alle Netze da auch ungemanagede Switche)?oder kann man das als Fehlerquelle ausschließen?
Wir wissen nicht was du wie und wo mitgeschnitten hast und welche Teile deines Netzes dies entspricht. Du hast alle nötigen Infos.http://packetpushers.net/good-nics-bad-things-blast-ipv6-multicast-list ...
http://www.ietf.org/rfc/rfc3810.txt
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipmulti_lsm/configurat ...
http://social.technet.microsoft.com/Forums/windows/en-US/945125a7-035f- ...
http://community.spiceworks.com/topic/422869-dell-optiplex-9020-blastin ...
Gruß,
Peter
hallo deichvogt,
eigentlich können die das nciht, da die kein ipv6 sprechen. Aber beschreibe mir mal bitte was du mit Lock-H oder Lock-B meinst...
Viele Grüße
Torsten
eigentlich können die das nciht, da die kein ipv6 sprechen. Aber beschreibe mir mal bitte was du mit Lock-H oder Lock-B meinst...
Viele Grüße
Torsten
IPv6 ist völlig unerheblich für Lock-H oder Lock-B Meldungen.
Lock-H kommt gerne bei MDE Geräten vor die kopiert / geklont wurden.
Siehe auch hier--> http://www.ingenuityworking.com/support/f/17/p/1974/8287.aspx
Lock-B deutet auf Probleme in der Datenbank hin.
Kann es sein das die DB einen täglichen Reorg fährt ?
was für eine DB habt ihr dahinter ?
Oracle ? MS SQL o.ä ?
Gruß
Deichvogt
Lock-H kommt gerne bei MDE Geräten vor die kopiert / geklont wurden.
Siehe auch hier--> http://www.ingenuityworking.com/support/f/17/p/1974/8287.aspx
Lock-B deutet auf Probleme in der Datenbank hin.
Kann es sein das die DB einen täglichen Reorg fährt ?
was für eine DB habt ihr dahinter ?
Oracle ? MS SQL o.ä ?
Gruß
Deichvogt
Hallo Peter,
also ich habe die Daten auf dem Switch mitgeschnitten auf den alle AccessPoints zusammen kommen.
Absender war unter anderem: 00:23:24:62:fc:4e
Ziel war: 33:33:ff:05:4d:88
Leider war ich heute alleine, so dass ich nicht zwei Dinge zur selben Zeit messen konnte. inSSIDer schreibe ich Morgen mit.
Ich prüfe mal alle Systeme, wer IPv6 aktiviert hat.
die Links schaue ich mir an. Nochmals vielen Dank an alle!!!
Viele Grüße
Torsten
also ich habe die Daten auf dem Switch mitgeschnitten auf den alle AccessPoints zusammen kommen.
Absender war unter anderem: 00:23:24:62:fc:4e
Ziel war: 33:33:ff:05:4d:88
Leider war ich heute alleine, so dass ich nicht zwei Dinge zur selben Zeit messen konnte. inSSIDer schreibe ich Morgen mit.
Ich prüfe mal alle Systeme, wer IPv6 aktiviert hat.
die Links schaue ich mir an. Nochmals vielen Dank an alle!!!
Viele Grüße
Torsten
ein ungemanagtes Netz kann sehr wohl IPV6 übertragen. Der Layer 2 ist ja ident.
Und damit gibt es auch eine gute Chance Broadcast raus zu blasen. Bitte gucke genau auf den Absender. MAC und IP. Anhand der MAC kannst möglicherweise das Gerät finden.
die MAC-Adressen können dir z.B: mit dem "angry ip-scanner" gezeigt werden. #Edit# Wenn du keinen DHCP hast, der dir die Daten liefert.
Ich kenne Datenübertragungen, die per Broadcast laufen - auf alten Maschinen. Dort war dann zeitweise nicht mehr ans Telefonieren zu denken.
Gruß Netman
Und damit gibt es auch eine gute Chance Broadcast raus zu blasen. Bitte gucke genau auf den Absender. MAC und IP. Anhand der MAC kannst möglicherweise das Gerät finden.
die MAC-Adressen können dir z.B: mit dem "angry ip-scanner" gezeigt werden. #Edit# Wenn du keinen DHCP hast, der dir die Daten liefert.
Ich kenne Datenübertragungen, die per Broadcast laufen - auf alten Maschinen. Dort war dann zeitweise nicht mehr ans Telefonieren zu denken.
Gruß Netman
Hallo Deichvogt,
wir nutzen eine MySql Datenbank. Die Geräte greifen nicht direkt auf eine Datenbank zu, sondern stellen eine Webseite eines TomcatServers dar. Der Zugriff passiert über den Wavelink TelnetClient. Der stellt eine Websession her.
Der TomcatServer greift dann auf die Datenbank zu...
Viele Grüße
Torsten
wir nutzen eine MySql Datenbank. Die Geräte greifen nicht direkt auf eine Datenbank zu, sondern stellen eine Webseite eines TomcatServers dar. Der Zugriff passiert über den Wavelink TelnetClient. Der stellt eine Websession her.
Der TomcatServer greift dann auf die Datenbank zu...
Viele Grüße
Torsten
okay, danke Dir. mit dem angry IP Scanner werde ich gleich mal auf Suche gehen...
Viele Grüße
Torsten
Viele Grüße
Torsten
Hallo,
Gruß,
Peter
Zitat von @torte79:
also ich habe die Daten auf dem Switch mitgeschnitten auf den alle AccessPoints zusammen kommen.
OK. sehr gut. Aber ist dieser Switch vom restlichen Netz getrennt oder sollen wir uns dein Netz vorstellen? Habt ihr nur 9 AP, 1 DB Server, den einen Switch und dein PC in diesem Broadcastnetz oder wer und was kann alles bei euch dort was im Netz senden ohne das du weisst wer sich alles in dein Broadcastnetz tummelt?also ich habe die Daten auf dem Switch mitgeschnitten auf den alle AccessPoints zusammen kommen.
Absender war unter anderem: 00:23:24:62:fc:4e
Suche ihn aber mir schwant übles... 00-23-24 (hex) G-PRO COMPUTER
002324 (base 16) G-PRO COMPUTER
first arrange C, YingHu industrial estate
QingXi Country
DongGuan City GuangDong Province 523648
CHINAZiel war: 33:33:ff:05:4d:88
Und das ist eine selbst generiete MAC?Leider war ich heute alleine, so dass ich nicht zwei Dinge zur selben Zeit messen konnte.
Ruhig Brauner, ruhig inSSIDer schreibe ich Morgen mit.
Je mehr APs gleichzeit, je besserGruß,
Peter
Hallo Peter,
also ich habe über Wireshark jetzt mal ausschließlich das ICMPv6 Protokoll analysiert. Dabei sind 2 Rechner aufgefallen, die den meisten Traffic erzeugt haben:
00:23:24:62:fc:4e
00:23:24:62:fb:65
das sind 2 Windows 7 Maschinen von Lenovo. Daher wahrscheinlich auch der Bezug zu China?!? Bei beiden habe ich das IPv6 Protokoll abgestellt. Ein Scann mit dem Virenscanner hat keinen Befall ausgewiesen. Die Maschinen die wir mit dazu gekauft haben, waren heute z.T. nicht online. Die sehe ich mir auch noch an.
Die Mac-Adresse 33:33:ff:05:4d:88 suche ich noch. Ich habe sie noch keine Dokumentation oder im Angry Scanner gefunden.
Morgen schreibe ich die Daten mit inSSIDer mit. Mal sehen was da raus kommt.
Viele Grüße
Torsten
also ich habe über Wireshark jetzt mal ausschließlich das ICMPv6 Protokoll analysiert. Dabei sind 2 Rechner aufgefallen, die den meisten Traffic erzeugt haben:
00:23:24:62:fc:4e
00:23:24:62:fb:65
das sind 2 Windows 7 Maschinen von Lenovo. Daher wahrscheinlich auch der Bezug zu China?!? Bei beiden habe ich das IPv6 Protokoll abgestellt. Ein Scann mit dem Virenscanner hat keinen Befall ausgewiesen. Die Maschinen die wir mit dazu gekauft haben, waren heute z.T. nicht online. Die sehe ich mir auch noch an.
Die Mac-Adresse 33:33:ff:05:4d:88 suche ich noch. Ich habe sie noch keine Dokumentation oder im Angry Scanner gefunden.
Morgen schreibe ich die Daten mit inSSIDer mit. Mal sehen was da raus kommt.
Viele Grüße
Torsten
Hallo Torsten
Hast du hoffentlich einen offline Virenscan gemacht oder?
Gruss
adminst
Hast du hoffentlich einen offline Virenscan gemacht oder?
Gruss
adminst
Hallo,
Schalte die Morgen um 12:55 aus und um 13:10 wieder ein oder ziehe den LAN Stecker und beobachte...
Es kann auch ein Defekte NIC sein......es muss nicht zwingend etwas mit Viren zu tun haben (sehr unwahrscheinlich). Was passiert auf den Rechnern um 13:00 Uhr?
Gruß,
Peter
Schalte die Morgen um 12:55 aus und um 13:10 wieder ein oder ziehe den LAN Stecker und beobachte...
Es kann auch ein Defekte NIC sein......es muss nicht zwingend etwas mit Viren zu tun haben (sehr unwahrscheinlich). Was passiert auf den Rechnern um 13:00 Uhr?
Die Mac-Adresse 33:33:ff:05:4d:88 suche ich noch. Ich habe sie noch keine Dokumentation oder im Angry Scanner gefunden.
ALLE MACs dokumentiert? ALLE Netze per angry-ip Scanner erreichbar? Router irgendwo? Wie ich dir schon agedeutet habe besteht dein Netz ja wohl nicht nur aus 10 Geräten oder? Wir kennen aber dein Netz und dessen aufbau nicht, daher können wir dir nur ALLGEMEINE hinweise geben.Morgen schreibe ich die Daten mit inSSIDer mit. Mal sehen was da raus kommt.
Gibt es einen WLAN Kontroller (ich kenne deine Geräte nicht)? Syslog Server der mitprotkollieren kann? VLANs? Router? Bridges? Können sich fremde unbekannte Geräte einfach irgendwo anstöpseln und dein netz irgendwie nutzen / missbrauchen / lahmlegen? Ports gepatcht? Virtuelle Maschinen die um 13 Uhr....Dir unbekannte Gerät irgend eines Mitarbeiters der sein Gerät um 13 Uhr einstöpselt?....Gruß,
Peter
Mirkowelle gibt es bei uns den Pausenräumen,
Nur eine defekte Gummilippe der Dichtung kann den ganzenLaden von Euch lahmlegen! Die Strahlungsimmision so eines
Gerätes ist um das 60.000 fache höher als bei WLAN.
Und dann immer pünktlich zur Mittagszeit?
Gruß
Dobby
Hallo Peter,
also zum Netzaufbau:
Wir haben ca. 45 Workstations (Windows 7), 1 Exchange Server 2010 (OS Windows 2008 R2), 3 Windows 2003 Server und 4 Windows 2008 R2 Server. Das ganze läuft in einer AD-Domäne. Der DomänenController läuft auf windows 2003. Dazu kommen 4 virtuelle Hosts. Darauf laufen Linux Maschinen (CentOs 6) und die MS Server. Als Switche haben wir überall Netgear Switche (nicht managebar). Als Router setzen wir die Cisco 2901 ein. Das ganze wird an 3 Standorten betrieben, die mittels VPN verbunden sind.
Die 3 IP Segmente habe ich mittel Angry IP Scanner durchsucht. und die Mac-Adresse 33:33ff:05:4d:88 noch nicht gefunden. Eine Suche unter http://hwaddress.com/?q=H&; hat leider ergeben, dass es die MAC-Adresse so eigentlich nicht geben kann. MAC-Adressen haben wir manuell nicht angepasst.
Es gibt keinen WLAN Controller auch keinen SYS_LOG Server, keine VLANs. Router wie gesagt, Cisco 2901... Bridges nein.
Also grundsätzlich kann man sich natürlich mittels Netzwerkkabel irgendwo einstöpseln. Aber bisher nicht aufgetaucht. Auch Befragung in den Abteilungen nichts erbracht. Die virtuellen Maschinen haben soweit keine zeitgesteuerten Vorgänge. Protokolle von VM-Ware geben da auch nichts her. keine virtuelle Maschine hat diese ominöse MAC-Adresse.
Ich stöpsle morgen die beiden Geräte mal aus und dann schauen wir mal, ob es das Problem wieder gibt...
Viele Grüße
Torsten
also zum Netzaufbau:
Wir haben ca. 45 Workstations (Windows 7), 1 Exchange Server 2010 (OS Windows 2008 R2), 3 Windows 2003 Server und 4 Windows 2008 R2 Server. Das ganze läuft in einer AD-Domäne. Der DomänenController läuft auf windows 2003. Dazu kommen 4 virtuelle Hosts. Darauf laufen Linux Maschinen (CentOs 6) und die MS Server. Als Switche haben wir überall Netgear Switche (nicht managebar). Als Router setzen wir die Cisco 2901 ein. Das ganze wird an 3 Standorten betrieben, die mittels VPN verbunden sind.
Die 3 IP Segmente habe ich mittel Angry IP Scanner durchsucht. und die Mac-Adresse 33:33ff:05:4d:88 noch nicht gefunden. Eine Suche unter http://hwaddress.com/?q=H&; hat leider ergeben, dass es die MAC-Adresse so eigentlich nicht geben kann. MAC-Adressen haben wir manuell nicht angepasst.
Es gibt keinen WLAN Controller auch keinen SYS_LOG Server, keine VLANs. Router wie gesagt, Cisco 2901... Bridges nein.
Also grundsätzlich kann man sich natürlich mittels Netzwerkkabel irgendwo einstöpseln. Aber bisher nicht aufgetaucht. Auch Befragung in den Abteilungen nichts erbracht. Die virtuellen Maschinen haben soweit keine zeitgesteuerten Vorgänge. Protokolle von VM-Ware geben da auch nichts her. keine virtuelle Maschine hat diese ominöse MAC-Adresse.
Ich stöpsle morgen die beiden Geräte mal aus und dann schauen wir mal, ob es das Problem wieder gibt...
Viele Grüße
Torsten
Hallo,
Hatte erst vor kurzem einen ähnlichen Fall. Bei mir war ein PC schuld, da hat die NIC eine Broadcastflut losgetreten, als der PC in den Ruhezustand ging und auf Wake-on-Lan horchte. Habs dann deaktivert und alles waren glücklich ;)
lg
Hatte erst vor kurzem einen ähnlichen Fall. Bei mir war ein PC schuld, da hat die NIC eine Broadcastflut losgetreten, als der PC in den Ruhezustand ging und auf Wake-on-Lan horchte. Habs dann deaktivert und alles waren glücklich ;)
lg
Hallo,
Hatte ich oben in diesem Link schon erwähnt http://packetpushers.net/good-nics-bad-things-blast-ipv6-multicast-list ...
Gruß,
Peter
Hatte ich oben in diesem Link schon erwähnt
http://packetpushers.net/good-nics-bad-things-blast-ipv6-multicast-list ...Gruß,
Peter
Sorry, hab nicht denn ganzen Thread gelesen...
lg
lg
Multicast über IPV6 ist natürlich ein heikles Thema. Und es kann auch von ausserhalb kommen.
Alle Geräte, die das nicht kennen, dazu gehören die APs und die Switche, müssen die komplett an alle Ports verteilen, was für ein WLAN tödlich ist.
Kann es sein, dass jemand ein Video auf diese Weise ansieht?
Abhilfe nur im Router, wenn es von aussen kommt.
Und IPV6 kann evtl auch über einen Tunnel kommen. Es gibt ja einige Kompatibilitätsmodi mit IPv4 Netzen.
Gruß
Netman
Alle Geräte, die das nicht kennen, dazu gehören die APs und die Switche, müssen die komplett an alle Ports verteilen, was für ein WLAN tödlich ist.
Kann es sein, dass jemand ein Video auf diese Weise ansieht?
Abhilfe nur im Router, wenn es von aussen kommt.
Und IPV6 kann evtl auch über einen Tunnel kommen. Es gibt ja einige Kompatibilitätsmodi mit IPv4 Netzen.
Gruß
Netman
Wir benutzen nicht managebare Switche von.......
Kann natürlich auch daran liegen, denn mit verwaltbaren Switchen undVLANs kann man so etwas in der Regeln viel schneller einkreisen oder
die Fehlerquelle ausfindig machen und eventuell ist es ja auch nur eine
Sache für die Zukunft, aber ich würde es mir einmal durch den Kopf gehen
lassen. Ebenso die Anschaffung eines WLAN Controllers mit dem man in
solchen Szenarien auch noch ganz anders agieren kann.
Gruß
Dobby
Hallo Netman,
jap, so sehe ich das allmählich auch. Gibt es von Eurer Seite Empfehlungen in Richtung managed Switche und WLAN Controller? Für die APs würden ja PoE Switche in Betracht kommen...
Ob sich da jemand ein Video anschaut, würde ich mal nicht sagen. Aber ausschließen will ich das auch nicht.
Wir werden heute die Rechner zum Zeitpunkt abschalten und dann das WLAN im Lager messen. Schauen wir mal...
Viele Grüße
Torsten
jap, so sehe ich das allmählich auch. Gibt es von Eurer Seite Empfehlungen in Richtung managed Switche und WLAN Controller? Für die APs würden ja PoE Switche in Betracht kommen...
Ob sich da jemand ein Video anschaut, würde ich mal nicht sagen. Aber ausschließen will ich das auch nicht.
Wir werden heute die Rechner zum Zeitpunkt abschalten und dann das WLAN im Lager messen. Schauen wir mal...
Viele Grüße
Torsten
Hallo Peter,
durch deine Links bin ich zu folgendem Link gekommen: https://communities.intel.com/message/225025
Dieser stellt ein ähnliches Problem dar. Habe mir den neuen Treiber besorgt. Trotzdem werde ich die Rechner über die Mittagspause herunterfahren lassen. Wenn das dann klappt, aktualisieren wir alle Treiber.
Viele Grüße
Torsten
durch deine Links bin ich zu folgendem Link gekommen: https://communities.intel.com/message/225025
Dieser stellt ein ähnliches Problem dar. Habe mir den neuen Treiber besorgt. Trotzdem werde ich die Rechner über die Mittagspause herunterfahren lassen. Wenn das dann klappt, aktualisieren wir alle Treiber.
Viele Grüße
Torsten
Hallo,
steigen Nur WLAN-Geräte aus? Was ist mit Laptops die im WLAN sind (z.B. Deins) sind die auch raus oder haben die noch Netzwerk?
Geht VPN zu den Standorten und Internet auch flöten zu dem Zeitpunkt?
Ist die Datenbank mit der sich die MDE verbinden bei Euch vor Ort oder hostet over Internet/VPN?
Gruß
Chonta
steigen Nur WLAN-Geräte aus? Was ist mit Laptops die im WLAN sind (z.B. Deins) sind die auch raus oder haben die noch Netzwerk?
Geht VPN zu den Standorten und Internet auch flöten zu dem Zeitpunkt?
Ist die Datenbank mit der sich die MDE verbinden bei Euch vor Ort oder hostet over Internet/VPN?
Gruß
Chonta
Hallo zusammen,
also heute haben wir die betroffenen Rechner über die Mittagszeit heruntergefahren. Es ist kein Ausfall aufgetreten. Nun habe ich die ganze Sache auch noch im Test mit einem Switch und einen betroffenen Rechner nachgestellt. In dem wir den Ruhezustand erzeugt haben und wieder aufgeweckt haben. Es konnte zwar nicht die gleiche Anzahl von Paketen erzeugt werden, aber es war zumindest schon einiger Traffic auf dem System
Unter dem bereits zitierten Link: https://communities.intel.com/message/225025 findet man den Hinweis auf die Intel Netzwerkkarte I-217LM. Diese ist auch in den Rechnern verbaut (Lenovo m93p). Intel hat dazu bereits einen neuen Treiber veröffentlich ( https://downloadcenter.intel.com/SearchResult.aspx?lang=deu&ProductF ... ). Diesen installieren wir nun auf allen betroffenen Maschinen und ich hoffe, dass wir dann wieder Ruhe haben!
Schon mal vielen Dank an alle...
Viele Grüße
Torsten
also heute haben wir die betroffenen Rechner über die Mittagszeit heruntergefahren. Es ist kein Ausfall aufgetreten. Nun habe ich die ganze Sache auch noch im Test mit einem Switch und einen betroffenen Rechner nachgestellt. In dem wir den Ruhezustand erzeugt haben und wieder aufgeweckt haben. Es konnte zwar nicht die gleiche Anzahl von Paketen erzeugt werden, aber es war zumindest schon einiger Traffic auf dem System
Unter dem bereits zitierten Link: https://communities.intel.com/message/225025 findet man den Hinweis auf die Intel Netzwerkkarte I-217LM. Diese ist auch in den Rechnern verbaut (Lenovo m93p). Intel hat dazu bereits einen neuen Treiber veröffentlich ( https://downloadcenter.intel.com/SearchResult.aspx?lang=deu&ProductF ... ). Diesen installieren wir nun auf allen betroffenen Maschinen und ich hoffe, dass wir dann wieder Ruhe haben!
Schon mal vielen Dank an alle...
Viele Grüße
Torsten
Hallo zusammen,
also das Problem ist nur wirklich gelöst.
Das Update für den Netzwerkkarten-Treiber hat wirklich die Lösung gebracht.
Nochmals vielen Dank an ALLE!!!
viele Grüße
Torsten
also das Problem ist nur wirklich gelöst.
Das Update für den Netzwerkkarten-Treiber hat wirklich die Lösung gebracht.
Nochmals vielen Dank an ALLE!!!
viele Grüße
Torsten
