[Résolu]Centre de paquets vide

El^ryo · le 21 novembre 2016

Bonsoir,

Je ne sais pas depuis quand, mais j'ai remarqué ce soir que le centre de paquets est vide ...

Il m'est donc impossible de mettre à jour ou installer de nouveaux package ...

Lorsque j'actualise au bout d'un moment, je reçois le message suivant "le serveur Synology est occupé, merci de réessayer plus tard."

En cherchant un peu sur le net j'ai trouvé quelques vérifications à faire (date et heure du NAS, DNS, désactivation de l'IPV6), mais rien à faire.

Ca ne change rien.

Dans le fichier log j'ai trouvé ceci :

Nov 21 21:17:23 PkgSynoMan.cgi: pkgtool.cpp:2995 http://update.synology.com/packageupdate/getpackages.php, Failed to request packages, httpResponseCode=504

Ce message se répète à chaque tentative, c'est donc le bon.

Est-ce que cela évoque quelque chose à quelqu'un ?

Quelqu'un aurait-il une idée sur la source du problème ?

Merci et bonne soirée.

Modifié le 21 novembre 2016 par El^ryo

Fenrir · le 21 novembre 2016

504 c'est un blocage, donc vérifie les firewall/proxy/...

Avec ton navigateur, l'adresse fonctionne ?

El^ryo · le 22 novembre 2016

Salut,

Oui, j'ai bien essayé avec le navigateur. Je reçois une réponse "application/json" avec seulement ceci dans la réponse :

[]

La réponse ne me tracasse pas plus que ça, car j'imagine que le programme envoi certains paramètres dans la requête HTTP qui ne sont pas répertoriés dans le log.

Du coup la requête que j'envoi n'est pas l'identique du logiciel....

j'ai essayé aussi un wget depuis le synology :

wget http://update.synology.com/packageupdate/getpackages.php
--10:06:25-- http://update.synology.com/packageupdate/getpackages.php
=> `getpackages.php'
Resolving update.synology.com... 54.192.131.103
Connecting to update.synology.com|54.192.131.103|:80... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: http://pkgautoupdate.synology.com/getOldUpdateList/0/0/0/0/stable/0/enu [following]
--10:06:26-- http://pkgautoupdate.synology.com/getOldUpdateList/0/0/0/0/stable/0/enu
=> `enu'
Resolving pkgautoupdate.synology.com... 54.240.184.4, 54.240.184.232, 54.240.184.80, ...
Connecting to pkgautoupdate.synology.com|54.240.184.4|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/json]

[ <=> ] 2 --.--K/s

10:06:26 (96.78 KB/s) - `enu' saved [2]

Coté proxy, pas de problème, je n'en ai pas. Pour ce qui est du firewall, il y en a un sur le routeur et j'ai fais l'essais en le désactivant.

Je ne sais pas encore comment je vais m'y prendre, car je ne suis pas sur de disposer des outils nécessaires, mais je vais tenter de mettre un système en place me permettant d'analyser toutes les requêtes http sortantes du NAS.

Merci pour ton aide.

Modifié le 22 novembre 2016 par El^ryo

Fenrir · le 22 novembre 2016

En vrac, test/vérifie ces points :

changer les serveurs DNS du syno (par exemple ceux de FDN)
rebooter le nas
espace disque sur la partition système

El^ryo · le 23 novembre 2016

Salut,

Merci pour ta réponse, j'ai vérifier les différents points, mais rien à faire :sad:

Je ne suis pas du tout spécialisé en réseau, mais j'ai fais un traceroute juste pouvoir ou ça passe et là j'ai des timeout...

traceroute update.synology.com
traceroute to update.synology.com (54.230.76.147), 30 hops max, 38 byte packets
1 192.168.1.1 (192.168.1.1) 0.197 ms 0.152 ms 0.100 ms
2 10.161.11.193 (10.161.11.193) 13.952 ms 11.225 ms 13.654 ms
3 host-78-129-126-229.dynamic.voo.be (78.129.126.229) 7.433 ms 7.723 ms 12. 445 ms
4 host-212-68-211-165.dynamic.voo.be (212.68.211.165) 27.525 ms 16.776 ms 1 1.604 ms
5 brx-b2-link.telia.net (80.239.193.145) 14.249 ms 21.476 ms 9.357 ms
6 prs-bb3-link.telia.net (62.115.112.144) 17.420 ms prs-bb3-link.telia.net ( 62.115.112.142) 19.629 ms prs-bb3-link.telia.net (213.155.136.232) 17.917 ms
7 prs-b8-link.telia.net (62.115.118.49) 24.119 ms prs-b8-link.telia.net (62. 115.117.113) 17.956 ms prs-b8-link.telia.net (62.115.118.55) 22.070 ms
8 mobipocket-ic-151917-prs-b8.c.telia.net (80.239.135.130) 16.671 ms 20.861 ms 16.108 ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 *

ça continue jusque 30 et puis stop.

Ce qui me semble curieux , c'est que lorsque je fais la même opération depuis mon pc via la commande tracert ou directement depuis le tools disponible sur mon routeur, je n'ai pas le même résultat que sur le NAS.

Tracing route to update.synology.com [54.192.131.103] over a maximum of 20 hops

1 15ms 10ms 7ms 10.161.11.193
2 14ms 9ms 10ms 78.129.126.229
3 14ms 11ms 12ms 212.68.211.165
4 12ms 54ms 15ms 80.239.193.145
5 16ms 13ms 13ms 213.155.136.230
6 19ms 15ms 14ms 62.115.141.39
7 13ms 15ms 20ms 213.248.73.174
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 15ms 15ms 13ms 54.192.131.103

Trace complete.

Peut être que je m'éloigne de la solution en partant dans cette direction, mais ça me semble étrange comme comportement.

Fenrir · le 23 novembre 2016

Il y a un soucis avec ton traceroute

Un nœud de plus dans le nas au départ

Il y a 5 heures, El^ryo a dit :

1 192.168.1.1 (192.168.1.1) 0.197 ms 0.152 ms 0.100 ms
2 10.161.11.193 (10.161.11.193) 13.952 ms 11.225 ms 13.654 ms
3 host-78-129-126-229.dynamic.voo.be (78.129.126.229) 7.433 ms 7.723 ms 12.

vs

Il y a 5 heures, El^ryo a dit :

1 15ms 10ms 7ms 10.161.11.193
2 14ms 9ms 10ms 78.129.126.229

C'est comme s'il était derrière un autre routeur que ton pc

Adresse locale de ton syno ?
Adresse locale de ton routeur ?
Adresse locale de ton pc ?

El^ryo · le 24 novembre 2016

Salut,

Haaaa ça c'est c'est moi, j'aurais du préciser. En fait le second traceroute a été effectué depuis mon routeur (ip: 192.168.1.1)

ip du routeur : 192.168.1.1

pc : 192.168.1.104

nas : 192.168.1.100

depuis le pc j'ai bien 192.168.1.1 comme première étape :

tracert update.synology.com

Détermination de l’itinéraire vers d678xndbtuwrj.cloudfront.net [54.192.131.103]
avec un maximum de 30 sauts :

1 <1 ms <1 ms <1 ms 192.168.1.1
2 9 ms 7 ms 7 ms 10.161.11.193
3 7 ms 8 ms 8 ms host-78-129-126-229.dynamic.voo.be [78.129.126.229]
4 9 ms 11 ms 8 ms host-212-68-211-165.dynamic.voo.be [212.68.211.165]
5 8 ms 10 ms 12 ms brx-b2-link.telia.net [80.239.193.145]
6 13 ms 13 ms 13 ms adm-bb4-link.telia.net [213.155.136.230]
7 14 ms 13 ms 20 ms adm-b2-link.telia.net [62.115.141.39]
8 16 ms 13 ms 15 ms a100row-ic-152598-adm-b7.c.telia.net [213.248.73.174]
9 * * * Délai d’attente de la demande dépassé.
10 * * * Délai d’attente de la demande dépassé.
11 * * * Délai d’attente de la demande dépassé.
12 13 ms 13 ms 12 ms server-54-192-131-103.ams50.r.cloudfront.net [54.192.131.103]

Ce que je ne comprend pas ce sont les timeout.

Depuis windows ou le routeur, malgré les timeout, on atteint finalement la destination mais depuis le NAS on n'y arrive jamais.

En activant le "verbose" sur le traceroute, j'ai récupérer ce message :

94 bytes from 192.168.1.100 to 192.168.1.100: icmp type 3 (Dest Unreachable) code 3

j'ai autoriser l'icmp sur le firewall, mais ça n'a rien changé.

Merci.

El^ryo · le 24 novembre 2016

j'ai modifié mon fichier /etc/hosts pour y mettre une ligne

192.168.1.104 update.synology.com

Sur le pc 192.168.1.104, j'ai mis mis un tunnel tcp pour visualiser ce qui passe.

La requête se termine bien avec une erreur 504 comme indiqué dans le log au départ :

requête

POST /packageupdate/getpackages.php HTTP/1.1
User-Agent: "Mozilla/4.0 (compatible; MSIE 6.1; Windows XP)"
Host: update.synology.com
Accept: */*
Content-Length: 98
Content-Type: application/x-www-form-urlencoded

timezone=Brussels&language=fre&unique=synology_ppc854x_408&arch=ppc854x&major=4&minor=0&build=2265

réponse

HTTP/1.1 504 Gateway Time-out
Content-Type: text/html
Content-Length: 669
Connection: keep-alive
Server: CloudFront
Date: Thu, 24 Nov 2016 14:25:33 GMT
X-Cache: Error from cloudfront
Via: 1.1 ce2b03db99d40501c5695fce9dfbb777.cloudfront.net (CloudFront)
X-Amz-Cf-Id: zhP8-3udIv-TvkeiMgcBA_4LtvoPp0CvtKhaxTMwpBnjeyABaGEeNg==

Je ne colle pas tous le HTML le message a retenir est : CloudFront attempted to establish a connection with the origin, but either the attempt failed or the origin closed the connection.

Lorsque je reconstruit la même requête HTTP (à un détail près, c'est a dire sans le User-Agent) depuis le PC, j'ai une réponse de redirection (comme pour le wget testé depuis le NAS) :

HTTP/1.1 302 Moved Temporarily
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Date: Thu, 24 Nov 2016 14:10:23 GMT
Server: Apache
Location: http://pkgautoupdate.synology.com/getOldUpdateList/4/0/2265/ppc854x/stable/synology_ppc854x_408/fre
Vary: Accept-Encoding
X-Cache: Miss from cloudfront

Si j'essaye d'atteindre http://pkgautoupdate.synology.com/getOldUpdateList/4/0/2265/ppc854x/stable/synology_ppc854x_408/fre j'ai bien les résultats en json.

Alors maintenant, si j'ajoute le User-Agent "Mozilla/4.0 (compatible; MSIE 6.1; Windows XP)"

Et là surpise motherf***** 504 GateWay Time-out !!!

Ce n'est donc pas le NAS, ni la configuration réseau, mais probablement le traitement de la requête par le destinataire (ou un intermédiaire) qui pose problème.

Pour corriger ce problème, il faudrait donc que je puisse modifier le user-agent de la requête... Si c'est hard codé dans logiciel c'est foutu, sinon faut-il encore trouver l’éventuel fichier de config.

Une autre solution plus barbare serait que j'écrive un programme qui

récupère cette requête (en jouant avec le fichier /etc/hosts comme je l'ai fait).
reconstruit une nouvelle requête avec un user-agent compatible.
balancer le résultat de la seconde requête à la requête initiale.

Mais pfff, j'ai pas envie.

Je continuerai d'indiquer mes découvertes au cas ou ce serait utile pour quelqu'un à l'avenir...

Modifié le 24 novembre 2016 par El^ryo

Fenrir · le 24 novembre 2016

il y a 51 minutes, El^ryo a dit :

Pour corriger ce problème, il faudrait donc que je puisse modifier le user-agent de la requête... Si c'est hard codé dans logiciel c'est foutu, sinon faut-il encore trouver l’éventuel fichier de config.

Un simple proxy permet de faire ça à la volée :

forwarded_for off
via off
request_header_access Allow allow all
request_header_access Authorization allow all
request_header_access WWW-Authenticate allow all
request_header_access Proxy-Authorization allow all
request_header_access Proxy-Authenticate allow all
request_header_access Cache-Control allow all
request_header_access Content-Encoding allow all
request_header_access Content-Length allow all
request_header_access Content-Type allow all
request_header_access Date allow all
request_header_access Expires allow all
request_header_access Host allow all
request_header_access If-Modified-Since allow all
request_header_access Last-Modified allow all
request_header_access Location allow all
request_header_access Pragma allow all
request_header_access Accept allow all
request_header_access Accept-Charset allow all
request_header_access Accept-Encoding allow all
request_header_access Accept-Language allow all
request_header_access Content-Language allow all
request_header_access Mime-Version allow all
request_header_access Retry-After allow all
request_header_access Title allow all
request_header_access Connection allow all
request_header_access Proxy-Connection allow all
request_header_access Cookie allow all
request_header_access User-Agent allow all
request_header_access All deny all

(ne prend pas tout, c'est un copié/collé d'une de mes conf)

El^ryo · le 24 novembre 2016

Salut Fenrir,

Merci pour l'info, ça me sera très utile.

Mes connaissance sur le fonctionnement du proxy est limitée, j'irai donc lire de la doc avant de me lancer.

Encore merci pour tes réponses, je pense que la solution est proche !

Fenrir · le 24 novembre 2016

La vrai question est, à mon sens, pourquoi chez toi ça se comporte comme ça.

Un début de réponse à mon avis est le fait que ta box n'est pas reliée à Internet à proprement parler, mais est dans un réseau privée géré par ton opérateur. Ça ne me surprendrai pas qu'ils aient installés une batterie de proxy ou autre système de DPI entre toi et le net.

Un test "relativement" simple à faire, est de passer par un VPN pour contourner ces équipements. Si tu connais quelqu'un avec un synology (ou un serveur vpn), vous pouvez monter un vpn entre les 2 (tu serais le client). Il va sans dire que cet connaissance ne doit pas être chez le même FAI.

Une autre façon de faire est de monter un reverse proxy pour transformer la requête HTTP en requête HTTPS (le serveur de syno à l'air de répondre en https). Avec un linux+nginx c'est 5min.

Si vraiment tu galères, je peux te faire un accès sur un de mes proxy ou vpn.

El^ryo · le 25 novembre 2016

Salut,

J'ai déjà testé ça hier, mais en réduisant le problème à sa plus simple expression.

La requête HTTP envoyée depuis mon nas est enregistrée, j'ai donc pu la relancée depuis une autre connexion (FAI différent).Le résultat est identique, le "traceroute" est pourtant différent. Là ou ça foire à chaque fois c'est toujours au niveau de cloudfront.net (c'est un service de amazon, synology fait surement appel à eux pour le stockage et mise à disposition des packages).

Il y a donc des chances que toutes personnes qui relance exactement la même requête se retrouve avec le même résultat.

Mes deux tests actuels sont limités à des FAI situés en Belgique, j'essayerai quand même à partir d'une connexion Française (ou autres) quand j'en aurai la possibilité.

Il faut savoir que je suis encore sur un NAS DS408 qui ne dispose plus du support depuis 2 ans, la dernière version DSM disponible est 4.0-2265...

La requête qui est générée par ma version du programme est probablement différente de la grande majorité des utilisateurs aujourd'hui.

Si tu as envie de faire l'essai, j'ai utilisé le logiciel nettools disponible ici : https://sourceforge.net/projects/nettool/

J'attache mes deux requêtes HTTP.

302.xml

504.xml

El^ryo · le 30 novembre 2016

Juste pour info, je viens donner quelques nouvelles sur ce problème.

Actuellement j'échange quelques mails avec le support.

Ils m'ont dis au départ que le problème devait venir de chez moi, car la commande curl fonctionne:

curl -vHL http://update.synology.com/packageupdate/getpackages.php -A "Mozilla/4.0 (compatible; MSIE 6.1; Windows XP)" --data "unique=synology_ppc854x_rs408&build=2265&language=fre&major=4&arch=ppc854x&minor=0"

* About to connect() to update.synology.com port 80 (#0)

* Trying 54.192.131.103... connected

* Connected to update.synology.com (54.192.131.103) port 80 (#0)

> POST /packageupdate/getpackages.php HTTP/1.1

> User-Agent: Mozilla/4.0 (compatible; MSIE 6.1; Windows XP)

> Host: update.synology.com

> Accept: */*

> Content-Length: 82

> Content-Type: application/x-www-form-urlencoded

>

< HTTP/1.1 302 Moved Temporarily

< Content-Type: text/html; charset=UTF-8

< Transfer-Encoding: chunked

< Connection: keep-alive

< Date: Wed, 30 Nov 2016 08:44:25 GMT

< Server: Apache

< Location: http://pkgautoupdate.synology.com/getOldUpdateList/4/0/2265/ppc854x/stable/synology_ppc854x_rs408/fre

< X-Cache: Miss from cloudfront

< Via: 1.1 70801f007508df9ad04c63e7be99eab2.cloudfront.net (CloudFront)

< X-Amz-Cf-Id: u1xNr-EPYC4_1MME64b0v3KkTroP93yDPRSv5ssduonAh-t4dDnSQA==

<

* Connection #0 to host update.synology.com left intact

* Closing connection #0

Sauf que en réalité le user-agent contient un double quote au début et à la fin, donc si on recommence la requête avec cet important détail :

curl -vHL http://update.synology.com/packageupdate/getpackages.php -A "\"Mozilla/4.0 (compatible; MSIE 6.1; Windows XP)\"" --data "unique=synology_ppc854x_rs408&build=2265&language=fre&major=4&arch=ppc854x&minor=0"

* About to connect() to update.synology.com port 80 (#0)

* Trying 54.192.131.103... connected

* Connected to update.synology.com (54.192.131.103) port 80 (#0)

> POST /packageupdate/getpackages.php HTTP/1.1

> User-Agent: "Mozilla/4.0 (compatible; MSIE 6.1; Windows XP)"

> Host: update.synology.com

> Accept: */*

> Content-Length: 82

> Content-Type: application/x-www-form-urlencoded

>

< HTTP/1.1 504 Gateway Time-out

< Content-Type: text/html

< Content-Length: 669

< Connection: keep-alive

< Server: CloudFront

< Date: Wed, 30 Nov 2016 08:42:06 GMT

< X-Cache: Error from cloudfront

< Via: 1.1 5fe8343a80de49928fae39084e131a25.cloudfront.net (CloudFront)

< X-Amz-Cf-Id: v86FZ_vl4d6tewjvZd7FhVe2oqORreYEox5lNJpSNaUGh8G1PIgDWQ==

Et la on peut reproduire le problème...

Je doute toutefois qu'une solution me soit apportée étant donné que ce NAS ne dispose plus des MAJ. Il est temps que je le remplace...

El^ryo · le 2 décembre 2016

Voilà, suite à mes messages Synology à modifié un paramètre au niveau de cloudfront.net et ça re-fonctionne enfin . voici leur réponse :

Hi Lorenzo,

Thanks for your reply.

Our developer has modified the settings on Cloudfront, and it should be working now.
Please try again.

Sorry for any inconvenience.

J'ai testé et validé le bon fonctionnement.

Merci de ton aide et de ton intérêt pour ce problème Fenrir.

Modifié le 2 décembre 2016 par El^ryo

Lelolo · le 2 décembre 2016

Le problème est maintenant résolu. N'hésitez pas à ouvrir un nouveau message en cas de problème. Ceci est une réponse automatique.

Connexion

[Résolu]Centre de paquets vide

Messages recommandés

El^ryo

Fenrir

El^ryo

Fenrir

El^ryo

Fenrir

El^ryo

El^ryo

Fenrir

El^ryo

Fenrir

El^ryo

El^ryo

El^ryo

Lelolo

Qui est en ligne 5 membres, 0 anonyme, 196 invités (Afficher la liste complète)

Contributeurs populaires

Forum

Discussions

Articles

Information importante