Quelques protocoles Ethernet expliqués

Rédigé par Admin Aucun commentaire
Classé dans : Automatisme, Connaissances, Informatique Mots clés : aucun

Multicast DNS (mDNS)

Le protocole multicast DNS (mDNS) résout les noms d'hôtes en adresses IP dans de petits réseaux qui ne comprennent pas de serveur de noms local.

Lorsqu'un client mDNS a besoin de résoudre un nom d'hôte, il envoie un message de requête de multidiffusion IP demandant à l'hôte portant ce nom de s'identifier. Cette machine cible envoie ensuite en multidiffusion un message qui inclut son adresse IP. Toutes les machines de ce sous-réseau peuvent ensuite utiliser ces informations pour mettre à jour leurs caches mDNS.

N'importe quel hôte peut renoncer à son droit sur un nom de domaine en envoyant un paquet de réponse avec un Time To Live (TTL) égal à zéro.

Par défaut, mDNS résout uniquement et exclusivement les noms d'hôtes se terminant par le domaine de premier niveau (TLD) .local. Cela peut poser des problèmes si ce domaine inclut des hôtes qui n'implémentent pas mDNS mais qui peuvent être trouvés via un serveur DNS unicast conventionnel. La résolution de ces conflits nécessite des modifications de la configuration réseau.

  • Lors de l'utilisation de trames Ethernet, l'adresse MAC de multidiffusion standard est 01:00:5E:00:00:FB (pour IPv4) ou 33:33:00:00:00:FB (pour IPv6).

  • Adresse IPv4 224.0.0.251 ou adresse IPv6 ff02::fb.

  • Port UDP 5353.

Les requêtes mDNS ne passeront pas par les routeurs (diffusion en Ethernet uniquement).

Lire la suite de Quelques protocoles Ethernet expliqués

Rappel sur la requête 23 (0x17) Read/Write Multiple registers

Rédigé par Admin Aucun commentaire
Classé dans : Automatisme Mots clés : aucun
  • This function code performs a combination of one read operation and one write operation in a single MODBUS transaction. The write operation is performed before the read.
  • Holding registers are addressed starting at zero. Therefore holding registers 1-16 are addressed in the PDU as 0-15.
  • The request specifies the starting address and number of holding registers to be read as well as the starting address, number of holding registers, and the data to be written. The byte count specifies the number of bytes to follow in the write data field.
  • The normal response contains the data from the group of registers that were read. The byte count field specifies the quantity of bytes to follow in the read data field.
Request    
Function code 1 Byte 0x17
Read Starting Address 2 Bytes 0x0000 to 0xFFFF
Quantity to Read 2 Bytes 0x0001 to 0x007D
Write Starting Address 2 Bytes 0x0000 to 0xFFFF
Quantity to Write 2 Bytes 0x0001 to 0X0079
Write Byte Count 1 Byte 2 x N*
Write Registers Value N*x 2 Bytes
*N = Quantity to Write    
Response    
Function code 1 Byte 0x17
Byte Count 1 Byte 2 x N'*
Read Registers value N'* x 2 Bytes  
*N' = Quantity to Read    

NTPV4 RefIDs et informations

Rédigé par Admin Aucun commentaire
Classé dans : Automatisme, Informatique Mots clés : NTP

 

Common time reference identifiers (refid) codes
Refid[27] Clock Source
GOES Geosynchronous Orbit Environment Satellite
GPS Global Positioning System
GAL Galileo Positioning System
PPS Generic pulse-per-second
IRIG Inter-Range Instrumentation Group
WWVB LF Radio WWVB Fort Collins, Colorado 60 kHz
DCF LF Radio DCF77 Mainflingen, DE 77.5 kHz
HBG LF Radio HBG Prangins, HB 75 kHz (ceased operation)
MSF LF Radio MSF Anthorn, UK 60 kHz
JJY LF Radio JJY Fukushima, JP 40 kHz, Saga, JP 60 kHz
LORC MF Radio Loran-C station, 100
TDF MF Radio Allouis, FR 162 kHz
CHU HF Radio CHU Ottawa, Ontario
WWV HF Radio WWV Fort Collins, Colorado
WWVH HF Radio WWVH Kauai, Hawaii
NIST NIST telephone modem
ACTS NIST telephone modem
USNO USNO telephone modem
PTB German PTB time standard telephone modem
MRS Multi Reference Sources
XFAC Inter Face Association Changed (IP address changed or lost)
STEP Step time change, the offset is less than the panic threshold (1000 s) but greater than the step threshold (125 ms)
GOOG Unofficial Google Refid used by google NTP servers as time4.google.com

Source de l’information

https://en.wikipedia.org/wiki/Network_Time_Protocol

Par exemple : 

Lorsque vous recevez le message "XFAC" en tant que Ref ID (identifiant de référence) lorsqu'un client NTPv4 tente de se connecter à un serveur NTPv4, cela indique généralement un problème d'authentification externe NTP avec clé automatique (XFAC). Cela peut être dû à plusieurs raisons :

  1. Configuration incorrecte : Assurez-vous que les clés de cryptographie et les paramètres d'authentification sont correctement configurés à la fois sur le client et le serveur NTP. Les clés doivent être générées et distribuées correctement pour permettre une authentification réussie.

  2. Clés de cryptographie manquantes ou invalides : Si les clés de cryptographie nécessaires pour l'authentification XFAC sont manquantes ou incorrectes sur l'un des côtés (client ou serveur), cela peut provoquer une erreur d'authentification.

  3. Problèmes de compatibilité : Vérifiez que le client et le serveur NTP utilisent tous les deux la version NTPv4 et prennent en charge l'authentification XFAC. Si les versions ou les méthodes d'authentification diffèrent, cela peut causer des erreurs.

  4. Problèmes de connectivité : Des problèmes de connectivité réseau entre le client et le serveur NTP peuvent empêcher l'établissement de la communication nécessaire pour l'authentification XFAC.

Pour résoudre ce problème, vérifiez attentivement la configuration des clés de cryptographie, assurez-vous que les versions et les méthodes d'authentification sont compatibles, et assurez-vous d'avoir une connectivité réseau stable entre le client et le serveur NTP.

Fil RSS des articles de cette catégorie