Posts Tagged ‘Upgrade’

Dienstag, 26. April 2022

Firmware des MagSafe Battery Packs aktualisieren

Apple hat kürzlich ein Firmware-Upgrade 2.7.0 für sein MagSafe Battery Pack veröffentlicht, welches die Ladegeschwindigkeit von 5 Watt auf 7.5W erhöht.

MacRumors hat darüber berichtet und ein How To veröffentlicht.

Die Firmware aktualisiert man am Besten, indem man das Battery Pack mit einem Lightning-auf-USB-C-Kabel an einen Mac oder ein iPad anschliesst. Ausser anschliessen kann man nichts tun; das Update wird vom Betriebssystem anschliessend selbständig eingespielt.

Beim Battery Pack meiner Frau (Firmware-Version: 2.5.0b) klappte das Upgrade innert 1-2 Minuten nachdem ich es an mein MacBook Air M1 angeschlossen hatte.

Mein Battery Pack (Firmware-Version: 2.0.2c) hing mit demselben Kabel für ca. 15 Minuten an meinem Mac mini M1 (macOS Monterey 12.3.1), ohne dass sich etwas tat. Danach schloss ich es an das MacBook Air (macOS Big Sur 11.6.5) an, doch auch hier tat sich nach 10 Minuten nichts.

Ohne grosse Hoffnung schloss ich das Battery Pack schlussendlich noch an ein Lightning-auf-USB-A-Kabel an, welches am Thinkvision-Monitor meines Arbeitgebers angeschlossen ist. Der Monitor ist mit Thunderbolt/USB-C an einem älteren MacBook Pro (macOS Big Sur 11.6.5) angehängt.

Und siehe da: Nachdem ich einige Emails beantwortet hatte und das Battery Pack vergessen hatte, öffnete ich nach ungefähr 5-10 Minuten Apfel-Menu > About this Mac > System Report > USB, wählte das MagSafe Battery Pack in der Liste aus, und siehe da:

MagSafe Battery Pack:

  Product ID:	0x1399
  Vendor ID:	0x05ac (Apple Inc.)
  Version:	27.0b
  Serial Number:	DL2FJGDE0NLJ
  Speed:	Up to 12 Mb/s
  Manufacturer:	Apple Inc.
  Location ID:	0x01100000 / 1
  Current Available (mA):	500
  Current Required (mA):	500
  Extra Operating Current (mA):	1900
  Sleep current (mA):	2400

Wieso der Version ein Punkt fehlt, ist mir schleierhaft. Als Originalversion stand in diesem Dialogfeld 20.2c, beim Battery Pack meiner Frau 25.0b.

Tipp: Wer den System Report geöffnet hat, kann mittels Apfel-R den Baum neu anzeigen lassen. Sollte die Firmware in der Zwischenzeit aktualisiert worden sein, spiegelt sich dass im Feld Version entsprechend wieder.

Sonstige Links: Diskussion bei Apfeltalk, Meldung bei Heise sowie Allgemeiner Support-Artikel von Apple.

Tags: , , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 16. Dezember 2021

g.fast SFP in Turris Omnia debuggen (leider erfolglos)

Grosser Nachtrag

vom 12. Februar 2022

Ich habe mir in der Zwischenzeit bei Engitech einen zweiten SFP bestellt.

Heute pröbelte ich mehrere Stunden mit dem Router herum. Auch der neue SFP konnte keine Verbindung aufbauen.

Beim Durchstöbern des irgendwie völlig neu ausschauenden Foris GUIs blieb ich auf der Unterseite Snapshots hängen. Und was sieht mein Auge da: Am 15. Dezember gab es Update-Aktivitäten! Und zwar wurde um 16:26 Uhr ein „Automatic pre-update snapshot“ angefertigt, und um 16:34 Uhr ein „Automatic post-update snapshot (TurrisOS 5.3.3)“. Also genau dann, als meine Internetverbindung gekappt wurde.

Eine böse, böse Vorahnung beschlich mich — und tatsächlich, nachdem ich auf TurrisOS 3.11.23 downgegradet hatte („Rollback“, dann Reboot), lief der SFP wieder und ich konnte eine Internet-Verbindung herstellen.

Da ich ein Problem mit 5.3.3 vermutete, installierte ich daraufhin TOS 5.3.5 (per SSH auf den Router einloggen, dann updater.sh ausführen). Doch das Problem bestand bei dieser neueren Version weiter.

Doch jetzt hatte ich die nötigen Indizien, mich in den Turris-Foren nach anderen Opfern herumzuschauen, und tatsächlich: No SFP connectivity after upgrade from 3.x, und sogar ein Init7-Kunde.

Wenn ich die Bemerkung Turris OS 5.0+ no longer supports switching between SFP and metallic in runtime im Artikel zum Upgrade TOS 3.x auf 5.x richtig verstehe, wird beim Update der SFP deaktiviert und stattdessen die mit dem SFP „geteilte“ Ethernetschnittstelle reaktiviert. KEIN WUNDER GEHT DANN (BEI MIR, UND ANDEREN SFP-BENUTZERN) GAR NICHTS MEHR. Heise hat einen Leser schon vor zwei Jahren darauf hingewiesen, wie er das Problem beheben kann.

Ah, und auch das Rätsel ist gelöst: WAN interface that was originally labeled in the system as eth1 is now eth2.

Morgen Sonntag, während Stephanie am Brunchen ist, werde ich also den Router erneut lüpfen, den Device Tree Blob (dtb) umbiegen und so hoffentlich den SFP wieder hochkriegen. Bye bye FrickelBox, eh Fritz!Box.


Heute am 15. Dezember 2021 um 16:34 Uhr fiel bei uns das Internet aus: Copper7 über g.fast (meine vom 1. Oktober bis heute, dem 15. Dezember 2021, verwendeten Komponenten sind hier beschrieben).

Zuerst war ich der Meinung, dass es sich um einen Ausfall von Swisscom oder Copper7 handelt, doch als die Internetverbindung auch nach einer Stunde und einem Reboot des Turris Omnia immer noch getrennt war, machte ich mich ans Debugging.

Leider habe ich die Internetverbindung mit dem g.fast SFP im Turris Omnia bis jetzt nicht mehr zum Laufen gebracht. Wie im oben verlinkten Artikel beschrieben hatte ich die von Init7 gelieferte AVM Fritz!Box 7582 noch im Lager, und diese hat nun (leider) den Turris Omnia ersetzt. Ich hoffe nur temporär …

Derzeit sehe ich zwei Möglichkeiten:

  • Swisscom hindert diesen spezifischen SFP seit heute an der Verbindungsaufnahme
  • Der SFP hat nach 75 Tagen Dauerbetrieb (teilweise) den Geist aufgegeben

Um den Fehler einzugrenzen habe ich die letzten Stunden noch etwas rumgepröbelt, nachdem unsere Wohnung wieder ans Netz kam.

  • Das Turris Omnia OS (TOS) ist 5.3.3
  • Der Turris Omnia SFP-Port heisst eth2 (mysteriös, denn auf den Screenshots vom Oktober habe ich eth1 mit PPPoE konfiguriert)
  • Ohne den SFP eingeschoben zu haben, gibt ethtool folgendes aus (MII = Media Independent Interface?):
    # ethtool eth2
    Settings for eth2:
    	Supported ports: [ MII ]
    	Supported link modes:   10baseT/Half 10baseT/Full
    	                        100baseT/Half 100baseT/Full
    	                        1000baseT/Full
    	Supported pause frame use: Symmetric
    	Supports auto-negotiation: Yes
    	Supported FEC modes: Not reported
    	Advertised link modes:  10baseT/Half 10baseT/Full
    	                        100baseT/Half 100baseT/Full
    	                        1000baseT/Full
    	Advertised pause frame use: Symmetric
    	Advertised auto-negotiation: Yes
    	Advertised FEC modes: Not reported
    	Speed: 10Mb/s
    	Duplex: Half
    	Port: MII
    	PHYAD: 0
    	Transceiver: internal
    	Auto-negotiation: on
    	Supports Wake-on: d
    	Wake-on: d
    	Link detected: no
  • Mit eingeschobenen SFP sieht die Ausgabe folgendermassen aus (TP = Twisted Pair?):
    # ethtool eth2
    Settings for eth2:
    	Supported ports: [ TP ]
    	Supported link modes:   1000baseX/Full
    	Supported pause frame use: Symmetric
    	Supports auto-negotiation: Yes
    	Supported FEC modes: Not reported
    	Advertised link modes:  1000baseX/Full
    	Advertised pause frame use: Symmetric
    	Advertised auto-negotiation: Yes
    	Advertised FEC modes: Not reported
    	Speed: 1000Mb/s
    	Duplex: Full
    	Port: Twisted Pair
    	PHYAD: 0
    	Transceiver: internal
    	Auto-negotiation: on
    	MDI-X: Unknown
    	Supports Wake-on: d
    	Wake-on: d
    	Link detected: no
  • Informationen über das SFP-Modul gibt man folgendermassen aus (werden Informationen angezeigt, bedeutet das gleichzeitig auch, dass der SFP erkannt wurde und funktioniert):
    # ethtool -m eth2
    	Identifier                                : 0x03 (SFP)
    	Extended identifier                       : 0x04 (GBIC/SFP defined by 2-wire interface ID)
    	Connector                                 : 0x22 (RJ45)
    	Transceiver codes                         : 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00
    	Transceiver type                          : Ethernet: 1000BASE-SX
    	Encoding                                  : 0x01 (8B/10B)
    	BR, Nominal                               : 1300MBd
    	Rate identifier                           : 0x00 (unspecified)
    	Length (SMF,km)                           : 0km
    	Length (SMF)                              : 0m
    	Length (50um)                             : 0m
    	Length (62.5um)                           : 0m
    	Length (Copper)                           : 255m
    	Length (OM3)                              : 0m
    	Laser wavelength                          : 0nm
    	Vendor name                               : PROSCEND
    	Vendor OUI                                : 00:00:00
    	Vendor PN                                 : 190-T
    	Vendor rev                                : V7.3
    	Option values                             : 0x08 0x00
    	Option                                    : Retimer or CDR implemented
    	BR margin, max                            : 0%
    	BR margin, min                            : 0%
    	Vendor SN                                 : XXXXXXXXXXXXXXXX
    	Date code                                 : 210528__
  • Wenn kein SFP eingesteckt ist:
    # ethtool -m eth2
    Cannot get Module EEPROM data: No such device or address
  • Wenn es sich um keinen SFP Slot handelt:
    # ethtool -m eth0
    Cannot get module EEPROM information: Not supported
  • Wird der SFP eingesteckt, findet man unter /var/log/messages folgende Mitteilung:
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.802636] sfp sfp: module PROSCEND         190-T            rev V7.3 sn XXXXXXXXXXXXXXXX dc 28-05-21
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.811981] sfp sfp:   unknown connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.820179] sfp sfp:   1000BaseSX+ 1000BaseLX- 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX-
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.830301] sfp sfp:   10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.836590] sfp sfp:   Wavelength 0nm, fiber lengths:
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.841657] sfp sfp:     9µm SM    : unsupported
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.846371] sfp sfp:  62.5µm MM OM1: unsupported/unspecified
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.852135] sfp sfp:    50µm MM OM2: unsupported/unspecified
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.857893] sfp sfp:    50µm MM OM3: unsupported/unspecified
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.863657] sfp sfp:    50µm MM OM4: 2.540km
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.868023] sfp sfp:   Options: retimer
    Dec 15 23:22:36 TURRIS-OMNIA kernel: [  974.871871] sfp sfp:   Diagnostics:
  • Mittels ip a sieht man noch weitere Infos — interessant ist NO-CARRIER (zu dem Zeitpunkt war das ADSL-Kabel nicht eingesteckt):
    ...4: eth2:  mtu 1500 qdisc mq state DOWN group default qlen 532
        link/ether XX:XX:XX:XX:XX:XX brd ff:ff:ff:ff:ff:ff
  • Den SFP kann man über den i2c Bus abfragen. Bei mir ist der SFP unter /dev/i2c-5 ansprechbar. XXX ist die Seriennummer, YYY ist die MAC-Adresse:
    # i2cdump 5 0x50
    No size specified (using byte-data access)
    WARNING! This program can confuse your I2C bus, cause data loss and worse!
    I will probe file /dev/i2c-5, address 0x50, mode byte
    Continue? [Y/n] y
         0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f    0123456789abcdef
    00: 03 04 22 00 00 00 01 00 00 00 00 01 0d 00 00 00    ??"...?....??...
    10: 00 00 ff 00 50 52 4f 53 43 45 4e 44 20 20 20 20    ....PROSCEND
    20: 20 20 20 20 00 00 00 00 31 39 30 2d 54 20 20 20        ....190-T
    30: 20 20 20 20 20 20 20 20 56 37 2e 33 00 00 00 fe            V7.3...?
    40: 08 00 00 00 31 39 32 30 37 4b 35 38 39 32 31 35    ?... XXXXXXXXXXX
    50: 30 30 34 38 32 31 30 35 32 38 00 00 00 00 00 92    XXXXXXXXXX.....?
    60: 30 30 30 45 41 44 34 41 30 36 41 38 00 00 00 00    YYYYYYYYYYYY....
    70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
    80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
    90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
    a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
    b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
    c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
    d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
    e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
    f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff    ................
  • Entfernt man den SFP, erscheint folgender Eintrag in /var/log/messages:
    Dec 15 23:21:22 TURRIS-OMNIA kernel: [  901.123920] sfp sfp: module removed

Tags: , , , , , , , , , , , , , , , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Sonntag, 19. Januar 2020

Einen Sony Bravia OLED KD-65AG8 auf Android TV 8 lüpfen

Gleich nach der Installation des neuen TVs öffnete ich die Einstellungen des Geräts und führte eine Suche nach Software-Aktualisierungen durch. Der TV, damals noch mit Android TV 7 ausgestattet, meldete mir, dass die Software auf dem neuesten Stand sei.

Ich wusste, dass das nicht stimmen konnte. Ich ging deshalb auf die Web-Site von Sony Schweiz und fand das gewünschte Update unter folgendem Link: Firmware-Update auf V6.6545 (via KD-65AG8 > Downloads

Die 1.8 GB grosse Datei herunterladen, auf einen USB-Stick kopieren, den USB-Stick an einem beliebigen USB-Anschluss des TVs einstecken — und schnurstracks installiert das Gerät das Update (der Benutzer wird nicht gefragt, ob er wirklich updaten möchte).

Der Unterschied zwischen den beiden Android TV-Versionen wird im folgenden Video gut gezeigt:

Beim KD-55AF8 waren im Juli 2019 noch andere Handstände nötig, um Android einzuspielen. Dies, weil Sony das Update damals noch nicht an die grosse Glocke gehängt hat. Ich habe mir notiert, dass ich mir damals die Datei sony_dtvota_2016_1606520100_eua_auth.zip suchen und herunterladen musste, welche damals auf irgendeinem Sony-Server in Japan herumlagen. Ich glaube, bin mir aber nicht sicher, dass ich mich von diesem Video habe anleiten lassen, um an die ZIP-Datei zu gelangen.

Tags: , , , , , , , , ,
Labels: Unterhaltungselektronik

Keine Kommentare | neuen Kommentar verfassen

Freitag, 29. September 2017

iOS 11 bereitet meinem iPhone (und mir) Kopfschmerzen

Normalerweise warte ich bei Major-Releases von iOS jeweils die Version X.0.1 ab, bevor ich meinen Gerätepark auf die neue Version des mobilen Betriebssystems „lüpfe“. Diese Woche hielt ich mich nicht an meine eiserne Regel — unter anderem, weil die Medienberichterstattung nicht von gravierenden Problemen berichtete. Ein Fehler, der aber auch nicht mit Abwarten auf X.0.1 Linderung gebracht hätte.

Leider kämpfe ich auf meinem iPhone SE (Kaufdatum: April 2016) mit folgenden permanenten oder sporadisch auftretenden Problemen:

  • Das Gerät ist spürbar langsamer als unter iOS 10 — sowohl das Betriebssystem selber als auch die Applikationen. Wenn ich Podcasts höre und dann Applikationen öffne oder bediene, höre regelmässig verzerrtes Audio, als würde die Podcast-Applikation mit der laufenden Applikation um Systemressourcen kämpfen. Mit der Haptik und der Reaktion fühlt sich das UI eher wie Android als iOS an. Furchtbar! Derzeit tippe ich Probleme mit dem Netzwerkstack (Bauchgefühl, kann ich nicht belegen).
  • Das Thumbnail für soeben gemachte Screenshots wird einige Male nach einem Reboot des Geräts angezeigt, dann nicht mehr. Nach einer Weile macht das Telefon nicht nur kein Geräusch, wenn ich den Bildschirm abfotografiere, sondern das Thumbnail zur Nachbearbeitung wird auch nicht mehr angezeigt. Das Photo selber landet aber anstandslos im Photoalbum. Dabei wäre dies eine der besten Produktivitätssteigerungen mit diesem iOS-Release.
  • Heute verschwand die Statusanzeige (Empfangsstärke 4G/WiFi, Uhrzeit, Batterieanzeige) ganz oben am Bildschirm, wenn der Homescreen und alle anderen Springboard-Screens angezeigt wurde. In den Applikationen selber wurde die Statusanzeige ohne Probleme angezeigt. Ein Neustart behob das Problem.
  • Mail.app hängt regelmässig, wenn ich meine Mails über IMAP und Gmail abrufe. Das Spinning-Icon dreht und dreht, ohne dass die Unified INBOX je aktualisiert wird. Ich muss dann jeweils Mail.app gewaltsam schliessen und neu starten, damit die neuen Mails heruntergeladen werden.
  • Vor einigen Tagen zeigte Waze nach dem Start nur einen schwarzen Bildschirm an. Ich konnte die App nicht starten.
  • Die Sonos-App zeigt nach der Ankunft Zuhause während mehreren Minuten den Splash-Screen an, und stürzt dann urplötzlich ab.

Es bleibt zu hoffen, dass Apple der Ursache des Problems auf der Spur ist und bald mit X.0.2 Abhilfe schafft.

PS: Das Problem beschränkt sich nicht nur auf mein iPhone SE — meine Frau klagt auch mit ihrem iPhone 6s ebenfalls über spürbare Performanceprobleme.

Tags: , , , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 29. Juni 2016

StatusCake funktioniert mit Hostpoint nicht mehr

Vor einigen Monaten wurde ich durch die Ankündigung einer Preiserhöhung beim schwedischen Pingdom aufgeschreckt und sah mich deshalb etwas genauer auf dem Markt für Web-Site-Monitoring herum.

Fündig wurde ich beim us-amerikanischen StatusCake, welches kostenloses Monitoring einer unlimitierten Zahl an Web-Sites bietet — sofern man damit leben kann, das Checks nur alle fünf Minuten erfolgen. Im Nu hatte ich um die 50 Tests eingerichtet — von SSH, OpenVPN, PPTP über ordinäres HTTP/S bis hin zu Dashboards, welche Laufzeitdaten zusammenziehen und mich mittels von 200 abweichenden HTTP-Codes bei Problemen warnen.

Das Monitoring funktionierte wunderprächtig, bis Hostpoint letzte Woche damit begann, von Apache 2.2 auf Apache 2.4 zu migrieren:

Apache Update

21.06.2016, 00:00 Uhr – 31.07.2016, 00:00 Uhr

Wir aktualisieren derzeit auf sämtlichen Server die Apache Version von 2.2 auf 2.4. Dieses Update ist grösstenteils transparent, nur in den unten aufgeführten Szenarien muss eine Anpassung vorgenommen werden. Für das Update wird es eine Unterbrechung von wenigen Sekunden geben.

HTTP/2

Neu Unterstützen wir mit Apache 2.4 das Protokoll HTTP/2. Dieses steigert die Effizienz bei der Kommunikation zwischen Browser und Server: Mehr Durchsatz, mehr Parallelität, weniger Latenz. Vor allem moderne web-2.0-typische Webseiten mit vielen kleinen Resourcen profitieren davon. Voraussetzung für HTTP/2 ist eine TLS geschützte Verbindung (SSL Zertifikat). Dieses steht dank FreeSSL all unseren Kunden zur Verfügung.

Quelle: Hostpoint – Statusseite

Wahrscheinlich seit der Migration auf die neue Web-Server-Version meldete StatusCake für jede meiner bei Hostpoint gehosteten Web-Sites Folgendes:

StatusCake - Geschichtstage Down
image-6773

Die konkreten Ausfallzeiten sind:

bibliothek-neuenegg.ch
2016-06-21 13:02:54 (Server: sl51.web.hostpoint.ch / s20)
sek-neuenegg.ch
2016-06-21 13:09:48 (Server: sl58.web.hostpoint.ch / s27)
geschichtstage.ch
2016-06-27 12:41:58 (Server: sl103.web.hostpoint.ch / s36)
ahc-ch.ch
2016-06-27 12:44:38 (Server: sl103.web.hostpoint.ch / s36)

Erste Anlaufstelle: Hostpoint

Zuerst dachte ich mir: Klarer Fall, da hat Hostpoint geschludert.

Ich kontaktierte dementsprechend deren Support am 28. Juni um 14:51 Uhr, um 17:22 Uhr erhielt ich die fachkundige Antwort von Jonas. Mittels eines Auszugs aus dem Domain Log legte er mir glaubwürdig dar, dass die StatusCake Probes den Server der Bibliothek Neuenegg bis heute alle fünf Minuten anpingen:

...
107.170.219.46 - - [28/Jun/2016:16:45:57 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
107.170.227.23 - - [28/Jun/2016:16:51:00 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
217.148.43.202 - - [28/Jun/2016:16:56:00 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
37.235.48.42 - - [28/Jun/2016:17:01:29 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
46.101.110.32 - - [28/Jun/2016:17:06:37 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
...

Eine manuelle Kontrolle meinerseits zeigte, dass dies auch bei allen anderen oben genannten Servern der Fall war.

Der Web-Server antwortet auf die HTTP/1.1-Anfrage mittels des HTTP-Codes 200 und liefert 8770 Bytes an Daten zurück. Ein kurzer Test mit wget von soeben zeigt, dass das durchaus hinkommt (wget erhält „nur“ 8697 Bytes zurück, also ca. 100 Bytes weniger — dies auf Grund einer Anpassung im Inhalt der Homepage; sprich: vernachlässigbar):

$ wget bibliothek-neuenegg.ch
--2016-06-29 19:34:30--  http://bibliothek-neuenegg.ch/
Auflösen des Hostnamens »bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)« … 217.26.52.30
Verbindungsaufbau zu bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)|217.26.52.30|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 301 Moved Permanently
Platz: https://bibliothek-neuenegg.ch/ [folgend]
--2016-06-29 19:34:31--  https://bibliothek-neuenegg.ch/
Verbindungsaufbau zu bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)|217.26.52.30|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »»index.html«« gespeichert.

index.html            [ <=>                ]   8,49K  --.-KB/s    in 0s      

2016-06-29 19:34:31 (49,4 MB/s) - »index.html« gespeichert [8697]

Zweite Anlaufstelle: StatusCake

Nun gut. Dementsprechend stellte ich alle wichtigen Infos zusammen, die einem Second-Level-Supporter nützlich erscheinen könnten und kontaktierte am selben Tag um 19:09 Uhr Schweizer Zeit den Support von StatusCake. Dan antwortete mir am folgenden Tag um 11:07 Uhr morgens, ging aber wie von us-amerikanischem Support-Personal gewohnt überhaupt nicht auf mein Anliegen ein. Stattdessen erhielt ich wohl einen Knowledge-Base-Artikel als Standardantwort:

We use a large global network of testing servers, it’s looking to me like you may need to whitelist our IPs on these servers, you can grab our full lists here – https://www.statuscake.com/kb/knowledge-base/what-are-your-ips/

9 Minuten später hatte ich ihm bereits geantwortet (wenn man einen Supporter schon mal „dran“ hat, sollte man ihn nicht mehr gehen lassen): Ich wies ihn darauf hin, dass die Apache Access Logs zeigen, dass die Server alle fünf Minuten Besuch von der Probe bekämen, Whitelisting also definitiv nicht das Problem sei.

Um 15:43 Uhr schrieb mir Dan zurück:

Had a look into this one. The only thing I can see that might be causing this is the introduction of HTTP/2, we don’t currently support this and will be giving a down result for any HTTP/2-only enabled sites.

Immerhin schien er die Status-Seite von Hostpoint aufgerufen und dort gelesen zu haben, dass HTTP/2 eingeführt wurde. Das wäre durchaus ein Ansatz, doch wieso taucht die Probe dann mit HTTP/1.1 in den Logs auf? Ich habe Dan zurückgeschrieben, doch bis jetzt ist noch keine weiterführende Antwort eingetrudelt. Ich bleibe dran!

Test mit wget

In der Zwischenzeit kam mir nun auch noch die Idee, dass der Web-Server vielleicht auf Grund des StatusCake User-Agents plötzlich meint, dass die Gegenseite fähig ist, HTTP/2 zu sprechen — und die Verbindung auf HTTP/2 upgradet.

Mit meinem lokal installierten wget probierte ich es aus:

$ wget --server-response --user-agent="Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)" https://www.bibliothek-neuenegg.ch/
--2016-06-29 19:47:56--  https://www.bibliothek-neuenegg.ch/
Auflösen des Hostnamens »www.bibliothek-neuenegg.ch (www.bibliothek-neuenegg.ch)« … 217.26.52.30
Verbindungsaufbau zu www.bibliothek-neuenegg.ch (www.bibliothek-neuenegg.ch)|217.26.52.30|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
  HTTP/1.1 200 OK
  Date: Wed, 29 Jun 2016 17:47:56 GMT
  Server: Apache/2.4
  X-Powered-By: PHP/7.0.7
  Set-Cookie: PHPSESSID=dbneu9nses8n52ge8i4esj72b1; path=/
  Expires: Thu, 19 Nov 1981 08:52:00 GMT
  Cache-Control: no-store, no-cache, must-revalidate
  Pragma: no-cache
  Upgrade: h2,h2c
  Connection: Upgrade, Keep-Alive
  X-Frame-Options: SAMEORIGIN
  X-Content-Type-Options: nosniff
  Keep-Alive: timeout=5, max=100
  Transfer-Encoding: chunked
  Content-Type: text/html; charset=utf-8
Länge: nicht spezifiziert [text/html]
Wird in »»index.html«« gespeichert.

index.html                   [ <=>                              ]   8,49K  --.-KB/s    in 0s      

2016-06-29 19:47:56 (30,9 MB/s) - »index.html« gespeichert [8697]

Wie man sieht antwortet der Hostpoint-Server brav mit HTTP/1.1 200 OK (wget spricht KEIN HTTP/2; hätte der Server also — nicht-standardkonform notabene — mit HTTP/2 geantwortet, hätte wget mir einen Fehler angezeigt.).

Dritte Reaktion: Hostpoint entdeckt Blog-Post

Heute (1. Juli 2016) trudelte kurz nach 11 Uhr morgens eine neue Nachricht zu meinem eigentlich als geschlossen geglaubten Support-Ticket bei Hostpoint ein: Jessica nahm Bezug auf meinen kürzlich veröffentlichten Blog-Artikel und teilte mir mit, dass die Angelegenheit intern noch einmal genauer angeschaut worden war. Sie war es, welche mir in diesem E-Mail den entscheidenden Hinweis gab:

StatusCake scheint NodeJS zu verwenden. Dieses hat einen Bug, wenn Apache einen Upgrade Header mitschickt. Dies ist HTTP-Konform und ist so korrekt.

Sie können die Details in folgendem Threads nachlesen:

NodeJS unable to make https requests when h2 enabled in Apache 2.4.18 #73
http: do not emit `upgrade` on advertisement #4337

Hostpoint hatte mit ein wenig Recherche herausgefunden, dass ältere Versionen von NodeJS HTTP/HTTPS-Verbindungen zu Web-Servern abbrechen, wenn dieser mit einer HTTP/2-Upgrade-Anforderung antwortet. Und irgendwie hatte Hostpoint weiter bemerkt, dass StatusCake höchstwahrscheinlich NodeJS für die Abfragen einsetzt.

Klasse, genau solches Debugging liebe ich an meinem Beruf so sehr — und umso mehr freut es mich, wenn sich Dienstleister in einen Bug verbeissen und alles tun möchten, um diesen zu beheben.

Ich bedankte mich bei Jessica und wendete mich anschliessend gleich Dan von StatusCake zu.

Vierte Reaktion: StatusCake

Da ich von Dan seit meiner Rückmeldung nichts mehr gehört hatte, antwortete ich erneut auf sein letztes Mail und beschrieb ihm auf Englisch die von Hostpoint vermutete Ursache hinter dem Problem. Ich hatte ehrlich gesagt nicht viel Hoffnung, dass ich jemals wieder von StatusCake hören würde (Kunde, der (noch) keinen Umsatz generiert, und mit komischen Problemen nervt) — doch ich täuschte mich auch hier.

Um 11:35 Uhr ging meine Anfrage an Dan raus, um 11:44 Uhr (innert 9 Minuten!) lag bereits seine Antwort in der INBOX. Und dieses Mal nichts aus der Büchse, sondern eine tatsächlich auf meine Anfrage Bezug nehmende Antwort.

Dies wahrscheinlich aus verschiedenen Gründen:

  • Ich teilte ihm mit, dass Hostpoint der grösste Hoster in der Schweiz sei
  • Ich erwähnte NodeJS
  • Ich erwähnte die Nachricht von Jessica von Hostpoint und fügte die Links auf die NodeJS-Bugs ein
  • Ich erwähnte, dass auf Grund der weltweit laufenden Upgrades auf Apache 2.4 dieses Problem exponentiell zunehmen würde

Dan schrieb mir:

[…] this has been escalated to our engineers. We are working on this and we will have it sorted asap, it’s a big job so you’ll appreciate that the resolution will not be instant. Sorry if I wasn’t great at troubleshooting this at first – the results we were seeing did not make sense.

Dann warten wir also geduldig, bis StatusCake ihre NodeJS-Installation upgegradet hat …

Tags: , , , , , , , , , , ,
Labels: IT, Web

Keine Kommentare | neuen Kommentar verfassen