Posts Tagged ‘Bluetooth’

Sonntag, 9. Juni 2019

Thoughts on Apple’s Find my (English)

(A friend of mine living in the US asked me about my thoughts on Apple’s upcoming Find my app announced at WWDC 2019 this week — that’s why this article is posted in English)

Links (preliminary reads)

My thoughts

In short: Very, very, very useful.

Once rolled out, this feature will help a lot of devices to be returned to their rightful owner, and probably will also lead to some arrests over times, as well as some very weird discussions with friends and family («Brother-in-law, I know my iPhone is in your house! What the f*** were you thinking?») …

Oh, and think about missing persons, unconscious or incapable of calling for help. You MIGHT find them as long as they’re not totally off the beaten track, even if they don’t have mobile reception. Interesting to see whether good hackers will try to improve their antenna designs to catch Bluetooth signals from miles away (if this is even physically and technically possible?).

Of course, this feature only works as long as your phone is charged, switched on and not damaged (as in hard- and/or software issues). A while ago, a friend lost his phone when „not fully sober“ in front of his condo’s building on a night it was snowing heavily. He found it two days later when the snow melted (after an oven session the thing switched on again and still works, yay!) … this technology would have helped him find it (probably) the morning after, when the phone still had a charge — given that he had access to a second device able to receive the Bluetooth beacon (or another person living in the neighbourhood passing by with his Apple device).

Some questions currently remain open:

  1. How safe is it? In theory it sounds bullet proof. My biggest fear is that hackers nevertheless might find vulnerabilities in the implementation once it is in the wild — looking at you, 36C3 and Def Con. I hope Apple will be able to fix such vulnerabilities with a quick software update …
  2. Does the Bluetooth beacon signal continue to work when Airplane mode is activated? I don’t see airlines tolerate Apple devices sending Bluetooth beacons on an airplane during start and landing. So the Apple devices will have to respect an activated Airplane Mode. If implemented this way, as an unwanted side effect, it will lead malicious persons to switch the device to Airplane Mode (works for iPhones and iPads, but not MacBooks AFAIK) immediately after finding/stealing it, to prevent the device to broadcasting it’s location. On a sidenote: If a device is NOT switched to Airplane mode and such beacons are caught by other devices during a flight, this would give some weird location readings :-)
  3. Will Apple extend this feature to a yet-to-be-introduced tag-like device, as in Bluetooth tiles? Then your tracking might not be limited to a phone anymore, but to anything that can be attached to something (e.g. Bluetooth tile to your keychain, sports bag, backpack etc.). This will totally crush the market for such tiles, because you won’t have to install a tile-specific app on your phone, let it run in the background on your device and hope that other people passing by the lost item also run the very same app to catch your tile’s distress signal …

Tags: , , , , , ,
Labels: Apple

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

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