NFC – dem TRF7970A auf die Pins geschaut

Damit ich wirklich verstehe, was der NFC-Chip auf der HydraNFC so macht, habe ich den SPI-Bus zwischen HydraBus und HydraNFC mit einem Logic-Analyzer dekodiert.
Auf diesem Bus unterhalten sich beide Module. Der NFC-Chip bekommt darüber mitgeteilt was und wie er etwas machen soll.
Normalerweise müsste ich nun mühsam die SPI-Bytes entziffern und mit der Doku abgleichen … aber glücklicherweise hat sich jemand die Mühe gemacht ein entsprechendes zu erstellen – und es frei zur Verfügung gestellt.

Damit sieht man schon in der Live-Ansicht sehr gut, was übertragen wird.

capture_trf_spi1

Der wirkliche Leckerbissen ist aber, das man die komplette Kommunikation in einer schönen Textdatei „lesbar“ ablegen kann.
Damit kann man dann alles in Ruhe nachlesen.

Hier ein Auszug aus der Initialisierung nach dem booten:

hydranfc_spi_bootinit

Mal sehen wie mir diese Informationen weiterhelfen.

NFC – graue Theorie

Leider scheitere ich immer noch der Hydra im Direct-Mode1 irgendwelche Daten zu entlocken. Nachdem ich mir im Quelltext die Initialisierung von DM1 angeschaut habe, und dazu alle Bitmuster mit der Dokumentation und der Applikation-Note verglichen habe – war ich nicht unbedingt klüger.
Es zeigte sich zwar, das im Hydra-Quelltext einiges anders ist – als in dem Beispiel … aber wieso rein gar kein Output kommt – völlig unklar.

Wenn man wiederum auf der Github-Seite schaut, sieht man das dazu aber schon ein Issue geöffnet wurde. Anscheinend bin ich nicht der ein zigste der damit ein Thema hat.

Ich habe dann einfach die Applikation-Note 1:1 programmiert und in die Hydra integriert. Aber ohne wirklichen Erfolg. Das ganze habe ich dann immer gegen ein Nexus Tab mit MifClassic-Card getestet.

Bei meinen Recherchen bin ich dabei auf folgenden Präsentation gestolpert – die das Thema NFC-P2P nett erklärt.

NFC etwas auf den Zahn gefühlt

Mittlerweile habe ich erfolgreich einige PCAP-Traces für Wireshark erstellt und mit selbigen analysiert. Leider bringt Wireshark von Haus aus keinen passenden Dissector um dieses Protokoll zu entschlüsseln.
Zum Glück hat sich schon jemand dieser Aufgabe gewidmet und einen entsprechenden Decoder geschrieben: NicoHub/Wireshark-RFID-dissector

Aber auch hier gab es am Anfang ein paar Stolpersteine … der Decoder hat Fehler geworfen. Da die Quelltext frei verfügbar ist – konnte ich die Fehler finden und fixen.
Damit konnte ich dann relativ einfach eine Kommunikation zwischen einem Galaxy Nexus Tab und einer Mifare-Card (14443-A) mitlesen und verstehen.

Dummerweise bringt mich das aber bei meiner P2P-Anwendung nicht wirklich weiter, da bei NFC verschiedene Modulationen \ Modi verwendet werden können und das einfache sniffen der Hydra für 14443-A ausgelegt ist.

Erklärungen zu den unterschiedlichen NFC-Modi (NFC-A -B -F)
Artikel zu den unterschiedlichen Modulationsarten

Aber zum Glück beherrscht das Board auch den sogenannten Direct-Mode. Bei diesem Modus kann man mit einem Logic-Analyzer an einem Ausgangspin den Datenstrom abnehmen und anzeigen lassen. Dann sieht man dann sehr genau was „an der Antenne“ ankommt.


img_8183

Man sieht sehr schön das alle 0,46 Sekunden eine neue Ausstrahlung beginnt.


capture1

Wenn man nun das ganze etwas aufzieht, sieht man das schon etwas besser… Man erkennt schön, das die „Start-Barke“ eine Dauer von 0,14 Sekunden hat.


capture2

Wenn man nun weiter hineinzoomt, sieht man dann auch schön wie die Datenpakete gesendet werden.


capture3

Sobald wieder etwas mehr Zeit ist, werde ich da dann weiter abtauchen.

Erste Schritte mit NFC

Zur Zeit bin ich wieder am Elektronik-Basteln – genauer gesagt beim experimentieren mit NFC. Zur Zeit habe ich hier zwei Geräte welche mittels dieser Technik Daten austauschen (P2P) und ich würde gerne verstehen wie (und vor allem was) die beiden sich austauschen.

Als erstes habe ich mir ein kleines PN532-Breakout-Board von adafruit gekauft, welches ich mit einem FTDI-Adapter an eine virtuelle Linux-Maschine (Ubuntu) angebunden habe. Dann habe ich – wie in etlichen Beispielen zu lesen – die LibNFC erstellt und eingebunden .. und siehe da – ich konnte einfache Smartcards „lesen“. Soweit ein erster Erfolg.

IMG_8180.JPG

Aber wie so oft im Leben – folgte die Enttäuschung auf dem Fuße. Um nun die P2P Kommunikation zwischen zwei Partner zu belauschen, bräuchte ich ein entsprechendes Stück Software was so etwas kann. Ich wurde auch fündig: NFCTool.
Dumm nur, das diese Software einen anderen Unterbau benötigt – und zwar Linux-NFC (NEARD) – und dieser hat mit LibNFC nicht viel gemeinsam.
Im Projekt NEARD gibt es zwar auch einen PN532/533 Treiber – aber dieser setzt andere USB-ID’s voraus. Ich müsste nun entweder mein FTDI-Modul umprogrammieren … wozu ich aber ehrlich gesagt keine Lust habe – oder einen anderen Weg beschreiten.

Als ich das PN532-Breakout-Board bestellt hatte, habe ich auch gleich eine andere Bestellung auf den Weg geschickt: Eine HydraBus samt der passenden NFC-Erweiterung. Bei diesem System kommt alles aus einem Guss und es kann schon „von Hause aus“ NFC-Traffic mitschneiden. Es dauerte einige Tage bis das gute Stück den Weg von Frankreich nach Deutschland gefunden hatte. Nachdem ich aus dem Plexiglas das Mini-Gehäuse gebaut und die NFC-Erweiterung eingesteckt hatte – konnte es gleich losgehen.

Das lesen diverser Smartcards hat gleich auf Anhieb funktioniert. Leider gab es beim Mitschneiden des P2P-Verkehrs aber Probleme. Es zeigte sich das ich dafür unbedingt eine MicroSD-Karte brauchte – also zum Media-Markt gefahren und eine Toshiba-32GB MicroSD gekauft. Danach konnte ich dann endlich auch was aufzeichnen. Es zeigte sich das der „Antennenschnürsenkel“ sehr fehleranfällig war – also habe ich die mitgelieferten SMA-Steckverbinder angelötet und noch eine kleines SMA-Kabel gekauft. Nun ist das ganze sehr viel stabiler geworden.

img_8179

Der nächste Schritt ist nun, die Daten nach Wireshark zu bringen um das ganze sinnvoll auswerten zu können.

So nun wisst ihr, womit ich zur Zeit die selbige vertrödle.

 

 

WhisperVision – Entscheidung ist gefallen

Nach einigem Hin- und Her und einer Menge Brainstorming, ist letztendlich eine Entscheidung gefallen. Leider gegen die Ubnt-Unifiy Lösung.
Zum einem war der Temperaturbereich der Kamera mit +35 Grad Celsius etwas zu mau – zum anderen war die Komplettlösung zu verschlossen. Es können bei dieser Lösung nur Ubnt-Kameras verwendet werden. Weiterhin hätte ich für diese Lösung wieder einen separaten Controller hinstellen müssen und hätte keine Lösung „aus einem Guss“ gehabt – das wäre aber meine Erwartung an einer einheitlichen Unify-Plattform gewesen !
Ein ähnliches Spiel zum Thema WhisperVoice – auch hier spielt Ubnt mit „verdeckten Karten“. Die eigentliche Software stellt nur ein Frontend für die USG-Hardware dar – welche die Telefonie durchführt. Wieder ein Stück Hardware was sicherlich vermeidbar wäre. Und auch diese Lösung ist für Fremdgerät nicht zugänglich – und Ubnt hat momentan nur ein sehr kleines Telefonsortiment…

Nachdem ich wusste was ich alles nicht wollte und mir nicht gefällt, ging es noch um die Frage was ich letztendlich als Lösung nehme. Gerade bei WhisperVision ist die Flexibilität für unterschiedliche Kameras sehr wichtig. Ich persönlich nutze ja ein SynologyNAS für ein ähnliches Thema – aber dummerweise kann Synology auch nur bis 35 Grad Celsius. Also ist es ein QNAP-NAS geworden, welches mit 2 Festplatten ausgestattet ist. Als Kamera habe ich dann wieder ein Mobotix gewählt – die sind solide und zuverlässig … leider auch teuer .

Das QNAP bietet auch eine „VirtualStation“ an – was nichts anderes als eine QEMU-Virtualisierung ist. Diese nutze ich um eine virtuelle Maschine mit einer Askozia-PBX zu betreiben. Somit hat man dann nur 1 Gerät mit 2 Funktionen. Später – wenn sich diese Lösung als solide herausstellt – kann ich dann auch noch den WLAN-Controller auf diese Plattform migrieren.

WhisperVision – erster Test

Im Projekt WhisperLan haben wir ja erfolgreich die WLAN-Lösung von Ubiquiti – genauer gesagt UniFi – im Einsatz. Der Hersteller bietet auf der selben Basis auch eine Überwachungslösung an: UniFi Video. Anfang des Jahres wurde eine neue kleine Kamera – UVC Micro – vorgestellt, und diese schien für das Projekt passend zu sein. Also lange gewartet und nun endlich konnte die Kamera samt Software getestet werden.

wpid-img_20150726_131726.jpgwpid-img_20150726_131751.jpg
Ein kleiner netter Karton lädt zum öffnen ein.

wpid-img_20150726_131924.jpg
Es ist eine gelungene Lösung aus Netzteil, langer Zuleitung und einer magnetischen Aufhängung.

wpid-img_20150726_131948.jpg
Und klein – sprich Micro – ist die Kamera wirklich. Da die Kamera nur per Wlan arbeitet, ist nur die dünne Leitung für die Stromversorgung notwendig.

Nach diesem WOW kam dann aber schnell die Ernüchterung. Zum einem sind die Systemvoraussetzungen für die UniFi-Vision-Software andere als erwartet – zum anderen gibt es von Hause aus keinen RemoteAccess für diese Lösung. Während man für die UniFi-WLan-Lösung so ziemlich jedes Linux als Basis nehmen kann, ist für die Unifi-Vision nur Debian/Ubuntu unterstützt. Sprich eine Installation auf CentOS – wie bei uns im Einsatz – ist so erst mal nicht möglich.
RemoteAccess ist nur möglich wenn man sich einen DynDNS-Dienst sowie PortForwarding installiert. Dummerweise bietet der lokale ISP bzw. deren CPE keine PortForwarding. Synology – als Konkurrenzlösung – bietet mit Ihrem myDS-Dienst durchaus eine Lösung welche auch ohne PortForwarding funktioniert. Ich muss mal in einer ruhigen Minute abschätzen welche Lösung man hier weiter verfolgt.

Mikrotik User Meeting 2015 in Zürich

Heute musste ich etwas früher aufstehen um den Flieger um 7 Uhr nicht zu verpassen. Ich war überrascht wie viele Menschen schon um halb Sechs auf dem Flughafen unterwegs waren. Selbst der Flughafen-Bus war überfüllt.
Um 8 Uhr 30 bin ich dann in der Schweiz, genauer gesagt in Zürich, gelandet. Es war ein sommerlicher Tag um die 27 Grad Celsius – Sonne Pur.

wpid-img_20150724_150150.jpgwpid-img_20150724_154419.jpg


wpid-img_20150724_092707.jpgBedingt durch meinen frühen Flug gehörte ich mit zu den ersten. Jeder Teilnehmer hat einen Beutel mit „Geschenken“ erhalten … und die wurden dann natürlich auch gleich ausgepackt und bewundert.

wpid-img_20150724_105450.jpg
Um 10h ging es dann los mit der Eröffnungsrede. Nachdem man ausführlich – und langatmig – erklärt hatte, wieso Mikrotik gute Produkte herstellt und man unbedingt diesen Hersteller vertreiben sollte , wurden die Neuheiten vorgestellt.

MikroTikNeuheitenMum2015
Und bei der Produktpräsentation waren dann auch 3 Produkte dabei die für mich bzw. WhisperLan von Vorteil wären. Das eine Produkt ist schon erhältlich wird demnächst mal bestellt und ausprobiert. Am meisten bin ich natürlich auf den hAP / hAP lite bespannt. Es scheint dann endlich ein DualRadio-AP mit ordentlichen Betriebssystem zu geben.

Danach gab es noch einen Vortag über CapsMan – das ist Mikrotik seine Wlan-Controller-Lösung. Der große Vorteil von CapsMan ist, das diese auf einem Mikrotik-Router „nebenbei“ her läuft. Sprich man braucht keine extra Hardware für den WLAN-Controller. Was mich aber stört, ist die Tatsache das CapsMan sich nur um das Device-Provisioning kümmert. Statistiken oder Tickets für Hotelanwendungen etc. gibt es leider nicht. Dafür muss man sich dann selber Software schreiben oder einkaufen. Anscheinend gibt es hier auch noch keinen Community-Lösung.

Danach gab es einen sehr spannenden Vortrag zum Thema Mikrotik im Backbone. Als ich die Überschrift gelesen hatte, dachte ich mir: „Was soll das den für ein Backbone sein wo Mikrotik zum Einsatz kommt ?“ Zumal ich durch meine Arbeit ja eine ziemliche genaue Vorstellung zu einem „Backbone“ habe.
Aber ich wurde überrascht: Es war sehr wohl ein Backbone und es ging um die Vernetzung von mehreren PoP’s (z.B. Zürich und Frankfurt (sicherlich bei eShelter in Rödelheim)) mittels eines IPv6-IPSec-Tunnels. In dem genannten Beispiel wurden Cisco ASR1000 durch Mikrotik-Router ersetzt. Das fand ich persönlich sehr interessant. Zumal es auch einige Seitenhiebe in Richtung Mikrotik gab (Dinge die funktionieren sollten es aber nicht taten)…

Danach gab es dann zwei Beiträge zum Thema Mikrotik und Redundanz. Da war für mich persönlich nicht viel neues dabei – aber es war sehr schön das alle Features und deren Pro + Con mal zentral erörtert wurden.

Was auch sehr schön war, war die Tatsache das man sich mal mit anderen MikroTik-Anwendern kurzschließen konnte.  Es war eine schöne Veranstaltung … und mal sehen, vielleicht bin ich ja nächstes Jahr mal in Prag mit dabei.