Un titre un peu sibyllin, mais voici une description
d'une anomalie dont je ne parviens pas =E0 trouver la cause :
Un logiciel "maison" sous XP r=E9cup=E9re l'heure sur un serveur SNTP
sur une autre machine distance ( un PC sous XP : windows time ).
Tout fonctionne bien.
Le logiciel en question permet de d=E9finir le num=E9ro de port source de
son
client SNTP ( donc , il n'est plus choisit par l'OS/stack IP ).
Le port destination reste inchang=E9 : 123.
Dans ce cas, cela ne fonctionne pas.
Sous Wireshark, le paquet UDP part bien du client avec pour port
destination 123 et
comme port source celui d=E9fini dans la conf du logiciel.
Mais le serveur ne r=E9pond pas.
Les deux machines sont sur le m=EAme LAN, il n'y a ni routeur, switch ou
firewall.
D'un point de vue purement protocolaire, je ne comprends pas pourquoi
le serveur qui
a =E9t=E9 contact=E9 sur son port d'=E9coute ne r=E9ponde pas avec le num=
=E9ro de
port
pr=E9sent dans le champ source du client. Car il le fait bien quand ce
m=EAme num=E9ro
de port a =E9t=E9 choisi automatiquement par le client.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Olivier Miakinen
Bonjour,
Le 07/10/2009 21:54, Stan a écrit :
Le logiciel en question permet de définir le numéro de port source de son client SNTP ( donc , il n'est plus choisit par l'OS/stack IP ). Le port destination reste inchangé : 123.
Dans ce cas, cela ne fonctionne pas. Sous Wireshark, le paquet UDP part bien du client avec pour port destination 123 et comme port source celui défini dans la conf du logiciel. Mais le serveur ne répond pas.
Je trouve ceci dans le RFC 4330 :
<cit. http://tools.ietf.org/rfc/rfc4330.txt> 4. Message Format
[...] The Source Port field of these messages can be any nonzero value chosen for identification or multiplexing purposes. The server interchanges these fields for the corresponding reply messages.
This differs from the RFC 2030 specifications, which required both the source and destination ports to be 123. </cit.>
Traduction : la version de SNTP décrite dans le RFC 4330 autorise n'importe quel port source, alors que dans le RFC plus ancien 2030 c'était 123 pour les deux.
Cela étant dit, ...
[...] je ne comprends pas pourquoi le serveur qui a été contacté sur son port d'écoute ne réponde pas avec le numéro de port présent dans le champ source du client. Car il le fait bien quand ce même numéro de port a été choisi automatiquement par le client.
Dans ce cas, il y a peut-être vérification que le port source appartient à une plage de ports déterminée, typiquement que ce numéro est supérieur à 1024. Tu ne nous as pas dit quel port était défini dans la config du logiciel... est-ce que cela fonctionne si tu prends l'un des ports qui a déjà fonctionné quand il était pris au hasard (mais >= 1024) ?
P.-S. : vérifie aussi la config de ton logiciel de nouvelles, il fait alterner les lignes longues et les lignes courtes d'une façon qui fait mal aux yeux.
Cordialement, -- Olivier Miakinen
Bonjour,
Le 07/10/2009 21:54, Stan a écrit :
Le logiciel en question permet de définir le numéro de port source de
son
client SNTP ( donc , il n'est plus choisit par l'OS/stack IP ).
Le port destination reste inchangé : 123.
Dans ce cas, cela ne fonctionne pas.
Sous Wireshark, le paquet UDP part bien du client avec pour port
destination 123 et
comme port source celui défini dans la conf du logiciel.
Mais le serveur ne répond pas.
Je trouve ceci dans le RFC 4330 :
<cit. http://tools.ietf.org/rfc/rfc4330.txt>
4. Message Format
[...] The Source Port
field of these messages can be any nonzero value chosen for
identification or multiplexing purposes. The server interchanges
these fields for the corresponding reply messages.
This differs from the RFC 2030 specifications, which required both
the source and destination ports to be 123.
</cit.>
Traduction : la version de SNTP décrite dans le RFC 4330 autorise
n'importe quel port source, alors que dans le RFC plus ancien 2030
c'était 123 pour les deux.
Cela étant dit, ...
[...] je ne comprends pas pourquoi
le serveur qui
a été contacté sur son port d'écoute ne réponde pas avec le numéro de
port
présent dans le champ source du client. Car il le fait bien quand ce
même numéro
de port a été choisi automatiquement par le client.
Dans ce cas, il y a peut-être vérification que le port source appartient
à une plage de ports déterminée, typiquement que ce numéro est supérieur
à 1024. Tu ne nous as pas dit quel port était défini dans la config du
logiciel... est-ce que cela fonctionne si tu prends l'un des ports qui a
déjà fonctionné quand il était pris au hasard (mais >= 1024) ?
P.-S. : vérifie aussi la config de ton logiciel de nouvelles, il fait
alterner les lignes longues et les lignes courtes d'une façon qui fait
mal aux yeux.
Le logiciel en question permet de définir le numéro de port source de son client SNTP ( donc , il n'est plus choisit par l'OS/stack IP ). Le port destination reste inchangé : 123.
Dans ce cas, cela ne fonctionne pas. Sous Wireshark, le paquet UDP part bien du client avec pour port destination 123 et comme port source celui défini dans la conf du logiciel. Mais le serveur ne répond pas.
Je trouve ceci dans le RFC 4330 :
<cit. http://tools.ietf.org/rfc/rfc4330.txt> 4. Message Format
[...] The Source Port field of these messages can be any nonzero value chosen for identification or multiplexing purposes. The server interchanges these fields for the corresponding reply messages.
This differs from the RFC 2030 specifications, which required both the source and destination ports to be 123. </cit.>
Traduction : la version de SNTP décrite dans le RFC 4330 autorise n'importe quel port source, alors que dans le RFC plus ancien 2030 c'était 123 pour les deux.
Cela étant dit, ...
[...] je ne comprends pas pourquoi le serveur qui a été contacté sur son port d'écoute ne réponde pas avec le numéro de port présent dans le champ source du client. Car il le fait bien quand ce même numéro de port a été choisi automatiquement par le client.
Dans ce cas, il y a peut-être vérification que le port source appartient à une plage de ports déterminée, typiquement que ce numéro est supérieur à 1024. Tu ne nous as pas dit quel port était défini dans la config du logiciel... est-ce que cela fonctionne si tu prends l'un des ports qui a déjà fonctionné quand il était pris au hasard (mais >= 1024) ?
P.-S. : vérifie aussi la config de ton logiciel de nouvelles, il fait alterner les lignes longues et les lignes courtes d'une façon qui fait mal aux yeux.
Cordialement, -- Olivier Miakinen
Stan
On 7 oct, 23:02, Olivier Miakinen <om+ wrote:
Dans ce cas, il y a peut-être vérification que le port source apparti ent à une plage de ports déterminée, typiquement que ce numéro est su périeur à 1024. Tu ne nous as pas dit quel port était défini dans la config du logiciel... est-ce que cela fonctionne si tu prends l'un des ports qui a déjà fonctionné quand il était pris au hasard (mais >= 1024) ?
J'utilise des ports > 1024 et qui plus est, dans une plage qui est proche de celle ou tout fonctionne correctement.
P.-S. : vérifie aussi la config de ton logiciel de nouvelles, il fait alterner les lignes longues et les lignes courtes d'une façon qui fait mal aux yeux.
J'utilise Google groupes :-(
-- -Stan
On 7 oct, 23:02, Olivier Miakinen <om+n...@miakinen.net> wrote:
Dans ce cas, il y a peut-être vérification que le port source apparti ent
à une plage de ports déterminée, typiquement que ce numéro est su périeur
à 1024. Tu ne nous as pas dit quel port était défini dans la config du
logiciel... est-ce que cela fonctionne si tu prends l'un des ports qui a
déjà fonctionné quand il était pris au hasard (mais >= 1024) ?
J'utilise des ports > 1024 et qui plus est, dans une plage
qui est proche de celle ou tout fonctionne correctement.
P.-S. : vérifie aussi la config de ton logiciel de nouvelles, il fait
alterner les lignes longues et les lignes courtes d'une façon qui fait
mal aux yeux.
Dans ce cas, il y a peut-être vérification que le port source apparti ent à une plage de ports déterminée, typiquement que ce numéro est su périeur à 1024. Tu ne nous as pas dit quel port était défini dans la config du logiciel... est-ce que cela fonctionne si tu prends l'un des ports qui a déjà fonctionné quand il était pris au hasard (mais >= 1024) ?
J'utilise des ports > 1024 et qui plus est, dans une plage qui est proche de celle ou tout fonctionne correctement.
P.-S. : vérifie aussi la config de ton logiciel de nouvelles, il fait alterner les lignes longues et les lignes courtes d'une façon qui fait mal aux yeux.
J'utilise Google groupes :-(
-- -Stan
Stan
On 8 oct, 10:26, Stan wrote:
On 7 oct, 23:02, Olivier Miakinen <om+ wrote:
> Dans ce cas, il y a peut-être vérification que le port source appar tient > à une plage de ports déterminée, typiquement que ce numéro est supérieur > à 1024. Tu ne nous as pas dit quel port était défini dans la conf ig du > logiciel... est-ce que cela fonctionne si tu prends l'un des ports qui a > déjà fonctionné quand il était pris au hasard (mais >= 1024) ?
Hoopss, en fait, c'était dû à une erreur au niveau de la saisie de l'adresse locale : En 'automatique', le couple adresse/port est vide dans le fichier, mais pour changer de port, j'ai dû ajouter l'adresse locale, et comme la machine possède 5 interfaces...je n'ai pas pris la bonne adresse.
Merci quand même.
-- -Stan
On 8 oct, 10:26, Stan <t...@neuf.fr> wrote:
On 7 oct, 23:02, Olivier Miakinen <om+n...@miakinen.net> wrote:
> Dans ce cas, il y a peut-être vérification que le port source appar tient
> à une plage de ports déterminée, typiquement que ce numéro est supérieur
> à 1024. Tu ne nous as pas dit quel port était défini dans la conf ig du
> logiciel... est-ce que cela fonctionne si tu prends l'un des ports qui a
> déjà fonctionné quand il était pris au hasard (mais >= 1024) ?
Hoopss, en fait, c'était dû à une erreur
au niveau de la saisie de l'adresse locale :
En 'automatique', le couple adresse/port est vide
dans le fichier, mais pour changer de port, j'ai dû
ajouter l'adresse locale, et comme la machine
possède 5 interfaces...je n'ai pas pris la bonne adresse.
> Dans ce cas, il y a peut-être vérification que le port source appar tient > à une plage de ports déterminée, typiquement que ce numéro est supérieur > à 1024. Tu ne nous as pas dit quel port était défini dans la conf ig du > logiciel... est-ce que cela fonctionne si tu prends l'un des ports qui a > déjà fonctionné quand il était pris au hasard (mais >= 1024) ?
Hoopss, en fait, c'était dû à une erreur au niveau de la saisie de l'adresse locale : En 'automatique', le couple adresse/port est vide dans le fichier, mais pour changer de port, j'ai dû ajouter l'adresse locale, et comme la machine possède 5 interfaces...je n'ai pas pris la bonne adresse.
Merci quand même.
-- -Stan
Olivier Miakinen
Le 08/10/2009 11:15, Stan a écrit :
Hoopss, en fait, c'était dû à une erreur [...] je n'ai pas pris la bonne adresse.
Je suis ravi que tu aies résolu ton problème.
Cordialement, -- Olivier Miakinen
Le 08/10/2009 11:15, Stan a écrit :
Hoopss, en fait, c'était dû à une erreur
[...] je n'ai pas pris la bonne adresse.
