Si aucune led ne s'allume, c'est qu'il y a un problème de continuité physique (quand bien même cela fonctionne avec les autres PC => sont-ils auto MDI/MDI-X ?)
Confirme tout de même la réponse de Thorgal: le câble est-il croisé?
les cartes réseaux sont des Gbps? 100 Mps ?
il ne faut pas définir la passerelle VPN comme route par défaut...
i.e tout ce qui n'est pas à destination du subnet VPN doit passer par la connexion réseau classique. C'est une case à cocher dans les propriétés de la connexion VPN si mes souvenirs sont bons
apparemment , l'interface STUN a une adresse de classe A et ça n'a pas l'air modifiable.
Pourquoi, utiliser Hamachi qui passe par un serveur centralisé et ne pas recourir au VPN implémenté dans windows?
Il est là où les MinGW se sont installés (dans c:\programfiles\codeblocks\.. ou c:\MinGW). Au pire, tu lui réindiques dans les options de l'interface de développement.
Si tu fais du C++, faut prendre g++
du C, faut prendre gcc
Fortran, faut prendre g77
...
les ports listés sont ceux évalués par le test (i.e. il ne scanne pas l'ensemble des 65536 ports possibles).
Un port fermé signife que le système a répondu à la sonde réseau que rien n'est en écoute (TCP RST)
Un port masqué fait intervenir un élément filtrant type pare-feu qui a la goujaterie de ne pas répondre aux sollicitations
c'est normal que si tu désactives le pare-feu windows, tu ne puisses plus désactiver les partages et la découverte étant donné que la désactivation de ces fonctionnalités passent par des règles du sus-dit pare-feu.
Tu désactives le pare-feu windows et tu configures comodo à ta guise ensuite. Où est le problème?
éviter 2 pare-feux logiciels sur la même machine => gros risques d'interférence.
configurer le pare-feu pour accepter les partages réseaux windows sur le réseau local
TCP 139,445
UDP 137,138
ton débit ATM correspond à ta vitesse de téléchargement actuelle (~ 270ko/s) donc ça a l"air de venir de ta ligne et/ou de ton DSLAM. Des travaux en cours peut-être ?
which --version n'est pas un opérande valide, le test pour déterminer si which est installé n'est pas valide
Tu modifies le script en conséquence
if [ $temp -eq 0 ];
then
#Other OSes should run "which" just fine...
which --version >/dev/null 2>&1
if [ $? -ne 127 ];
then
which_OK="true"
fi
fi
par
if [ $temp -eq 0 ];
then
which_OK="true"
fi
c'est barbare mais ça ne plantera pas à la détection de l'éxécutable which
code à modifier pour les fonctions Check_Utils et Check_Tools
which renvoie le chemin absolu d'un exécutable donné en argument. Si tu ne donnes pas d'argument, which ne peut rien renvoyer.
pourquoi as tu besoin de which pour faire tourner F@H ?
sous debian, c'est dans le package debianutils mais sous FreeBSD ?
l'utilitaire de gestion de paquets ne permet-il pas de réaliser une recherche sur les fichiers ? (comme apt-file)
$ apt-file search /usr/bin/which
debian-goodies: /usr/bin/which-pkg-broke
debianutils: /usr/bin/which
emboss: /usr/bin/whichdb
sinon tu bootes en single (ajouter single à la ligne du menu.lst affiché par grub)
tu démarres avec le strict mininum, tu te logges en root et tu modifies tes paramètres d'affichage
sinon y'a la fonction RECHERCHEV pour extraire d'une matrice les données d'une colonne y basé sur la valeur d'une cellule de la colonne x
//je confirme brunodm13, ça marche aussi chez moi
SMBus est le bus des capteurs de température, vitesse ventilo,... de la carte-mère. Peut-être qu'une réinstall des pilotes de celle-ci remédierait au problème
quand tu lis le CD via windows, qu'y a-t-il? une arborescence ou un fichier iso?
pour le bios, c'est souvent Echap, F1, Suppr (ou F12 pour choisir l'ordre de boot sans rentrer dans le bios)