Greywolf

mon ancienne 3DFx2 en port PCI marchait très bien sur un Pentium 200 MHz couplée à une matrox mystique 4 Mo sur port PCi aussi (l'AGP n'existait pas à l'époque; je crois me souvenir que ces cartes ne gèrent que la 3D, ce qui impliquait la nécessité d'avoir un chip graphique pour l'affichage "normal", mais je n'en suis plus trop sûr)

je viens de trouver, c'était trop bête le terminal server de XP Pro n'autorise qu'une seule session à la fois et je n'avais pas quitté la session du XP Pro avant d'essayer de m'y connecter... ça marche edit: au boulot, (oui le but c'était ça ), la station est sous Win2000Pro Workstation, les fonctionnalités terminal server sont-elles identiques à celle de XP Pro?

Pour en revenir à la problématique initiale, à savoir déterminer si il y a présence ou non d'un serveur DHCP sur le LAN et sinon attribuer une IP fixe à l'interface réseau, on peut utiliser l'utilitaire netsh dans un script comme décrit sur le site de JCB: http://bellamyjc.net/fr/windows2000.html#NETSH (j'ai pas essayé mais j'ai un peu tendance à faire confiance au contenu du site de JCB)

tiens en parlant de terminal server.. j'essaye actuellement d'accéder via le LAN (pour l'instant) à une machine XP Pro ayant le service Terminal Server/remote desktop/IIS (et tout un tas de conneries avec, ajouté lors de "exécution de tâches supplémentaires" => "créer une connexion bureau à distance" quand on lui insère le CD de XP Pro) à partir d'une autre station sous linux (avec rdesktop) ou Win98 (avec le client "Connexion bureau à distance") dans les propriétés du répertoire tsweb, onglet sécurité, connexion anonyme a été coché (pour l'instant), les fw baissés de chaque côté. => connection obtient un joli time-out (des TCP syn envoyé vers le 3389 du PC XP Pro qui restent sans réponse), si je regarde les sockets ouverts sur le XP, y'a pas de TCP/UDP 3389 à l'écoute (donc normal qu'il réponde pas..enfin non il pourrait envoyer un RST....) J'ai essayé de voir dans les services IIS si on peut modifier le port d'écoute quelquepart mais j'ai pas trouvé J'essaye une connexion via IE/konqueror sur http://IPduPC_XPPro/tsweb, j'arrive sur une interface de login java, dans nom du serveur je renseigne l'IP du XP Pro, clic sur connexion et.... nada. => enfin si, une page blanche de connect.asp avec un flag d'erreur en bas: Cet objet ne gère pas cette propriété ou cette méthode: Mstsc.server Dans l'observateur d'évènements de XP, ben ... y'a pas grand chose (ou alors je regarde pas les bonnes entrées) sur le XP PRO en écoute (à part les 445, 139 et Cie) j'ai du MSDTC:1165 (c'est le client remote desktop, je crois), des services IIS INETINFO sur 80,443,1171 et 3456 (qu'est ce que ça ouvre comme merde ces services IIS) mais aucune connexion dessus n'aboutit... j'ai essayé VNC (qui marche) mais les commandes envoyées à distance se voient en local, ce que j'aimerai éviter... d'où le terminal server mais il y a quelquechose qui m'échappe. personne n'a une adresse d'un tuto pas à pas/debugging de terminal server? merci.

Bon anniversaire Kewlcat

http://java.sun.com/webapps/download/Redir...dows-i586-i.exe

pas vraiment compris la question... /etc/init.d/samba start , non? et /etc/samba/smb.conf (ou ailleurs dans /etc selon la distri)? tu trouveras ici un article sur samba: http://lea-linux.org/reseau/samba.php3

merci des explications Kewlcat, je vais essayer de me débrouiller avec ça (et puis si j'y arrive pas, je reviendrai à la charge ). ("man test".... oui en effet, moi je faisais "man if" ) edit: ça marche! et j'ai compris le script . En fait, je lui faisais surveiller un processus fils de ppp0 (ppp-eciadsl.pid) qui n'apparait que lors d'une reconnexion (pourquoi, j'en sais rien..). Donc en surveillant ppp0.pid, ie le processus père, le script recrée la connexion lorsqu'elle disparait. pon, poff et plog ont donc l'air d'être spécifiques debian Il ne me reste plus qu'à le lancer en tant que demon au démarrage (parce que si je le mets dans ip-up, le script se termine en même temps qu'ip-up non?), va falloir que le regarde le /etc/ppp/ppp_on_boot ou le rc.adsl du driver du modem....

dans une fenêtre MSDOS, tu fais ping www.tonsite.com ou ping pop.tonfai.fr .... là tu vois si tu arrives à "causer" avec le site distant. Si ça ne fonctionne pas, il peut y avoir 2 raisons: la résolution des noms ne se fait pas=> hote inconnu. C'est probablement les serveurs de noms de ton FAI qui merdent (ce sont eux qui font la correspondance entre les noms www.truc.com avec leur adresse IP) => essaye en pingant directement l'IP du site (si tu la connais) ping xxx.xxx.xxx.xxx le réseau est bloqué quelquepart => host unreachable, délai d'attente dépassé tes paquets IP que tu envoies bloquent quelquepart (ou le serveur distant ne répond pas aux pings...) avec la commande traceroute tu peux voir où ça merde: tracert xxx.xxx.xxx.xxx ou tracert www.tonsite.com tu verras tous les routeurs par lesquels passent tes paquets (si tu n'arrives pas à atteindre le premier routeur, c'est que ta connexion est tombée)

boot sur le CD de win2000, format de C: et install non? (voire même virer toutes les partitions et démarrer sur un DD neuf)

j'ai trouvé ici un script shell qui est censé se lancer au démarrage et surveiller en tâche de fond la présence ou non de la connexion. Je l'ai donc bêtement copié et essaye de comprendre comment ça marche en le lançant à la main dans un premier temps. le début du script a l'air de vérifier la présence ou non du processus entré dans la variable N. => déjà premier problème: alors que ma connexion est active (/var/run/ppp-eciadsl.pid existe), il ne m'affiche pas le message comme quoi la connexion est déjà active. En fait, le script ne rentre pas dans la deuxième boucle (si je mets un else echo "machintruc" après le exit 0, j'obtiens machintruc) que veut dire le -d qui suit le if de la deuxième boucle? (j'ai pas trouvé sur le net) (pourtant quand je fais un # ls /proc/`cat /var/run/ppp-eciadsl.pid`, j'obtiens bien le contenu du pid correspondant mais avec une erreur parce que le fichier ppp-eciadsl.pid contient 2 lignes: la première avec le pid et une deuxième avec ppp0 => ça doit être la cause du plantage mais pourquoi il a deux lignes le ppp-eciadsl.pid?) suite du script là j'avoue que ça me donne mal au crâne => ça sert à quoi de mettre des $$ dans /var/run§$N.pid? => à quoi servent les boucles if [ $? -eq 0]? => j'imagine que les poff adsl et pon adsl doivent appeler le fichier adsl de /etc/ppp/peers ? c'est ptet des questions bêtes mais j'essaye d'apprendre, merci

ah je me souviens maintenant, ça fait suite à ce post la solution de Yul ne fonctionnait donc pas (configurer ton PC de bureau avec une IP de la même classe que celle attribuée par défaut après le time-out du DHCP discover)?

le pilote de ton modem qui bugge et dont le process ne veut pas se terminer? => essayer un autre driver un conflit avec ce qui est chargé en mémoire? => qu'y a t il de chargé?

le CD de XP est bootable normalement, tu as gravé un slipstream avec SP1 ?

est ce que tu as déjà consulté ça? http://lea-linux.org/hardware/graphire.php3 (sinon c'est quand même plus instructif de faire ça à la main)

avec un firewall qui autorise les connexions TCP sortantes en provenance du poste à surveiller uniquement sur l'adresse IP:80 du serveur en question. Les autres trames seront bloquées non?

oups, en effet, j'aurais mieux fait de tenir ma langue moi....

sinon pour des mesures de diagnostic, tu peux essayer de pinger le serveur web/pop/smtp que tu comptes atteindre (nom de domaine et IP) et/ou faire un traceroute dessus pour voir où ça bloque.

sinon y'a Bind (bon UNIX.. d'accord...)

çàd??? le PC ne boote pas sur le CD ou l'install ne démarre pas?

ça doit faire suite à ce post j'imagine.

ton -5V me semble bien faible.... 3.55V ça peut être cause d'instabilité.

PPPoE et PPPoA sont des modes d'encapsulation des trames PPP soit sur un adaptateur Ethernet soit ATM. Normalement les DSLAM sont compatibles avec les 2. Il me semble avoir lu que le bewan était reconnu comme un adaptateur ATM par windows, donc à moins d'un protocole spécifique à ton FAI, le PPPoA devrait fonctionner (aussi bien que le PPPoE d'ailleurs), c'est qui ton FAI?

l'url fonctionne sous konqueror et mozilla 1.2.1 (version debian) => ton url appelle du java apparemment, tu es à jour question interpréteur Java? pour les sites https, certains demandent une identification du navigateur en tant que IE => tu dois avoir une option dans mozilla pour dire "s'authentifier en tant que IE pour tel site"

OS? modem? drivers? filtres en place? pas de téléphone branché dessus (ça peut jouer parait-il)?