Greywolf

une trame ethernet fait 1518 octets et c'est immuable quelquesoit votre abonnement. Sur ces 1518 octets, 18 octets sont dédiés; ce qui fait qu'il n'en reste plus que 1500 pour la portion IP Si on est en PPPoE, l'encapsulation des paquets nécessite 8 octets, ce qui fait que la MaxMTU est de 1492 En PPPoA, il n'y a pas cette imitation, la MaxMTU peut donc être de 1500 octets. //rappel : MTU = MSS (information TCP/UDP/ICMP)+ entête du protocole de transport (TCP,UDP,ICMP) + entête du protocole de niveau 3 (IP)

c'est quand tu pinges ta propre adresse IP que ça fait ça? (l'adresse IP publique? freebox en mode routeur/bridge ?) tu as essayé en désactivant ton firewall?

Pour l'établissement d'une connexion PPP (cas du non dégroupé; en dégroupé je sais pas), c'est du PPPoA avec comme VPI/VCI 8,35. Le couple login/password est envoyé en tant que challenge (CHAP) à la passerelle distante d'authentification (192.168.254.254/32 je crois)

l'erreur 691 est une erreur d'authentification PPP pour autant que je m'en souvienne. Vérifie à tout hasard ton couple login/pass ainsi que, s'il y a la possibilité, dans les propriétés de la connexion, le mode d'authentification: CHAP ou PAP. Sinon, c'est ptet le serveur distant qui merdouille (et ça arrive relativement souvent)

si on pouvait avoir la sortie du ./configure et/ou du make, ça aiderait

modprobe floppy ?

avant de tester avec des logiciels divers et variés, on pourrait peut-être simplement vérifier la couche IP... En partant du principe que tu es bien connecté en wifi (ce qui est la première chose à vérifier), peux tu pinger l'adresse IP de ton routeur? ping <adresse_IP> et au passage, donne nous l'adressage IP de ton PC wifi ipconfig /all

APIC est la gestion avancée du contrôleur d'interruptions (qui permet aux périphériques d'interagir avec le CPU) l'ACPI est un mode de gestion de l'alimentation (mise en veille, suspend to ram, suspend to disk,...) pour tes problèmes de résolution graphique, as tu correctement installé ta carte graphique et correctement réglé ton serveurX => drakconf doit pouvoir te faire ça en mode graphique

non, il y a toi, utilisateur du système, et root, admnistrateur du système. Et même si les personnes physiques sont les mêmes, ce sont bien 2 comptes utilisateurs différent. Un dossier/fichier appartenant à root ne peut être modifié par un utilisateur lambda

diminuer la MTU du PC2 (Cf article optimiser connexion adsl) manuellement dans le registre ou avec un logiciel du type TCPOptimizer

s'il ne veut pas faire de voisinage réseau avec, probablement non. dans le cas contraire, il y a risque d'y avoir 2 sous-réseaux différents: celui de la 9Box et celui de la connexion partagée XP (à moins que taiji62 n'ai fait un pont ethernet entre son interface usb et son interface filaire). Si tel est le cas, le mode de diffusion des noms des PC ne fonctionnera pas et il faudra régler le fichier lmhosts (+ facile) ou mettre en place un serveur DNS/WINS (+ compliqué ou - facile au choix)

il a bien une interface web d'admnistration, non?

cette commande t'a permis de donner les droits rwx (écriture-lecture-exécution) pour l'utilisateur propriétaire, le groupe propriétaire et tout le reste du monde sur ce dossier. Ton problème provenait du fait que toi, en tant que simple utilisateur, n'avait pas de droit d'écriture et/ou d'exécution sur ce dossier, t'empêchant ainsi de le déplacer/supprimer. La dernière commande que j'ai donnée permettait de lister le propriétaire et les droits associés sur le dossier en question

heu... c'est quoi le rapport avec la question initiale? //edit oki compris.. oui les utilitaires wanadoo ne sont pas requis pour établir une connection

le dossier n'appartient pas à ton user, c'est pour ça que tu n'a aucun droit dessus. donc soit en tant que root rmdir /le/chemin/vers/dossier soit root redonne le dossier à ton utilisateur chown -R <user>:<user> /le/chemin/vers/dossier après libre à toi d'en faire ce que tu veux juste par curiosité, à qui appartient ce dossier et quels sont les droits associés? ls -l /home/<user>/Desktop |grep dossier

tes connexions ne sont pas en écoute mais en attente d'une réponse (FIN_WAIT et TIME_WAIT) lsof -i pour voir à qui appartiennent les connexions (ou netstat -lapute ce dernier bien que peu élégant est un efficace moyen mnémotechnique). les adresses distantes correpondent à lookupip.com et google.com 192.168.0.1 est un PC de ton LAN qui héberge un serveur web. Pas de quoi s'affoler

c'est l'absence de réponse du firewall qui fait qu'un port est masqué. C'est en fait une entorse aux RFC de TCP/IP qui préconisent que la pile TCP/IP doit répondre RST à une requête de connexion si celle-ci arrive sur un port qui n'est pas en écoute. => la fonction de masquage de port d'un FW est en fait une absence de réponse aux requêtes. s/21/110/

tu payes pour un abonnement illimité 24h/24 et possède un modem-routeur permettant de connecter plusieurs PC ou assimilés qui utilisent TCP/IP... donc non pas de surplus à payer (sauf si les jeux ont des serveurs avec abonnement payant mensuel)

pour qu'un port soit détecté comme fermé, il faut qu'il renvoie un TCP Rst en réponse au TCP Syn du scan. Un port masqué ne renvoie rien (drop) et le scan attend un time-out pour décréter que sa sonde s'est perdue dans la nature Le fonctionnement de ZA est connu pour ce "souci". Quant aux différences obtenues entre le scanner zebulon et GRC, peut-être est-ce du au fait que l'un est un TCP scanner (full-open scan) et que l'autre soit un syn scanner (half-open scan). Chaque type de scan renvoie des informations différentes, le tout est de savoir les interpréter correctement et du côté scanné, on peut s'amuser avec une règle tarpit au lieu de drop qui renvoie aléatoirement une réponse farfelue au scanner (histoire de faire s'arracher les cheveux à certains )

ZA met par défaut le port 113 en fermé et non masqué pour éviter d'attendre le time-out des requêtes d'authentification (finger) des serveurs IRC. Si tu le masques, tu mettras plus de temps à t'authentifier. Si le port répond fermé, le serveur passe à la séquence d'authentification par login/password. Pour le reste, tous les ports testés sont masqués.

installe libstdc++5 alors

des versions piratées donc illégales avec plein de log sous copyright intégrés et qui ne t'offriront aucun support de notre part

si vous ne disposez pas d'IP publiques en interne sur votre réseau ou si tu passes par un proxy pour surfer, il y a de fortes chances pour que le scanner scanne non pas ton PC mais la passerelle et/ou le proxy.

ldconfig en root pour (re)faire les liens sinon à quoi ressemble ls -l /usr/lib/libstdc++*

je viens d'avoir le même souci avec une Ubuntu 5.10 lors d'une recompilation de noyau avec le fichier de configuration de l'ancien (le 2.6.12-9-386). Le problème provenait de mon oubli de générer une image initrd du système étant donné que les options par défaut du noyau mettent tout en module (IDE, système de fichier) => le noyau ne trouvait pas les modules au démarrage et s'arrêtait sur le shell BusyBox de l'image montée en RAM. Après un reboot rapide sur l'ancien noyau (en éditant les lignes de boot de grub), un simple mkinitramfs -o /boot/initrd-<le_nouveau_noyau> /lib/modules/<le_nouveau_noyau> et l'ajout de la ligne initrd correspondante dans /boot/grub/menu.lst et ça roule. Cependant, si tu es passé par un upgrade du kernel par une image précompilée, je ne comprends pas pourquoi ce problème t'es arrivé (vu que tout doit être bien mis au carré dans le package contenant cette image)