etrangeté dont je ne trouve pas la source.

Version imprimable

20/07/2011, 17h32
frp31

etrangeté dont je ne trouve pas la source.
bonjour,
j'ai un cas assez complexe à soumettre sous un système unix périmé...
tru64 v5.1b donc je prie pour trouver de l'aide, malgré que je le connaisse quand même pas mal :cry:

-non on peut pas changer l'OS il faut à tout prix être conforme au client (à l'identique absolue même pour les modèles de cartes PCI et leur ordre dans les machines etc....) inutile donc de demander/proposer quelque modif que ce puisse être... ;)

bref 2 machines identiques même OS, même révision SRM (ce qui remplace le bios sur les machines DEC)

sur la machine A je reçois ce que j'attends comme couche MAC/LLC sur 2 entrée réseaux port A et port B (matériellement) c'est les ports réseau de carte mère. (des traces d'équipement que j'attends en fait (je check ça avec un simple tcpdump -i tu0 et tu1 (les noms respectifs des port A et B)).

sur la machine B je reçois tout sauf ça, (du bootp, et d'autres choses)
mais aucune trace des équipements que je veux "voir".

test logique, je prends les câblages de la machine A et les place en lieu et place de la machine B ... et là toujours la même situation....

je remets les câblages en place : la machine A recommence à recevoir les signaux attendus.

La machine B reste toujours dans le même état.

J'ai bien vérifié dans le SRM que les ports soit en 100FullD
je les ai même forcés dans le doute :
Code:

1 2 3 set ewa0_mode FastFD set ewb0_mode FastFD boot
j'ai bien sur fait coté OS, aussi un,

Code:

hwmgr refresh component

& vérifié que les cartes sont bien up

Code:

ifconfig -au

les montrent bien "UP" et donc active.
d'ailleur si je fais le

Code:

tcpdump -i tu0

, je vois bien des choses passer, mais pas ce que j'attends...

C'est à devenir fou, après un test en copie brut (par téléchargement depuis la machine A), j'ai copier la config qui marchait pour la mettre à l'identique sur la machine B...

Si la machine A lit les bons signaux sur un câble n°XXX
la machine B ne peut en aucun cas ne pas recevoir ces même signaux sur le même câble !!! avec la même configuration...hardware comme software... surtout que là je testes ça à très bas niveau , avec un tcpdump !?
je fais le

Code:

tcpdump -i tu0

, je vois bien des choses passer, mais pas ce que j'attends...pourtant j'ai piqué le câble avec lequel je reçoit les bons signaux sur l'autre machine !!!

Coté équipement réseau : c'est le même switch passif (non manageable) qui donne les 4 câbles vers les deux machines. Donc il n'est pas possible que ce soit un problème de configuration des ports réseau non plus...

Dans le doute et pour tester j'ai ajouter quand même une carte réseau supplémentaire sur la machine B. Je le configure à l'identique et paf, rebelote toujours la même chose sur ce nouveau port réseau...

J'ai bien regardé partout, je ne vois ni pentacles, ni cactus émetteur de mauvaises ondes, ni corbeau mort pendu, ni chouettes mortes clouées au portes ni aucune autre traces de malédiction...

Comment est ce possible ? qu'aurais je pu tenté que j'aurai oublié de faire ?
toute idée....

NON pas toute idée, il y en a une dont je ne veut pas, à savoir tremper la machine allumée dans une bassine d'eau bénite. ;)

par contre d'autres idées ?
si il y a encore des experts tru64 en ce monde .... même si là ça sent très fort le phénomène paranormal...:aie:
21/07/2011, 10h07
matafan

Les paquets que tu attends et que tu ne vois pas, c'est quoi ? Tes deux machines utilisent les même adresses IP sur tu0 ?
21/07/2011, 11h41
gangsoleil
Bonjour,

Est-ce que tu as acces a ethtool ? Si oui, est-ce que tu peux verifier que les 4 ports reseaux sont bien reconnus de maniere identiques, et parametres de la meme maniere.

Sinon, si tes deux machines sont rigoureusement identiques et qu'elles ne sont pas en prod, tu peux echanger les disques durs systemes, puis relancer une serie de tests :
- si le comportement est le meme, c'est probablement un probleme lie aux cartes, et pour le verifier, il faut remettre les disques dans leur machine d'origine et echanger les cartes reseaux.
- si le comportement est inverse, alors c'est un probleme logiciel : difference dans l'OS, dans les drivers, ...
21/07/2011, 12h10
frp31

Citation:

Envoyé par matafan

Les paquets que tu attends et que tu ne vois pas, c'est quoi ? Tes deux machines utilisent les même adresses IP sur tu0 ?

c'est pas de l'ip, comme je l'ai indiqué c'est de la couche2
21/07/2011, 12h17
frp31
Citation:
Envoyé par gangsoleil

Bonjour,

Est-ce que tu as acces a ethtool ? Si oui, est-ce que tu peux verifier que les 4 ports reseaux sont bien reconnus de maniere identiques, et parametres de la meme maniere.

Sinon, si tes deux machines sont rigoureusement identiques et qu'elles ne sont pas en prod, tu peux echanger les disques durs systemes, puis relancer une serie de tests :

si le comportement est le meme, c'est probablement un probleme lie aux cartes, et pour le verifier, il faut remettre les disques dans leur machine d'origine et echanger les cartes reseaux.
si le comportement est inverse, alors c'est un probleme logiciel : difference dans l'OS, dans les drivers, ...
ethtool non mais hwmgr qui est le hardwaremanager de tru64 oui, et bien sur ca à déjà été vérifié, comme je l'ai indiqué à deux niveau distinct :
-celui du shell système : (Tru64 commande hwmgr -get att -cat network )
-celui du bios système (SRM : show ewa0* et show ewb0*)

-ça ne peut pas être un problème de cartes car comme indiqué c'est premièrement les ports de la carte mère, et qu'il fonctionnent puisqu'il y a de l'activité dessus.
-de plus pour test j'ai ajouté une carte pci DEC500 et le résultat est identique. Même en croisant le câble avec la machine qui lit bien les signaux...
-il n'y a pas de différences coté soft ces machines sont générés par copie physique des disques :), (hormis ce que je testes moi aujroud'hui)

c'est à s"arracher les cheveux.... :aie:
par contre pour teste j'ai ajouter le allmulti sur le multicast des cartes et là ça mache je reçoit les bons signaux mais ducoup la conformité n'y ai plus, donc j'ai pas la possibilité de faire comme ça ... et c'est normal que ça marche en multicast puisque ça aspire tout ce qui passe sans traiter...
ce qui confirme le bon fonctionnement matériel....Ca permet donc d'éliminer définitivement cette hypothèse.

On y comprend rien .... :?;) c'est barge cette histoire !! :cry:

PS: les n° de révision des cartes mères, du SRM sont bien identiques.
21/07/2011, 12h35
gangsoleil
Bien.

Il te reste donc les solutions suivantes :
- prier
- passer les machines au broyeur, pour que le client en rachete des nouvelles, en esperant ne pas reproduire l'erreur.
A tout hasard, mais je suppose que tu as deja verifie, tu n'as pas de probleme d'adresses mac (redondante par exemple) ?
21/07/2011, 12h49
matafan

Citation:

Envoyé par frp31

c'est pas de l'ip, comme je l'ai indiqué c'est de la couche2

Merci pour le -1, ça donne envie de t'aider. La seule chose que tu as dit à ce sujet c'est "je reçois ce que j'attends comme couche MAC/LLC", ce qui ne veux pas dire que ces paquets ne contiennent pas de l'IP. Si je demande, c'est parce que si c'est de l'IP ça pourrait venir d'un problème d'ARP.

Par ailleurs même si tu trouve mes questions stupides (d'ailleurs j'avais deux questions), ça ne coute pas grand chose d'y répondre.
21/07/2011, 13h53
frp31
Citation:
Envoyé par gangsoleil

Bien.

Il te reste donc les solutions suivantes :

prier
passer les machines au broyeur, pour que le client en rachete des nouvelles, en esperant ne pas reproduire l'erreur.

A tout hasard, mais je suppose que tu as deja verifie, tu n'as pas de probleme d'adresses mac (redondante par exemple) ?
les adresses mac ne sont pas changeables sur DEC,
je vais quand même voir si sur le même réseau il y a des pc mais je suis sur que non.
21/07/2011, 13h54
frp31

Le signal attendu est spécifique à l'équipement identifiable par des entêtes fd:ff:ff:.....:6b:6f ou les ... sont le n° de l'équipement.

désolé pour le moins 1 mais ce problème me prends le choux, depuis si longtemps que le fait d'avoir tapé à coté...j'arrive même pas à dormir correctement.
21/07/2011, 14h07
frp31
Citation:
Envoyé par gangsoleil

Bien.

Il te reste donc les solutions suivantes :

prier
passer les machines au broyeur, pour que le client en rachete des nouvelles, en esperant ne pas reproduire l'erreur.

A tout hasard, mais je suppose que tu as deja verifie, tu n'as pas de probleme d'adresses mac (redondante par exemple) ?
même chez les bockers c'est introuvable, c'était déjà rare du temps de la gloire de DEC, mais maintenant c'est bien pire.
Et c'est pas possible de prendre un autre modèle car il faut à tout prix être conforme ; à ce qui existe sur site. :calim2: d'où l'importance de la situation
21/07/2011, 16h52
Pouic

As-tu vérifié que sur A et sur B tu avais :
- exactement les mêmes processus de lancés ?
- exactement les mêmes descripteurs de fichiers / sockets d'ouverts ? Je dis ça parce que si par exemple tu as un process avec des sockets raw ouvertes sur ta carte, et qui est plus prioritaire que tcpdump, il pourrait te bouffer tes packets (selon l'implémentation de ta stack).
21/07/2011, 20h24
frp31

Citation:

Envoyé par Pouic

As-tu vérifié que sur A et sur B tu avais :
- exactement les mêmes processus de lancés ?
- exactement les mêmes descripteurs de fichiers / sockets d'ouverts ? Je dis ça parce que si par exemple tu as un process avec des sockets raw ouvertes sur ta carte, et qui est plus prioritaire que tcpdump, il pourrait te bouffer tes packets (selon l'implémentation de ta stack).

C'est logique mais hélas ça fait partie des choses auxquelles on a pensé... et le problème n'etais pas là non plus... ;)

je deviens fou avec ce cas .. quand on va trouver la solution ...
22/07/2011, 10h26
Pouic

Arf.

Alors en vrac, quelques idées (si vous ne les avez pas déjà eues):

- est-ce la même version de tcpdump sur les deux machines ?
- est-ce la même version de pcap sur les deux machines ?
- As-tu essayé de sniffer tes packets avec autre chose que tcpdump (genre un programme que tu écris toi-même en ouvrant une socket RAW, et tu vois ce qui passe)
- est-ce que dans ton tcpdump, ton "-i XX" est mappe sur la bonne interface (verifier les index des interfaces)
- est-ce que la charge réseau diffère quand tu fais tes tests ? (grosse charge qui te ferait louper des packets)
- est-ce que tes deux machines ont autant de mémoire vive ? Est-ce qu'une barrette de la machine B pourrait être endommagée ?
- est-ce que les interfaces des deux machines sont paramétrées pour avoir la même taille de queue ?
- si tu attends de l'unicast ou du multicast, j'ai vu que sous tru64 il fallait activer le copy-all-mode pour permettre à tcpdump de voir correctement les packets ?
- est-ce que dans /dev (ou équivalent), tu as les mêmes droits d'accès en lecture ? Sont-ce les mêmes noms ?
- est-ce qu'il y a un montage NFS quelque part qui foutrait le bazar (compte utilisateur, utilitaires, etc.)

Après... Je ne sais pas trop :-)
Bon courage :)
22/07/2011, 11h08
frp31

Merci

Citation:

- As-tu essayé de sniffer tes packets avec autre chose que tcpdump (genre un programme que tu écris toi-même en ouvrant une socket RAW, et tu vois ce qui passe)
- est-ce que les interfaces des deux machines sont paramétrées pour avoir la même taille de queue ?

à part tester le sniff avec un programme perso effectivement ça on a pas fait
-la taille des queues j'y avais pas pensé, mais c'est idem sur les deux...

aujourd'hui stand by sur le test, car ils nous ont déconnecté le réseau concérné...pour au moins la journée.

je vous tiens au ju
25/07/2011, 13h54
frp31

pas encore de nouveau sur le sujet, je vous tiens au courant
26/07/2011, 11h44
frp31

on va chercher encore.... ça n'est tjrs pas bon les modifs d'hier.
03/08/2011, 08h40
frp31

Bon on a pas trouvé de solution on a boté en touche en demandant un nouvel équipement avec des spécs définies par nous...

:calim2: