{"id":84024,"date":"2020-06-04T19:42:32","date_gmt":"2020-06-04T17:42:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty"},"modified":"2020-06-04T19:42:32","modified_gmt":"2020-06-04T17:42:32","slug":"ble-pod-mikroskopom-atty-gatty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","title":{"rendered":"BLE unter dem Mikroskop (ATTs GATTs\u2026)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"BLE<\/p>\n

BLE unter dem Mikroskop (ATTs GATTs\u2026)<\/h2>\n

Teil 1, \u00dcberblick<\/b><\/p>\n

Es ist schon eine ganze Weile her, seit die erste Spezifikation f\u00fcr Bluetooth 4.0 ver\u00f6ffentlicht wurde. Und obwohl das Thema BLE sehr interessant ist, h\u00e4lt es viele Entwickler aufgrund seiner Komplexit\u00e4t immer noch auf Abstand. In meinen fr\u00fcheren Artikeln habe ich haupts\u00e4chlich die untersten Ebenen, die Link Layer und Physical Layer, behandelt. Dies erm\u00f6glichte es, nicht auf die komplexen und verworrenen Begriffe wie den Attributprotokoll (ATT) und das allgemeine Attributprofil (GATT) einzugehen. Doch man kommt nicht daran vorbei \u2013 ohne ihr Verst\u00e4ndnis ist die Entwicklung kompatibler Ger\u00e4te nicht m\u00f6glich. Heute m\u00f6chte ich mein Wissen mit Ihnen teilen. In meinem Artikel werde ich mich auf Lehrbuch<\/a><\/noindex> f\u00fcr Einsteiger von der Seite Nordic st\u00fctzen. Lassen Sie uns beginnen.
\n<\/a><\/noindex><\/p>\n

Warum ist alles so kompliziert?<\/h3>\n

\nMeiner Meinung nach war von Anfang an klar, dass die Steuerung von Ger\u00e4ten \u00fcber Smartphones ein sehr zukunftstr\u00e4chtiges und nachhaltiges Thema ist. Deshalb wurde beschlossen, es sofort umfassend zu strukturieren, damit die Hersteller verschiedener Gadgets keine eigenen Protokolle entwickeln, die sp\u00e4ter nicht kompatibel sein w\u00fcrden. Daher die Komplexit\u00e4t. Bereits in der ersten Phase wurde versucht, alles M\u00f6gliche in das BLE-Protokoll zu integrieren. Und es spielt keine Rolle, ob es sp\u00e4ter gebraucht wird oder nicht. Au\u00dferdem wurde die M\u00f6glichkeit vorgesehen, die Liste der Ger\u00e4te f\u00fcr die Zukunft zu erweitern.<\/p>\n

Schauen wir uns das Bild an, auf dem das Schema des BLE-Protokolls dargestellt ist. Es besteht aus mehreren Schichten. Die unterste physische Schicht (PHY) ist f\u00fcr den Funkkanal des Ger\u00e4ts verantwortlich. Link Layer (LL) enth\u00e4lt die gesamte Byte-Sequenz in der \u00fcbertragenen Nachricht. In fr\u00fcheren Artikeln haben wir uns genau mit ihm besch\u00e4ftigt. Das Host Controller Interface (HCI) ist das Protokoll f\u00fcr den Austausch zwischen den Schichten oder Chips des BLE, falls Controller und Host auf verschiedenen Chips implementiert sind. F\u00fcr die Paketerstellung, die Aufteilung in Frames, die Fehlerkontrolle und die Zusammenstellung der Pakete ist das Logical Link Control and Adaptation Protocol (L2CAP) zust\u00e4ndig. Das Security Manager Protocol (SMP) ist f\u00fcr die Verschl\u00fcsselung der Pakete verantwortlich. Das allgemeine Zugangsprofil (GAP) ist verantwortlich f\u00fcr den anf\u00e4nglichen Datenaustausch zwischen Ger\u00e4ten, um \u201eWer ist wer\u201c zu bestimmen. Dazu geh\u00f6ren auch das Scanning und das Advertising. In diesem Artikel werde ich mich auf die beiden verbleibenden Teile des Protokolls \u2013 GATT und ATT \u2013 konzentrieren. GATT ist ein Overlay \u00fcber ATT, daher sind sie stark miteinander verwoben.<\/p>\n

\"BLE
\n
\nUm die Erz\u00e4hlung zu vereinfachen, m\u00f6chte ich auf eine Analogie eingehen. Ich habe sie irgendwo geh\u00f6rt und m\u00f6chte sie unterst\u00fctzen. Stellen Sie sich ein BLE-Ger\u00e4t als ein B\u00fccherregal mit mehreren Regalen vor. Jedes Regal ist ein separates Thema. Zum Beispiel haben wir Regale mit Science-Fiction, Mathematik, Enzyklop\u00e4dien. Auf jedem Regal stehen B\u00fccher zu dem angegebenen Thema. Und in einigen B\u00fcchern gibt es sogar Papierlegemarken mit Notizen. Dar\u00fcber hinaus haben wir einen kleinen Papierkatalog aller B\u00fccher. Wenn Sie sich an Schulbibliotheken erinnern \u2013 das ist eine schmale Schublade mit Papierkarten. Bei dieser Analogie ist das Regal das Profil unseres Ger\u00e4ts. Die Regale sind die Dienste, die B\u00fccher sind die Merkmale und der Katalog ist die Tabelle der Attribute. Die Legemarken in den B\u00fcchern sind die Deskriptoren, \u00fcber die ich sp\u00e4ter ebenfalls ausf\u00fchrlicher sprechen werde.<\/p>\n

Jeder, der Ger\u00e4te entwickelt hat, wei\u00df, dass in vielen Projekten \u00e4hnliche Codeabschnitte vorhanden sind. Das liegt daran, dass viele Ger\u00e4te eine \u00e4hnliche Funktionalit\u00e4t besitzen. Zum Beispiel, wenn Ger\u00e4te von Batterien betrieben werden, wird dasselbe Problem mit dem Aufladen und der Kontrolle ihres Niveaus auftreten. Gleiches gilt f\u00fcr Sensoren. Tats\u00e4chlich erm\u00f6glicht der objektorientierte Ansatz in der Programmierung \u201edie Erstellung von Objekten, die Eigenschaften und Verhaltensweisen zu einer eigenst\u00e4ndigen Einheit verbinden, die dann mehrfach verwendet werden kann\u201c<\/i>. Meiner Meinung nach wurde im BLE ein \u00e4hnlicher Ansatz versucht. Die Bluetooth Special Interest Group (SIG) hat Profile entwickelt. Ger\u00e4te von verschiedenen Herstellern, die dieselben Profile haben, sollten problemlos miteinander funktionieren. Die Profile bestehen wiederum aus Diensten, und die Dienste aus Merkmalen, die durch Deskriptoren erg\u00e4nzt werden. Im Allgemeinen k\u00f6nnte das so aussehen:<\/p>\n

\"BLE
\n
\nAls Beispiel betrachten wir das Schema des Herzfrequenzmonitors (Fitnessarmband). Es besteht aus zwei Diensten und mehreren Merkmalen. Daraus wird sofort die Hierarchie des Profils klar. Das Merkmal der Kontrollpunkt setzt die Gesamtsumme der Kalorienverbrauch auf null zur\u00fcck. <\/p>\n

1. Der Herzfrequenzdienst umfasst drei Merkmale (0x180D):
\n    a) Obligatorisches Merkmal der Herzfrequenz (0x2A37)
\n    b) Fakultatives Merkmal der K\u00f6rperpositionssensor (0x2A38)
\n    c) Bedingtes Merkmal des Kontrollpunkts der Herzfrequenz (0x2A39)
\n2. Der Service f\u00fcr die Batteriepflege (0x180F):
\n    a) Obligatorische Kennzeichnung des Batterieladezustands (0x2A19)<\/p>\n

UUID<\/h3>\n

\nUm eindeutig auf die Elemente des Profils (Dienste, Merkmale und Deskriptoren) zugreifen zu k\u00f6nnen, m\u00fcssen diese einer Nummerierung unterzogen werden. Zu diesem Zweck wird das Konzept der Universally Unique ID (UUID) oder des Universellen eindeutigen Identifikators eingef\u00fchrt. Die UUID ist in Klammern bei jeder Zeile angegeben. Und hier gibt es eine Besonderheit. F\u00fcr UUIDs wurde ein Code mit einer L\u00e4nge von 16 und 128 Bit verwendet. Warum, fragen Sie sich? Im BLE-Protokoll dreht sich alles um Energiesparen. Aus diesem Grund ist eine Dimension von 16 Bit durchaus sinnvoll. Es ist unwahrscheinlich, dass in naher Zukunft mehr als 65 Tausend einzigartige Dienste und Merkmale erstellt werden. Bis jetzt wurde alles, was m\u00f6glich war, bereits gez\u00e4hlt (erinnern Sie sich an das Sprichwort \u2014 \u201eEr hat auch Sie gez\u00e4hlt\u201c :-)) Nummerierte Elemente profile<\/a><\/noindex>, Dienste<\/a><\/noindex>, merkmale<\/a><\/noindex> und deskriptoren<\/a><\/noindex> k\u00f6nnen Sie \u00fcber die Links einsehen.<\/p>\n

Ich denke jedoch, dass sich alle an die Geschichte mit den 4 Byte IP-Adressen im Internet erinnern. Zuerst dachte man, das w\u00fcrde ausreichen, und jetzt k\u00f6nnen wir einfach nicht auf die 6 Byte Adresse umsteigen. Um diesen Fehler nicht zu wiederholen und den schelmischen H\u00e4nden von Bastlern keinen Raum zu geben, beschloss der SIG gleich, auch 128-Bit UUIDs einzuf\u00fchren. Das erinnert mich pers\u00f6nlich an das nicht lizenzierte Frequenzband von 433 MHz, das an verschiedene Bastler aus der Radiokanal-Community verkauft wurde. In unserem Fall wurde der 128-Bit Identifikator f\u00fcr Dienste und Merkmale zum Verkauf angeboten. Das bedeutet, dass wir f\u00fcr unsere Dienste und Ger\u00e4te praktisch jeden 128-Bit Wert verwenden k\u00f6nnen. Die Wahrscheinlichkeit, dass zwei identische UUIDs erfunden werden, tendiert gegen Null.<\/p>\n

Tats\u00e4chlich haben die kurzen 16-Bit UUIDs ihre Erweiterung auf einen 128-Bit Wert. In den Spezifikationen wird diese Erweiterung Bluetooth Base UUID genannt und hat den Wert 00000000-0000-1000-8000-00805F9B34FB. Wenn die 16-Bit UUID des Attributs beispielsweise den Wert 0x1234 hat, dann hat die entsprechende 128-Bit UUID den Wert 00001234-0000-1000-8000-00805F9B34FB. Es wird sogar eine entsprechende Formel angegeben:<\/p>\n

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID<\/p>\n

Woher diese magische Zahl stammt, ist mir nicht bekannt. Wenn jemand aus den Lesern es wei\u00df, kann er in den Kommentaren schreiben (Der Benutzer mit dem Nicknamen Sinopteek hat dies bereits getan. Siehe Kommentare). Was das Erstellen von 128-Bit UUIDs betrifft, so kann man im Prinzip einen speziellen Generator<\/a><\/noindex>, der das f\u00fcr Sie erledigt.<\/p>\n

ATT\u044b GATT\u044b\u2026<\/h3>\n

\n Tats\u00e4chlich beginnt jetzt das Interessanteste. Ich erinnere daran, dass ATT auf einer Client-Server-Beziehung basiert. Jetzt betrachten wir das Ger\u00e4t des Servers. Es enth\u00e4lt Informationen wie Sensordaten, den Zustand des Lichtschalters, Standortdaten usw. Nun, da alle \u201eTeilnehmer unserer Parade\u201c nummeriert sind, m\u00fcssen sie im Speicher des Ger\u00e4ts angeordnet werden. Dazu platzieren wir sie in einer Tabelle, die als Attributtabelle bezeichnet wird. Merkt euch das gut. Das ist das Herzst\u00fcck von BLE. Genau das werden wir weiter betrachten. Nun werden wir jede Zeile als Attribut bezeichnen. Diese Tabelle befindet sich tief im Stack und normalerweise haben wir keinen direkten Zugriff darauf. Wir initialisieren sie und greifen darauf zu, aber was dort innen passiert, bleibt hinter sieben Siegeln verborgen. <\/p>\n

Betrachten wir das Bild aus der Spezifikation, jedoch m\u00f6chte ich zuvor auf die h\u00e4ufige Verwirrung bei den Begriffen hinweisen, insbesondere bei den Deskriptoren. Die Rolle des Deskriptors besteht darin, die Beschreibung einer Eigenschaft zu erg\u00e4nzen. Wenn man ihre M\u00f6glichkeiten erweitern muss, werden Deskriptoren verwendet. Sie sind ebenfalls Attribute und stehen gleichwertig zu Diensten und Eigenschaften in der Attributtabelle. Wir werden sie im zweiten Teil des Artikels ausf\u00fchrlich behandeln. Manchmal werden jedoch mit Deskriptoren die Zeilennummern in der Attributtabelle bezeichnet. Das sollte man im Hinterkopf behalten. Um Verwirrung zu vermeiden, verwenden wir hierf\u00fcr den Begriff \u201eAttributanzeiger\u201c.
\n\"BLE
\n
\nEin Attribut ist also ein diskretes Wert, das die folgenden Eigenschaften besitzt:
\n1. Attributanzeiger (Attribute Handle) \u2014 das ist der Index der Tabelle, der dem Attribut entspricht
\n2. Attributtyp (Attribute Type) \u2014 das ist die UUID, die seinen Typ beschreibt
\n3. Attributwert (Attribute Value) \u2014 das sind die Daten, die durch den Attributanzeiger indiziert werden
\n4. Attributberechtigungen (Attribute Permissions) sind ein Teil des Attributs, Berechtigungen, die nicht k\u00f6nnen gelesen oder geschrieben werden mit dem Attributprotokoll<\/p>\n

Wie versteht man das alles? Der Attributanzeiger ist, um es vorsichtig auszudr\u00fccken, seine Nummer in unserer Tabelle.
\nEs erm\u00f6glicht dem Kunden, in Lese- oder Schreibanfragen auf ein Attribut zu verweisen. Wir k\u00f6nnen unsere Zeilen (Attribute) von 0x0001 bis 0xFFFF nummerieren. In unserer Assoziation mit einem B\u00fccherregal ist dies die Kartennummer im Papierkatalog. \u00c4hnlich wie im Bibliothekskatalog sind die Karten in aufsteigender Reihenfolge nummeriert. Die Nummer jeder nachfolgenden Zeile muss gr\u00f6\u00dfer sein als die vorherige. Wie in der Bibliothek gehen manchmal einige Karten verloren, so dass auch in unserer Nummerierung der Zeilen L\u00fccken auftreten k\u00f6nnen. Das ist zul\u00e4ssig. Wichtig ist, dass sie aufsteigend sind.<\/p>\n

Der Attributtyp bestimmt, was dieses Attribut darstellt. Analog zur Programmiersprache C,
\nwo es Boolesche Variablen, numerische Variablen und Strings gibt, so gibt es auch hier Unterschiede. Anhand des Attributtyps erfahren wir,
\nwomit wir es zu tun haben und wie wir mit diesem Attribut weiterarbeiten k\u00f6nnen. Unten werden wir einige spezifische Attributtypen betrachten. Zum Beispiel \u201eService Declaration\u201c (0x2800), \u201eCharacteristic Declaration\u201c (0x2803), \u201eDescriptor Declaration\u201c (0x2902).<\/p>\n

Der Attributwert ist genau das, was er bedeutet, entschuldigen Sie die Tautologie. Wenn der Attributtyp ein String ist, kann der Attributwert beispielsweise der Slogan \u201eHello World !!!\u201c sein. Wenn der Attributtyp \u201eService Declaration\u201c ist, besteht sein Wert im Dienst selbst. Manchmal handelt es sich auch um Informationen dar\u00fcber, wo andere Attribute und deren Eigenschaften zu finden sind.<\/p>\n

Die Berechtigungen der Attribute erm\u00f6glichen es dem Server zu verstehen, ob der Zugriff zum Lesen oder Schreiben erlaubt ist.
\nBitte beachten Sie, dass diese Berechtigungen nur f\u00fcr den Attributwert gelten, nicht f\u00fcr den Zeiger, den Typ und das Feld der Berechtigungen selbst. Das hei\u00dft, wenn das Schreiben eines Attributs erlaubt ist, k\u00f6nnen wir zum Beispiel die Zeile \u201eHello World !!!\u201c in die Zeile \u201eGood morning\u201c \u00e4ndern. Aber wir k\u00f6nnen nicht das Hinzuf\u00fcgen einer neuen Zeile untersagen oder den Attributtyp \u00e4ndern und die Zeile als \u201eService Declaration\u201c kennzeichnen. Wenn der Client auf den Server zugreift, fragt der Client nach seinen Attributen. Dies erm\u00f6glicht es dem Client, zu erfahren, was der Server bereitstellen kann. Es ist jedoch nicht notwendig, Werte zu lesen und zu schreiben.<\/p>\n

Wie es aussieht<\/h3>\n

\nDas Konzept von GATT besteht darin, Attribute in der Attributtabelle in einer sehr spezifischen und logischen Reihenfolge zu gruppieren. Lassen Sie uns das Profil der Herzfrequenz, das unten aufgef\u00fchrt ist, genauer betrachten. Die ganz linke Spalte dieser Tabelle ist optional. Sie beschreibt nur, was diese Zeile (Attribut) ist. Alle anderen Spalten sind uns bereits bekannt.<\/p>\n

\"BLE
\n
\nImmer an oberster Stelle jeder Gruppe haben wir das Attribut zur Dienstdeklaration. Sein Typ ist immer 0x2800, und der Zeiger h\u00e4ngt davon ab, wie viele Attribute bereits in der Tabelle vorhanden sind. Seine Berechtigungen sind stets nur lesbar und erfordern keine Authentifizierung oder Autorisierung. \u00dcber diese Konzepte werden wir sp\u00e4ter sprechen. Der Wert ist ein weiterer UUID, der bestimmt, um welchen Dienst es sich handelt. In der Tabelle hat der Wert 0x180D, der von Bluetooth SIG als Dienst f\u00fcr Herzfrequenzen definiert wird. <\/p>\n

Nach der Dienstdeklaration folgt die Charakteristikdeklaration. In der Form ist sie analog zur Dienstdeklaration. Ihr UUID hat immer den Wert 0x2803, und die Berechtigungen sind ebenfalls stets nur lesbar, ohne dass eine Authentifizierung oder Autorisierung erforderlich ist. Lassen Sie uns das Feld Attributwert betrachten, das einige Daten umfasst. Es enth\u00e4lt immer einen Zeiger, UUID und eine Menge von Eigenschaften. Diese drei Elemente beschreiben die nachfolgende Deklaration des Charakteristikwerts. Der Zeiger bezeichnet nat\u00fcrlich den Ort der Deklaration des Charakteristikwerts in der Attributtabelle. Die UUID beschreibt, welche Art von Informationen oder Werten wir erwarten k\u00f6nnen. Zum Beispiel den Temperaturwert, den Status eines Lichtschalters oder einen anderen beliebigen Wert. Und schlie\u00dflich die Eigenschaften, die beschreiben, wie man mit dem Charakteristikwert interagieren kann. <\/p>\n

Hier wartet auf uns ein weiterer Stolperstein. Er steht im Zusammenhang mit den Berechtigungen der Attribute und den Eigenschaften der Charakteristiken. Lassen Sie uns das Bild der Eigenschaften des Bitfelds aus der Spezifikation betrachten.<\/p>\n

\"BLE
\n
\nWie Sie sehen k\u00f6nnen, gibt es hier auch Felder, die Lese- und Schreibm\u00f6glichkeiten bieten. Sie k\u00f6nnten sich fragen, warum wir Berechtigungen f\u00fcr das Lesen\/Schreiben f\u00fcr das Attribut und die Eigenschaften haben.
\nLesen\/Schreiben f\u00fcr den Wert der Eigenschaft? Sollten diese nicht immer gleich sein? Die Sache ist die, dass die Eigenschaften f\u00fcr den Wert der Eigenschaft tats\u00e4chlich nur Empfehlungen f\u00fcr den Kunden sind, die in GATT und Anwendungsschichten verwendet werden. Es sind einfach Hinweise darauf, was der Kunde von der Eigenschaftsdeklaration erwarten kann. Lassen Sie uns das n\u00e4her betrachten. Welche Arten von Berechtigungen gibt es f\u00fcr die Eigenschaft? <\/p>\n

1. Zugriffsberechtigungen:
\n     \u2014 lesen
\n     \u2014 schreiben
\n     \u2014 lesen und schreiben
\n2. Authentifizierungsberechtigung:
\n     \u2014 Authentifizierung erforderlich
\n     \u2014 Authentifizierung nicht erforderlich
\n3. Autorisierungsberechtigung:
\n     \u2014 Autorisierung erforderlich
\n     \u2014 Autorisierung nicht erforderlich<\/p>\n

Der Hauptunterschied zwischen den Berechtigungen der Attribute und den Eigenschaften der Merkmale besteht darin, dass erstere sich auf Server beziehen, w\u00e4hrend letztere sich auf Kunden beziehen. Ein Server kann die Leseerlaubnis f\u00fcr den Wert des Merkmals haben, jedoch die Anforderung einer Authentifizierung oder Autorisierung bestehen. Daher werden wir, wenn der Kunde Eigenschaften des Merkmals anfordert, feststellen, dass das Lesen erlaubt ist. Bei dem Versuch, zu lesen, wird jedoch ein Fehler auftreten. Daher kann man mit Fug und Recht von der Priorit\u00e4t der Berechtigungen gegen\u00fcber den Eigenschaften sprechen. Das Wissen dar\u00fcber, welche Berechtigungen das Attribut hat, k\u00f6nnen wir von der Kundenseite aus nicht erhalten.<\/p>\n

Deskriptor<\/h3>\n

\nKommen wir zur\u00fcck zu unserer Tabelle. Nach der Deklaration des Wertes der Eigenschaft sind folgende Deklarationen der Attribute m\u00f6glich:
\n1. Neue Merkmalsdeklaration (es kann viele Merkmale im Dienst geben)
\n2. Neue Dienstdeklaration (es kann viele davon in der Tabelle geben)
\n3. Deklaration des Deskriptors <\/p>\n

Im Falle der Charakterisierung der Messung der Herzfrequenz wird in unserer Tabelle die Ank\u00fcndigung des Wertzeichens von der Ank\u00fcndigung des Deskriptors begleitet. Der Deskriptor ist ein Attribut mit zus\u00e4tzlichen Informationen zur Charakteristik. Es gibt mehrere Arten von Deskriptoren. Dar\u00fcber werden wir im zweiten Teil dieses Artikels ausf\u00fchrlich sprechen. Jetzt werden wir uns nur mit dem Deskriptor der Konfiguration der Client-Charakteristika (Client Characteristic Configuration Descriptor \u2013 CCCD) befassen. Er hat eine UUID von 0x2902. Mithilfe dieses Deskriptors hat der Client die M\u00f6glichkeit, die Anzeige oder Benachrichtigung auf dem Server zu aktivieren. Der Unterschied zwischen ihnen ist gering, aber dennoch vorhanden. Eine Benachrichtigung erfordert keine Best\u00e4tigung des Empfangs durch den Client. Eine Anzeige hingegen erfordert dies, auch wenn sie auf GATT-Ebene erfolgt und nicht bis zur Anwendungsebene gelangt. Warum ist das so, fragen Sie? Leider wei\u00df ich das nicht. Ich kann nur sagen, dass die Experten von Nordic empfehlen, die Benachrichtigung zu verwenden. Zudem findet die \u00dcberpr\u00fcfung der Integrit\u00e4t des Pakets (mittels CRC) in beiden F\u00e4llen statt.<\/p>\n

Fazit<\/h3>\n

\nAm Ende des Artikels m\u00f6chte ich Folgendes sagen. Die letzte Tabelle ist etwas verwirrend. Ich habe jedoch darauf bestanden, da sie in Artikel<\/a><\/noindex>, auf die ich mich st\u00fctze. Im zweiten Teil meines Artikels beabsichtige ich, mich eingehender mit der Spezifikation von BlueTooth 4.0 zu besch\u00e4ftigen. Dort erwarten uns genauere Diagramme und Zeichnungen. Im dritten Teil m\u00f6chte ich ein Protokoll analysieren, das mit dem Programm Wireshark von einem der Gadgets erfasst wurde, und die gesamte Theorie, die wir zusammen lernen, \u201elive\u201c sehen.<\/p>\n

Mitarbeiter der Unternehmensgruppe \u201eC\u00e4sar Satellite\u201c<\/a><\/noindex>
\nWladimir Pecherski
\n
Quelle: habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b…) \u0427\u0430\u0441\u0442\u044c 1, \u043e\u0431\u0437\u043e\u0440\u043d\u0430\u044f \u0423\u0436\u0435 \u043f\u0440\u043e\u0448\u043b\u043e \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u0432\u0440\u0435\u043c\u044f, \u0441 \u0442\u0435\u0445 \u043f\u043e\u0440, \u043a\u043e\u0433\u0434\u0430 \u0432\u044b\u0448\u043b\u0430 \u043f\u0435\u0440\u0432\u0430\u044f \u0441\u043f\u0435\u0446\u0438\u0444\u0438\u043a\u0430\u0446\u0438\u044f \u043d\u0430 Bluetooth 4.0. \u0418, \u0445\u043e\u0442\u044f \u0442\u0435\u043c\u0430 BLE \u043e\u0447\u0435\u043d\u044c \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u0430, \u043e\u043d\u0430 \u0434\u043e \u0441\u0438\u0445 \u043f\u043e\u0440 \u043e\u0442\u0442\u0430\u043b\u043a\u0438\u0432\u0430\u0435\u0442 \u043c\u043d\u043e\u0433\u0438\u0445 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u043e\u0432, \u0438\u0437-\u0437\u0430 \u0441\u0432\u043e\u0435\u0439 \u0441\u043b\u043e\u0436\u043d\u043e\u0441\u0442\u0438. \u0412 \u0441\u0432\u043e\u0438\u0445 \u043f\u0440\u0435\u0434\u044b\u0434\u0443\u0449\u0438\u0445 \u0441\u0442\u0430\u0442\u044c\u044f\u0445 \u044f \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u043b \u0432 \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u043c \u0441\u0430\u043c\u044b\u0439 \u043d\u0438\u0436\u043d\u0438\u0439 \u0443\u0440\u043e\u0432\u0435\u043d\u044c Link Layer \u0438 Physical Layer. […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":84025,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-84024","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47BLE unter dem Mikroskop (ATTs, GATTs\u2026) | ProHoster","description":"BLE unter dem Mikroskop (ATTs, GATTs...) Teil 1.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b\u2026) | ProHoster","og:description":"BLE \u043f\u043e\u0434 \u043c\u0438\u043a\u0440\u043e\u0441\u043a\u043e\u043f\u043e\u043c (ATT\u044b GATT\u044b...) \u0427\u0430\u0441\u0442\u044c 1.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2020-06-04T17:42:32+00:00","article:modified_time":"2020-06-04T17:42:32+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"84024","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 15:06:38","updated":"2022-09-28 11:11:59","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/84024","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=84024"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/84024\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/84025"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=84024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=84024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=84024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}