Mon NVR HIKVISION fait redémarrer mon IPX

Bonjour,

Depuis plusieurs semaines j’ai mes relais de ma carte IPX800 V3 qui repassent à OFF aléatoirement et sans raison.
Mon IPX est couplé à Jeedom.
J’ai vérifié toutes les entrées/sorties (couplage, Ta et Tb), j’ai tenté un hard reset avec rechargement firmware, j’ai recréé toutes I/0, mais rien n’y fait.
Dans les logs de jeedom, je ne vois aucune commande HTTP qui serait à l’origine de ce dysfonctionnement.
Par contre à chaque fois que le problème ce produit, je reçois des Push provenant de l’IPX des inputs qui sont fermées (comme si l’IPX avait redémarré).
J’ai également testé avec une autre alimentation 12V, mais toujours pareil.

Je pense à un problème interne dans l’IPX, le problème c’est qu’on a pas accès au log interne de l’IPX

Bonjour,

vous pouvez éventuellement déconnecter l’IPX du réseau, vous sauriez déjà si le problème est interne à l’IPX ou externe.

Cdlt

Bonjour,

j’ai finalement trouvé l’origine du problème.
Apparemment c’est mon NVR HIKVISION qui est à l’origine de ces dysfonctionnements.
Dès que je le retire du réseau, je n’ai plus aucun symptôme.
Par contre je trouve bizarre qu’un équipement IP comme l’IPX se retrouve aussi facilement « perturbé » par un autre équipement.
Je précise que les équipements sont sur des switchs distincts.
J’ai essayé de multiples manips (changement IP, changement Port, etc…) mais le problème réapparaît aussitôt.
Je reste dubitatif!

bonjour,

votre NVR dispose de ports POE/POE+ sur lesquels vous avez branché vos caméras ?
Si oui, peut-être que les perturbations électriques sur le réseau viennent de là.
Il existe des filtres/parasurtenseurs pour les réseaux ethernet. mais pas donné du tout :frowning:

Voir à connecter les caméras sur un autre switch POE 802.11af.

Sinon, il faudra peut-être remplacer le switch côté IPX800 par un switch avec une plus grande immunité aux perturbations électromagnétiques. Vérifiez que tous vos câbles éthernet sont bien des câbles blindés et qu’ils sont en bon état.

cdlt

Mon NVR ne dispose pas de port POE, mais juste un port GE.
Mes caméras sont toutes sur un switch Cisco POE installé dans le grenier.
Tous mes câbles sont de cat. 6 et de bonne qualité.
Mon réseau se compose d’un routeur et 3 switchs, L’IPX, les cams IP et le NVR sont tous sur des switchs distincts.
A part des trames IP envoyé par le NVR qui « dérange » l’IPX, je vois pas trop d’ou ça peut venir :frowning:
Je vais continuer les tests…

peut-être tester en laissant le nvr en réseau mais en isolant les caméras POE une à une, puis le switch Cisco POE car c’est peut-être le cisco qui génère les perturbations.
Le NVR est derrière un onduleur ? une protection surtension ?

Le constat est de plus en plus clair, le problème survient lorsque le NVR envoi ses requêtes en broadcast afin de rechercher les éventuelles caméras sur le réseau. Ses requêtes parviennent à faire reseter les relais de l’IPX.
Ce qui me surprend c’est la facilité avec laquelle l’IPX est perturbé par ces requêtes.
Je suis un peu septique sur la fiabilité protocolaire des flux ethernet de l’IPX, je l’aurais pensé un peu plus résistante.

1 « J'aime »

Avez-vous pu identifier la trame qui pose problème ?

Je ne suis malheureusement pas assez calé avec wireshark pour identifier la trame.
Le problème est bien identifié et se produit lorsque je lance une recherche camera via le GUI du NVR.

Je commencerais par filtrer les trames en provenance de l’adresse MAC du NVR.

voici la solution de contournement mise en place en attendant mieux…
J’ai installé un routeur secondaire (LAN-WAN) sur mon réseau et j’y ai rattaché mon NVR, comme cela les trames broadcast reste dans son réseau.

C’est quand même étonnant que les trames de broadcast perturbent l’IPX.

C’est possible si c’est une trame similaire à ce qu’attends l’IPX mais incomplète ou invalide.

oui mais c’est quand même super bizare, dans l’absolu il faudrait qu’il y ait toute la chaine, avec la clé API et tout ? non sérieusement je n’y crois pas.
par contre à un joli BUG là oui :smile:

Bonjour,
je suis tout autant dubitatif.
Je ne vois pas comment l’IPX pourrait confondre des trames aussi différentes au niveau de l’entête, d’autant qu’il faudrait aussi qu’elle confonde les couches OSI (Réseau / application) :open_mouth:
Cdt

L’IPX est capable de lire des trames de type broadcast (sans ça ni le DHCP ni l’utilitaire Scan Device ne fonctionneraient ;))

heureusement qu’elle les comprend. Je suis d’accord, et je ne pense pas avoir dit le contraire. :wink:
Par contre, je ne comprends pas comment une trame ARP, même endommagée pourrait ressembler à une autre trâme du protocole TCP, Les entêtes sont différentes, le corps du message est différent.
L’IPX ne peut pas confondre, donc je ne vois pas pourquoi une trâme « endommagée » (selon vos termes) pourrait remettre un relai en position OFF. :wink: d’où le fait que je reste dubitatif sur les conclusions de ce post.
Cdt

Je n’ai jamais précisé le protocole/niveau de la trame :wink:

Je l’imagine comme un problème d’écrasement de mémoire dû à une trame invalide/incomplète.
Mais cela ne reste que pure spéculation.

Il vaux mieux attendre plus d’informations sur la(les) trame(s) qui pose(nt) problème.

Bonjour à tous,
je rencontre un problème similaire.
Quand je démarre une machine virtuelle debian (sous vmware), un de mes relais se met en fonction.
Avez-vous une idée ?

Comme premier test : j’ai désactiver la carte réseau cette machine lors d’un redémarrage, et le problème n’intervient pas. Il y a donc une perturbation provoquée par mon système sur mon réseau.

Une idée ?

Je pense qu’il faudrait trouver un scénario facile a reproduire par l’équipe GCE, afin qu’ils puissent se pencher sur le problème.

Je ne sais pas si avec WireShark on peut enregistrer les trames, pour les rejouer par la suite …
ça permettrait d’essayer d’isoler la séquence qui fout le bordel.