Répondre avec un protocole non pris en charge lors de l'écriture de la pile réseau personnalisée

Question

J'ai écrit ma propre version du protocole 802.11 avec la pile réseau. C'est surtout une expérience d'apprentissage pour voir plus en profondeur sur le fonctionnement des réseaux.

Ma question est, y a-t-il une norme pour répondre aux périphériques client qu'un certain protocole n'est pas supporté?

J'ai un périphérique Android se connectant à mon périphérique wifi personnalisé et envoyant immédiatement une TON de requêtes sur le port DNS de mon protocole UDP. Puisque je voudrais tester d'autres protocoles j'aimerais beaucoup un moyen pour mon appareil wifi pour dire à l'appareil Android que DNS n'est pas disponible et l'obtenir à un peu plus bas.

Merci d'avance!

Answer 1

Je ne vois pas la possibilité d'envoyer une réponse qu'un service n'est pas disponible.

Je ne trouve rien à propos de ce cas dans le UDP specification.

Un part of the DNS specification suppose qu'il existe plusieurs serveurs DNS et définit comment gérer la communication avec eux. Cela explique une partie du comportement dans votre réseau, mais ne fournit pas beaucoup d'informations sur la façon de le gérer.

4.2.1 Messages - Format - utilisation UDP

La politique optimale de retransmission UDP variera en fonction des performances de l' Internet et les besoins du client, mais les suivantes sont recommandées:

• Le client doit essayer d'autres serveurs et adresses de serveur avant de répéter une requête à une adresse spécifique d'un serveur. L'intervalle de retransmission doit être basé sur les statistiques antérieures si possible. Une retransmission trop agressive peut facilement ralentir les réponses pour la communauté dans son ensemble. Selon sur la façon dont le client est bien connecté à ses serveurs attendus, l'intervalle de retransmission minimum devrait être de 2-5 secondes.

7.2 Resolver Mise en œuvre - l'envoi des requêtes

• Si un résolveur obtient une erreur de serveur ou une autre réponse bizarre à partir d'un serveur de noms, il doit le retirer de SLIST, et peut souhaite planifier une transmission immédiate à l'adresse du serveur candidat suivante.

Selon cela, vous pouvez essayer d'envoyer des ordures au client, mais cela est plutôt un hack, ou une erreur, mais comment une erreur ressemble? Une telle solution suppose que vous avez des connaissances sur le service que vous ne supportez pas.

Je crois que les requêtes DNS peuvent être évitées en utilisant DHCP. DHCP permet de spécifier les serveurs DNS répertoriés dans la page liée. C'est la manière habituelle que je connais pour un résolveur de DNS dans un réseau local pour obtenir les serveurs DNS initiaux bien que je ne trouve rien à ce sujet dans la spécification de DNS. Vous pouvez attribuer à l'appareil Android un serveur DNS avec DHCP afin qu'il doive essayer d'interroger votre appareil. Interroger votre appareil pourrait être une solution de repli.

En plus de DNS il y a mDNS qui utilise des multidiffusions dans le réseau pour envoyer des requêtes. Cela ne semble pas être le protocole que vous avez à faire car il utilise le port spécial 5353.

Answer 2

Impossible d'arrêter le DNS de la façon dont vous l'entendez. Cependant, seulement pour vos tests vous pouvez vérifier les messages UDP et trouver les noms que le périphérique recherche. Ensuite, vous mettez à jour le fichier hosts (google comment le faire: http://www.howtogeek.com/140576/how-to-edit-the-hosts-file-on-android-and-block-web-sites/) et ajoutez ces noms avec une adresse IP de localoop. Cela pourrait fonctionner pour votre test. Autre possibilité est de changer le serveur DNS à une adresse IP de localloop: http://xslab.com/2013/08/how-to-change-dns-settings-on-android/ Encore une fois, c'est uniquement pour éviter d'avoir tous les messages DNS via la connexion wifi.