Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Windows XP et serveur Dhcp (windows ou autres)

12 réponses
Avatar
ro
Bonjour

Voila mon soucis : des postes XP qui n'arrivent pas a valider les offres
d'adresses IP faites pas mes serveurs Dhcp primaires ou secondaires.
C'est incroyable parfois ils n'acceptent l'adresse IP du serveur qu'au bout
de 8 heures.Si si j'ai fait le test ce Week-End....Ipconfig /release pour
liberer l'adresse IP la commande Dhcprelease arrive de suite sur le serveur
Dhcp (Linux Aie pas sur la tête).Ipconfig /renew pour redemander une adresse
IP et c'est la que la galére commence :o(( certains postes la valide de
suite,d'autres au bout de 2 minutes,d'autres au bout de 10 minutes,d'autres
au bout de 8 heures,et d'autres jamais boucle infinie :o(
Même aprés avoir taper la commande "Netsh int ip reset reset.txt" (Merci
Nina....) puis rebooter rien n'y fait.
J'ai remarqué que si je met dans mon fichier de config dhcpd.conf une
adresse IP fixe pour telle ou telle machine la demande est validé de suite.
Pour pousser plus loin,j'ai re-installer completement une machine Windows XP
SP2 avec toutes les mises a jour faites !!! puis re-installer completement
ma machine Linux et donc de ce fait le serveur Dhcp.Ensuite j'ai isolé ces
deux machine sur un Hub et refait le test Ipconfig /release et ipconfig
/renew a partir de la machine XP il lui a fallu quasiment plus de 3 minutes
pour accepter l'adresse IP offerte par le serveur Dhcp a coup de
DhcpDiscover au moins 10 lignes de DhcpDiscover de la part de machine XP.
Je ne comprend pas d'ou vient le probleme au niveau de windows XP.Je precise
que les firewalls sont desatives sur les 2 machines !!!!
Sur mon portable XP par exemple l'attribution d'une adresse IP fixe ou
flottante de la part du serveur Dhcp est quasiment instantané
J'ai recherché sur le Net mais rien trouvé de bien convaincant.Le probleme
existe aussi d'aprés ce que j'ai vu entre des machines Windows XP et des
serveur Dhcp sous Windows 2000 ou Windows 2003 server.Ce qui me fait penser
que c'est bien le client Dhcp Windows XP qui deconne.
Dans le gestionnaire des evenements de Windows XP les lignes suivantes
apparaissent :

Le bail de l'adresse IP 0.0.0.0 pour la carte réseau dont l'adresse réseau
est 00065BDCF431 a été refusé par le serveur DHCP 0.0.0.0 (celui-ci a envoy
un message DHCPNACK).

ces lignes se comptent par dizaines.......

Ce qui est faux si l'on en juge par les traces sur le serveur Dhcp :

Mar 19 07:43:48 GESTION-1 dhcpd: DHCPREQUEST for 192.168.1.129
(192.168.1.25) from 00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:48 GESTION-1 dhcpd: DHCPACK on 192.168.1.129 to
00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:49 GESTION-1 dhcpd: DHCPREQUEST for 192.168.1.129
(192.168.1.25) from 00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:49 GESTION-1 dhcpd: DHCPACK on 192.168.1.129 to
00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:50 GESTION-1 dhcpd: DHCPREQUEST for 192.168.1.129
(192.168.1.25) from 00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:50 GESTION-1 dhcpd: DHCPACK on 192.168.1.129 to
00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:51 GESTION-1 dhcpd: DHCPREQUEST for 192.168.1.129
(192.168.1.25) from 00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:51 GESTION-1 dhcpd: DHCPACK on 192.168.1.129 to
00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:52 GESTION-1 dhcpd: DHCPREQUEST for 192.168.1.129
(192.168.1.25) from 00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:52 GESTION-1 dhcpd: DHCPACK on 192.168.1.129 to
00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:53 GESTION-1 dhcpd: DHCPREQUEST for 192.168.1.129
(192.168.1.25) from 00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:53 GESTION-1 dhcpd: DHCPACK on 192.168.1.129 to
00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:54 GESTION-1 dhcpd: DHCPREQUEST for 192.168.1.129
(192.168.1.25) from 00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:54 GESTION-1 dhcpd: DHCPACK on 192.168.1.129 to
00:11:2f:db:04:55 (TOTO) via eth0
Mar 19 07:43:55 GESTION-1 dhcpd: DHCPREQUEST for 192.168.1.129
(192.168.1.25) from 00:11:2f:db:04:55 (TOTO) via eth0

Ces lignes se comptent également par dizaines voir par centaines lorsque la
station Windows XP n'accepte pas l'adresse IP alloué par le serveur...

J'espere que vous pourrez m'apporter une solution car je suis en train de
deprimer grave avec cette connerie.....

Merci d'avance a vous toutes et tous

A+

RO

10 réponses

1 2
Avatar
Nina Popravka
On Wed, 21 Mar 2007 14:05:30 +0100, "ro"
wrote:

J'espere que vous pourrez m'apporter une solution car je suis en train de
deprimer grave avec cette connerie.....


Ben, ça va moyennement faire avancer le schmilblic, mais je suis sûre
à 99.99% que le client DHCP de XP (ou de w2k) n'a pas de problèmes
particuliers.
Parce que j'utilise toujours DHCP sur les parcs que je gère, avec des
serveurs divers et variés, et je n'ai jamais rencontré ce genre de
problèmes.
Mais il est vrai que j'ai déjà vu des témoignages dans le genre du
vôtre.
Si ça peut aider, je fais toujours en sorte d'avoir un seul serveur
dhcp sur le lan.
Et un DHCPNACK, c'est en général parce que l'adresse a été donnée à
quelqu'un d'autre. Regardez aussi du côté de vos switches, les modèles
modernes peuvent donner des résultats étranges, je me demande si
certains protocoles de spanning tree ne foutent pas le bordel à ce
niveau.
--
Nina

Avatar
ro
Hello

Si ça peut aider, je fais toujours en sorte d'avoir un seul serveur
dhcp sur le lan.


J'ai fait le test aussi avec simplement un serveur Dhcp cela ne change rien.

Et un DHCPNACK, c'est en général parce que l'adresse a été donnée à
quelqu'un d'autre.


A priori non j'ai pris grand soin de ne donner des ranges d'adresses qui ne
sont pas attribuées (Scannage du reseau avant avec Languard Network Scanner)
Mais ce qui m'etonnes c'est que le serveur Dhcp ne renvoi pas de DHCPNACK
dans les traces :o(((

Regardez aussi du côté de vos switches, les modèles
modernes peuvent donner des résultats étranges, je me demande si
certains protocoles de spanning tree ne foutent pas le bordel à ce
niveau.


Que faire au niveau de mes switches,je n'utilises pas de Vlans et ce sont
des cisco catalyst 2900 series XL.

A+

Ro

Avatar
ro
Re

Regardez aussi du côté de vos switches, les modèles
modernes peuvent donner des résultats étranges, je me demande si
certains protocoles de spanning tree ne foutent pas le bordel à ce
niveau.


Le spanning tree est desactivé sur les switches

Ro

Avatar
Nina Popravka
On Wed, 21 Mar 2007 14:38:32 +0100, "ro"
wrote:

A priori non j'ai pris grand soin de ne donner des ranges d'adresses qui ne
sont pas attribuées (Scannage du reseau avant avec Languard Network Scanner)
Mais ce qui m'etonnes c'est que le serveur Dhcp ne renvoi pas de DHCPNACK
dans les traces :o(((


Oui, mais XP, le dhcpnack, il l'a pas inventé.
D'autre part, n'oubliez pas, si vous avez eu la sinistre idée de
laisser le FW de XP activé, que par défaut il interdit la réponse au
ping. Ca fait plaisir aux neuneus qui ont peur qu'on les pingue
derrière leur connexion adsl, mais pour gérer un réseau, c'est l'enfer
total.
Et particulièrement un serveur dhcp, pour vérifier qu'une adresse
n'est pas attribuée avant de la donner, envoie... un ping.
Plus généralement, pour suivre ce genre de problème, le mieux est de
monter un sniffer sur le serveur et les stations à une heure de faible
trafic, on voit très exactement ce qui se passe, c'est plus lumineux
que des logs ou le journal d'évènement.

Que faire au niveau de mes switches,je n'utilises pas de Vlans et ce sont
des cisco catalyst 2900 series XL.
Je savais bien que vous aviez des trucs de luxe :-)

Mes clients n'ont pas les moyens de se payer des Catalyst, mais bon
j'ai aussi du dhcp qui fonctionne derrière des trucs un peu modernes.
Toutefois, si le problème persiste, ça peut être intéressant de sortir
un brave switch de secours de chez chinois du placard :-)
--
Nina

Avatar
ro
Oui, mais XP, le dhcpnack, il l'a pas inventé.


Oui c'est bien cela qui me chagrine......

D'autre part, n'oubliez pas, si vous avez eu la sinistre idée de
laisser le FW de XP activé, que par défaut il interdit la réponse au
ping. Ca fait plaisir aux neuneus qui ont peur qu'on les pingue
derrière leur connexion adsl, mais pour gérer un réseau, c'est l'enfer
total.


FW desactivé,pas de soucis de ce coté.

Et particulièrement un serveur dhcp, pour vérifier qu'une adresse
n'est pas attribuée avant de la donner, envoie... un ping.
Plus généralement, pour suivre ce genre de problème, le mieux est de
monter un sniffer sur le serveur et les stations à une heure de faible
trafic, on voit très exactement ce qui se passe, c'est plus lumineux
que des logs ou le journal d'évènement.


Je vais faire mumuse avec TcpDump sur mon serveur Dhcp


Que faire au niveau de mes switches,je n'utilises pas de Vlans et ce sont
des cisco catalyst 2900 series XL.
Je savais bien que vous aviez des trucs de luxe :-)

Mes clients n'ont pas les moyens de se payer des Catalyst, mais bon
j'ai aussi du dhcp qui fonctionne derrière des trucs un peu modernes.
Toutefois, si le problème persiste, ça peut être intéressant de sortir
un brave switch de secours de chez chinois du placard :-)


Ou alors d'aller brûler une caisse de cierges Mdrrrrrrrrrrrr j'y suis
presque a ce stade. :o)

A+ et merci de vous interessé a mon probleme

Ro


Avatar
Nina Popravka
On Wed, 21 Mar 2007 15:21:51 +0100, "ro"
wrote:

Je vais faire mumuse avec TcpDump sur mon serveur Dhcp


Et Wireshark sur les stations...
--
Nina

Avatar
ro
Hello

Voici les traces de Wireshark sur la becane en question :
Le serveur Dhcp a pour adresse 192.168.1.191
La becanne a pour adresse 192.168.1.100
On voit bien que le dialogue ne se fait que dans un sens serveur ->
becane.La becane ne renvoie jamais de DHCPREQUEST pour dire que cela lui
convient,et le serveur ne renvoi jamais de DHCPNACK contrairement a ce que
laisse supposer le gestionaire d'evenements Windows.
Ce qui est bizarre egalement c'est que la becane n'envoie pas non plus de
DHCPDISCOVER pour trouver un serveur Dhcp a la suite de la commande ipconfig
/renew

No. Time Source Destination Protocol
Info
3 0.000284 192.168.1.100 192.168.1.191 DHCP
DHCP Release - Transaction ID 0x1c3a0dd
4 13.922344 192.168.1.191 192.168.1.100 ICMP
Echo (ping) request
5 14.547932 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0x14ff5498
6 14.550171 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0x14ff5498
7 15.543653 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0xb6cd4ef2
8 15.545734 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0xb6cd4ef2
9 16.543651 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0x3264640c
10 16.545611 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0x3264640c
11 17.543514 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0x1b0a93b5
12 17.545867 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0x1b0a93b5
13 18.588103 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0x3b793a0a
14 18.590401 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0x3b793a0a
15 18.919073 Supermic_70:a8:ed DellComp_dc:f4:31 ARP Who
has 192.168.1.100? Tell 192.168.1.191
16 19.590452 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0x405918c9
17 19.592555 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0x405918c9
18 19.918378 Supermic_70:a8:ed DellComp_dc:f4:31 ARP Who
has 192.168.1.100? Tell 192.168.1.191
19 20.592833 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0xb04aa84a
20 20.595073 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0xb04aa84a
21 20.918479 Supermic_70:a8:ed DellComp_dc:f4:31 ARP Who
has 192.168.1.100? Tell 192.168.1.191
22 21.590328 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0x8a8ef06a
23 21.592223 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0x8a8ef06a
24 21.918601 Supermic_70:a8:ed Broadcast ARP Who
has 192.168.1.100? Tell 192.168.1.191
25 22.590309 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0x3412084d
26 22.592597 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0x3412084d
27 22.918715 Supermic_70:a8:ed Broadcast ARP Who
has 192.168.1.100? Tell 192.168.1.191
28 23.590186 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0x99e88aa7
29 23.592146 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0x99e88aa7
30 23.918824 Supermic_70:a8:ed Broadcast ARP Who
has 192.168.1.100? Tell 192.168.1.191
31 24.590170 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0xf4d30508
32 24.592170 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0xf4d30508
33 25.590164 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0x8131628b
34 25.592004 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0x8131628b
35 26.590156 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0x93fc9647
36 26.592418 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0x93fc9647
37 27.590144 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0xd92ae1ed
38 27.592162 192.168.1.191 192.168.1.100 DHCP
DHCP ACK - Transaction ID 0xd92ae1ed
39 28.590134 192.168.1.191 192.168.1.100 DHCP
DHCP Offer - Transaction ID 0xb43ccef

pour info voici les traces de la connection de mon portable a ma livebox le
dialogue est completement different mais a priori conforme a un echange
client > serveur

No. Time Source Destination Protocol
Info
61 31.487130 0.0.0.0 255.255.255.255 DHCP
DHCP Discover - Transaction ID 0x17a3fdb5
62 31.491373 192.168.0.66 192.168.0.61 DHCP
DHCP Offer - Transaction ID 0x17a3fdb5
63 31.491877 0.0.0.0 255.255.255.255 DHCP
DHCP Request - Transaction ID 0x17a3fdb5
64 31.513690 192.168.0.66 192.168.0.61 DHCP
DHCP ACK - Transaction ID 0x17a3fdb5

A+

Ro
Avatar
Nina Popravka
On Thu, 22 Mar 2007 08:49:38 +0100, "ro"
wrote:

Ce qui est bizarre egalement c'est que la becane n'envoie pas non plus de
DHCPDISCOVER pour trouver un serveur Dhcp a la suite de la commande ipconfig
/renew

No. Time Source Destination Protocol
Info
3 0.000284 192.168.1.100 192.168.1.191 DHCP
DHCP Release - Transaction ID 0x1c3a0dd
4 13.922344 192.168.1.191 192.168.1.100 ICMP
Echo (ping) request


Et y a un autre truc très fort, c'est qu'après un dhcp release, la
machine trouve quand même le moyen de recevoir une requête d'écho.
On va dire que c'est une histoire de cache arp...
Vous avez tenté un netsh int ip reset resetlog.txt ?
--
Nina

Avatar
Nina Popravka
On Thu, 22 Mar 2007 08:49:38 +0100, "ro"
wrote:

Voici les traces de Wireshark sur la becane en question


Et en fait, votre trace, c'est exactement comme si c'était une autre
machine qui avait demandé le bail, et que le serveur réponde à
celle-ci...
--
Nina

Avatar
ro
Hello

J'ai trouvé non de dieu...............
Apres plusieures series de traces avec Wireshark,j'ai vu apparaître une
adresse IP d'un serveur Dhcp.Ce serveur Dhcp était tout simplement un petit
routeur netgear qui trainait dans un coin dont j'avais completement oublie
l'existence....Et ce con etait configure pour faire routeur Dhcp
!!!!!!!!!!!!!!!
C'etait lui qui envoyait les DHCPNACK aux bécanes puisqu'il était configuré
pour ne distribuer simplement qu'une adresse IP :o)
Je me suis servi de ce routeur Wifi pour faire mes essais de connections il
y un sacré bout de temps pour connecter un Pocket PC Wifi sur le reseau avec
une authentification sur mon serveur Radius.
Le principal c'est d'avoir trouvé.La déprime vient de s'envoler d'un seul
coup :o)

A+

Ro
"Nina Popravka" a écrit dans le message de news:

On Thu, 22 Mar 2007 08:49:38 +0100, "ro"
wrote:

Voici les traces de Wireshark sur la becane en question


Et en fait, votre trace, c'est exactement comme si c'était une autre
machine qui avait demandé le bail, et que le serveur réponde à
celle-ci...
--
Nina



1 2