{"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\/da\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","title":{"rendered":"BLE under mikroskopet (ATT'er GATT'er…)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"BLE<\/p>\n

BLE under mikroskopet (ATT'er GATT'er…)<\/h2>\n

Part 1, Overview<\/b><\/p>\n

It has been quite some time since the first specification for Bluetooth 4.0 was released. And while the topic of BLE is very interesting, it still deters many developers due to its complexity. In my previous articles, I mainly focused on the lowest levels: Link Layer and Physical Layer. This allowed me to avoid delving into complex and convoluted concepts such as the Attribute Protocol (ATT) and the Generic Attribute Profile (GATT). However, there\u2019s no escaping it; without understanding these concepts, developing compatible devices is impossible. Today, I would like to share this knowledge with you. In my article, I will refer to h\u00e5ndbogen<\/a><\/noindex> the beginner's guide from Nordic. So, let's get started.
\n<\/a><\/noindex><\/p>\n

Why is it all so complicated?<\/h3>\n

\nIn my opinion, it was immediately clear that controlling devices via smartphones is a very promising and long-term topic. Therefore, they decided to structure it right from the start as comprehensively as possible. This is to prevent manufacturers of various gadgets from inventing their own protocols that would later be incompatible. Hence, the complexity. Even in the first stage, the BLE protocol attempted to squeeze in everything that was possible. And it doesn't matter whether it will be useful later or not. Furthermore, provisions were made for future device list expansion.<\/p>\n

Let's take a look at the diagram illustrating the BLE protocol. It consists of several layers. The lowest, physical layer (PHY) is responsible for the device's radio channel. The Link Layer (LL) contains the entire sequence of bytes in the transmitted message. In previous articles, we studied this layer specifically. The Host Controller Interface (HCI) is the protocol for communication between the layers or BLE chips if the Controller and Host are implemented on different chips. The Logical Link Control and Adaptation Protocol (L2CAP) is responsible for packet formation, fragmentation, error control, and packet assembly. The Security Manager Protocol (SMP) is in charge of encrypting packets. The Generic Access Profile (GAP) is responsible for the initial data exchange between devices to determine 'Who is who'. It also includes scanning and advertising. In this article, I will focus on the two remaining parts of the protocol \u2014 GATT and ATT. GATT is built on top of ATT, so they are closely intertwined.<\/p>\n

\"BLE
\n
\nFor the sake of simplicity in storytelling, I would like to refer to an analogy. I heard it somewhere and would like to support it. Imagine a BLE device as a bookshelf with several shelves. Each shelf represents a different theme. For example, we have shelves for fiction, mathematics, and encyclopedias. On each shelf, there are books covering the specified topic. Some of these books even have paper bookmarks with notes. Additionally, we have a small paper catalog of all the books. If you remember school libraries, it's like a narrow drawer with paper cards. In this analogy, the bookshelf is the profile of our device. The shelves are the services, the books are the characteristics, and the catalog is the attribute table. The bookmarks in the books are the descriptors, which I will also discuss later in more detail.<\/p>\n

Anyone who has developed devices knows that many projects have similar pieces of code. The fact is that many devices have similar functionalities. For example, if devices run on batteries, the problem of charging and monitoring their levels will be the same. The same applies to sensors. In fact, the object-oriented approach in programming provides the opportunity to create objects that connect properties and behaviors into a self-contained union that can then be reused multiple times.<\/i>In my opinion, a similar approach has been attempted in BLE. The Bluetooth Special Interest Group (SIG) developed profiles. Devices from different manufacturers that have the same profiles should easily work with each other. Profiles, in turn, consist of services, and services consist of characteristics complemented by descriptors. Generally, this might look like:<\/p>\n

\"BLE
\n
\nFor example, let's consider the profile of a heart rate monitor (fitness tracker). It consists of two services and several characteristics. This immediately clarifies the hierarchy of the profile. The characteristic of the control point resets the overall calorie expenditure count to zero. <\/p>\n

1. The heart rate service includes three characteristics (0x180D):
\n    a) Mandatory characteristic of heart rate (0x2A37)
\n    b) Optional characteristic of body sensor location (0x2A38)
\n    c) Conditional characteristic of heart rate control point (0x2A39)
\n2. Battery service (0x180F):
\n    a) Obligatorisk batteriniveauegenskab (0x2A19)<\/p>\n

UUID<\/h3>\n

\nFor at vi entydigt kan referere til profilens elementer (tjenester, egenskaber og beskrivelser) er det n\u00f8dvendigt at nummerere dem. Til dette form\u00e5l introduceres et begreb kaldet Universally Unique ID (UUID) eller Universel unik identifikator. Den n\u00f8dvendige UUID er angivet i parentes i hver linje. Der er en s\u00e6rlig egenskab ved dette. For UUID besluttede man at bruge en kode med en l\u00e6ngde p\u00e5 16 og 128 bit. Hvorfor, sp\u00f8rger du? I BLE-protokollen er alt underordnet energibesparelse. Derfor er dimensionen p\u00e5 16 bit ganske fornuftig. Det er usandsynligt, at der i den n\u00e6rmeste fremtid vil blive skabt mere end 65.000 unikke tjenester og egenskaber. Lige nu har vi allerede talt alt, hvad vi kunne (husker du hvor det kommer fra \u2014 \"han har ogs\u00e5 talt dig\" :-)) Nummererede elementer profiler<\/a><\/noindex>, tjenester<\/a><\/noindex>, egenskaber<\/a><\/noindex> og beskrivelser<\/a><\/noindex> du kan se det via links.<\/p>\n

Men jeg tror, at alle husker historien om de 4 byte IP-adresser p\u00e5 internettet. F\u00f8rst troede man, det var tilstr\u00e6kkeligt, men nu kan vi ikke komme videre til 6-byte adresser. For ikke at gentage denne fejl og give plads til nysgerrige h\u00e6nder fra opfindere, besluttede SIG straks at introducere 128-bit UUID'er. Det minder mig personligt om det ikke-licensekr\u00e6vende b\u00e5nd p\u00e5 433 MHz, som blev givet til diverse opfindere inden for radiokanalen. I vores tilf\u00e6lde blev det 128-bit identifikator for tjenester og egenskaber givet videre. Det betyder, at vi for vores tjenester og enheder kan bruge praktisk talt enhver 128-bit v\u00e6rdi. Sandsynligheden for at finde en identisk UUID n\u00e6rmer sig nul.<\/p>\n

Faktisk har de korte 16-bit UUID'er deres udvidelse til en 128-bit v\u00e6rdi. I specifikationen kaldes denne udvidelse Bluetooth Base UUID og har v\u00e6rdien 00000000-0000-1000-8000-00805F9B34FB. Hvis en 16-bit UUID for en attribut har v\u00e6rdien 0x1234, s\u00e5 vil den \u00e6kvivalente 128-bit UUID have v\u00e6rdien 00001234-0000-1000-8000-00805F9B34FB. Der gives endda den tilsvarende formel:<\/p>\n

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

Hvor dette magiske tal kommer fra, ved jeg ikke. Hvis nogen af l\u00e6serne ved det \u2014 s\u00e5 skriv gerne i kommentarerne (Brugeren med navnet Sinopteek har allerede gjort det. Se kommentarerne). Hvad ang\u00e5r generering af 128-bit UUID'er, kan man i princippet bruge en speciel generator<\/a><\/noindex>, som vil g\u00f8re det for dig.<\/p>\n

ATT'er GATT'er\u2026<\/h3>\n

\n Her begynder det egentlige interessante. Jeg minder om, at ATT er baseret p\u00e5 et klient-server-forhold. Nu ser vi p\u00e5 serverens enhed. Den indeholder information som sensorv\u00e6rdier, status for lyskontakten, placeringsdata osv. Nu, hvor alle \"deltagerne i vores parade\" er nummereret, skal de placeres i enhedens hukommelse. For dette placerer vi dem i en tabel, der kaldes attributtabel. Husk dette godt. Det er hjertet af BLE. Det er det, vi vil unders\u00f8ge n\u00e6rmere. Nu vil vi kalde hver r\u00e6kke en attribut. Denne tabel ligger dybt i stakken, og som regel har vi ikke direkte adgang til den. Vi initialiserer den og tilg\u00e5r den, men hvad der sker inden i, er skjult for os bag syv segl. <\/p>\n

Lad os se p\u00e5 billedet fra specifikationen, men f\u00f8r det vil jeg gerne henlede opm\u00e6rksomheden p\u00e5 den hyppige forvirring i terminologien, is\u00e6r med hensyn til deskriptorer. Deskriptorens rolle er at supplere beskrivelsen af en egenskab. N\u00e5r det er n\u00f8dvendigt at udvide dens funktioner, anvendes deskriptorer. De er ogs\u00e5 attributter og placeres ligesom tjenester og egenskaber i attributtabellen. Vi vil g\u00e5 grundigt igennem dem i del to af artiklen. Men nogle gange kaldes deskriptorer ogs\u00e5 linjenummeret i attributtabellen. Det er vigtigt at have in mente. For at undg\u00e5 forvirring vil vi bruge termen \"attributpeger\" til disse form\u00e5l.
\n\"BLE
\n
\nS\u00e5 attribut er en diskret v\u00e6rdi, der har f\u00f8lgende tilknyttede egenskaber:
\n1. Attributpeger (Attribute Handle) \u2013 det er indekset for tabellen, der svarer til attributten.
\n2. Attributtype (Attribute Type) \u2013 det er UUID'en, som beskriver dens type.
\n3. Attributv\u00e6rdien (Attribute Value) \u2013 det er dataene, der indekseres af attributpegeren.
\n4. Attributtilladelser (Attribute Permissions) \u2014 er en del af attributten, tilladelser, som ikke     kan l\u00e6ses eller skrives ved hj\u00e6lp af attributprotokollen<\/p>\n

Hvordan forst\u00e5r man alt dette? Attributpegeren er, s\u00e5 at sige, dens nummer i vores tabel.
\nDet giver kunden mulighed for at referere til attributten i l\u00e6se- eller skriveanmodninger. Vi kan nummerere vores r\u00e6kker (attributter) fra 0x0001 til 0xFFFF. I vores association med reolen er dette nummeret p\u00e5 kortet i det fysiske katalog. Tilsvarende, som i et biblioteks katalog, er kortene placeret i stigende r\u00e6kkef\u00f8lge efter nummer. Nummeret p\u00e5 hver efterf\u00f8lgende r\u00e6kke skal v\u00e6re st\u00f8rre end det forrige. Ligesom i biblioteket, kan nogle kort g\u00e5 tabt, og s\u00e5ledes kan der v\u00e6re huller i nummereringen af r\u00e6kker. Dette er tilladt. Det vigtigste er, at de f\u00f8lger en stigende r\u00e6kkef\u00f8lge.<\/p>\n

Attributtypen bestemmer, hvad den p\u00e5g\u00e6ldende attribut repr\u00e6senterer. P\u00e5 samme m\u00e5de som i C-sprog,
\nhvor der findes boolske, numeriske variabler og strenge, her er det det samme. Gennem attributtypen kan vi finde ud af,
\nhvad vi har med at g\u00f8re, og hvordan vi skal arbejde med denne attribut fremad. Nedenfor vil vi se p\u00e5 nogle specifikke typer attributter. For eksempel \"serviceerkl\u00e6ring\" (0x2800), \"karakteristikserkl\u00e6ring\" (0x2803), \"descriptor-erkl\u00e6ring\" (0x2902).<\/p>\n

Attributv\u00e6rdien er i grunden dens v\u00e6rdi, undskyld for tautologien. Hvis attributtypen er en streng, kan v\u00e6rdien f.eks. v\u00e6re sloganet \"Hello World !!!\". Hvis attributtypen er \"serviceerkl\u00e6ring\", er v\u00e6rdien den selve service. Og nogle gange er det information om, hvor man kan finde andre attributter og deres egenskaber.<\/p>\n

Attributtilladelser giver serveren mulighed for at forst\u00e5, om l\u00e6se- eller skriverettigheder er tilladt.
\nBem\u00e6rk, at disse tilladelser kun g\u00e6lder for attributv\u00e6rdien, og ikke for pegeren, typen og selve tilladelsesfeltet. Det vil sige, hvis skrivning af attributten er tilladt, kan vi \u00e6ndre for eksempel r\u00e6kken \"Hello World !!!\" til r\u00e6kken \"Good morning\". Men vi kan ikke n\u00e6gte at skrive en ny r\u00e6kke eller \u00e6ndre attributtypen og angive r\u00e6kken som \"serviceerkl\u00e6ring\". N\u00e5r klienten henvender sig til serveren, anmoder klienten om dens attributter. Dette g\u00f8r det muligt for klienten at finde ud af, hvad serveren kan tilbyde. Selvom det ikke n\u00f8dvendigvis er n\u00f8dvendigt at l\u00e6se og skrive v\u00e6rdier.<\/p>\n

How it looks<\/h3>\n

\nGATT-konceptet handler om at gruppere attributter i en attributtabel sammen p\u00e5 en meget specifik og logisk m\u00e5de. Lad os tage et t\u00e6ttere kig p\u00e5 profilen for hjertefrekvensen, som er angivet nedenfor. Den venstre kolonne i denne tabel er valgfri. Den beskriver blot, hvad denne r\u00e6kke (attribut) er. Alle de andre kolonner er allerede kendte for os.<\/p>\n

\"BLE
\n
\n\u00d8verst i hver gruppe har vi altid attributten for serviceannonceret. Dens type er altid lig med 0x2800, og pegepinden afh\u00e6nger af, hvor mange attributter der allerede er til stede i tabellen. Dens tilladelser er altid kun tilg\u00e6ngelige for l\u00e6sning, uden nogen form for godkendelse eller autorisation. Vi vil tale mere om disse begreber senere. V\u00e6rdien er endnu en UUID, der definerer, hvilken service det er. I tabellen er v\u00e6rdien lig med 0x180D, som er defineret af Bluetooth SIG som en hjertefrekvensservice. <\/p>\n

Efter serviceannonceret f\u00f8lger der en karakteristikannonce. I formen ligner den serviceannoncen. Dens UUID har altid v\u00e6rdien 0x2803, og tilladelserne er ogs\u00e5 altid kun tilg\u00e6ngelige for l\u00e6sning uden nogen form for godkendelse eller autorisation. Lad os tage et kig p\u00e5 feltet Attributv\u00e6rdi, som inkluderer nogle data. Det indeholder altid en pegepind, UUID og et s\u00e6t egenskaber. Disse tre elementer beskriver den efterf\u00f8lgende annoncering af karakteristikv\u00e6rdien. Pegepinden angiver naturligvis placeringen af karakteristikv\u00e6rdien i attributtabellen. UUID'en beskriver, hvilken type information eller v\u00e6rdi vi kan forvente. For eksempel temperaturv\u00e6rdi, tilstand af en lyskontakt eller en hvilken som helst anden vilk\u00e5rlig v\u00e6rdi. Og endelig egenskaberne, som beskriver, hvordan man kan interagere med karakteristikv\u00e6rdien. <\/p>\n

Her venter der os endnu en f\u00e6lde. Den er relateret til attributtilladelser og karakteristikegenskaber. Lad os tage et kig p\u00e5 billedet af bitfeltets egenskaber fra specifikationen.<\/p>\n

\"BLE
\n
\nSom du kan se, er der ogs\u00e5 felter, der giver l\u00e6se- og skrivemuligheder. Du kunne undre dig over, hvorfor vi har l\u00e6setilladelser\/skrivning for attributten og egenskaben.
\nL\u00e6sninger\/skrivninger for karakteristikv\u00e6rdi? Skal de ikke altid v\u00e6re ens? Sandheden er, at egenskaberne for karakteristikv\u00e6rdien blot er anbefalinger til kunden, der anvendes i GATT og applikationslagene. Det er simpelthen forslag om, hvad kunden kan forvente af attributten for karakteristikken. Lad os dykke lidt dybere ned i dette. Hvilke typer tilladelser findes der for attributten? <\/p>\n

1. Adgangstilladelser:
\n     \u2014 l\u00e6sning
\n     \u2014 skrivning
\n     \u2014 l\u00e6sning og skrivning
\n2. Autentifikationstilladelser:
\n     \u2014 autentifikation p\u00e5kr\u00e6vet
\n     \u2014 autentifikation ikke p\u00e5kr\u00e6vet
\n3. Autorisationstilladelser:
\n     \u2014 autorisation p\u00e5kr\u00e6vet
\n     \u2014 autorisation ikke p\u00e5kr\u00e6vet<\/p>\n

Den prim\u00e6re forskel mellem tilladelser for attributter og egenskaber for karakteristikker er, at de f\u00f8rstn\u00e6vnte relaterer til servere, mens de sidstn\u00e6vnte relaterer sig til kunder. En server kan have tilladelse til at l\u00e6se karakteristikv\u00e6rdien, men samtidig have krav om autentifikation eller autorisation. Derfor, n\u00e5r en kunde anmoder om egenskaberne for karakteristikken, vil vi f\u00e5, at l\u00e6sning er tilladt. Men ved fors\u00f8g p\u00e5 at l\u00e6se vil vi f\u00e5 en fejl. S\u00e5 det kan med sikkerhed siges, at tilladelserne har forrang over egenskaberne. Vi, fra kundens side, kan ikke f\u00e5 viden om, hvilke tilladelser der er for attributten.<\/p>\n

Descriptor<\/h3>\n

\nLad os vende tilbage til vores tabel. Efter erkl\u00e6ringen af karakteristikv\u00e6rdien er f\u00f8lgende erkl\u00e6ringer for attributter mulige:
\n1. Ny karakteristikserkl\u00e6ring (der kan v\u00e6re mange karakteristika i tjenesten)
\n2. Ny tjenesteerkl\u00e6ring (der kan v\u00e6re mange i tabellen)
\n3. Erkl\u00e6ring om descriptor <\/p>\n

N\u00e5r det kommer til m\u00e5lingen af puls, ledsages offentligg\u00f8relsen af m\u00e5lev\u00e6rdien af en beskrivelse. Beskrivelsen er en attribut med yderligere information om m\u00e5lingen. Der findes flere typer af beskrivelser. Det vil vi tale n\u00e6rmere om i anden del af denne artikel. Men nu vil vi kun ber\u00f8re den beskrivelse, der relaterer til kundeegenskaber (Client Characteristic Configuration Descriptor \u2013 CCCD). Den har et UUID der svarer til 0x2902. Ved hj\u00e6lp af denne beskrivelse kan kunden aktivere serverens indikation eller notifikation. Forskellen mellem dem er lille, men eksisterer. Notifikationen kr\u00e6ver ikke bekr\u00e6ftelse fra kunden, mens indikation kr\u00e6ver dette, selvom det foreg\u00e5r p\u00e5 GATT-niveauet, uden at det n\u00e5r op til applikationsniveauet. Hvorfor er det s\u00e5dan, sp\u00f8rger du? Desv\u00e6rre er jeg ikke klar over det. Jeg kan kun sige, at specialister fra Nordic anbefaler at bruge notifikation. Is\u00e6r fordi integritetstjekket (via CRC) udf\u00f8res i begge tilf\u00e6lde.<\/p>\n

Konklusion<\/h3>\n

\nTil slut i artiklen vil jeg gerne sige dette. Den sidste tabel er lidt forvirrende. Men jeg har valgt den, fordi den er n\u00e6vnt i artikel<\/a><\/noindex>, som jeg baserer mig p\u00e5. I anden del af min artikel planl\u00e6gger jeg at dykke ned i specifikationen for Bluetooth 4.0. Her vil vi finde mere korrekte diagrammer og illustrationer. I tredje del vil jeg gerne gennemg\u00e5 loggen opn\u00e5et med programmet Wireshark fra en af gadgets og se \"live\" den teori, vi studerer.<\/p>\n

Medarbejder i Gruppefirmaet \u00abC\u00e6sar Satellit\u00bb<\/a><\/noindex>
\nPechersky Vladimir
\n
Kilde: 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\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 under mikroskopet (ATT\u2019er GATT\u2019er\u2026) | ProHoster","description":"BLE under mikroskopet (ATT\u2019er GATT\u2019er\u2026) Del 1.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/84024","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=84024"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/84024\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/84025"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=84024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=84024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=84024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}