{"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\/es\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","title":{"rendered":"BLE bajo el microscopio (ATT y GATT\u2026)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"BLE<\/p>\n

BLE bajo el microscopio (ATT y GATT\u2026)<\/h2>\n

Parte 1, revisi\u00f3n<\/b><\/p>\n

Ha pasado bastante tiempo desde que se public\u00f3 la primera especificaci\u00f3n de Bluetooth 4.0. Y, aunque el tema de BLE es muy interesante, todav\u00eda rechaza a muchos desarrolladores debido a su complejidad. En mis art\u00edculos anteriores, he tratado principalmente el nivel m\u00e1s bajo, el Link Layer y el Physical Layer. Esto me permiti\u00f3 evitar conceptos tan complejos y confusos como el protocolo de atributos (ATT) y el perfil de atributos general (GATT). Sin embargo, no hay forma de evitarlo; sin entenderlos, es imposible desarrollar dispositivos compatibles. Hoy me gustar\u00eda compartir con ustedes estos conocimientos. En mi art\u00edculo, me basar\u00e9 en manual<\/a><\/noindex> los fundamentos para principiantes del sitio de Nordic. As\u00ed que, comencemos.
\n<\/a><\/noindex><\/p>\n

\u00bfPor qu\u00e9 todo es tan complicado?<\/h3>\n

\nEn mi opini\u00f3n, qued\u00f3 claro desde el principio que el control de dispositivos a trav\u00e9s de smartphones es un tema muy prometedor y de largo plazo. Por lo tanto, decidieron estructurarlo de inmediato al m\u00e1ximo. De esta manera, los fabricantes de varios gadgets no inventar\u00edan sus propios protocolos que luego no ser\u00edan compatibles. De ah\u00ed la complejidad. Ya en la primera etapa, el protocolo BLE intent\u00f3 incluir todo lo que fuera posible, sin importar si ser\u00eda \u00fatil posteriormente o no. Adem\u00e1s, se previ\u00f3 la posibilidad de ampliar la lista de dispositivos en el futuro.<\/p>\n

Veamos la imagen que muestra el esquema del protocolo BLE. Se compone de varias capas. La capa m\u00e1s baja, la capa f\u00edsica (PHY), es responsable del canal de radio del dispositivo. El Link Layer (LL) contiene toda la secuencia de bytes en el mensaje transmitido. En art\u00edculos anteriores estudiamos precisamente esto. La Interfaz de Controlador de Host (HCI) es el protocolo de intercambio entre capas o chips BLE, cuando el Controller y el Host est\u00e1n implementados en diferentes chips. La formaci\u00f3n de paquetes, la fragmentaci\u00f3n en tramas, el control de errores y la recopilaci\u00f3n de paquetes se realiza mediante el Protocolo de Control L\u00f3gico de Enlace y Adaptaci\u00f3n (L2CAP). El Protocolo de Seguridad de Administrador (SMP) se encarga del cifrado de paquetes. El perfil de acceso general (GAP) es responsable del intercambio inicial de datos entre dispositivos, para determinar \"qui\u00e9n es qui\u00e9n\". Esto tambi\u00e9n incluye escaneo y publicidad. En este art\u00edculo me centrar\u00e9 en las dos partes restantes del protocolo: GATT y ATT. GATT es una superestructura sobre ATT, por lo que est\u00e1n muy entrelazados.<\/p>\n

\"BLE
\n
\nPara simplificar la narrativa, quisiera utilizar una analog\u00eda. La escuch\u00e9 en alg\u00fan lugar y me gustar\u00eda apoyarla. Imagina un dispositivo BLE como una estanter\u00eda con varias baldas. Cada balda es un tema distinto. Por ejemplo, tenemos baldas de ciencia ficci\u00f3n, matem\u00e1ticas, enciclopedias. En cada balda hay libros sobre el tema correspondiente. Y en algunos libros incluso hay marcap\u00e1ginas con anotaciones. Adem\u00e1s, tenemos un peque\u00f1o cat\u00e1logo en papel de todos los libros. Si recuerdas las bibliotecas escolares, es una caja estrecha con tarjetas de papel. Con esta analog\u00eda, la estanter\u00eda es el perfil de nuestro dispositivo. Las baldas son los servicios, los libros son las caracter\u00edsticas, y el cat\u00e1logo es la tabla de atributos. Los marcap\u00e1ginas en los libros son los descriptores, de los que tambi\u00e9n hablar\u00e9 m\u00e1s adelante, con m\u00e1s detalle.<\/p>\n

Todos los que han desarrollado dispositivos saben que en muchos proyectos hay trozos de c\u00f3digo similares. La raz\u00f3n es que muchos dispositivos tienen funciones similares. Por ejemplo, si los dispositivos funcionan con bater\u00edas, el problema de la carga y el control de su nivel ser\u00e1 el mismo. Lo mismo se aplica a los sensores. De hecho, el enfoque orientado a objetos en la programaci\u00f3n \u00abofrece la posibilidad de crear objetos que conectan propiedades y comportamientos en una uni\u00f3n aut\u00f3noma que luego se puede reutilizar m\u00faltiples veces\u00bb<\/i>. En mi opini\u00f3n, en BLE se ha intentado un enfoque similar. El grupo Bluetooth Special Interest Group (SIG) ha desarrollado perfiles. Los dispositivos de diferentes fabricantes que tienen perfiles id\u00e9nticos deben funcionar sin problemas entre s\u00ed. Los perfiles, a su vez, constan de servicios, y los servicios de caracter\u00edsticas, complementadas por descriptores. En general, esto puede verse as\u00ed:<\/p>\n

\"BLE
\n
\nPor ejemplo, consideremos el esquema del perfil de un monitor de frecuencia card\u00edaca (pulsera de fitness). Consiste en dos servicios y varias caracter\u00edsticas. De inmediato se comprende la jerarqu\u00eda del perfil. La caracter\u00edstica del punto de control reinicia el recuento total de calor\u00edas gastadas a cero. <\/p>\n

1. El servicio de frecuencia card\u00edaca incluye tres caracter\u00edsticas (0x180D):
\n    a) Caracter\u00edstica obligatoria de frecuencia de pulso (0x2A37)
\n    b) Caracter\u00edstica opcional de posici\u00f3n del sensor corporal (0x2A38)
\n    c) Caracter\u00edstica condicional del punto de control de frecuencia card\u00edaca (0x2A39)
\n2. Servicio de gesti\u00f3n de bater\u00eda (0x180F):
\n    a) Caracter\u00edstica obligatoria del nivel de carga de la bater\u00eda (0x2A19)<\/p>\n

UUID<\/h3>\n

\nPara que podamos referirnos de manera \u00fanica a los elementos del perfil (servicios, caracter\u00edsticas y descriptores), necesitamos numerarlos de alguna manera. Para ello se introduce el concepto de Identificador \u00danico Universal (UUID). En los par\u00e9ntesis de cada l\u00ednea se indica precisamente el UUID. Y aqu\u00ed hay una peculiaridad. Para el UUID se decidi\u00f3 utilizar un c\u00f3digo de 16 y 128 bits de longitud. \u00bfPor qu\u00e9, se preguntar\u00e1n? En el protocolo BLE, todo est\u00e1 subordinado a la conservaci\u00f3n de energ\u00eda. Por lo tanto, un tama\u00f1o de 16 bits es bastante razonable. Es poco probable que en un futuro cercano se creen m\u00e1s de 65 mil servicios y caracter\u00edsticas \u00fanicas. Hasta ahora, lo que pod\u00edan, ya lo han calculado (recuerden de d\u00f3nde proviene esto: \"\u00e9l tambi\u00e9n los cont\u00f3 a ustedes\" :-)) Elementos numerados perfiles<\/a><\/noindex>, servicios<\/a><\/noindex>, caracter\u00edsticas<\/a><\/noindex> y descriptores<\/a><\/noindex> pueden consultarlo a trav\u00e9s de los enlaces.<\/p>\n

Sin embargo, creo que todos recuerdan la historia de los 4 bytes de la direcci\u00f3n IP en Internet. Al principio se pensaba que ser\u00eda suficiente, pero ahora no logramos pasar a una direcci\u00f3n de 6 bytes. Para no repetir este error y dar rienda suelta a las manos traviesas de los improvisadores, SIG decidi\u00f3 introducir tambi\u00e9n UUID de 128 bits. Esto me recuerda personalmente al rango no licenciado de 433 MHz, que fue otorgado a varios inventores del canal de radio. En nuestro caso, se otorg\u00f3 el identificador de 128 bits para servicios y caracter\u00edsticas. Esto significa que para nuestros servicios y dispositivos, podemos utilizar pr\u00e1cticamente cualquier valor de 128 bits. La probabilidad de inventar un UUID id\u00e9ntico se acerca a cero.<\/p>\n

En realidad, los UUID cortos de 16 bits tienen su extensi\u00f3n hasta un valor de 128 bits. En la especificaci\u00f3n, esta extensi\u00f3n se llama Bluetooth Base UUID y tiene el valor 00000000-0000-1000-8000-00805F9B34FB. Si, por ejemplo, el UUID del atributo de 16 bits tiene el valor 0x1234, el UUID de 128 bits equivalente tendr\u00e1 el valor 00001234-0000-1000-8000-00805F9B34FB. E incluso se proporciona la f\u00f3rmula correspondiente:<\/p>\n

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

De d\u00f3nde proviene este n\u00famero m\u00e1gico, no lo s\u00e9. Si alguien de los lectores lo sabe, que lo escriba en los comentarios (El usuario con el apodo Sinopteek ya lo ha hecho. Consulten los comentarios). En cuanto a la creaci\u00f3n de UUID de 128 bits, en principio se puede utilizar un generador<\/a><\/noindex>, que lo har\u00e1 por usted.<\/p>\n

ATTs GATTs\u2026<\/h3>\n

\n En realidad, aqu\u00ed es donde comienza lo m\u00e1s interesante. Recuerdo que ATT se basa en la relaci\u00f3n cliente-servidor. Ahora estamos considerando la configuraci\u00f3n del servidor. Contiene informaci\u00f3n como valores de sensores, estado del interruptor de luz, datos de ubicaci\u00f3n, etc. Ahora que todos los \"participantes de nuestro desfile\" est\u00e1n numerados, debemos organizarlos en la memoria del dispositivo. Para esto, los colocamos en una tabla llamada tabla de atributos. Recuerden bien esto. Es el coraz\u00f3n de BLE. Precisamente esto es lo que examinaremos m\u00e1s adelante. Ahora, cada fila la llamaremos atributo. Esta tabla se encuentra en lo profundo de la pila y, por regla general, no tenemos acceso directo a ella. La inicializamos y accedemos a ella, pero lo que sucede dentro est\u00e1 oculto para nosotros tras siete sellos. <\/p>\n

Veamos la imagen de la especificaci\u00f3n, pero antes quiero se\u00f1alar de inmediato la confusi\u00f3n frecuente en los t\u00e9rminos, especialmente en los descriptores. El papel de un descriptor es complementar la descripci\u00f3n de una caracter\u00edstica. Cuando es necesario ampliar sus capacidades, se aplican descriptores. Tambi\u00e9n son atributos y, junto con servicios y caracter\u00edsticas, se encuentran en la tabla de atributos. Detallaremos esto en la segunda parte del art\u00edculo. Sin embargo, a veces, el n\u00famero de fila en la tabla de atributos se denomina descriptores. Esto es importante tenerlo en cuenta. Para evitar confusiones, utilizaremos el t\u00e9rmino \"indicador de atributo\" para estos prop\u00f3sitos.
\n\"BLE
\n
\nAs\u00ed que un atributo es un valor discreto que tiene las siguientes propiedades asociadas:
\n1. Indicador de atributo (Attribute Handle) \u2014 es el \u00edndice de la tabla correspondiente al atributo
\n2. Tipo de atributo (Attribute Type) \u2014 es el UUID que describe su tipo
\n3. Valor del atributo (Attribute Value) \u2014 son los datos indexados por el indicador de atributo
\n4. Permisos de atributos (Attribute Permissions) \u2014 son parte del atributo, los permisos que no pueden ser le\u00eddos o escritos utilizando el protocolo de atributos<\/p>\n

\u00bfC\u00f3mo entender todo esto? El indicador de atributo es, en t\u00e9rminos simples, su n\u00famero en nuestra tabla.
\nPermite al cliente referirse a un atributo en las solicitudes de lectura o escritura. Podemos numerar nuestras filas (atributos) del 0x0001 al 0xFFFF. En nuestra asociaci\u00f3n con una biblioteca, esto es el n\u00famero de la tarjeta en el cat\u00e1logo de papel. De manera similar, al igual que en el cat\u00e1logo de una biblioteca, las tarjetas se organizan en orden ascendente por n\u00famero. El n\u00famero de cada fila posterior debe ser mayor que el anterior. Al igual que en una biblioteca, algunas tarjetas a veces se pierden, por lo que pueden existir huecos en la numeraci\u00f3n de las filas. Esto es aceptable. Lo importante es que sean ascendentemente.<\/p>\n

El tipo de atributo define qu\u00e9 representa este atributo. Por analog\u00eda con el lenguaje C,
\ndonde existen variables booleanas, num\u00e9ricas y cadenas, aqu\u00ed tambi\u00e9n. Por el tipo de atributo, sabemos
\ncon qu\u00e9 estamos tratando y c\u00f3mo debemos trabajar con este atributo. A continuaci\u00f3n, examinaremos algunos tipos espec\u00edficos de atributos. Por ejemplo, 'declaraci\u00f3n de servicio' (0x2800), 'declaraci\u00f3n de caracter\u00edstica' (0x2803), 'declaraci\u00f3n de descriptor' (0x2902).<\/p>\n

El valor del atributo es su valor en s\u00ed, disculpen la tautolog\u00eda. Si el tipo de atributo es una cadena, el valor del atributo puede ser, por ejemplo, el eslogan 'Hello World !!!'. Si el tipo de atributo es 'declaraci\u00f3n de servicio', su valor es el propio servicio. Y a veces es informaci\u00f3n sobre d\u00f3nde encontrar otros atributos y sus propiedades.<\/p>\n

Los permisos de los atributos permiten al servidor entender si el acceso a la lectura o escritura est\u00e1 permitido.
\nTenga en cuenta que estos permisos se aplican solo al valor del atributo, no al puntero, tipo y al campo de permisos en s\u00ed. Es decir, si se permite la escritura del atributo, podemos cambiar, por ejemplo, la cadena 'Hello World !!!' a 'Good morning'. Pero no podemos prohibir la escritura de una nueva cadena o cambiar el tipo de atributo y designar la cadena como 'declaraci\u00f3n de servicio'. Al solicitar al servidor, el cliente pide sus atributos. Esto permite al cliente conocer lo que puede ofrecer el servidor. Aunque no es necesario leer y escribir valores.<\/p>\n

C\u00f3mo se ve esto<\/h3>\n

\nEl concepto de GATT consiste en agrupar los atributos en la tabla de atributos de una manera muy espec\u00edfica y l\u00f3gica. Veamos m\u00e1s de cerca el perfil de frecuencia card\u00edaca que se muestra a continuaci\u00f3n. La columna m\u00e1s a la izquierda de esta tabla es opcional. Simplemente nos describe qu\u00e9 es esta fila (atributo). Todas las dem\u00e1s columnas ya nos son familiar.<\/p>\n

\"BLE
\n
\nEn la parte superior de cada grupo siempre tenemos el atributo de declaraci\u00f3n del servicio. Su tipo siempre es 0x2800, y el puntero depende de cu\u00e1ntos atributos ya est\u00e1n presentes en la tabla. Su permisos siempre son de solo lectura, sin ninguna autenticaci\u00f3n o autorizaci\u00f3n. Hablaremos de estos conceptos m\u00e1s adelante. El valor es otro UUID que define qu\u00e9 tipo de servicio es. En la tabla, el valor es 0x180D, que est\u00e1 definido por Bluetooth SIG como el servicio de frecuencia card\u00edaca. <\/p>\n

Tras la declaraci\u00f3n del servicio, sigue la declaraci\u00f3n de la caracter\u00edstica. Su formato es similar al de la declaraci\u00f3n del servicio. Su UUID siempre tiene el valor 0x2803, y los permisos tambi\u00e9n son siempre de solo lectura sin ninguna autenticaci\u00f3n o autorizaci\u00f3n. Veamos el campo Valor del Atributo, que incluye algunos datos. Siempre contiene un puntero, un UUID y un conjunto de propiedades. Estos tres elementos describen la posterior declaraci\u00f3n del valor de la caracter\u00edstica. El puntero, naturalmente, designa el lugar de la declaraci\u00f3n del valor de la caracter\u00edstica en la tabla de atributos. El UUID describe qu\u00e9 tipo de informaci\u00f3n o valor podemos esperar. Por ejemplo, el valor de temperatura, el estado del interruptor de luz o cualquier otro valor arbitrario. Y por \u00faltimo, las propiedades que describen c\u00f3mo se puede interactuar con el valor de la caracter\u00edstica. <\/p>\n

Aqu\u00ed nos espera otra trampa. Est\u00e1 relacionada con los permisos de los atributos y las propiedades de las caracter\u00edsticas. Vamos a echar un vistazo a la imagen de las propiedades del campo de bits de la especificaci\u00f3n.<\/p>\n

\"BLE
\n
\nComo pueden ver, tambi\u00e9n hay campos que ofrecen capacidades de lectura y escritura. Puede preguntarse por qu\u00e9 tenemos permisos de lectura\/escritura para el atributo y la propiedad.
\n\u00bfLas lecturas\/escrituras para el valor de atributo no deber\u00edan ser siempre las mismas? El hecho es que las propiedades del valor de atributo son, de hecho, solo recomendaciones para el cliente, utilizadas en GATT y en capas de aplicaci\u00f3n. Son simplemente sugerencias sobre lo que el cliente puede esperar del atributo de declaraci\u00f3n del atributo. Vamos a profundizar en esto. \u00bfQu\u00e9 tipos de permisos existen para el atributo? <\/p>\n

1. Permisos de acceso:
\n     \u2014 lectura
\n     \u2014 escritura
\n     \u2014 lectura y escritura
\n2. Permiso de autenticaci\u00f3n:
\n     \u2014 se requiere autenticaci\u00f3n
\n     \u2014 no se requiere autenticaci\u00f3n
\n3. Permiso de autorizaci\u00f3n:
\n     \u2014 se requiere autorizaci\u00f3n
\n     \u2014 no se requiere autorizaci\u00f3n<\/p>\n

La principal diferencia entre los permisos de los atributos y las propiedades de los atributos es que los primeros se refieren a los servidores, mientras que los segundos a los clientes. Un servidor puede tener permitido la lectura del valor de un atributo, pero puede haber un requisito de autenticaci\u00f3n o autorizaci\u00f3n. Por lo tanto, al solicitar las propiedades del atributo por parte del cliente, obtendremos que la lectura est\u00e1 permitida. Pero al intentar leer, obtendremos un error. As\u00ed que se puede decir con seguridad que los permisos tienen prioridad sobre las propiedades. No podemos obtener informaci\u00f3n sobre qu\u00e9 permisos tiene el atributo desde el lado del cliente.<\/p>\n

Descriptor<\/h3>\n

\nRegresando a nuestra tabla. Despu\u00e9s de declarar el valor del atributo, se pueden realizar los siguientes anuncios de atributos:
\n1. Nueva declaraci\u00f3n de atributo (puede haber muchos atributos en el servicio)
\n2. Nueva declaraci\u00f3n de servicio (puede haber muchas en la tabla)
\n3. Anuncio del descriptor <\/p>\n

En el caso de la caracter\u00edstica de medici\u00f3n de la frecuencia card\u00edaca, en nuestra tabla, el anuncio del valor de la caracter\u00edstica va acompa\u00f1ado de un anuncio del descriptor. Un descriptor es un atributo con informaci\u00f3n adicional sobre la caracter\u00edstica. Existen varios tipos de descriptores. Hablaremos de ellos en detalle en la segunda parte de este art\u00edculo. Ahora, solo tocaremos el descriptor de configuraci\u00f3n de caracter\u00edsticas del cliente (Client Characteristic Configuration Descriptor - CCCD). Tiene un UUID igual a 0x2902. Con este descriptor, el cliente tiene la capacidad de activar la indicaci\u00f3n o la notificaci\u00f3n en el servidor. La diferencia entre ambas es peque\u00f1a, pero existe. La notificaci\u00f3n no requiere confirmaci\u00f3n de recepci\u00f3n por parte del cliente. La indicaci\u00f3n s\u00ed lo requiere, aunque ocurre a nivel de GATT, sin llegar al nivel de la aplicaci\u00f3n. \u00bfPor qu\u00e9 es as\u00ed, preguntar\u00e1n ustedes? Lamentablemente, no lo s\u00e9. Solo dir\u00e9 que los especialistas de Nordic recomiendan usar la notificaci\u00f3n. Adem\u00e1s, la verificaci\u00f3n de la integridad del paquete (mediante CRC) se realiza en ambos casos.<\/p>\n

Conclusi\u00f3n<\/h3>\n

\nAl final del art\u00edculo, me gustar\u00eda mencionar lo siguiente. La \u00faltima tabla es algo confusa. Sin embargo, me detuve en ella porque se presenta en el art\u00edculo<\/a><\/noindex>, en la que me baso. En la segunda parte de mi art\u00edculo, tengo la intenci\u00f3n de profundizar en la especificaci\u00f3n BlueTooth 4.0. All\u00ed nos esperan esquemas y dibujos m\u00e1s precisos. En la tercera parte, quisiera analizar el log obtenido a trav\u00e9s del programa Wireshark de uno de los dispositivos y ver en 'vivo' toda esa teor\u00eda que estamos estudiando.<\/p>\n

Empleado del Grupo de Empresas \u00abC\u00e9sar Satelital\u00bb<\/a><\/noindex>
\nVladimir Pechersky
\n
Fuente: 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 bajo el microscopio (ATTs GATTs\u2026) | ProHoster","description":"BLE bajo el microscopio (ATTs GATTs...) Parte 1.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ble-pod-mikroskopom-atty-gatty","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/84024","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=84024"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/84024\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/84025"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=84024"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=84024"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=84024"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}