Archiv ‘IT’

Sonntag, 23. Januar 2022

iMac Late 2015 mit kaputtem Lüfter

Gestern Samstag-Abend: Vor dem-zu-Bett-gehen starte ich die Aktualisierung meines iMac 27 Zoll (iMac 17,1), Late 2015, Quad-Core i7, 24 GB, 2 TB von macOS Big Sur 11.6.1 auf 11.6.2. Ich habe das Gerät im Oktober 2017 für 1950 CHF gebraucht gekauft; da ist das Gerät gerade sieben Monate alt. Schnäppchen!

Heute Morgen ist das elektronische Postfach voll mit in Episoden an- und abklingenden monit-Meldungen. Als ich mich am Vormittag hinter das Gerät setze, ist schnell klar, dass etwas ganz und gar nicht stimmt. Es folgt ein Debug-Marathon, ursprünglich davon ausgehend, dass ich es mit einem Software-Problem zu tun habe. Im Laufe des Tages folgt das (widerwillige) Upgrade auf macOS Monterey, bis ich schlussendlich der Ursache des Ausfalls auf die Schliche komme:

Der im Innern des iMacs installierte Lüfter muss während — oder kurz nach — dem Betriebssystem-Upgrade kaputt gegangen sein.

Die Symptome:

  • Der Prozess kernel_task beansprucht knapp 500 Prozent der CPU-Leistung (siehe Link weiter unten)
  • In der Prozessliste findet man dutzende mds_stores Prozesse
  • Die Kiste läuft, plötzlich wird der integrierte sowie der angeschlossene Dell P2415Q-Bildschirm schwarz — und plötzlich startet der iMac ohne zu tun neu
  • Der per DisplayPort angeschlossene Dell P2415Q verliert andauernd das Signal
  • Jede Aktion im GUI dauert extrem lange — es fühlt sich an, als würde man einen 286er bedienen. Doppelklick, eine Minute warten. Alt-Tab, Sekunden vergehen bis die gewählte Applikation in den Vordergrund tritt
  • Die Eingabe über die Tastatur hakelt extrem — zwischen Tastendruck und Anzeige auf dem Bildschirm können Sekunden vergehen
  • Die Situation verbessert sich spürbar, wenn man das Kabel des externen Monitors abhängt
  • htop weist eine Load Average nördlich von 15 aus
  • Im /var/log/system.log (per SSH eingeloggt kann man das Gerät debuggen, ohne mit dem GUI kämpfen zu müssen) liest man verschiedene komische Meldungen …
    • … der Service mds (Spotlight-Indexierung) muss andauernd Indexierungsprozesse abschiessen. Auch das Deaktivieren von Spotlight mittels sudo mdutil -a -i off (Quelle) bringt nichts
    • … Apps finden Grafikkartentreiber nicht (nicht sicher, ob das wirklich ein echtes Problem ist): VTDecoderXPCService[558]: getattrlist failed for /Library/GPUBundles/AMDRadeonVADriver.bundle/Contents/MacOS/AMDRadeonVADriver: #2: No such file or directory und Dock[1242]: getattrlist failed for /Library/GPUBundles/AppleIntelSKLGraphicsVADriver.bundle/Contents/MacOS/AppleIntelSKLGraphicsVADriver: #2: No such file or directory
    • … immer wieder erscheinen com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.user.89): entering bootstrap mode und com.apple.xpc.launchd[1] (com.apple.xpc.launchd.domain.user.89): exiting bootstrap mode
  • Die Ping-Latenz fluktuiert spürbar in einer Art Wellenform; von den erwarteten einstelligen Millisekunden bis zu dreistelligen Werten (siehe Anhang)

Obwohl sich dieser Stackexchange-Artikel und dieser offizielle Apple-Artikel auf (überhitzende) MacBook Pros bezieht, gibt er mir den wichtigsten Tipp: Hitze!

Und tatsächlich, das Gehäuse ist heiss. Und plötzlich erinnere ich mich, dass ich den Lüfter des iMacs verdächtig lange nicht (mehr) gehört habe. Normalerweise lief der täglich mehrmals an, insbesondere, wenn zwei Mal täglich Backups (rsync auf das Synology NAS, TimeMachine auf die TimeCapsule sowie mit Arq zu Backblaze) durchgeführt wurden.

Ich installiere mir die Software Macs Fan Control, welche den Verdacht bestätigt: Die aktuelle Umdrehungszahl beträgt (orange eingefärbt) 0. Minimal müssten eigentlich 1200 Umdrehungen gefahren werde. Ich schalte auf Full Blast (2850 Umdrehungen) — doch kein Wank, kein Geräusch, keine Zirkulation. Währenddessen sehe ich, dass die CPU-Temperatur bei 87 Grad angekommen ist.

Nachtrag: Das geht übrigens alles auch von der Kommandozeile, ohne Installation von Drittsoftware. Um die Temperaturen der CPU-Kerne auszulesen:

# powermetrics --samplers smc | grep -i "CPU die temperature"
CPU die temperature: 47.70 C
CPU die temperature: 46.17 C
CPU die temperature: 46.41 C
CPU die temperature: 46.48 C
CPU die temperature: 46.30 C
...

Um die Lüftergeschwindigkeit auszulesen:

# powermetrics --samplers smc | grep Fan
Fan: 0 rpm
Fan: 0 rpm
...

Und plötzlich macht alles Sinn: Die CPU droht zu überhitzen, weil sie der iMac mangels funktionierendem Lüfter nicht mehr kühlen kann. Deshalb schreitet nun kernel_task zur Tat: Er drosselt alle laufenden Prozesse, damit diese die CPU nicht weiter strapazieren. Für den Benutzer bedeutet das ein extrem träges System. Indem ich den externen Monitor abgehängt habe, läuft die GPU nicht mehr (so) heiss, was ebenfalls Linderung in der „finnischen Sauna“ im Innern des iMac bringt.

Rückblickend ein Wunder, dass ich Monterey während Stunden (!) tatsächlich installieren konnte und die Kiste dabei nicht gegrillt habe (geschweige denn einen Wohnungsbrand ausgelöst habe).

Ich trenne den iMac vom Strom, um den System Management Controller (SMC) zurückzusetzen (Quelle). Leider springt der Lüfter auch danach nicht mehr an. Damit sind alle Lösungsversuche, die auch unter folgender Frage beschrieben wurden, ausgeschöpft: iMac fans stopped, what must I do?

Die leider letzte verbleibende Lösung? Den defekten Lüfter austauschen — hilfreich könnte diese iFixIt-Anleitung sein. Ich habe aber keine Lust, an meinem iMac rumzumechen.

Nun habe ich mir als Ersatz einen Mac mini M1 bestellt.

Sobald das Ersatzgerät da ist, werde ich abklären, wie viel mich bei DataQuest DQ Solutions in Bern ein Austausch des Lüfters kosten wird (ich befürchte mehrere hundert Franken, da der ganze Mac auseinandergebaut und ein Ersatzlüfter eingebaut werden muss).

Dann werde ich mir überlegen müssen, ob ich das Gerät repariere, und falls ja, ob ich es danach wieder in Betrieb nehme, oder es auf Ricardo verkaufe. Vermutlich Letzteres: Die Zukunft gehört M1, und wahrscheinlich wäre das der richtige Zeitpunkt, auch auf dem Desktop den Wechsel zu vollziehen (diesen Text schreibe ich auf einem MacBook Air M1).

Anhang

64 bytes from 1.2.3.4: icmp_seq=11856 ttl=64 time=5.659 ms
64 bytes from 1.2.3.4: icmp_seq=11857 ttl=64 time=5.565 ms
64 bytes from 1.2.3.4: icmp_seq=11858 ttl=64 time=8.133 ms
64 bytes from 1.2.3.4: icmp_seq=11859 ttl=64 time=6.890 ms
64 bytes from 1.2.3.4: icmp_seq=11860 ttl=64 time=6.753 ms
64 bytes from 1.2.3.4: icmp_seq=11861 ttl=64 time=14.673 ms
64 bytes from 1.2.3.4: icmp_seq=11862 ttl=64 time=52.217 ms
64 bytes from 1.2.3.4: icmp_seq=11863 ttl=64 time=101.217 ms
64 bytes from 1.2.3.4: icmp_seq=11864 ttl=64 time=153.161 ms
64 bytes from 1.2.3.4: icmp_seq=11865 ttl=64 time=11.308 ms
64 bytes from 1.2.3.4: icmp_seq=11866 ttl=64 time=6.809 ms
64 bytes from 1.2.3.4: icmp_seq=11867 ttl=64 time=9.474 ms
64 bytes from 1.2.3.4: icmp_seq=11868 ttl=64 time=5.172 ms
64 bytes from 1.2.3.4: icmp_seq=11869 ttl=64 time=6.211 ms
64 bytes from 1.2.3.4: icmp_seq=11870 ttl=64 time=7.839 ms
64 bytes from 1.2.3.4: icmp_seq=11871 ttl=64 time=5.575 ms
64 bytes from 1.2.3.4: icmp_seq=11872 ttl=64 time=5.559 ms
64 bytes from 1.2.3.4: icmp_seq=11873 ttl=64 time=20.077 ms
64 bytes from 1.2.3.4: icmp_seq=11874 ttl=64 time=60.732 ms
64 bytes from 1.2.3.4: icmp_seq=11875 ttl=64 time=107.225 ms
64 bytes from 1.2.3.4: icmp_seq=11876 ttl=64 time=159.577 ms
64 bytes from 1.2.3.4: icmp_seq=11877 ttl=64 time=6.760 ms
64 bytes from 1.2.3.4: icmp_seq=11878 ttl=64 time=13.282 ms
64 bytes from 1.2.3.4: icmp_seq=11879 ttl=64 time=15.027 ms
64 bytes from 1.2.3.4: icmp_seq=11880 ttl=64 time=6.770 ms
64 bytes from 1.2.3.4: icmp_seq=11881 ttl=64 time=4.986 ms
64 bytes from 1.2.3.4: icmp_seq=11882 ttl=64 time=5.948 ms
64 bytes from 1.2.3.4: icmp_seq=11883 ttl=64 time=8.361 ms
64 bytes from 1.2.3.4: icmp_seq=11884 ttl=64 time=5.632 ms
64 bytes from 1.2.3.4: icmp_seq=11885 ttl=64 time=21.801 ms
64 bytes from 1.2.3.4: icmp_seq=11886 ttl=64 time=66.570 ms
64 bytes from 1.2.3.4: icmp_seq=11887 ttl=64 time=109.075 ms
64 bytes from 1.2.3.4: icmp_seq=11888 ttl=64 time=153.075 ms
64 bytes from 1.2.3.4: icmp_seq=11889 ttl=64 time=10.720 ms
64 bytes from 1.2.3.4: icmp_seq=11890 ttl=64 time=8.682 ms

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

Keine Kommentare | neuen Kommentar verfassen

Montag, 3. Januar 2022

Nicht alle Migros Bank-Kunden können TWINT benutzen, weil …

… man halte sich fest:

„Bei den betroffenen Kund*innen hat Twint noch nie funktioniert […] Es sind nur Kund*innen betroffen, deren Vertragsnummer mit einer Null beginnt.“

Quelle: Migros Bank schmeisst ihr Uralt-Ebanking in den Müll

Als ITler und Freizeit-Softwareentwickler würden mich detaillierte Ausführungen über den technischen Grund hinter diesem Problem wirklich brennend interessieren.

Tags: ,
Labels: IT

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

2 Kommentare | neuen Kommentar verfassen

Freitag, 10. Dezember 2021

GL.iNet Travel Router mag keine Sonderzeichen in SSIDs

Heute Nachmittag sind wir nach einer Odyssee durch das verschneite Schweizerische Mittelland im Elsass angekommen.

Spannendes Problem, welches ich mit etwas IT-MacGyvern gelöst habe: Die SSID des Hotels lautet L'Hotel et Spa Ribeauvillé. Wenn ich meinem GL.iNet Travel Router (dem Vorgängermodel des GL-MT300N-V2) sage, sich mit diesem WiFi zu verbinden, speichert die Router-Software die SSID als L, und die Verbindung schlägt – logischerweise – fehl.

Für Profis ist rasch klar, was das Problem ist: Das Apostroph in der SSID signalisiert der Router-Software, dass der SSID-Name hier aufhört. Alles dahinter wird abgeschnitten. Ein klassisches Sonderzeichen Escape-Problem. Und seit mindestens 2018 bekannt (könnte aber sein, dass ich mal die Firmware aktualisieren sollte — mein Router fährt mit Version 2.264): Bug + Security Issue: Special Characters Remote SSID Name

Hinzu kommt noch das Accent Aigu. Eigentlich fehlen nur noch Emojis in der SSID, dann wäre die Party komplett.

Der GL.iNet basiert auf OpenWRT. Auf Grund meiner Erfahrung mit anderen solchen Routern (primär dem Turris Omnia) weiss ich, dass die WiFi-Konfiguration in einer Textdatei unter /etc/config/wireless abgelegt ist.

Mein Plan: Da das GUI die SSID nicht sauber abspeichern kann, trage ich sie halt per SSH und mit vim über die Kommandozeile ein.

Nächstes Problem: Tippe ich das Accent Aigu in vim ein, erscheinen stattdessen zwei Doppelpunkte. Mist. In ash, dem Shell des Routers, wird das Accent Aigu aber sauber angezeigt, wenn man es tippt. Hilft mir aber nicht weiter (ausser ich befasse mich vielleicht mit sed und Inline Suchen-und-Ersetzen). Schlussendlich kopiere ich den Inhalt der Datei aus dem Terminal und füge es in Atom-Dokument auf meinem MacBook ein.

Ich versuche nun, die SSID in der Textdatei zu komplettieren. Um das Apostroph in der SSID verwenden zu können, umschliesse ich den Variablenwert in doppelten Anführungszeichen (OpenWRT verwendet standardmässig einfache Anführungszeichen):

config network 'sta0'
	option channel '11'
	option device 'radio0'
	option ssid "L'Hotel et Spa Ribeauvillé"
	option encryption 'psk2'
	option key 'password'

Ich speichere die Datei, und schreibe sie mittels scp root@192.168.1.1:/tmp/wireless auf den Router zurück. Dort eingeloggt kopiere ich die Datei und überschreibe das Ziel, /etc/config/wireless.

Leider funktioniert es nach einem Reboot damit noch nicht.

Mit etwas greppen dann die Erkenntnis: Unter /etc/wireless/ssids ist das WiFi ebenfalls eingetragen. Somit führe ich den oben beschriebenen Prozess noch einmal durch, dieses Mal aber für diese Datei. Rüberkopiert, den Travelrouter neu gestart — und tada, jetzt poppt auf meinem MacBook das Authentifizierungsportal des Hotel WiFis auf.

Yiha!

Tags: , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 23. November 2021

Xerox B215 druckt gelegentlich, aber reproduzierbar Zeichensalat

Seit längerem habe ich das gelegentliche Problem, dass unser neuer Xerox B215 Multifunktionslaserdrucker bei einigen Druckaufträgen unter macOS 11.6 Zeichensalat ausdruckt, und das über dutzende von Seiten.

Gestern war es wieder einmal so weit. Ich hatte eine zu druckende PDF-Datei, die bei jedem Druckauftrag solchen Zeichensalat produzierte.

Nach einigen Recherchen im Netz dann die Lösung: Printing gibberish or random characters in Xerox B215:

I’ve found that most of the problems were due to „Airprint Secure“. I disabled airprint and it seems to have reduced the cases.

Anstelle von (Secure) AirPrint habe ich den Drucker neben AirPrint nun mittels Internet Printing Protocol (IPP, Port 631) eingerichtet. Diesen neuen Drucker ausgewählt, und das PDF druckte auf Anhieb problemlos.

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

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 18. November 2021

Was ist eigentlich mit der Swiss Covid-App?

Ein Kollege schickt mir gerade den Watson-Artikel Nicht alle werden kontaktiert – Contact Tracing in mehreren Kantonen am Anschlag, und bemerkt trocken: „Contact Tracing — das machen die immer noch?!“.

Worauf ich antworte: „Erinnert ihr euch noch an die Swiss Covid-App von Marcel Salathé? Die ist irgendwie auch ganz, ganz leise in der Versenkung verschwunden …“

Wie naiv wir 2020 waren, als wir glaubten, die grösste Pandemie aller Zeiten zu besiegen, indem wir eine App auf Smartphones installieren, und gut isses. Irgendwie sinnbildlich für den damals noch herschenden Zeitgeist — „There’s an app for that!“.

Die Suche nach salathe app spült diesen Artikel vom Oktober 2020 nach oben: Contact Tracing: Wo klemmts genau bei der Covid-App, Herr Salathé?.

Ein wahrlich passender Schluss für diesen Blog-Post.

Tags: , , , ,
Labels: Gesundheit, IT

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 14. Oktober 2021

OpenInTerminal meldet „Waiting…“

Vor einiger Zeit habe ich hier im Artikel Öffne Terminal mit dem aktuellen macOS Finder-Pfad über die macOS Finder-Erweiterung OpenInTerminal geschrieben.

Folgendes Problem tritt dabei periodisch auf: Klickt man auf das Finder-Icon, heisst es im aufklappenden Dialog lapidar „Waiting…“

Die Lösung, eine Antwort auf meinen Bug-Report: Option-Klick auf Finder und Relaunch anwählen.

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 10. Oktober 2021

Init7 Copper7 mit g.fast SFP

Am 15. Dezember 2021 um 16:34 starb unsere Internetverbindung, und bis jetzt konnte ich den g.fast SFP im Turris Omnia nicht mehr zum Laufen bringen. Momentan surfen wir über die AVM Fritz!Box 7582, welche ich für genau solche Fälle glücklicherweise im Archiv abgelegt hatte. Siehe den eigenständingen Blog-Artikel g.fast SFP in Turris Omnia debuggen (leider erfolglos)

Unser Umzug von der Stadt Bern in die Agglo (oder ist das hier schon „Land“?) hat sich gelohnt.

Der einzige Wermutstropfen aus IT-Sicht war, Fiber7 (1 Gbit/s symmetrisch; wenige Tage vor dem Umzug wurde der POP zudem fit gemacht für sagenhafte 25 GBit/s symmetrisch) hinter sich zu lassen und sich neu mit Copper7 g.fast (500 Mbit/s down, 100 Mbit/s up) begnügen zu müssen.

Bei der Umzugsmeldung an Init7 habe ich mir eine Fritz!Box 7582 mitbestellt, welche xDSL und g.fast kann.

Mein Plan war aber von vornherein, meinen Turris Omnia Router wenn irgendwie möglich auch hier weiterzubetreiben. Die Fritz!Box sollte nur für den Parallelbetrieb verwendet werden, und notfalls als Testgerät, falls ich mit dem Copper7-Support zu tun hätte und ich hätte sicherstellen müssen, dass ich mit einem offiziell unterstützen Gerät eine Verbindung aufbauen könnte.

Den Turris Omnia wollte ich aus folgenden Gründen weiterbetreiben: Nicht nur, weil der Router einfach besser geeignet für Nerds ist, sondern weil ich zu faul war, die voll funktionsfähige, jahrelang erprobte Konfiguration auf die Fritz!Box zu portieren.

Die einfachste Art, dies zu bewerkstelligen, den Fiber7-SFP (FlexOptix, ich habe darüber gebloggt) im Turris Omnia mit einem g.fast SFP zu ersetzen. Und dies gibt es auf dem Markt tatsächlich, es handelt sich aber um ein Nischenprodukt.

Hoffnung gab der Blog-Artikel Migrated to G.fast 500 Mbit DSL with Turris Omnia and SFP von Daniel Pocock, welcher genau das beschrieb, was ich vor hatte. Daniel gab mir freundlicherweise per Email noch Auskunft auf meine spezifischen Fragen. Top, und Danke!

Leider reagierte der von Daniel empfohlene Hersteller MVMTel auf mehrere meiner Anfragen (sowohl über das Web-Formular, als auch direkt per Email) nicht.

In der Schweiz machte ich zum Glück dann folgende zwei Anbieter von g.fast SFPs aus:

Ich bestellte die Ware bei Engitech, und am 1. Oktober 2021 war es so weit: Ich nahm den Fiber7-SFP aus dem Router raus, steckte den g.fast SFP rein, schloss das ADSL-Kabel an. Anschliessend musste ich das Protokoll des WAN-Interfaces (eth1, da SFP) noch von DHCP auf PPPoE umschalten und die von Copper7 per Email gesendeten Zugangsdaten eingeben (PAP/CHAP Username: INIT7.%benutzername%@downstream.ch, PAP/CHAP Password: siehe Datenblatt). Fertig. Nach wenigen Sekunden war der Router online.

Vorher:

Nachher:

Zwecks Troubleshooting noch dies: Der SFP verfügt über zwei LEDs, je auf einer Seite des SFPs. Wenn die Klemme des ADSL-Kabels nach unten zeigt, muss die rechte LED grün blinken („SGMII activity LED“), während die linke LED stetig orange (gelb?) leuchtet („MT5321 G.fast SFP link status“). Quelle

Sollte ich dereinst noch Zugriff auf ein Netzqualitäts- und Debug-Interface des Proscend SFPs finden, werde ich es hier posten. Hier ist die Fritz!Box meilenweit voraus:

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

2 Kommentare | neuen Kommentar verfassen

Mittwoch, 29. September 2021

UniFi Network App wird unter iOS 15 mit Spotlight nicht (mehr) gefunden

Scheint ein iOS 15-Problem zu sein: Wenn ich UniFi in der Spotlight-Suche eingebe, erscheinen massenhaft Einträge. Nur nicht die App selber.

Ich bin mit dem Problem nicht allein, und es ist auch schon anderen Leuten aufgefallen. Wenn ich doch nur wüsste, auf welchem Screen sich die App befindet …

Tags: ,
Labels: Apple, IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 29. September 2021

Elgato Key Light Air wird von Control App unter iOS und macOS nicht mehr erkannt

Gestern fand die Elgato Control App unter iOS mein Elgato Key Light Air plötzlich nicht mehr im Netzwerk. Auch die nachträglich installierte Control App unter macOS Big Sur meldete kein Licht zur Steuerung.

Ich setzte das Licht mehrere Male zurück, und verband es mit Müh und Not wieder mit dem WLAN. Das alles half nichts.

Mysteriös: Mein DHCP-Server erteilte dem Licht eine statische IP, und ich konnte die Lampe von allen Geräten aus auch pingen. Doch die Control App sah die Lampe nicht; ich vermute, dass es ein Problem mit Apples Bonjour gab.

Einige Ansätze: UniFi AP-AC-PRO Not Crossing mDNS/Multicast/Broadcast between 2.4GHz and 5GHz Networks?, iTunes Remote Multicast / Bonjour 2.4/5GHz Radio Issue).

Das Schlimmste am Ganzen: Das Licht verfügt einzig über einen Ein- und Ausschalter. Das Licht selber kann man aber nur über die App steuern (Helligkeit, und Lichttemperatur).

Auch der Trick mit der manuellen Anpassung von Settings.xml (auch: Elgato Control Center Settings.xml) funktionierte nicht, weil sich unter macOS keine solche Datei findet. Immerhin fand ich das Einstellungsverzeichnis (~/Application Support/com.corsair.ControlCenter), und (jetzt erst beim Schreiben des Blog-Artikels) die Einstellungsdatei (~/Preferences/com.corsair.ControlCenter.plist)

Was genau das Problem verursacht hat, kann ich nicht mit Sicherheit sagen. Aber allenfalls hat ein mehrmaliger Reboot meiner UniFi-Access Points während der Debugging-Übung das Problem unbeabsichtigt gelöst.

Doch zu dem Zeitpunkt hatte ich mir auf Basis von Automating Elgato Key Lights From macOS Touch Bar bereits selbst geholfen. Folgende zwei Scripts lassen einen die Lampe einschalten und eigene Lichtwerte einstellen, sowie die Lampe ausschalten:

on.sh

#!/bin/bash

IP="1.2.3.4"

BRIGHTNESS="100" #max
TEMPERATURE="256" #max

if [ $# -gt 0 ]
then
    BRIGHTNESS="$1"
fi

if [ $# -gt 1 ]
then
    TEMPERATURE="$2"
fi

DATARAW="{\"lights\":[{\"brightness\":$BRIGHTNESS,\"temperature\":$TEMPERATURE,\"on\":1}],\"numberOfLights\":1}"

curl --location --request PUT "http://$IP:9123/elgato/lights" \
--header 'Content-Type: application/json' \
--data-raw "$DATARAW"
echo ""

exit 0

off.sh

#!/bin/bash

IP="1.2.3.4"

curl --location --request PUT "http://$IP:9123/elgato/lights" \
--header 'Content-Type: application/json' \
--data-raw '{"lights":[{"on":0}],"numberOfLights":1}'
echo ""

exit 0

Als nächstes würde es mich reizen, für den Geschäftslaptop diese Funktionalität auch gleich noch auf die Touchbar zu legen, wie im Artikel weiter unten beschrieben

Mittlerweile „sendet“ die Lampe (wieder) unter Bonjour. Discovery.app zeigt folgenden Eintrag an:

_elg._tcp. - 1 item
Elgato
elgato.local.
1.2.3.4:9123
[fe80::]:9123
mf=Elgato
dt=200
id=3C:6A:9D:00:00:00
md=Elgato Key Light Air 123456789
pv=1.0

Unter Linux mit installierten avahi-utils kann man vermutlich mit folgendem Befehl dieselbe Information extrahieren:

$ avahi-browse -a

Tags: , , , , , , , ,
Labels: Home Automation, IT

Keine Kommentare | neuen Kommentar verfassen