je ne l’ai pas enregistré car elle est quasi identique a celle que j’ai posté plus haut.
Bonjour,
Du coup pourriez vous identifier les différents éléments du réseau qui sont visibles sur ce wireshark ? 65:rasp, 42 et 62 : ipx mais quid de 254, 64 et 115 ?
Autre point, si j’ai bien compris vous pouvez reproduire le soucis à souhait. Dans ce cas, pouvez vous vous assurer que les IPX ne redémarre pas lorsque ces relais tombent ?
Bonjour,
.254: BBOX
.64:ipx800v3
.115:NVR HIKVISION
.65:raspberry
Pour vérifier que l’ipx ne redémarre pas, comment procéder? Visuellement avec les leds?
Bonjour,
une suggestion pour isoler les trames de broadcast du NVR: avez vous essayé la mise en place d’un VLAN taggé ? C’est une pratique répandue pour les applications de video surveillance car cela permet d’isoler les flux video du restant du réseau.
Pourriez vous aussi préciser un peu votre topologie de réseau ? Comment sont connectés vos différents appareils ?
-
Filaire
un routeur ou deux? tout est il en filaire? -
WIFI?
Quel type d’appareil Wifi: routeur, point d’accés, … -
CPL?
-
Switch ? switch manageable ?
avez vous des regles de BAN d’adresse mac? ou filtres d’adresse MAC ?
N’avez vous jamais de conflit d’adresse IP ?
Une requête en broadcast ARP a pour but d’associer une MAC adresse a une IP(contenue dans la trame) … en cas de conflit / ecrasement d’IP meme momentané cela peut poser des pb … d’où le besoin de connaitre votre topologie de réseau
Bonjour,
@raslittle, as tu testé sur une IPXV4 ? Ton problème m’inquiète !
Pour remettre les choses à plat et éviter de s’éparpiller, j’ai monter un lab chez moi.
J’ai utilisé un routeur switch TPLINK (wifi désactivé), sans connexion à internet (réseau local fermé) @192.168.0.254
J’y ai connecté une IPX800 V3 (V42) dont je ne me sert pas pour le moment. @192.168.0.3
J’ai connecté mon NVR HIKVISION @192.168.0.2, et mon PC afin d’enregistrer les trames sous wireshark @192.168.0.1
Lorsque je vais une recherche de caméra sur le NVR (Broadcast), je vois bien le port éthernet de l’IPX se reseter dans la seconde qui suit.
J’ai refait le test une dizaine de fois à l’identique, et le phénomène se reproduit à chaque fois
Routeur: .254
PC: .1
NVR: .2
IPX: .3
Ci dessous la trame complète wireshark
broadcastnvr1.zip (11,1 Ko)
@JSLG78: Je vois que tu habites dans les yvelines, si jamais on est à coté je te file le NVR pour des tests sur V4
Bonjour,
C’est peut être un problème de compatibilité matériel…
Je dois étudier la trame pour comprendre avec précision ce qui se passe.
Cdt
Bonjour @raslittle
je viens d’étudier votre trame wireshark.
La première constatation est que la requête de broadcast émise par votre NVR ne correspond pas à une requête ARP. On voit bien que le type de broadcast 0x8033 est même inconnu par wireshark.
Nous sommes donc très bas niveau (couche 1 et 2 du modèle osi). Le protocole utilisée par votre NVR à tout simplement été crée par le constructeur qui utilise la couche MAC pour faire ses annonces sur le reseau.
L’IPX800 ne traite pas les paquets dont le protocole est inconnu; C’est ce qui est curieux…car normalement la requête doit passer sans même inquiéter l’ipx800 qui ne fera que laisser passer le packet sans le traiter.
Je vais reproduire le broadcast de votre NVR au bureau demain pour voir si j’arrive à reproduire un reset de l’IPX800.
Merci pour le temps consacré à ce problème.
Effectivement, c’est certainement une requête constructeur 'HIKVISION" pour la reconnaissance des caméras.
Rhooo c’est pas bien de travailler le dimanche !
Sinon cool pour le début d’explications 
Re,
J’ai fait des test en UDP sur les port de l’IPX en broadcast dans tout les sens et je n’arrive pas à faire planter l’IPX.
Si quelqu’un peux me donner des éléments plus précis pour que je puisse chercher au bon endroit ça serait bien car sinon je n’ai aucune chance de reproduire le bug (si il y en a un !)…
Bonjour,
je persiste à croire que le broadcast n’est pas la cause directe même si trame inconnue (donc rejetée).
EDIT : Autre idée : est-ce que les switchs utilisés sont administrables ?
Si oui, le paramètre Energy Efficient Ethernet (EEE) pourrait être désactivé pour tests car dans certains cas, il peut causer des microcoupures sur certains ports.
Lorsque l’IPX reboote, y a t’il une trace dans les logs du switch ?
cdt
Bonjour,
Il y a VRAIMENT un problème !
Suite à la remonté du problème de raslittle, besoin d’un NVR je me suis procuré un DS-7608NI-I2.
Sur mon réseau local, géré par mon propre routeur TL-MR3220, j’ai toute une liste d’équipements, dont les principaux :
TEST :
Sur l’une de ma V4, j’ai passé un relais à ON, et mis à 1 des Entrées et sorties virtuelles.
Sur ma V3, j’ai mis un relais non utilisé à ON (il m’en restait un 
).
Je me connecte sur le NVR, je clique sur « Ajout rapide » (de camera), et là, même chose que raslittle !!! 
Le relais sur la V3 est passé OFF, même chose sur la V4. Je m’aperçois que ma deuxième V4 a du redémarrer aussi car une entrée virtuelle qui était à 1 est passé à 0 !
PI quand je redémarre ma 1ère V4 moi même, à cause des conditions de certaines entrées, je reçois des SMS sur mon téléphone, ce qui est normale. Or lors de mes tests, à chaque lancement « Ajout rapide » j’ai reçu ces SMS, ce qui confirme le redémarrage de l’IPXV4.
Je n’ai JAMAIS constaté de tel redémarrage de mon IPXV4, car je l’utilise 24h/24 notamment pour mon alarme, ma V4 fonctionne très bien.
PS J’ai une BOX domotique, un module AUDIO SONOE, aucun ne redémarre.
Cordialement,
Bonjour,
Un conflit entre 2 produits est possible…mais pour le résoudre il faut l’identifier !
Or tout les tests que j’ai fait pour le moment n’ont pas permis de reproduire ce soucis !
On continu de chercher…mais ça risque être long de trouver avec aussi peu d’informations.
Cdt
Avez-vous la possibilité de générer un dump du traffic réseau sous Wireshark lorsque vous cliquez sur le bouton « Ajout rapide » ?
Je vois que je ne suis plus le seul a rencontré ce problème de compatibilité HIKVISION Vs IPX
Pour info mon modèle de NVR est le DS-7608N-E2, un peu moins évolué que celui de JLSG78.
Le mieux serait peut être de tester avec le NVR en réel plutôt que de simuler.
Je suis open pour un prêt de mon matériel si besoin.
Bonjour,
pour vérifier si c’est le protocole de découverte « plug & play » de Hikvision qui est en cause, vous pouvez utiliser l’utilitaire SADP sur un PC.
(outil de recherche devices P&P)
il est téléchargeable ici.
http://www.hikvisioneurope.com/portal/index.php?dir=Software/00%20%20%20Software%20Tool%20Package/01%20%20%20SADP%20Tools/new/V3.0.0.2/&file=SADP_v3.0.0.2build20150911.zip
et la doc
http://www.hikvisioneurope.com/portal/index.php?dir=Software/00%20%20%20Software%20Tool%20Package/01%20%20%20SADP%20Tools/new/V3.0.0.2/&file=SADP%20User%20Manual.pdf
Nous verrons si c’est le protocole( donc trame) ou si c’est le matériel (NVR) qui est en cause.
EDIT: pendant l’utilisation, une capture wireshark permettrait de vérifier si les trames de type inconnu (décelées par GCE) sont présentes, et si le reboot de l’IPX se reproduit.
cdt
Bonjour,
J’ai installé le logiciel et les ipx800 ne sont pas affectés. Le logiciel ne fait qu’envoyer la trame en 0x8033 que j’avais déjà identifié. Donc c’est lorsque un appareil répond que ça doit générer le bug.
Si raslittle veux bien nous prêter son matériel pour lever le doute, je veux bien faire des tests pour voir ce qui se passe.
Pour info j’ai fait quelques recherches sur internet et on trouve quand même pas mal de soucis d’intégration avec cette marque chinoise !
Cdt
Oui, j’ai noté aussi ces problèmes récurrents, notamment avec le POE sur les caméras.
@JSLG78 : vos caméras IP sont-elles en POE ?
si oui, ça vaudrait le coup d’inclure ce paramètre dans les tests.
cdt