Posts Tagged ‘Avahi’

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

Sonntag, 3. Februar 2019

host löst einen lokalen Domain-Namen auf, wget und Python requests3 hingegen nicht

Vor einigen Tagen habe ich meinen Web-Server im lokalen LAN aufgeräumt und viele Services, welche über eine DynDNS-Adresse gegen das Internet zugänglich waren, deaktiviert. Ab sofort können diese Web-Services nur noch mit einer privaten FQDN à la service.server.location.domain.local aus dem LAN angesprochen werden.

Diese Anpassung führte dazu, dass mein Bluetooth-Scanner, welchen ich auf meinem Raspberry Pi betreibe, seine Scan-Resultate nicht mehr an den Web-Server übermitteln konnte. Ein Python-Script führt auf dem RPi alle 5 Minuten einen Bluetooth-Scan durch, übersetzt die Resultate ins JSON-Format und versendet die Daten dann mit requests3 per HTTP an den Web-Server.

Die Fehlermeldung, die das Script ab der Umstellung ausspuckte, lautete folgendermassen:

$ /usr/bin/python /usr/local/bin/bluelog/bluetooth-scan.py --output api
Traceback (most recent call last):
  File "/usr/local/bin/bluelog/bluetooth-scan.py", line 424, in <module>
    response = requests.post(url, json=macs, auth=HTTPDigestAuth('user','password'))
  File "/usr/lib/python2.7/dist-packages/requests/api.py", line 110, in post
    return request('post', url, data=data, json=json, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/api.py", line 56, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 488, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/sessions.py", line 609, in send
    r = adapter.send(request, **kwargs)
  File "/usr/lib/python2.7/dist-packages/requests/adapters.py", line 487, in send
    raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPConnectionPool(host='service.server.location.domain.local', port=80): Max retries exceeded with url: /index.php (Caused by NewConnectionError('<requests.packages.urllib3.connection.HTTPConnection object at 0x75e41b10>: Failed to establish a new connection: [Errno -2] Name or service not known',))

Auf dem RPi eingeloggt funktionierte die Namensauflösung mit dem host-Kommando aber problemlos:

$ host service.server.location.domain.local
service.server.location.domain.local has address 10.1.2.3

Doch als ich die Verbindung zum Web-Server mit wget überprüfen wollte schlug auch das fehl:

$ wget http://service.server.location.domain.local/index.php
--2019-02-02 15:56:22--  http://service.server.location.domain.local/index.php
Resolving service.server.location.domain.local (service.server.location.domain.local)... failed: Name or service not known.
wget: unable to resolve host address "service.server.location.domain.local"

Herumgooglen brachte nicht die gewünschte Lösung. Deshalb griff ich zur nächstbesten Lösung und rief wget mit strace auf. Im Trace dann der entscheidende Hinweis:

$ strace wget http://service.server.location.domain.local/index.php
...
connect(3, {sa_family=AF_UNIX, sun_path="/var/run/avahi-daemon/socket"}, 110) = 0
fcntl64(3, F_GETFL)                     = 0x2 (flags O_RDWR)
fstat64(3, {st_mode=S_IFSOCK|0777, st_size=0, ...}) = 0
write(3, "RESOLVE-HOSTNAME-IPV4 service.serv."..., 55) = 55
read(3, "-15 Timeout reached\n", 4096)  = 20
close(3)                                = 0
...

Was zum Teufel hat der Avahi-Daemon mit /var/run/avahi-daemon/socket im strace zu suchen? Jetzt hatte ich ausreichend Infos, um Google noch einmal zu befragen. Und siehe da:

Is Avahi running or installed? Avahi uses .local domain for its usage and puts its config in /etc/nsswitch.conf. My experience with it, using a .local domain name for my internal use is that it can be a little flaky (for lack of a better technical term), and would show behavior similar to what you are seeing.

Quelle: [SOLVED] resolver weirdness – avahi and .local

Die Lösung war im selben Beitrag gepostet:

/etc/nsswitch.conf

Aus …

...
hosts:      files mdns4_minimal [NOTFOUND=return] dns
...

… wird folgender Eintrag:

...
hosts:          files dns mdns4_minimal
...

Und seither lösen sich auch die .local-Adressen reibungslos auf.

Tags: , , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 28. Mai 2014

AirPrint mit einem HP LaserJet 1300 auf einem Linux-Server aktivieren

Heute habe ich den Linux-Server in meinem Heimnetzwerk so konfiguriert, dass der dort per USB angeschlossene HP LaserJet 1300 auch von iOS-Geräten (iPhone und iPad) mittels AirPrint angesteuert werden kann.

Dies stellt sich heutzutage, anno 2014, als ein äusserst simples Unterfangen heraus:

CUPS installieren

Zuerst installiert man auf dem Server CUPS, das Common UNIX Printing System, welches von Apple gehegt und gepflegt wird. In meinem Fall hat dieses Drucksystem lprng ersetzt, welches automatisch deinstalliert wird:

# apt-get install cups

cups Web-Oberfläche freigeben

In /etc/cups/cupsd.conf sind in allen Location-Elementen (merke: CUPS verwendet Apache als Web-Frontend) die IPs des lokalen Netzwerks für erlaubte Zugriffe freizugeben:

...
Listen *:631
...
DefaultAuthType BasicDigest
...
<Location />
  Order allow,deny
  Allow From 10.0.10.0/24
</Location>
...
<Location /admin>
  Order allow,deny
  Allow From 10.0.10.0/24
</Location>
...

DefaultAuthType BasicDigest habe ich von Basic auf Digest umgestellt, damit ich das Passwort meines sudo-befähigten Benutzers nicht im Klartext über das Netzwerk gesendet wird. Damit man sich nach dieser Konfigurationsanpassung einloggen kann, muss man zuerst noch einen entsprechenden Benutzer erstellen:

# lppasswd -a <username>
Enter password: ********
Enter password again: ********

Eigener Benutzer der Gruppe lpadmin hinzufügen

Damit ich CUPS über die Web-Oberfläche administrieren kann, habe ich meinen persönlichen Benutzernamen zusätzlich der lokalen Gruppe lpadmin zugewiesen:

# usermod -aG lpadmin <username>

CUPS LPD-Druckserver einrichten

Obwohl heute IPP das Mass aller (Druck)dinge ist, verwende ich für Mac OS X- und Windows-Clients weiterhin das LPR/LPD-Druckprotokoll, weil es so simpel gestrickt und kaum fehleranfällig ist. Da CUPS aber lprng deinstalliert hat, muss in /etc/inetd.conf folgende Zeile eingefügt werden, welche den CUPS-eigenen LPD-Server aktiviert:

...
printer stream tcp nowait lp /usr/lib/cups/daemon/cups-lpd cups-lpd -o document-format=application/octet-stream

inetd startet man unter Debian folgendermassen neu:

# /etc/init.d/openbsd-inetd restart

Drucker einrichten und konfigurieren

Über die Web-Oberfläche, welche man unter http://localhost:631 erreicht (respektive über http://10.0.10.10:631) richtet man sich mit dem Installationsassistenten den USB-Drucker ein. Bei mir wurde das Gerät an der USB-Schnittstelle problemlos erkannt und auch entsprechende HP-Treiber angeboten.

WICHTIG: Ich hatte erhebliche Probleme mit dem Postscript-Druckertreiber (der HP LaserJet 1300 kann Postscript 2 emulieren): Jeder zweite Druckauftrag — egal ob von Mac oder vom iPad — blockierte den Drucker entweder oder liess ihn eine fast leere Seite mit der Fehlermeldung „Offending Command“ ausdrucken. Doch sobald ich den Drucker auf den Sample monochrome PCL XL/PCL 6 driver umgestellt hatte, funktionierte die Druckerei tadellos. In diesem Fall ist aber darauf zu achten, dass man unter Mac OS X ebenfalls mit dem PCL-Druckertreiber druckt, damit man dem CUPS-Druckserver die Umwandlung von PostScript zu PCL erspart.

Fertig!

Obwohl ältere AirPrint-Installationsanleitungen im Internet die Sysadmins nun auch noch auffordern, Avahi zu installieren (war bei mir schon vor dieser Neukonfiguration des Drucksystems auf dem Server aktiv) und mittels des Scripts airprint-generate.py einen Bonjour-Service anzukündigen, funktionierte die Anpreisung mit CUPS 1.7.2-3 ohne irgendwelche Konfigurationsanpassungen.

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen