Greywolf

tu peux pas faire simplement un if (file_exists(ton_fichier_xml)) avant d'essayer de le lire?

parce qu'il faut l'enregistrer avec l'extension .cmd et non .txt (voire .bat)

le serveur du fai propose-t-il de l'imap? (ça permet à tout le monde d'être synchronisés au niveau des mails et de l'arborescence des répertoires de la mbox)

ping et vnc n'ont rien à voir le firewall XP du 3ème doit bloquer les requêtes ICMP entrantes pour VNC, il faudra autoriser les connexions entrantes TCP 5900 (autoriser une exception VNC TCP 5900)

il faut peut-être le créer ce certificat non? avec openssl, c'est facile de générer une clé privée et un certificat X.509 et de les empaqueter au format PKCS.12 mais là sous windows

le fichier ymp c'est pas comme un rpm? il faut peut-être le rendre exécutable et double-cliquer dessus (même si ça s'appelle one-click install). Avec un éditeur de texte, on voit que c'est un fichier xml qui contient les informations de dépôts et de packages à installer. A priori, ça doit pouvoir s'interfacer avec Yast pour la gestion des dépendances et lancer le téléchargement et l'installation des paquets

l'imprimante est géré par les pilotes gutenprint http://www.linuxprinting.org/show_printer....n-Stylus_CX6600 sont-ils installés? (faire une recherche avec Yast)

ben, suffit de filtrer UDP 138 sur l'interface wan ... y'en a encore qui se balladent sans pare-feu ou avec du netbios ouvert sur le net ?

UDP étant un protocole déconnecté, tu peux oublier RWIN. En abaissant le MTU, tu gagnes et tu perds en même temps: - plus d'overhead; tu dois envoyer plus de paquets pour la même charge utile - les paquets sont plus petits, vitesse de tranfert unitaire plus rapide - si un paquet est perdu, seule une faible quantité d'information le sera Le tout c'est de trouver le meilleur compromis pas trop d'overheads/paquets pas trop petits. Les tests sont rendus difficiles par la nature même du protocole pour lequel la destination n'accuse pas réception des paquets: l'émetteur envoie sans avoir une notion de la congestion du réseau, des pertes éventuelles de paquets,... Par ailleurs, tu ne mentionnes pas ton type de connexion. A l'ère des connexions DSL Mbps, un paquet de 1500 octets se tranfère rapidement; tu pourrais profiter de la MTU maximale imposée par Ethernet (soit 1500 octets)

la table de routage est OK... donc on résume, l'association à la livebox est OK le PC reçoit une adresse IP de la livebox la table de routage est OK la résolution de noms est OK la connectivité IP est OK (ping) les catalogues winsock ont été réinitialisés Le navigateur internet, KO... tu as essayé avec d'autres navigateurs? le pare-feu de vista est activé? un serveur proxy est-il configuré dans les paramètres de connexion internet?

il faut exécuter ces commandes dans un terminal administrateur et non en tant que simple utilisateur d'ailleurs, tu ne nous as toujours pas indiqué ta table de routage route print

ça utilise pas l'interpréteur Python, scapy par hasard? (et pas bash) (ou il faut que tu lances ces commandes dans une session scapy)

s'il est connecté au net c'est plutôt le catalogue winsock à réinitialiser netsh winsock reset catalog

c'est bizarre le PC a obtenu une adresse de la Livebox, c'est donc que l'association, l'encryption et le serveur DHCP fonctionne correctement.. un problème de routage? route print

moi je colle ça dans mon /etc/network/interfaces sous debian dans la partie correspondante à mon interface wifi. Existe-il un équivalent pour le rc.conf, je sais pas... sinon, tu colles la ligne de commande de wpa_supplicant dans ton fichier rc.local (ou un script rcX.d) pour que le daemon wpasupplicant soit lancé avant le montage de ton interface réseau

dans la fenêtre DOS, exécuter la commande suivante ipconfig /all et nous donner le résultat pour l'interface réseau sans fil

que dis wpa_supplicant lorsqu'il est lancé manuellement? wpa_supplicant -Bw -i eth1 -c /etc/wpa_supplicant.conf après tu te connectes avec wpa_cli et tu zieutes les messages. Une fois la config de wpa_supplicant OK, il faut le lancer avant le montage de eth1; y'a moyen de faire ça dans le rc.conf genre wpa-conf /etc/wpa_supplicant.conf ? Dans ton /etc/wpa_supplicant.conf, il te manque peut-être les informations de: protocole utilisé (proto=WPA RSN) mode de gestion des clés (key_mgmt=WPA-PSK) mode d'association (pairwise=CCMP TKIP)

tu as essayé les commandes de configuration de l'interface wifi que je t'avais donné? ifconfig wlan0 down iwconfig wlan0 key restricted <clé WEP (26 caractères hexa> mode managed essid <ton_SSID> ifconfig wlan0 up dhclient wlan0

cherche pas plus loin.....

Le chipset wifi semble être un RTL8187S peu ou mal supporté manifestement. Pour en être sûr, connecte ton PC à internet via un câble réseau et exécute cette commande en tant que super-utilisateur update-pciids ensuite lspci |grep Network Regarde si le statut "Unknown device" a changé. Selon le Wiki MSIWind, il semblerait qu'il faille compiler des drivers extérieurs à l'actuel noyau ou changer de carte wifi :-/ Ce qui m'étonne, c'est que tu as un wlan0 dans la sortie de ifconfig tu peux faire en tant que super-utilisateur grep -ri "alias wlan0" /etc et donner le résultat? Tu peux toujours essayer les commandes que je t'avais filées en substituant ath0 par wlan0, des fois que ça marche "out of the box"

tu oublies d'ouvrir le fichier texte créé dans le répertoire avec un éditeur de texte (gedit par exemple vu que tu es sous gnome) donc su - gedit ifconfig.txt iwconfig.txt lspci.txt

regarde dans /var/log/syslog, /var/log/kern.log, /var/log/messages pour avoir des indices de la cause de cette perte d'interface wifi (un simple redémarrage du service networking ne suffit pas à récupérer la connexion? voire même un déchargement/rechargement du module gérant ton interface wifi?)

si tu pouvais mettre le contenu des fichier textes créés lors de l'exécution de la commande ça aiderait plus si on en croit la sortie (tronquée ?) de iwconfig, il n'y a aucune interface réseau disposant de capacités wi-fi. On en saura plus avec le résultat des commandes lspci, ifconfig et iwconfig

virtualdub ça marche avec le format DV ?

il y au au moins tcp 1723 à forwarder et voir sir les routeurs sont PPtP-passthrough (protocole GRE sur IP)