ESP8266 DNS szerver debug

 ( plt | 2017. szeptember 12., kedd - 7:45 )

ESP8266-osra szeretnék egy minimális DNS szervert, hogy mikor AP-ként üzemelve egy kliens kapcsolódik hozzá, minden nevet az ESP ip címére oldjon fel. Mindezt RTOS alapokon, amihez most az esp-open-rtos projectet használom. Sajnos ebben nincs DNS szerver. FreeRTOS-ban írt valaki egy captdns szervert, amit megpróbáltam átpofozni. Már el is indul, csak épp nem működik. Próbáltam - amennyire tudtam - debugolni, azaz a DNS szerver folyamatában ellenőrizni, mikor mi történik valójában.
Ha a kliensen kiadok egy "host alma" parancsot, akkor a DNS szerver rendben megkapja az A típusú DNS kérésben az alma szót feloldásra, összeállítja a választ, azt visszaküldi (netconn_send) a kliensnek, és a visszaküldés sikeres.
A kliens mégsem elégedett a válasszal. Újra megpróbálja a folyamatot, majd timeout-tal kiszáll.
Amilyen DNS szerver/kliens forráskódokat láttam, azok alapján a DNS szerverem azt teszi, amit kell.
Mondjuk furcsaság, hogy néha kap egy 28-as típusú DNS kérést is, amiről nem tudom, micsoda, emiatt figyelmen kívül hagyom, de ez elvileg az A típusú DNS kérést nem befolyásolja.
Azt hiszem innentől a kliens szerver közötti UDP forgalmat kellene valahogy debugolnom.
Tudtok erre valamilyen eszközt Debian alatt?
Írt már valaki primitív DNS szervert - netán ESP alatt -, vagy van ötlete? Arduino környezetbe létezik egy működő DNS szerver ESP-re, amit már használtam is, de annak a portolásától jobban tartok. Az nem is RTOS alapú, meg azért C-t is csak annyit használok, amennyi ehhez az ESP-hez kell.
Ha van bárkinek ötlete, tapasztalata, netán alternatív javaslata, hogy mi más módon adhatnám vissza a klienseknek mindig az ESP ip címét névfeloldásra, azt megköszönném.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Szerintem én az első linkedben megadott captiveportal DNS szerverének FreeRTOS változatából indultam ki.
Az mDNS pedig nem szabvány DNS, hanem egy egyszerűsített protokoll, de sajnos kliensfüggő, hogy ki ismeri, és ki nem. Jellemzően android eszköz alapból nem, ha jól emlékszem. Ráadásul csak a .local végződést kezeli, én meg tetszőleges névre szeretném visszaadni az ESP IP címét.

Ez érdekes lehet, meg fogom nézni, bár úgy tűnik, egészen más, mint amit most használok.

sub

"néha kap egy 28-as típusú DNS kérést is, amiről nem tudom, micsoda, emiatt figyelmen kívül hagyom"
Az RRTYPE 28 az AAAA (IP6 Address) rekord. IANA, Domain Name System (DNS) Parameters

"Azt hiszem innentől a kliens szerver közötti UDP forgalmat kellene valahogy debugolnom. Tudtok erre valamilyen eszközt Debian alatt?"
WireShark/tshark, tcpdump stb. nem jó? Vagy másra gondoltál?

A tcpdump nekem is eszembe jutott, de úgy emlékszem, ott csak teljes eszköz forgalmát lehet figyelni. Nekem csak arra a részre lenne szükségem, amit a host parancs generál, vagy csak az ESP IP címével kapcsolatos forgalomra. Lehet így paraméterezni a tcpdump-ot?

Igen, meg minden pcap-képes programot hasonlóan lehet filterezni, például:

tcpdump host 192.168.0.1 and udp port 53

man pcap-filter

Köszönöm, szerintem ez kell nekem!

Vagy hasznalhatod a wiresharkot is, ott ossze lehet klikkelgetni az ilyen szuroket, nem pilotavizsgas (van, akinel ez elony).

--
Worrying about killer AI and the superintelligent robots is like worrying about overcrowding on Mars. - Garry Kasparov

Köszönöm mindenkinek a segítséget.
Végül a wireshark segítségével hamar megtaláltam a hibát. Számomra nem csak az volt az előnye, hogy különösebb háttérismeret nélkül is össze lehet kattintgatni a szűrési feltételeket, hanem az, hogy felismeri az alapvető csomagokat, és értelmezi is az adatforgalmat!
Cserébe, ha bárkinek szüksége lenne egy captive dns szerverre esp-open-rtos alapokon, kiegészítve egy route és resolv megadására képes dhcp szerverrel, szívesen elküldöm. (Persze, majd egyszer fel is kerül valahová, de addig is...)

Mi volt a hiba?

A forrásul használt dns szerver egy olyan csomagot használt, amit nem tudtam rendesen lefordítani esp-open-rtos alatt (espconn* azt hiszem). Az esp-open-rots szerverei mind a netconn parancsokkal kezelték a hálózati kapcsolatot, de nem volt olyan kód, amiből láthattam volna, hogy hogyan kell visszaküldeni netconn-nal UDP csomagot. Érdekes módon a dhcp szerver broadcast IP címre küldte vissza a választ, fix 68-as portra.
Mivel nem tudtam, honnan jön a kérés, a default netconn_send() paranccsal küldtem vissza a választ, de a debug alapján kiderült, hogy azt a 0-ás protra küldi, nem pedig a kérést intézőnek. Ezek után megpróbáltam a netconn_peer paranccsal megkapni a kérelmet küldő IP címét és portját, de ez nem működik a leírtaknak megfelelően. Ez is 0-át ad vissza a peer_port értékének.
Végül kiderült valami kódmorzsából, hogy a netbuf tartalmazza a kérelmező IP címét és portját is, és van pár mágikus makró, amivel ezek kinyerhetőek, így netconn_sendto()-val, konkrétan megadva, hogy melyik IP címre, milyen portra küldje a választ, már csodálatosan működik!
Azt nem értem, az alapértelmezett netconn_send() miért nem a kérelmezőnek küldi vissza a választ - mintha a leírása szerint ezt kellene tennie. Az is lehet, hogy ez még bug. De netconn_sendto() jó paraméterekkel tökéletes!
Ezek után már csak a dhcpserver csomagot kellett egy picit kibővíteni, hogy a dhcp kliensnek adjon resolv és route IP címet, így most már felcsatlakozva az esp-re, pingethető, bármilyen forgalom indítható felé, böngészőbe beírva egy tetszőleges címet, bejön az esp webszervere.
A wireshark használhatóságára meg annyit, hogy amint leszűrtem egy helyes névfeloldás csomagjait, meg az én hibás csomagjaimat, már láttam is a különbséget: a helyesnél jelezte, hogy a kérelem és válasz összetartoznak, az én hibás csomagjaimat meg felismerte ugyan helyes DNS csomagoknak, de nem jelzett kapcsolatot köztük. Tehát rögtön lehetett tudni, merre keresgéljek.

ugyes, koszi!

Szép, gratulálok