WLAN Hotspot/Tethering Verbindungsprobleme und Paketverluste

F

forkbomb8

Neues Mitglied
0
Hallo,

ich habe seit einer Woche ein Huawei P10 plus mit AMUI 5.1 und Android 7.0.
Ich habe heute einen WLAN Hotspot mit dem Smartphone erstellt und festgestellt, dass die Verbindung sehr instabil (eigentlich komplett unbrauchbar) ist: In 80% der Fälle kann ich mich nichtmal zum mobilen Hotspot verbinden. Obwohl beide Geräte wenige cm voneinander entfernt liegen scheint die Sendeleistung des Hotspots manchmal auch sehr schwach zu sein. Sollte es dann doch mal klappen, dann braucht der Verbindungsaufbau zum einen ewig (20s bis 30s) und zum anderen steigt die Latez beim Pingen alle paar Sekunden auf über eine Sekunde.

Ich habe das Problem sowohl mit OSX, Win 10, als auch unter Linux nachstellen können. Selbst nach einem Factory Reset trat das Problem noch auf.

Mit meinem Galaxy S6 (Android 6.0.1) funktioniert das Ganze ohne Probleme. Nun stellt sich mir die Frage, ob es sich um ein Software-Problem handelt (wo ich ggf. nen Patch erwarten kann) oder, ob es wohl doch ein Hardwarefehler ist.

Google befragen hat mir leider auch nicht weitergeholfen und die Huawei Hotline rät auch nur zur Reperatur oder zum Umtusch (denen traue ich aber irgendwie nicht... sehr kompetent schien mir die Person am Telefon nicht gewesen zu sein).

Lässt sich dises Problem bei euch reproduzieren oder funktioniert der mobile Hotspot bei euch?

Wenn es bei einem Großteil ein ähnliches Verhalten zeigt, dann würde ich mal auf einen Softwarefehler tippen. Sollte dieses Verhalten allerdings keiner reproduzieren können, dann werde ich es wohl doch umtauschen gehen müssen.

Ich freue mich über jede Antwort :)

Nachtrag: Das Problem besteht anscheinend bei mir allg. beüglich WLAN. Der oben beschriebene Effekt tritt auch auf, wenn ich PC und Smartphone in meinem regulären WLAN habe :-(

VG FB

Hier mal ein Beispiel wie es unter Windows aussieht

C:\Users\fork>ping -t -w 2000 192.168.43.1

Pinging 192.168.43.1 with 32 bytes of data:
Request timed out.
Reply from 192.168.43.1: bytes=32 time=412ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.43.1: bytes=32 time=2ms TTL=64
Reply from 192.168.43.1: bytes=32 time=189ms TTL=64
Reply from 192.168.43.1: bytes=32 time=207ms TTL=64
Reply from 192.168.43.1: bytes=32 time=225ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.43.1: bytes=32 time=2ms TTL=64
Reply from 192.168.43.1: bytes=32 time=2ms TTL=64
Reply from 192.168.43.1: bytes=32 time=164ms TTL=64
Reply from 192.168.43.1: bytes=32 time=160ms TTL=64
Reply from 192.168.43.1: bytes=32 time=186ms TTL=64
Reply from 192.168.43.1: bytes=32 time=194ms TTL=64
Reply from 192.168.43.1: bytes=32 time=210ms TTL=64
Request timed out.
Reply from 192.168.43.1: bytes=32 time=548ms TTL=64
Reply from 192.168.43.1: bytes=32 time=7ms TTL=64
Reply from 192.168.43.1: bytes=32 time=176ms TTL=64
Reply from 192.168.43.1: bytes=32 time=198ms TTL=64
Reply from 192.168.43.1: bytes=32 time=218ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.43.1: bytes=32 time=427ms TTL=64
Reply from 192.168.43.1: bytes=32 time=13ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.43.1: bytes=32 time=183ms TTL=64
Reply from 192.168.43.1: bytes=32 time=205ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.43.1: bytes=32 time=582ms TTL=64
Reply from 192.168.43.1: bytes=32 time=2ms TTL=64
Reply from 192.168.43.1: bytes=32 time=210ms TTL=64
Reply from 192.168.43.1: bytes=32 time=225ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.43.1: bytes=32 time=25ms TTL=64
Request timed out.
Request timed out.
Reply from 192.168.43.1: bytes=32 time=599ms TTL=64
Reply from 192.168.43.1: bytes=32 time=4ms TTL=64
Reply from 192.168.43.1: bytes=32 time=214ms TTL=64
Request timed out.
Request timed out.

Ping statistics for 192.168.43.1:
Packets: Sent = 47, Received = 29, Lost = 18 (38% loss),
Approximate round trip times in milli-seconds:
Minimum = 2ms, Maximum = 599ms, Average = 199ms
 
Zuletzt bearbeitet:
Es gibt für Wlan genauso wie BT nur Standards aber keine festgelegte Norm. Von Gerät zu
Gerät kann Hardware und Software Inkompatiblität auftreten. Liegt es nur an der Software
lässt sich wenn vorhanden dies updaten.

Zum Beispiel bei der Fritzbox kamen vor geraumer Zeit Firmwareupdates raus zur Verbesserung
der Wlan Anbindung zu diversen Handys. D.H. es muss kein Hardwaredefekt sein.

Wenn Wlan Verbindungen nicht fehlerfrei funktioniert, kann man es einfacher testen wenn man
zum Test die Verschlüsselung kurz deaktiviert. Wenn es ohne Verschlüsselung besser funktioniert
kann es helfen eine feste Konfiguration zu verwenden > ohne DHCP.

Mit welchen Gerät/Adapter versuchst du das Handy zu verbinden?

Bisher habe ich mein LG G5 und das Huawei P10 Plus per Hotspot verbunden um die Daten
zu Clonen, es lief super mit ~8MB/s untereinander.
 
Zuletzt bearbeitet:
@Alphonse erst mal ein Dankeschön für deine Antwort.

Ich erstelle mit dem Smartphone den Mobile Hostspot [1].
Das Smartphone dienst also als WLAN Access Point und der PC verbindet sich direkt als WLAN Client dran.
In Kombination mit den unterschiedlichen PCs hatte ich folgende Adapter bzw. Chipsätze:
Linux - Intel Ultimate-N 6300
Win - TP-Link Archer T2UH
Mac - keine Ahnung was drin verbau ist (kann ich leider auch gerade nicht nachsehen)

[1] How To Set Up Mobile Hotspot On Huawei P10 And P10 Plus
 
Mit TP-Link hatte ich bisher keine gute Erfahrungen gemacht weil von einem Raum zum
anderen die Verbindung schon nicht mehr funktioniert hat, aber wenn das Handy direkt
daneben liegt sollte es funktionieren.

Wie sieht es aus wenn:
  • Du mobiles Internet am P10 nutzt?
  • Temporär die Verschlüsselung weck lässt?
  • Du dein S6 mit dem P10 Plus Hotspot verbindest?
  • Kein DHCP verwendest und IP's etc. manuell vergiebst?
 
@Alphonse

Ja, TP-Link WLAN Sticks sind wirklich nicht die besten, aber ich habe deswegen ja noch zwei andere Konfigurationen getestet ;-)

1. Mobile Daten funktionieren (ist ja aber auch erstmal egal, da hierfuer ein anderer Chipsatz zuständig ist)
2. Verschlüsselung weglassen macht es auch nicht besser (wäre allerdings auch keine Option für mich und wenn es daran läge, dann wäre das schon ein echtes Armutszeugnis)
3. Was soll es bringen das S6 an das P10+ zu verbinden?
4. Ich habe keine Option im gefunden, um beim mobilen WLAN-Hotspot DHCP zu deaktivieren. Das würde ggf. auch nur beim Verbindungsaufbau etwas bringen. Sobald die Verbindung allerdings steht sind die IPs ja zugewiese. Sollte daher keine Auswrkung auf Latenz haben (solange das Handz nicht alle 5s IPs neu zuweisen will... und das tut es nicht)

Langsam geht meine Vermutung in die Richtung Powersaving. Deswegen habe ich das Ping-Intervall nochmal auf 0.1s gesetzt damit das P10+ nicht die Gelegenheit bekommt WLAN in nen Sleep mode zu versetzen (das sollte bei nem mobilen Hotspot m.E. allerdings aber auch garnicht passieren).

Hier das Ergebnis

ping-png.565327


Mit gelegentlichen 100ms Ausreißern könnte ich ja leben... aber das hier ist regelrecht echt ein Witz!
Systematisch alle 5 bis 6 Sekunden lange Phasen mit extrem hohen Latenzen dürfte bei einem mobilen Hotspot eigentlich nicht auftreten, da VoIP, Streaming und Alles was Echtzeitanforderung hat nicht mehr effektiv nutzbar ist.

MfG Fork
 

Anhänge

  • ping.png
    ping.png
    5,5 KB · Aufrufe: 2.631
Zuletzt bearbeitet:
1. Gilt auch nur um zu wissen ob es hier mit dem Internet Schwierigkeiten gibt
3. Um eine Direkte Verbindung zu testen.
4. Nicht der Hotspot muss auf DCHP verzichten, der Client muss die Daten fest definiert haben.

Als Hotspot kannst du vorgeben welches Band verwendet werden soll. 2,4GHz oder 5GHz
Auch der Kanal lässt einstellen. Empfohlen wenn zuviele den selben nutzen einen anderen zu wählen.

Feste Daten zu verwenden beschleunigt nicht nur das verbinden, auch während des betriebes
erhöht das die Zuverlässigkeit einer Verbindung z.B. wenn die Latenz schlechter wird.

Verwendest du eine zusätzliche Speicherkarte? Es wäre nicht das erste mal das ein fehlerhaftes
Dateisystem oder beschädigte microSD für Instabilität sorgt. Bei meinem Vorgänger LG-G5 war
eine Sandisk der Auslöser für gesprächsabbrüche und spontane neustarts.
 
Ich habe das mal nachvollzogen und stellte ein gewöhnliches ICMP-Verhalten zu externen Zielen hin fest, dagegen verzögerte ICMP-Pakete nach dem ersten Ping auf das Gateway.


Bei einem Flush-Ping mit Rootrechten auf das Gateway hatte ich auch nach 32768 Paketen keine Packetverluste, aber eben stark verzögerte Antworten.


Ich benutzte ein T400s unter einer Fedora 25 mit einem WLAN-Chip Intel Ultimate N Wifi Link 5300, ein "lspci -s 03:00.0 - n" brachte mir das Paar HerstellerID:GeräteID 8086:4236.


Letzlich scheint es sich hier um eine Art Floodprotection am Gateway des P10 Plus zu handeln, die bekannten Angriffsvektoren vor allem auf diverse Windows-Clients vorbeugen will, indem sie ICMP-Nachrichten filtert und während dieser Behandlung verzögert. So ein Verhalten lässt sich durch eine Filterregel wie "iptables -A - p ICMP - m limit --limit 1/second -j ACCEPT" erzielen.


Verbindungen nach extern erschienen mir nicht beeinträchtigt und die normale Nutzung fürs "Surfen/Chatten/Mailen" sichergestellt.
 

Ähnliche Themen

I
Antworten
0
Aufrufe
508
ilias1969
I
Z
  • zero2000
Antworten
5
Aufrufe
8.067
Bladefs
B
H
  • Horgul123
Antworten
11
Aufrufe
4.385
DroydFreak
DroydFreak
Zurück
Oben Unten