Instabile EC-Terminals im WLAN

Wenn moderne 802.11n-Features alte POS-Hardware aus dem Takt bringen

Bei uns in der Firma wurden an zwei Standorten die zentralen WLAN-Router von den betagten LANCOM 1781VAW auf die aktuellen 1800VAW ausgetauscht. Seit diesem Austausch traten den letzten Wochen sporadische Probleme mit EC-Kartenzahlungen auf. Die Zahlungen selbst funktionierten meist noch, doch gelegentlich kam es zu sehr langen Autorisationszeiten oder zu Fehlermeldungen wie „SSL-Handshake fehlgeschlagen – keine Verbindung zum Multikonnektor“. Besonders häufig scheiterte der nachgelagerte Belegtransfer.

Nach mehreren Tagen Analyse stellte sich heraus: Die Ursache lag nicht beim Zahlungsdienstleister, sondern im Zusammenspiel eines modernen WLAN-Routers mit einem POS-Terminal.

Dieser Beitrag dokumentiert die Ausgangssituation, die Fehlersuche und die letztlich gefundene Lösung. Vielleicht hilft er anderen Administratoren, ähnliche Probleme schneller zu identifizieren.

Ausgangssituation

Die Infrastruktur sah vereinfacht so aus:

• Router: LANCOM 1800VAW
• Zahlungsdienstleister: VR Payment / Fiserv
• EC-Terminal: Ingenico Move/5000
• WLAN-Netz: separates IoT-WLAN im 2,4-GHz-Band

Das Terminal kommuniziert über TLS-gesicherte TCP-Verbindungen zu mehreren Payment-Servern.

Die Symptome waren:

• sporadisch sehr langsame Zahlungsfreigaben bis hin zu Zahlungsabbrüchen
• gelegentliche Abbrüche beim Belegtransfer
• SSL-Handshake-Fehler im Terminal
• Ping-Spitzen von bis zu 4 Sekunden zum Terminal

Auffällig war, dass die Probleme an zwei Standorten mit jeweils der gleichen Hardware gleichzeitig auftraten.

Erste Hypothesen

Da EC-Zahlungen von vielen Komponenten abhängen, wurden zunächst verschiedene mögliche Ursachen geprüft:

Netzwerk / Router

• NAT-Timeouts
• TCP-Aging
• Firewall-Regeln
• MTU-Probleme
• DSL-Verbindungsprobleme

Payment-Backend

• Erreichbarkeit der Payment-Server
• TLS-Handshake
• DNS-Auflösung

Zur Überwachung wurde im Monitoring (Icinga2) eine regelmäßige Prüfung der Payment-Server implementiert:

• Ping
• TCP-Connect auf den relevanten Ports
• SSL-Zertifikatsprüfung

Diese Checks blieben jedoch stabil – die Payment-Server waren jederzeit erreichbar.

Der entscheidende Hinweis: Ping-Analyse

Ein Ping vom Router zum Terminal zeigte ein ungewöhnliches Muster:

4012 ms
3012 ms
2012 ms
1012 ms

Danach folgten wieder normale Werte im Bereich von 20–80 ms.

Dieses 4-3-2-1-Sekunden-Pattern trat regelmäßig auf.

Ein solches Verhalten ist typisch für WLAN-Frame-Buffering oder Power-Save-Mechanismen, bei denen Pakete verzögert gesammelt und anschließend in einem Burst zugestellt werden.

Das erklärt auch die TLS-Probleme: Ein TLS-Handshake reagiert empfindlich auf Verzögerungen von mehreren Sekunden.

WLAN-Analyse

Das EC-Terminal war über WLAN mit dem Router verbunden:

• Distanz: ca. 7 m
• freie Sicht
• Signalstärke: ca. 63 %

Das WLAN lief zunächst im Modus:

802.11b/g/n

Alle Energiesparmechanismen wie WMM-PowerSave waren bereits deaktiviert.

Da Embedded-Geräte häufig Probleme mit modernen WLAN-Features haben, wurde testweise der WLAN-Modus geändert.

Der entscheidende Test

Das IoT-WLAN wurde auf 802.11g only umgestellt.

Nach einem Neustart des Routers ergab ein neuer Ping-Test:

3–100 ms RTT
0 % Paketverlust
keine Ausreißer mehr > 500 ms

Seit dieser Umstellung liefen die EC-Terminals stabil.

Vermutete Ursache

Der wahrscheinlichste Auslöser ist die Interaktion zwischen:

• moderner 802.11n-Implementierung im LANCOM 1800VAW
• älterem WLAN-Stack im Ingenico Move/5000

802.11n führt mehrere Mechanismen ein, die WLAN effizienter machen:

• Frame-Aggregation (AMPDU)
• Block ACK
• größere MAC-Queues
• HT-Power-Save

Diese Features funktionieren hervorragend mit modernen Geräten wie Smartphones oder Laptops.

Embedded-Hardware in POS-Terminals hat jedoch oft vereinfachte WLAN-Stacks, die mit solchen Mechanismen nicht immer korrekt umgehen.

Empfohlene WLAN-Konfiguration für POS- oder IoT-Geräte

Für Zahlungsgeräte oder andere Embedded-Clients empfiehlt sich ein bewusst einfaches WLAN-Setup.

1. Eigenes IoT-WLAN

Separates SSID nur für Terminals.

2. Nur 2,4 GHz

Viele Geräte unterstützen nur dieses Band zuverlässig.

3. WLAN-Modus

802.11g only

Das deaktiviert komplexe 802.11n-Mechanismen.

4. Feste Kanäle

Beispielsweise:

Kanal 1, 6 oder 11

5. Energiesparmechanismen deaktivieren

• WMM Power Save
• aggressive Power-Save-Features

6. Moderne Verschlüsselung

WPA2 / AES-CCMP

Fazit

Die Fehlersuche zeigte einmal mehr, dass Netzwerkprobleme selten sofort offensichtlich sind. Obwohl zunächst der Zahlungsdienstleister verdächtigt wurde, lag die Ursache letztlich im WLAN.

Die wichtigsten Erkenntnisse:

• TLS-Fehler können auch durch WLAN-Latenzspitzen entstehen
• Embedded-Geräte reagieren empfindlich auf moderne WLAN-Features
• für POS-Terminals ist ein einfaches, stabiles WLAN oft besser als ein maximal optimiertes

Mit einem dedizierten IoT-WLAN im 802.11g-Modus laufen die EC-Terminals nun stabil.

Tipp für Administratoren

Wenn POS-Terminals sporadisch Probleme machen, lohnt sich ein einfacher Test:

ping -c 4 <Terminal-IP>

Wenn dabei sekundenlange Latenzspitzen auftreten, liegt die Ursache sehr wahrscheinlich im WLAN-Layer – nicht im Payment-Backend.

Solche Probleme sind selten dokumentiert, da sie nur in bestimmten Kombinationen aus Access Point und Embedded-Client auftreten. Umso wichtiger ist es, Erfahrungen aus der Praxis zu teilen.