Tag Archives: bug

Android: FireFox und das WiFi-Tickling

Posted on by

Und auch heute wieder ein Beitrag aus der Kategorie „Niemals genauer hinschauen“ :

Wie im Beitrag gestern über Tastatureingaben, die an Suchmaschinen geschickt werden, habe ich auch heute wieder was aus meinem neuesten Projekt für Euch. Euer lieber Firefox bombardiert das Gateway mit scheinbar unsinnigen Paketen:

16:05:52.958119 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:52.973897 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:52.990415 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.018183 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.023820 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.040692 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.058932 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.075325 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.091926 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.108330 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.124708 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0
16:05:53.141359 IP 192.168.20.3.59077 > 1.0.0.0.4886: UDP, length 0

In einem Bugreport an Firefox wird das genauer geschildert:

FireFox Android 5.1

FireFox Android 5.1

„If you’re on wifi and an IPv4 DHCP network we will send 0 length UDP packets at port 4886 of your gateway at the default rate of 60hz for 400ms from the start of the transaction in an attempt to improve RTT during the critical early phases. I call this „tickle time“. “

Nur so ganz stimmt das nicht, denn 1.0.0.0 gehört nicht meinem Router, sondern ist den Arpa-Laps zugeordnet und auch an sich eher nicht routbar, genau wie 10.0.0.1/8 und ähnliche private Netzwerke.

RTT steht dann für RoundTripTime und der Sinn des Ganzen ist, daß das Antwortverhalten vom WLAN Router verbessert wird, weil er sieht, daß da „massiv“ Pakete kommen und er die echten Pakete dann schneller routet, weil die ja wichtig sind.

Hier zu merken ist: Das macht nur Firefox so, ergo: sieht man son Traffic, weiß man, es ist ein Android Phone mit FireFox, der grade aktiv genutzt wird. Das wir das noch brauchen werden, werdet Ihr bald sehen 🙂

mehr dazu:  https://bugzilla.mozilla.org/show_bug.cgi?id=888268

Warnung vor Kernel 4.8.13 – 32Bit

Aufgrund von Tests auf unserer Serverfarm, kann man nur vor dem Einsatz von Kernel 4.8.13 warnen. Lediglich wenig genutzte Rechner kommen dafür in Frage. Die Testserver unserer Farm fielen nach wenigen Stunden durch wahre OOM-Killer Amokläufe aus, obwohl nicht ein BIT Swap Speicher genutzt wurde, oder der reale Hauptspeicher auch nur annähernd erschöpft gewesen wäre.

Die Ursache kann daher nur Speicherfragmentierung sein. Es gibt zwar in Summe genug Hauptspeicher, aber nicht genug zusammenhängenden Speicher um Anfragen zu befriedigen.

Kernel 4.9+ soll Abhilfe schaffen. Glücklicherweise wurde der grade freigegeben.

Gnomefehler bei Libinputupdate beheben

Posted on by

Da kommt aus heiterem Himmel ein Update für Cinnamon und Gnome kann plötzlich nicht mehr richtig mit der Maus scrollen. Und jetzt ?

In dem Beitrag über die Anpassungen zu den Mausgeschwindigkeiten, die bei Gnome set einiger Zeit nicht mehr sauber funktionieren, wird gezeigt, wie man sein Eingabegerät ermittelt:

~]$ xinput list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ ImPS/2 BYD TouchPad id=11 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ Power Button id=6 [slave keyboard (3)]
↳ Power Button id=7 [slave keyboard (3)]
↳ UVC Camera (046d:081b) id=8 [slave keyboard (3)]
↳ Eee PC WMI hotkeys id=9 [slave keyboard (3)]
↳ AT Translated Set 2 keyboard id=10 [slave keyboard (3)]

Meins ist die ID 11, was an einem bekannten Kernelbug zur Erkennung von Touchpads liegt.

Seit dem besagten Update scrollte meine Maus mit dem Scrollrad falsch rum, was unter Cinnamon komischerweise korrekt funktionierte.  Dank der Liste verfügbarer Eigenschaften des „Touchpads“ :

~]$ xinput list-props 11
Device 'ImPS/2 BYD TouchPad':
    Device Enabled (151):    1
    Coordinate Transformation Matrix (153):    1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
    libinput Accel Speed (289):    -0.500000
    libinput Accel Speed Default (290):    0.000000
    libinput Accel Profiles Available (291):    1, 1
    libinput Accel Profile Enabled (292):    1, 0
    libinput Accel Profile Enabled Default (293):    1, 0
    libinput Natural Scrolling Enabled (294):    1
    libinput Natural Scrolling Enabled Default (295):    0
    libinput Send Events Modes Available (273):    1, 0
    libinput Send Events Mode Enabled (274):    0, 0
    libinput Send Events Mode Enabled Default (275):    0, 0
    libinput Left Handed Enabled (296):    0
    libinput Left Handed Enabled Default (297):    0
    libinput Scroll Methods Available (298):    0, 0, 1
    libinput Scroll Method Enabled (299):    0, 0, 0
    libinput Scroll Method Enabled Default (300):    0, 0, 0
    libinput Button Scrolling Button (301):    2
    libinput Button Scrolling Button Default (302):    274
    libinput Middle Emulation Enabled (303):    0
    libinput Middle Emulation Enabled Default (304):    0
    Device Node (276):    "/dev/input/event3"
    Device Product ID (277):    2, 5
    libinput Drag Lock Buttons (305):    <no items>
    libinput Horizonal Scroll Enabled (278):

konnte ich mit einem Einzeiler die Scrollrichtung wieder umdrehen:

xinput set-prop 11 289 -0.5 2>/dev/null           # Mausgeschwindigkeit mit LibInput
xinput set-prop 11 294 0 2>/dev/null                # Scrollradrichtung

Komisch, das sowas im Testlauf nicht gefunden wird…

Update: 13.12.2016

Der neue Kernel 4.8.13 behebt das Problem, weil die PS/2 Mäuse jetzt als Maus erkannt werden un dnicht mehr als Touchpads.