Internet of Things

Laborator 5
mDNS şi DNS-SD
(anul universitar 2021-2022)

Universitatea Tehnică ”Gheorghe Asachi” din Iaşi

Facultatea de Automatică şi Calculatoare
Departamentul de Calculatoare
 Cuprins
1 Scopul laboratorului 1
2 mDNS 1
3 DNS-SD 2
4 Sarcini de lucru 2
Materiale de studiu 4

Listă tabele

Listă figuri
Fig. 1 Exemplu de interacţiune mDNS 1

1
1. Scopul laboratorului

Familiarizarea cu conceptul de sistem DNS descentralizat şi implementarea unei aplicaţii

ce facilitează comunicaţia cu celelalte platforme de dezvoltare disponibile ı̂n laborator.

2. mDNS

Multicast DNS este un protocol de comunicaţie care are ca scop principal identificarea
adreselor IP asociate numelor de domeniu interogate. Tipurile de resurse vehiculate sunt
aceleaşi ca ı̂n cazul infrastructurii DNS standard, ı̂nsă comunicaţia se realizează descen-
tralizat prin intermediul grupului multicast 224.0.0.251 (ff02::fb pentru IPv6).
Mai exact, un echipament dintr-o reţea locală se asociază grupului multicast indicat mai
sus şi porneşte un server mDNS (resolver) la nivelul căruia va configura un nume. Ulterior,
serverul va răspunde la interogări recepţionate la nivelul grupului multicast pentru resursa
nume.local (.local este domeniul implicit folosit de către mDNS, convenţional având
vizibilitatea limitată la nivelul reţelei locale). Răspunsurile sunt trimise ı̂n mod implicit
la nivelul grupului multicast, existând şi posibilitatea de trimitere unicast (alegerea se real-
izează ı̂n vederea reducerii numărului de pachete generate de mDNS ı̂n funcţie de specificul
sistemelor - dacă au capacitatea de stocare a unui cache se foloseşte varianta multicast, dacă
nu, se foloseşte varianta unicast).

Fig. 1. Exemplu de interacţiune mDNS

1
3. DNS-SD

Implementarea mDNS poate fi folosită şi pentru descoperirea unor servicii expuse la nivel
de reţea locală. De exemplu, o imprimantă de reţea poate răspunde la interogări pentru
servicii de tip printer şi poate oferi detalii referitoare la ce nume/adresă IP are configurată,
setări implicite, cale de acces (ex. interfaţă web) etc.
Numele de servicii sunt stocate prin intermediul ı̂nregistrărilor de tip PTR. Cheia folosită
are forumatul tip serviciu. protocol, unde tip serviciu este un nume de serviciu
proprietar sau ı̂nregistrat de către IANA (lista aici), iar protocol este tipul protocolului
de nivel transport folosit ( tcp sau udp). Înregistrarea PTR include şi un nume de instanţă
pe lângă tipul serviciului şi protocol pentru a putea interoga ulterior şi celelalte ı̂nregistrări
ale serviciului.

#<nume> <ttl> <cls> <type> <rdata>

_http._tcp 3600 IN PTR serveru_web_a_lu_ion._http._tcp

Listing 1. Exemplu de ı̂nregistrare PTR

Informaţii suplimentare pentru un serviciu pot fi obţinute prin intermediul următoarelor

tipuri de ı̂nregistrări:

• SRV - conţine informaţii despre locaţia serviciului (nume gazdă şi număr de port)

#<serv.proto.dom> <ttl> <cls> <type> <prio> <pond> <port> <gazda>

_http._tcp.local 3600 IN SRV 0 0 80 placa_esp32.local

Listing 2. Exemplu de ı̂nregistrare SRV

• TXT - conţine informaţii suplimentare care sunt necesare accesării serviciului (ex.
cale implicită, dimensiuni buffere, valori temporizare)

Info
Pentru descoperirea tuturor serviciilor disponibile ı̂n domeniul local poate fi realizată
o interogare pentru ı̂nregistrarea PTR cu cheia services. dns-sd. udp.local.
Toate serverele mDNS care expun servicii vor răspunde ı̂n mod automat.

4. Sarcini de lucru

1. Consultaţi documentaţia modulului mDNS din esp-idf.

2
2. Creaţi un proiect nou, importaţi din laboratoarele trecute codul folosit pentru conectarea
la AP-ul din laborator. Configuraţi numele platformei (mdns hostame set()) pe
baza numelul vostru de familie ı̂n formatul esp32-numedefamilie.local. Descoperiţi
adresele IP configurate pe platformele colegilor folosind funcţia mdns query a() şi
afişaţi-le sub formă de listă.

3. Completaţi aplicaţia anterioară şi realizaţi o descoperire a tuturor serviciilor disponi-

bile ı̂n reţeaua locală.

4. Creaţi un proiect nou şi importaţi codul scris pentru sarcina de lucru 2 din laboratorul
3 (controlul LED-ului de pe o altă platformă ESP32 prin trimiterea de datagrame
UDP).
În cazul respectivei aplicaţii o limitare era reprezentată de cunoaşterea anterioară a
adresei IP a platformei către care se trimiteau datagrame. De aceea, codul va fi extins
ı̂n următorul mod:
Pentru recepţie:

(a) Platforma va primi un nume de gazda unic ı̂n formatul esp32-numedefamilie.

Atribuirea poate fi testată prin rularea de pe PC-urile din laborator (evident,
conectate la AP-ul lab-iot) a comenzii ping esp32-numedefamilie.local.
(b) Se va ı̂nregistra un serviciu de tipul control led. udp şi se va asocia cu un
număr de port ales la discreţie. Acest număr de port va fi integrat ı̂n codul
existent (ı̂n funcţia bind).

Astfel, nu mai este necesară cunoaşterea adresei IP a plăcii şi a portului folosit la
nivelul socket-ului pentru controlul LED-ului la distanţă.
Pentru transmisie:

(a) La apăsarea butonului se va realiza o interogare pentru serviciile de tip control

led. udp. Se vor aştepta răspunsuri timp de 5 secunde.
(b) Dacă au fost recepţionate mai multe răspunsuri, se va alege ı̂n mod aleator unul
dintre ele şi se vor extrage adresa IP şi numărul de port.
(c) Se va trimite o datagramă către perechea (IP, port) ı̂n formatul specificat ı̂n
laboratorul 3.

3
Materiale de studiu

• Foaie de catalog şi manual ESP32

• Documentaţie API esp-idf

Erată

Descrierea problemei: Platforma răspunde foarte rar la interogări mDNS, astfel făcând
dificilă descoperirea numelui sau a serviciilor expuse.
Analiza problemei: În urma depanării s-a observat că recepţia cadrelor multicast se re-
alizează foarte rar. Imposibilitatea de recepţie a tuturor cadrelor multicast/broadcast este
normală ı̂n reţelele Wi-Fi (dar nu la scara observată) deoarece:

• aceste cadre sunt trimise cu confirmare de la o staţie către AP, dar sunt trimise necon-
firmat de la AP către restul staţiilor

• ı̂n cazul ı̂n care există staţii conectate care folosesc mecanismului de management
al consumului (IEEE 802.11 Power Management Protocol), AP-ul stochează ı̂ntr-un
buffer cadrele multicast/broadcast pe perioada DTIM şi le livrează la cerere staţiilor
la sfârşitul perioadei

Corelând informaţiile de mai sus cu faptul că ı̂n mod implicit interfaţa Wi-Fi a platformei
este configurată să folosească modul de management al consumului (PS), experimental s-au
observat următoarele:

• Cu modul PS activ se recepţionează corect cadre broadcast (teste bazate pe protocolul

ARP)

• Cu modul PS activ se recepţioneazua foarte rar cadre multicast (teste bazate pe

socket-uri UDP)

• Cu modul PS dezactivat se recepţionează corect cadre multicast şi broadcast

Se concluzionează că ar exista o deficienţă de implementare fie la nivelul driver-ului Wi-Fi,

fie la nivelul unei componente din stiva lwIP. Testele au fost rulate pe versiunile esp-idf 4.3
şi 4.3.2. Anterior, ı̂n versiunea 4.2 nu a fost remarcată această problemă.
Rezolvare: La configurarea interfeţei Wi-Fi, după apelul esp wifi start() şi pı̂nă la
stabilirea unei conexiun (ı̂naintea apelului esp wifi connect()) se va dezactiva modul de
management al consumui prin intermediul comenzii esp wifi set ps(WIFI PS NONE).