Posts Tagged ‘WLAN’

Donnerstag, 22. März 2018

WiFi-Kennwörter auch aus dem Recovery-Modus eines Macs entfernen

Kürzlich habe ich meinen Mac mini (Late 2012) verkauft. Als ich das Gerät frisch formatiert und aufgesetzt habe, habe ich realisiert, dass sich der Mac im Recovery-Modus automatisch mit meinem WLAN verbindet. Das konnte nur bedeuten, dass das Passwort für mein WLAN-Netzwerk auch noch ausserhalb der frisch formatierten Festplatte abgelegt sein musste.

Eine Frage auf Ask Different nimmt sich diesem Thema an: How to prevent storing the WiFi password on the recovery partition?

Ich entschied mich deshalb, das NVRAM des Mac minis zu löschen. Das funktioniert, indem man beim Booten folgende Tastenkombination drückt und gedrückt hält:

Option + Command + P + R

Quelle: How to reset NVRAM on your Mac

Ein erneuter Reboot in den Recovery Modus belegte dann, dass sich der Mac nicht mehr automatisch mit meinem WLAN-Netzwerk verband.

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

Keine Kommentare | neuen Kommentar verfassen

Samstag, 10. Februar 2018

UniFi Controller erkennt einen Repeater als Rogue Access Point

Im letzten Jahr hat ein Bekannter von mir in seinem Haus eine neue Wärmepumpe der Firma Waterkotte installiert, welche Wärme aus einer Quellwasserleitung extrahiert, die das Grundstück durchquert.

Die Wärmepumpe verfügt zeitgemäss auch über einen eingebauten Industrie-Computer (PCEngines APU2C2) mit Netzwerkanschluss, auf welchem ein Web-Server läuft. Darüber lassen sich nicht nur die Vitaldaten des Geräts abfragen, sondern dieses auch steuern.

Wie es aber in älteren Gebäuden so ist, hat im Boilerraum natürlich niemand einen Netzwerkanschluss installiert und auch keine Netzwerkkabel hingezogen. Wie bringt man das Gerät somit ins lokale Netzwerk?

Der lokale Lieferant hatte die Lösung: Der Industrie-PC ist mit einem Ethernet-Kabel an einen D-Link DIR-809 angeschlossen. Der Access Point wiederum ist per WLAN mit dem UniFi Access Point der Wohnung im oberen Stockwerk verbunden. Dies, indem der D-Link Access Point in den Repeater-Modus geschaltet wurde und die WLAN-Zugangsdaten statisch einprogrammiert wurden.

Der Bekannte klagte in der Folge aber über instabile Netzwerkverbindungen — mal war die Wärmepumpe erreichbar, aber oftmals nicht. Nach einigem Debugging dann die Erkenntnis: Der UniFi-Controller im LAN erkennt den Repeater nicht als „normalen“ Client, sondern als Rogue Access Point, d.h. als ein Access Point, der vorgibt, ein anderer Access Point zu sein.

Hat man bei einer ähnlichen Installation dieselbe Vermutung, überprüft man das in der Web-Oberfläche des UniFi-Controllers. Einerseits warnt einem der Controller sowohl in der Oberfläche (Nachrichten-Pop-Up) als auch per E-Mail über Rogue Access Points, die in der Empfangsreichweite von UniFi Access Points mit derselben SSID funken …

image-7663

… andererseits werden solche Geräte in der Rubrik „Insights“ auch markant mit einem roten Punkt in der Spalte „Rogue“ dargestellt:

image-7664

Das Problem ist in dem Fall, dass Rogue Access Points vom UniFi Controller automatisch geblockt werden. Dies führte zum Symptom mit den Verbindungsabbrüchen.

Ich habe dann die Funktion benutzt, Rogue Access Points als bekannt zu markieren und den D-Link whitegelistet. Die UniFi-Firmware besitzt diese Funktion offenbar seit Version 5.5.19.

Leider half das aber auch nur temporär; der D-Link Access Point wurde regelmässig wieder als Rogue Access Point klassifiziert und geblockt.

Schlussendlich entschied ich mich dazu, den D-Link Access Point dem Installateur zurückzugeben, (damals) 120 CHF zu investieren und einen UniFi AC Mesh AP im Boilerraum zu installieren.

Am Netzwerkanschluss des Mesh Access Points hängt neben dem PoE-Injektor der Industrie-PC und der Mesh Access Point verbindet sich nun seit Monaten reibungslos mit dem UniFi AP AC Pro.

Keine Unterbrüche, keine Sorgen — mitsamt dem Vorteil, dass im Untergeschoss nun besserer WLAN-Empfang herrscht.

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

Keine Kommentare | neuen Kommentar verfassen

Freitag, 20. Oktober 2017

Canon Selphy wird bei der Treiberinstallation unter Windows nicht im Netzwerk erkannt

Letzte Woche habe ich für eine Bekannte einen gebrauchten Canon Selphy-Photodrucker gepostet. Das Gerät war im Nu ins heimische Netzwerk integriert und druckte daraufhin direkt vom iPhone übermittelte Photos problemlos aus.

Einzig bei der Installation des Druckertreibers unter Windows 7 kam es zu Komplikationen: Das Installationsprogramm konnte den Drucker partout nicht im Netz erkennen, obwohl er nachweislich eingeschaltet war und das WLAN-Symbol anzeigte.

Nach etwas Google-Recherche dann die Erleuchtung: Der Computer war aus irgendeinem Grund nicht mit dem Netzwerk-Modus „Heimnetzwerk“ unterwegs, sondern im Modus „Öffentliches Netzwerk“.

Damit der Drucker gefunden werden kann, muss die Option „Network Discovery“ aktiviert werden: How to Turn Network Discovery On or Off in Windows 7

  1. Control Panel
  2. Network and Sharing Center
  3. Change advanced sharing settings
  4. Pfeil nach unten beim zutreffenden Netzwerkprofil (dasjenige, das „current profile“ anzeigt)
  5. Klick auf „Turn on network discovery“

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 14. Mai 2017

iPhone zeigt Landing Page eines WLAN-Gästeportals nicht an

Am Mittwoch nahm ich beruflich im Hotel Mövenpick in Egerkingen an einem Workshop teil. Abgesehen vom kalten Duschwasser (das Hotel war in der Nacht vom Mittwoch auf den Donnerstag restlos ausgebucht) ein sehr angenehmer Aufenthalt!

Ein Arbeitskollege hatte aber anfänglich mit dem Gästeportal des kostenlosen WLAN zu kämpfen. Obwohl er sich jeweils mit dem WLAN verband, zeigte sein iPhone die sogenannte „Landing Page“ des Gästeportals nicht an. So war es ihm nicht möglich, sich mit Vornamen, Nachnamen und E-Mail-Adresse zu registrieren und den Internetzugang freizuschalten.

Mit meinem iPhone klappte die Registrierung problemlos, wobei sich das Telefon sowieso die meiste Zeit im Swisscom-WLAN einbuchte. Der Kollege war aus Wien und kam deshalb nicht in den Genuss von WLAN-Roaming seines Mobilfunkanbieters.

Doch wie löst man ein solches Problem? Ein kurze Google-Suche später die Erkenntnis:

Load the Authentication / Login Page manually

To load the login page, you have to get the router gate IP. You can get router gateway IP address from Wi-Fi details screen. To get router IP, go to iPhone Settings > Wi-Fi > tap on “i” of selected Wi-Fi network > Next Screen DHCP Tab > Router IP.

Now copy this router IP Address and type into your browser address area and enter to load the page.

Your browser will load the Wi-Fi provider’s authentication page, fill out the necessary details on this page before submitting.

Once you submit and the provider authenticates your connection, then you can start to enjoy the free Wi-Fi.

Quelle: How to Solve Wi-Fi Login Page not Loading Issue in iPhone & Connect Wi-Fi HotSpot

Diesen Trick kannte ich zugegebenermassen selber noch nicht: Man surfe einfach die IP des Gateways an (diese Informationen hat das iPhone vom DHCP-Server erhalten), und die Landing Page erscheint. Genau so funktionierte es auch bei dieser WLAN-Infrastruktur. Nett!

Tags: , , , , , ,
Labels: IT

1 Kommentar | neuen Kommentar verfassen

Montag, 20. März 2017

UniFi Controller erkennen automatisch unerlaubte WiFi Access Points

Als ich gestern mit meinem TP-LINK TL-MR3020 am herumspielen war, tauchte plötzlich folgende E-Mail-Nachricht in meiner INBOX auf:

image-7226

Ein Feature, von dem ich nicht wusste, dass es existiert. Nett. Umkehrschluss: Da der UniFi Controller das erste Mal ausgeschlagen hat, hatte ich noch nie einen „Rogue Access Point“ im Netz.

PS: Und ja, bevor jemand fragt: Die Konfigurationsoption für den Domain-Namen des Systems habe ich mittlerweile auch entdeckt und der Realität angepasst …

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

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Februar 2017

ELK: Race Condition mit resolv.conf und WiFi

Seit einer Woche läuft auf einem Laptop bei mir zu Hause der ELK-Stack und sammelt per Syslog die Logs aller meiner Devices an drei Standorten. In unregelmässigen Abständen werde ich hier über Erkenntnisse berichten, die ich dank der zentralisierten Analyse der Logs gemacht habe.

Dank ELK fand ich auf Grund von postfix Log-Meldungen bald einmal heraus, dass mein Raspberry Pi 3, welcher ein Dashboard in unserer Wohnung antreibt, keine E-Mails versenden kann. postfix konnte den Hostnamen meines Mail-Providers nicht auflösen:

DASHBOARD postfix/error[1234]: ABCDEF: to=<log@domain.tld>, orig_to=<root@dashboard>, relay=none, delay=40662, delays=40584/78/0/0.27, dsn=4.4.3, status=deferred (delivery temporarily suspended: Host or domain name not found. Name service error for name=server41.cyon.ch type=A: Host not found, try again)

Nach einer längeren Debugging-Session dann die Erkenntnis:

The problem is that Postfix checks /etc/resolv.conf before the WiFi is connected. Therefore, /var/spool/etc/postfix/resolv.conf stays empty after the boot and mails cannot be sent.

Quelle: Postfix error: Host or domain name not found

Genau das war das Problem. Während der Kommentator auf Superuser empfiehlt, postfix erst nach der erfolgreichen WiFi-Verbindung zu starten, löste ich das Problem anderweitig, indem ich einen Cron-Job einrichtete:

...
*/1 * * * *	root	cp /etc/resolv.conf /var/spool/postfix/etc/resolv.conf
...

Sicherlich nicht sexy, aber es löst das Problem (und schafft eventuell einige andere).

Tags: , , , , , , , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 17. Januar 2016

WiFi-Sicherheit erhöhen: Bye bye TKIP

Auf dem Flug von Tel Aviv nach Zürich hatte ich Zeit, längst überfällige YouTube-Videos zu schauen. Unter anderem auch eine Präsentation von der BruCON 0x07 mit dem Titel „Advances WiFi Attacks using Commodity Hardware“:

Noch während dem Flug notierte ich mir gemäss den Ausführungen im Video ab 42 Minuten 52 Sekunden, zu Hause auf meinem Asus RT-AC66U mit DD-WRT das unsichere Verschlüsselungsprotokoll TKIP zu deaktivieren. Aus (unnötigen) Kompatibilitätsgründen könnte dieses Protokoll nämlich auch 2016 noch Standardmässig auf WLAN-Access Points aktiviert sein.

Erleichtert durfte ich zu Hause dann aber feststellen, dass ich offenbar in weiser Voraussicht längst nur noch AES-CCMP aktiviert hatte:

DD-WRT Wireless Security
image-6464

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

Keine Kommentare | neuen Kommentar verfassen

Montag, 22. Juni 2015

Raspberry Pi 2 einrichten (2/n): WLAN USB-Stick konfigurieren

Für meinen zweiten Raspberry habe ich in meinem Elektronik-Lager einen unbenutzten WLAN USB-Stick Linksys WUSB54GC v3 gefunden. Mit der Standard-Stromversorgung (1.2A) funktioniert dieser Stick problemlos (keine andere Peripherie an den USB-Anschlüssen) und Raspbian erkennt den WLAN-Stick automatisch.

Als erstes gilt es, den Raspberry Pi 2 zu booten. Angeschlossen an einen HDMI-Monitor und mit einem USB-Keyboard geht man danach an die Konfiguration des WLAN-Adapters, damit man die restliche Konfiguration per SSH vornehmen kann.

Nachdem man nach dem ersten booten in raspi-config landet, vergrössert man zuerst die Partition und startet den Taschencomputer neu. Beim nächsten Neustart loggt man sich mit dem Standardbenutzer pi und dem Passwort raspberry in die Shell ein. Dort startet man raspi-config erneut, und wechselt das Keyboard-Layout im Menupunkt „INTERNATIONALISATION OPTIONS“ auf „Deutsch (Schweiz)“. Anschliessend wechselt man das Passwort des Standardbenutzers. Sicher ist sicher.

Da in der Standardinstallation vim noch nicht vorhanden ist, nehmen wir nano und bearbeiten folgende Datei:

/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet manual

auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
   wpa-ssid EMEIDI-LEGACY
   wpa-psk ********

iface default inet dhcp

Um die Verbindung herzustellen, habe ich den WLAN-Stick kurzerhand aus- und wieder eingestöpselt. Nach gefühlten 10 Sekunden führte der Befehl ifconfig für das Interface wlan0 dann eine gültige IP-Adresse auf (sofern der in dieser Konfiguration zwingend benötigte DHCP-Server im Netzwerk sauber funktioniert).

Nachdem man sich die IP unter dem Interface wlan0 notiert hat, geht es an den Mac mini, von welchem aus man mittels SSH die restliche Konfiguration des Systems vornimmt.

WLAN nach Komplikationen automatisch neu starten

Falls man mit gelegentlichen Verbindungsproblemen kämpft, welche einen automatischen Neustart des WLAN-Interfaces nötig machen, sollte man einen entsprechenden Cron-Job einrichten:

/etc/crontab

...
* * * * *	root	/usr/local/bin/check-wifi.sh > /dev/null 2>&1
...

Das Script liest sich folgendermassen:

#!/bin/bash
##################################################################
# A Project of TNET Services, Inc
#
# Title:     WiFi_Check
# Author:    Kevin Reed (Dweeber)
#            dweeber.dweebs@gmail.com
# Project:   Raspberry Pi Stuff
#
# Copyright: Copyright (c) 2012 Kevin Reed 
#            https://github.com/dweeber/WiFi_Check
#
# Purpose:
#
# Script checks to see if WiFi has a network IP and if not
# restart WiFi
#
# Uses a lock file which prevents the script from running more
# than one at a time.  If lockfile is old, it removes it
#
# Instructions:
#
# o Install where you want to run it from like /usr/local/bin
# o chmod 0755 /usr/local/bin/WiFi_Check
# o Add to crontab
#
# Run Every 5 mins - Seems like ever min is over kill unless
# this is a very common problem.  If once a min change */5 to *
# once every 2 mins */5 to */2 ... 
#
# */5 * * * * /usr/local/bin/WiFi_Check 
#
##################################################################
# Settings
# Where and what you want to call the Lockfile
lockfile='/var/run/WiFi_Check.pid'
# Which Interface do you want to check/fix
wlan='wlan0'
##################################################################
echo
echo "Starting WiFi check for $wlan"
date
echo 

# Check to see if there is a lock file
if [ -e $lockfile ]; then
    # A lockfile exists... Lets check to see if it is still valid
    pid=`cat $lockfile`
    if kill -0 &>1 > /dev/null $pid; then
        # Still Valid... lets let it be...
        #echo "Process still running, Lockfile valid"
        exit 1
    else
        # Old Lockfile, Remove it
        #echo "Old lockfile, Removing Lockfile"
        rm $lockfile
    fi
fi
# If we get here, set a lock file using our current PID#
#echo "Setting Lockfile"
echo $$ > $lockfile

# We can perform check
echo "Performing Network check for $wlan"
if ifconfig $wlan | grep -q "inet addr:" ; then
    echo "Network is Okay"
else
    echo "Network connection down! Attempting reconnection."
    ifdown $wlan
    sleep 5
    ifup --force $wlan
    ifconfig $wlan | grep "inet addr"
fi

echo 
echo "Current Setting:"
ifconfig $wlan | grep "inet addr:"
echo
 
# Check is complete, Remove Lock file and exit
#echo "process is complete, removing lockfile"
rm $lockfile
exit 0

##################################################################
# End of Script
##################################################################

Quelle: dweeber/WiFi_Check

Tags: , , ,
Labels: IT, Linux

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 7. Mai 2015

Koubachi Pflanzensensor mit dem heimischen Netzwerk verbinden

Über eine interne Präsentation von 365d habe ich kürzlich von sogenannten Pflanzensensoren (Plant Sensors») erfahren, mit welchen man die Vitaldaten von Blumentöpfen aufzeichnen kann:

Koubachi

Über Tutti.ch fand ich ein preisgünstiges Occasionmodel dieses Sensors und habe es kurzerhand gekauft.

Bei der Installation mittels der Online-Anleitung und der Smartphone-Applikation aus dem App Store stiess ich aber auf folgende Fehlermeldung:

Error Code: 1/3

Die Hilfe-Seite für WLAN/WiFi-Probleme war nicht weiter hilfreich.

Nach einigem Pröbeln realisierte ich, dass das Problem mit der WiFi-Konfiguration meines WLAN-Access Points zusammenhing: Dieser sendete bis dahin nur im 802.11n-Modus. Der Pflanzensensor benötigt aber 802.11g.

Kurzerhand passte ich die Einstellungen unter DD-WRT folgendermassen an:

dd-wrt-80211ng
image-6259

Anschliessend klappte es problemlos, das Gerät mit meinem heimischen WLAN zu verbinden.

Es wäre wünschenswert, wenn die Fehlermeldungen der Smartphone-Applikation detaillierter ausfielen und das Problem auch präziser beschrieben werden würde …

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

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