Posts Tagged ‘Bluetooth’

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

Samstag, 8. Oktober 2016

Wenn iOS 10 partout „usegfunge“ zu „Umseglungen“ korrigiert

Seit dem Umstieg auf iOS 10 sah ich mich beim Erfassen von berndeutschen iMessages mit dem Problem konfrontiert, dass die berndeutschen Wörter permanent in ähnlich klingende deutsche Wörter umgewandelt wurden.

Aus „usegfunge“ (dt. herausgefunden) wurde so stets „Umseglungen“.

Bravo, Apple! Am Donnerstag regte ich mich derart über dieses „Feature“ auf, dass ich ihm genauer auf den Grund ging.

Unter Settings > General > Keyboard war die Eigenschaft „Auto-Correction“ für „All Keyboards“ längst deaktiviert. Als deutschsprachiger Schweizer ist das wohl eine der ersten Konfigurationsanpassungen, die man an einem jungfräulichen iOS vornimmt.

Doch wieso wurden meine Texte trotzdem reproduzierbar korrigiert?

Nach einigen Google-Suchen dann die Erkenntnis: Ich schreibe meine Texte auf dem iPad in der Regel mit einer Hardware-Tastatur; in meinem Fall mit einer Logitech Type+ for iPad Air.

In iOS 10 gibt es für Hardware-Tastaturen gesonderte Einstellungen (welche erscheinen, wenn die Tastatur verbunden ist)! Diese lassen sich unter Settings > General > Keyboard > Hardware Keyboard anpassen.

Ich deaktivierte so auch an dieser Stelle Auto-Capitalization und Auto-Correction.

iOS 10 General Settings Keyboard Hardware Keyboard Auto-Correction
image-6984

Zurück in iMessage zeigte sich der erhoffte Effekt aber nicht: „usegfunge“ wurde weiterhin zu „Umseglungen“ ersetzt. Erst als ich iMessage zwangsweise beendete (Doppelklick auf den Home-Button, das iMessage-Fenster dann nach oben wischend) und neu startete konnte ich endlich wieder sauberes, unkorrigiertes Berndeutsch schreiben.

Via: Disable Autocorrect for External BlueTooth Keyboard – iOS 9.2

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

Keine Kommentare | neuen Kommentar verfassen

Montag, 16. März 2015

Das WiFi-Passwort einer Withings WiFi-Waage WS-30 anpassen

Kürzlich habe ich die WLAN-Infrastruktur zu Hause umgestellt und betreibe nun einerseits ein Legacy-Netz mit 802.11n auf 2.4 GHz sowie ein 802.11ac/n-Netzwerk, welches auf 5 GHz funkt.

Um Geräte zu finden, welche kein 5 GHz funken können, benannte ich das Legacy-Netz um („…-LEGACY“). Und siehe da, der ZyXel-Adapter des Raspberry Pi Dashboards musste umkonfiguriert werden wie auch der Fujitsu ScanSnap-Scanner. Erst einige Tage nach der Umstellung realisierte ich beim Wägen meines Gewichts dann auch, dass die Withings WS-30 offenbar auch keinen 5 GHz-Funkchip verbaut hat.

Doch wie setze ich das WiFi-Passwort der Waage neu? Nach dem vielmaligen Betätigen der Setup-Taste an der Unterseite der Waage, viel pröbeln mit der Smartphone App, einem Besuch des cloud-basierten Web-Dashboards des Herstellers und dem Download eines Mac OS X-Clients fand ich dann endlich die Lösung, vergraben in Withings Knowledgebase:

I want to update the Wi-Fi configuration on my Wireless Scale, WS-30

Kurz: Man tut so, als würde man die Waage über die Smartphone-Applikation neu installieren, beachtet dann aber die Angaben auf dem Smartphonebildschirm und zweigt im Konfigurationsdialog am richtigen Zeitpunkt ab. Damit klappte die Verbindungsaufnahme der Waage mit dem WiFi dann innert wenigen Sekunden.

Tags: , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen