Archiv ‘IT’

Freitag, 22. April 2022

OmniCharge: „Download APP to Unlock“

Lösung: Siehe ganz unten im Nachtrag

Meine OmniCharge Omni 20+ meldet (wieder einmal) Download APP to Unlock.

Wie ich das genau geschafft habe, weiss ich nicht auf sicher — aber das Problem hatte ich bereits vor zwei Jahren im April 2020 einmal.

Damals hatte ich die Batterie probehalber an einem 10W Solarpanel betrieben, und einen Verbraucher angeschlossen.

Irgendwann kam eine Schlechtwetterperiode, das Solarpanel lieferte kaum mehr Strom, und der Verbraucher leerte die Batterie offenbar bis auf den letzten Tropfen Saft.

Meine Vermutung: Ohne Strom passiert in der Batterie-Firmware irgendwas, und wenn die Batterie wieder Strom hat, denkt sie, dass es sich um ein Leihgerät handelt.

OmniCharge bietet nämlich mit der Omni Power-Station eine Art Ausleihstation mit gerüsteten Batterien an, und Personen können von dort mittels ihres Smartphones und eines Omnicharge-Accounts Batterien ausleihen.

Der Support konnte mir seinerzeit nicht weiterhelfen und löste einen RMA-Auftrag aus. Offenbar hat der Austausch nichts gebracht.

Leider ist es heute (April 2022) nun so, dass die Web-Site omnicharge.co/app nur noch anzeigt: „This page is in the process of being updated, please check back later.“

Folgende App sollte man sich auf das iPhone herunterladen: Omnicharge

Ich hatte von den Handständen vom April 2020 noch ein Konto (inkl. hinterlegter Kreditkarte, aber seit einem Jahr abgelaufen) und konnte mich in die App einloggen. Ich kann mich aber vage daran erinnern, dass die Erstellung des Kontos selbst ungeheur kompliziert war und ich meine Web Entwickler-Kenntnisse und Debug-Werkzeuge anwenden musste. Fragt mich aber bitte nicht mehr, was genau ich damals gemacht habe.

Einmal eingeloggt habe ich folgendes durchgespielt, was die Batterie tatsächlich entsperrt hat (leider nur bis zum … Montag, 20. April … hä?):

Danach war die Batterie entsperrt:

Obwohl ich froh bin, dass die Batterie entsperrt ist — mich nervt solches Gefrickel mit Ware, die ich legal erstanden habe und von der ich erwarte, dass sie einfach funktioniert.

Nachtrag

Dieses Mal habe ich einen kompetenteren Support-Mitarbeiter erwischt. Mit folgender Anleitung habe ich die Batterie entsperren können:

  1. Press and hold the power button until the Omnicharge logo shows up, then,
  2. While still holding a power button, press the AC, then the USB button in turn for 4 times.
  3. Release the power button.
  4. Select SYSTEM MODE from the menu, check UNLOCKED and exit the menus.
  5. Power on Omnicharge, and it should be unlocked.

Durch das Menu zirkelt man mit der AC-Taste (nach oben) und der USB-Taste (nach unten). Einen Menu-Eintrag wählt man mit der Power-Taste aus.

Meine Batterie war im Omnie BLE (3) (Bluetooth Low Energy?) Modus:

Ich habe auf Unlocked (6) gewechselt, und schwupp, die Batterie war entsperrt.

Danke, Dusan!

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 3. April 2022

imapfilter debuggen

Kürzlich spammte ein via Cron alle fünf Minuten laufendes imapfilter-Script meine INBOX mit der folgenden Meldung voll:

imapfilter: IMAP (3): 1014 BAD Could not parse command

Wie debuggen? Gar nicht so kompliziert. Man führt das „Rezept“ einfach manuell auf der Kommandozeile aus.

$ imapfilter -l /tmp/log.txt -d /tmp/debug.txt -c recipe.lua

Anschliessend schaut man sich debug.txt an, sucht nach der Nummer des Befehls (hier: 1014) und schaut einige Zeilen davor an, um den Filterbefehl zu isolieren, der zur Fehlermeldung geführt hat. Das kann einige Zeilen vorher gewesen sein, weil imapfilter im Debug-Modus jede Aktion gegen den Mailserver aufführt. Das Gute: Jeder Befehl wird fortlaufend nummeriert. Beispiel:

1013 OK SEARCH completed (Success)
...
sending command (5):
1014 UID COPY
...
getting response (5):
1014 OK [COPYUID 100
...
sending command (5):
1015 UID STORE
...
getting response (5):
1015 BAD Could not parse command

In meinem Fall schienen alte Emails von Batmaid das Problem auszulösen. Ich passte den Filterbefehl an (indem ich jetzt neu gegen das Subject filtere, anstelle gegen den From-Header), und danach verschob ich die Emails auch noch manuell in den Unterordner.

Seither tritt die Fehlermeldung nicht mehr auf.

Vermutung: Irgendein nicht konformer Header im Email.

Tags: ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 15. März 2022

Wie viel Strom zieht ein US-16-150W ohne PoE-Geräte?

Ubiquiti UniFi Switch mit 16+2 Anschlüssen, von welchen alle Ethernet-Ports PoE machen können (maximal 150W)

Antwort: 16 Watt, ohne dass irgendwelche Geräte angeschlossen sind, und 20 Watt, wenn Netzwerkgeräte (ohne Power-over-Ethernet!) dran hängen.

Quelle: [Power Consumption] Unifi 8-60W vs 8-150W vs 16-150W

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Samstag, 12. März 2022

Was, wenn man noch eine Weile auf der alten UniFi Controller-Version bleiben möchte?

Kürzlich:

Get:1 http://security.debian.org bullseye-security InRelease [44.1 kB]
Get:2 http://debian.ethz.ch/debian bullseye-backports InRelease [44.2 kB]                      
Hit:3 http://phoscon.de/apt/deconz buster InRelease                                            
Hit:4 https://debian.ethz.ch/debian bullseye InRelease                                         
Hit:5 https://deb.nodesource.com/node_16.x bullseye InRelease                                  
Get:6 https://debian.ethz.ch/debian bullseye-updates InRelease [39.4 kB]                  
Get:7 http://packages.cloud.google.com/apt cloud-sdk-bullseye InRelease [6,772 B]              
Hit:8 https://debian.ethz.ch/debian buster InRelease                                           
Get:10 http://debian.ethz.ch/debian bullseye-backports/main Sources.diff/Index [63.3 kB]
Get:11 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages.diff/Index [63.3 kB]
Get:12 http://debian.ethz.ch/debian bullseye-backports/main Sources T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [715 B]
Get:12 http://debian.ethz.ch/debian bullseye-backports/main Sources T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [715 B]
Get:13 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [17.3 kB]
Get:13 http://debian.ethz.ch/debian bullseye-backports/main amd64 Packages T-2022-03-10-1401.49-F-2022-03-10-0801.51.pdiff [17.3 kB]
Get:9 https://dl.ubnt.com/unifi/debian stable InRelease [3,038 B]                             
Reading package lists... Done  
E: Repository 'https://dl.ubnt.com/unifi/debian stable InRelease' changed its 'Codename' value from 'unifi-6.5' to 'unifi-7.0'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

Die relevante Zeile:

E: Repository 'https://dl.ubnt.com/unifi/debian stable InRelease' changed its 'Codename' value from 'unifi-6.5' to 'unifi-7.0'

Es war aber spätabends und ich war auf keine Experimente mit meinem WLAN aus.

Wie macht man, dass diese Meldung weggeht, und die restlichen, nicht-UniFi Pakete trotzdem aktualisiert werden? Ganz einfach: In /etc/apt/sources.list ersetzt man in der Unifi-Zeile „stable“ mit „oldstable“:

...
deb         http://www.ubnt.com/downloads/unifi/debian oldstable ubiquiti
...

Tags: , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 23. Februar 2022

dhcpd: Unable to add forward map from X to 1.2.3.4: SERVFAIL

Ich habe meine lokalen DHCP-Server so konfiguriert, dass Geräte mit ihrem lokalen DNS-Namen auch in named (BIND9) registriert werden.

Gelegentlich treffe ich folgendes Problem an:

Feb 23 01:15:15 SERVER dhcpd[2746174]: Unable to add forward map from apple-tv.domain.tld. to 10.1.2.3: SERVFAIL

Wie ich mittlerweile nach unzähligen verbratenen Stunden herausgefunden habe hängt dies mit diesem beschissenen AppArmor zusammen. Obwohl ich es jeweils deinstalliere, taucht es nach Updates wieder im System auf.

Die Lösung:

# apt-get remove apparmor
# systemctl stop apparmor
# systemctl disable apparmor

Quelle: How to disable and remove AppArmor in Ubuntu and Debian

Je nach Tageslaune ist dann auch noch ein Reboot nötig.

Mittlerweile habe ich eine monit-Regel eingerichtet, die mich alarmiert, wenn ein solcher Log-Event in /var/log/dhcp.log auftaucht.

(Auf meiner Todo-Liste steht, die Installation mittels apt zu verbieten)

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 13. Februar 2022

Tragödie: Turris OS 5.0 unterstützt meinen g.fast SFP nicht

Jetzt ist es klar: Trotz mehreren Stunden Investition habe ich es nicht geschafft, meinen Proscend T-190 g.fast SFP in meinem Turris Omnia mit Turris OS 5.3.5 zum Laufen zu bringen.

Wie der Router den SFP sieht:

[   13.657984] libphy: SFP I2C Bus: probed
[   14.013558] sfp sfp: module PROSCEND         190-T            rev V7.3 sn 19207J7B92080009 dc 31-08-20
[   14.022906] sfp sfp:   unknown connector, encoding 8b10b, nominal bitrate 1.3Gbps +0% -0%
[   14.031107] sfp sfp:   1000BaseSX+ 1000BaseLX- 1000BaseCX- 1000BaseT- 100BaseTLX- 1000BaseFX- BaseBX10- BasePX-
[   14.041249] sfp sfp:   10GBaseSR- 10GBaseLR- 10GBaseLRM- 10GBaseER-
[   14.047550] sfp sfp:   Wavelength 0nm, fiber lengths:
[   14.052617] sfp sfp:     9µm SM    : unsupported
[   14.057337] sfp sfp:  62.5µm MM OM1: unsupported/unspecified
[   14.063112] sfp sfp:    50µm MM OM2: unsupported/unspecified
[   14.068875] sfp sfp:    50µm MM OM3: unsupported/unspecified
[   14.074659] sfp sfp:    50µm MM OM4: 2.540km
[   14.079030] sfp sfp:   Options: retimer
[   14.082886] sfp sfp:   Diagnostics:

Vorbemerkung: Ja, das Folgende habe ich gemacht (resp. musste ich nicht machen, war schon so):

# ln -sf armada-385-turris-omnia-sfp.dtb /boot/dtb && reboot

Die Probleme begannen am 15. Dezember 2021, als der Router sich selbständig von TOS 3 auf 5 aktualisierte — und danach mit dem SFP keine Internet-Verbindung mehr möglich war. Ich habe darüber gebloggt.

Das Traurige: Unter TOS 3 funktioniert der SFP anstandslos.

Meine Vermutung ist es, dass das Problem mit inband/1000base-x zu tun hat:

...
[   13.913182] mvneta f1034000.ethernet eth2: switched to inband/1000base-x link mode
...

Bei TOS 3 lautete das noch:

...
[  340.701090] mvneta f1034000.ethernet eth1: Link is Up - 1Gbps/Full - flow control off
...

Ich habe nicht herausgefunden, ob und wie man das anpassen kann.

Ich habe einige Forenbeiträge gefunden, die einem helfen, das Problem nachzuvollziehen:

Vielleicht schafft es ja Turris OS 6.0 mit diesem Patch wieder, meinen SFPs zu unterstützen …

Tags: , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Montag, 7. Februar 2022

Vowes Kampf mit Microsoft Azure, und seine Kreuzfahrtschiff-Analogie

And the terrible thing about these shadow accounts is that when anything goes wrong you are being told to contact your admin, but there is is no admin. You are on a cruise ship without a captain. You never wanted to own a cruise ship. In fact, you only wanted to cross the river to get to the other side. […]

I totally understand that Microsoft makes it difficult to sink a cruise ship, but remember, I never wanted one in the first place.

Quelle: I defeated the Azure end boss

Tags: , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

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

1 Kommentar | neuen Kommentar verfassen