Re: Plantage bizarre

[Daniel Caillibaud]

Le 11/04/18 à 21:11, Daniel Caillibaud  a écrit :
DC> Donc je vois toujours pas…

Changer la carte réseau a réglé le souci.

Le pb se posait avec l'interface Gbps intégrée à la carte mère. Une vieille
carte 10/100 qui était branchée mais ne servait plus depuis longtemps
n'avait pas donné de meilleur résultat (et elle n'était plus reconnue
depuis ma réinstall), son clone rigoureusement du même modèle (SMC 1211)
règle le pb !

Je comprends toujours pas pourquoi un pb hardware sur une carte réseau peut
donner ces symptômes, tout marche sauf sur un host, et pas tout le temps
(en https avec le browser, j'arrivais à me logguer en insistant, mais
seulement avec chromium, quasi jamais avec firefox), et pas avec tous les
dépôts (avec certains ça marchait en forçant le cipher, pas d'autres).

Je suppose que ça dépend de la taille des paquets tcp, ou un truc du genre,
mais j'y ai laissé qq touffes de cheveux…

-- 
Daniel

Méfie-toi des proverbes chinois
Proverbe berrichon

Re: Plantage bizarre

[Daniel Caillibaud]

Le 11/04/18 à 15:01, BERTRAND Joël  a écrit :
BJ> Je pensais à un truc plus tordu dans les options du noyau (les
BJ> rp_filter et consorts).

Ça pourrait être de ce coté là, mais réinstaller une stretch from scratch
en laissant tout par défaut aurait dû régler le pb non ?

Comment je peux lister les valeurs de ces différentes options (pour les
comparer avec la machine qui fonctionne) ?

J'ai regardé un diff sur la sortie de `sysctl -a` des deux machines, et je
vois rien qui différe sur les clés net.* (sur les autres, qq différences
légères sur ce qui touche à la ram ou au limites de fs, ou les 
kernel.sched_domain.cpuX.domainY)

la seule différence des clés net.* est
net.ipv4.tcp_mem = 93225124300  186450
vs
net.ipv4.tcp_mem = 94365125823  188730

(net.ipv4.conf.enp2s0 est rigoureusement identique au net.ipv4.conf.eth0 de
l'autre)

Donc je vois toujours pas…

-- 
Daniel

L'avenir est un lieu commode pour y mettre des songes.
Anatole France

Re: Plantage bizarre

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 11/04/18 à 09:34, BERTRAND Joël  a écrit :
> […]
> BJ> > - ça fonctionne bien depuis mon portable, qui est aussi sous stretch,
> BJ> > avec le même ssh/openssl/clé ssh (et la même connexion, j'ai même été
> BJ> > jusqu'à lui coller même mac, en utilisant le même cable RJ45 sur le
> BJ> > même port de la même box)
> BJ> >   
> BJ> > => le pb vient donc de la gestion du réseau par mon desktop vs
> BJ> > laptop. Vu que les deux ont la même debian, reste 
> BJ> > - le driver de la carte réseau, et je comprends vraiment pas comment
> BJ> > ça peut influer sur des échanges chiffrés (à priori lui n'agit que
> BJ> > sur la couche réseau, pas applicative).
> BJ> > - le (dé)chiffrement AES par le cpu
> BJ> > 
> BJ> > Y'a moyen de changer des paramètres du kernel pour modifier la
> BJ> > gestion AES du cpu ?
> BJ> > 
> BJ> > Vous voyez une autre piste ?  
> BJ> 
> BJ>   Je sèche. Je n'ai pas quoi ouvrir les fichiers là, tout de
> BJ> suite. Mais si ce n'est pas une histoire de chiffrement, ça peut
> BJ> ressembler à une histoire de chemin.
> 
> Ça pourrait, mais ici ip route me donne la même chose depuis desktop et
> laptop, ça passe par la même box donc les mêmes routes (j'ai vérifié avec
> un traceroute).

Je pensais à un truc plus tordu dans les options du noyau (les
rp_filter et consorts).



> Ça je suis d'accord, si on élimine des cipher dans openssl, faut aussi
> virer leur usage dans les paquets qui l'utilisent (mais y'en a bcp), et ça
> ne devrait se faire que d'une debian à la suivante (mais ça je suppose que
> c'était le cas).
> Mais à priori tous les outils qui utilisent openssl commencent par lui
> demander quels sont les ciphers dispos, donc ça devrait pas poser pb.
> 
> Mais dans ton cas, ton sendmail devait utiliser les cipher mis à dispo par
> openssl, ce sont les smtp en face qui devaient pas savoir les gérer.

Et c'est bien le cas. Le fait de virer chez Debian des ciphers
arbitrairement fait qu'on peut avoir de sérieux effets de bord avec les
serveurs distants.

JKB

Re: Plantage bizarre

[Daniel Caillibaud]

Le 11/04/18 à 09:34, BERTRAND Joël  a écrit :
[…]
BJ> > - ça fonctionne bien depuis mon portable, qui est aussi sous stretch,
BJ> > avec le même ssh/openssl/clé ssh (et la même connexion, j'ai même été
BJ> > jusqu'à lui coller même mac, en utilisant le même cable RJ45 sur le
BJ> > même port de la même box)
BJ> >   
BJ> > => le pb vient donc de la gestion du réseau par mon desktop vs
BJ> > laptop. Vu que les deux ont la même debian, reste 
BJ> > - le driver de la carte réseau, et je comprends vraiment pas comment
BJ> > ça peut influer sur des échanges chiffrés (à priori lui n'agit que
BJ> > sur la couche réseau, pas applicative).
BJ> > - le (dé)chiffrement AES par le cpu
BJ> > 
BJ> > Y'a moyen de changer des paramètres du kernel pour modifier la
BJ> > gestion AES du cpu ?
BJ> > 
BJ> > Vous voyez une autre piste ?  
BJ> 
BJ> Je sèche. Je n'ai pas quoi ouvrir les fichiers là, tout de
BJ> suite. Mais si ce n'est pas une histoire de chiffrement, ça peut
BJ> ressembler à une histoire de chemin.

Ça pourrait, mais ici ip route me donne la même chose depuis desktop et
laptop, ça passe par la même box donc les mêmes routes (j'ai vérifié avec
un traceroute).

BJ> > BJ>   Si c'est bien ce à quoi je pense, il faudrait que des
BJ> > BJ> gens qui ne comprennent pas les implications de leurs patches
BJ> > BJ> arrêtent de les imposer...  
BJ> > 
BJ> > Sur la suppression de certains ciphers d'openssl, c'est un choix
BJ> > délibéré je suppose, interdire les connexions qui paraissent
BJ> > sécurisées mais ne le sont pas car utilisant des ciphers vulnérables.
BJ> > 
BJ> > C'est le choix de firefox & chrome par ex, ils refusent désormais les
BJ> > connexions https vers des sites qui ne font pas de TLS ou utilisent
BJ> > des ciphers trop faibles.  
BJ> 
BJ> C'est surtout très bête dans le cas d'une bibliothèque générale.
BJ> Lorsque tu ne peux plus envoyer de mails à la moitié du monde, tu es en
BJ> général content (d'autant que les gars qui ont patché cela n'ont pas
BJ> patché les outils utilisant cette bibliothèque pour leur permettre de
BJ> rester isofonctionnels).

Ça je suis d'accord, si on élimine des cipher dans openssl, faut aussi
virer leur usage dans les paquets qui l'utilisent (mais y'en a bcp), et ça
ne devrait se faire que d'une debian à la suivante (mais ça je suppose que
c'était le cas).
Mais à priori tous les outils qui utilisent openssl commencent par lui
demander quels sont les ciphers dispos, donc ça devrait pas poser pb.

Mais dans ton cas, ton sendmail devait utiliser les cipher mis à dispo par
openssl, ce sont les smtp en face qui devaient pas savoir les gérer.

Ou alors un pb de conf perso, qui indique une suite de cipher préférés,
liste qui n'aurait pas été mise à jour suite à l'évolution des ciphers
disponibles dans openssl. Du coup tu annonces des ciphers que tu ne peux
pas gérer ensuite.

Je dis ça parce que j'ai des smtp qui causent avec pas mal d'autres et j'ai
pas eu ce pb lors des ≠ upgrades (depuis sarge ou etch).

-- 
Daniel

Pour marcher au pas d'une musique militaire, il n'y a pas besoin de
cerveau, une moelle epiniere suffit.
Albert Enstein.

Re: Plantage bizarre

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 10/04/18 à 23:12, BERTRAND Joël  a écrit :
> BJ> Daniel Caillibaud a écrit :
> BJ> > Le 10/04/18 à 15:43, BERTRAND Joël  a
> BJ> > écrit :  
> BJ> > BJ> Je ne sais pas sur quoi agit l'option -4 (hormis le fait
> BJ> > BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que
> BJ> > BJ> même interrogés en IPv4, certains DNS renvoient des résolutions
> BJ> > BJ> IPv6 et c'est au soft de faire le tri dans les réponses. Mais
> BJ> > BJ> encore une fois, je ne sais pas si ssh est assez subtil pour
> BJ> > BJ> cela.  
> BJ> > 
> BJ> > Je pense quand même que même si la requête dns lui renvoyait du ,
> BJ> > il n'utiliserait que les champs A pour se connecter.
> BJ> >   
> BJ> > BJ> Peux-tu poster ici un dump réseau complet de quelque
> BJ> > BJ> chose qui fonctionne et d'une transaction qui échoue ? Par
> BJ> > BJ> complet, c'est avec les options -v et -e.  
> BJ> > 
> BJ> > Avec git on ne peut pas activer -e  
> BJ> 
> BJ>   Je pensais à un tcpdump bien senti.
> 
> J'avais mis un résumé dans un mail précédent (04/04/18 à 08:35), pour la
> totale c'est là
> 
> - connexion git+ssh qui foire
> 
> https://framadrop.org/r/V20FQ0lVJQ#hUYB/LRdm74/ytm+wl4LllfHIYrIq0QdMsoDY/az4jA=
> 
> - connexions du browser qui déconnent aussi
> 
> https://framadrop.org/r/iLXjIVEK69#xiJSfmU3WB7bDZWvO9WUJAqHz5t5lvYyJvdvAEOdRT4=
> 
> BJ> > La même commande
> BJ> >   env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers=aes256-ctr" git pull
> BJ> > sur le dépôt qui plante (1) et un qui fonctionne (à condition
> BJ> > d'imposer le cipher) (2)  
> BJ> 
> BJ>   Rhohh... Idée ! J'ai eu un truc similaire avec les concetés
> BJ> debianesques. Il y a des chiffrements qui ont disparu de certaines
> BJ> versions récentes d'OpenSSL qui m'empêchaient d'envoyer des mails à
> BJ> certains (gros) domaines. Il m'a fallu patcher sendmail pour contourner
> BJ> le problème !...
> BJ> 
> BJ>   Peux-tu compiler un OpenSSL officiel (non patché par Debian) ?
> 
> Pas la peine, le pb ne peut pas venir de là car
> - en imposant le cipher, on voit que le handshake ssh se passe bien donc
>   ils ont trouvé un cipher commun
> - ça fonctionne bien depuis mon portable, qui est aussi sous stretch, avec
>   le même ssh/openssl/clé ssh (et la même connexion, j'ai même été jusqu'à
>   lui coller même mac, en utilisant le même cable RJ45 sur le même port de
>   la même box)
> 
> => le pb vient donc de la gestion du réseau par mon desktop vs laptop. Vu
> que les deux ont la même debian, reste 
> - le driver de la carte réseau, et je comprends vraiment pas comment ça
>   peut influer sur des échanges chiffrés (à priori lui n'agit que sur la
>   couche réseau, pas applicative).
> - le (dé)chiffrement AES par le cpu
> 
> Y'a moyen de changer des paramètres du kernel pour modifier la gestion AES
> du cpu ?
> 
> Vous voyez une autre piste ?

Je sèche. Je n'ai pas quoi ouvrir les fichiers là, tout de suite. Mais
si ce n'est pas une histoire de chiffrement, ça peut ressembler à une
histoire de chemin.

> BJ>   Si c'est bien ce à quoi je pense, il faudrait que des gens qui
> BJ> ne comprennent pas les implications de leurs patches arrêtent de les
> BJ> imposer...
> 
> Sur la suppression de certains ciphers d'openssl, c'est un choix délibéré
> je suppose, interdire les connexions qui paraissent sécurisées mais ne le
> sont pas car utilisant des ciphers vulnérables.
> 
> C'est le choix de firefox & chrome par ex, ils refusent désormais les
> connexions https vers des sites qui ne font pas de TLS ou utilisent des
> ciphers trop faibles.

C'est surtout très bête dans le cas d'une bibliothèque générale.
Lorsque tu ne peux plus envoyer de mails à la moitié du monde, tu es en
général content (d'autant que les gars qui ont patché cela n'ont pas
patché les outils utilisant cette bibliothèque pour leur permettre de
rester isofonctionnels).

Cordialement,

JKB

Re: Plantage bizarre

[Daniel Caillibaud]

Le 10/04/18 à 23:12, BERTRAND Joël  a écrit :
BJ> Daniel Caillibaud a écrit :
BJ> > Le 10/04/18 à 15:43, BERTRAND Joël  a
BJ> > écrit :  
BJ> > BJ>   Je ne sais pas sur quoi agit l'option -4 (hormis le fait
BJ> > BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que
BJ> > BJ> même interrogés en IPv4, certains DNS renvoient des résolutions
BJ> > BJ> IPv6 et c'est au soft de faire le tri dans les réponses. Mais
BJ> > BJ> encore une fois, je ne sais pas si ssh est assez subtil pour
BJ> > BJ> cela.  
BJ> > 
BJ> > Je pense quand même que même si la requête dns lui renvoyait du ,
BJ> > il n'utiliserait que les champs A pour se connecter.
BJ> >   
BJ> > BJ>   Peux-tu poster ici un dump réseau complet de quelque
BJ> > BJ> chose qui fonctionne et d'une transaction qui échoue ? Par
BJ> > BJ> complet, c'est avec les options -v et -e.  
BJ> > 
BJ> > Avec git on ne peut pas activer -e  
BJ> 
BJ> Je pensais à un tcpdump bien senti.

J'avais mis un résumé dans un mail précédent (04/04/18 à 08:35), pour la
totale c'est là

- connexion git+ssh qui foire

https://framadrop.org/r/V20FQ0lVJQ#hUYB/LRdm74/ytm+wl4LllfHIYrIq0QdMsoDY/az4jA=

- connexions du browser qui déconnent aussi

https://framadrop.org/r/iLXjIVEK69#xiJSfmU3WB7bDZWvO9WUJAqHz5t5lvYyJvdvAEOdRT4=

BJ> > La même commande
BJ> >   env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers=aes256-ctr" git pull
BJ> > sur le dépôt qui plante (1) et un qui fonctionne (à condition
BJ> > d'imposer le cipher) (2)  
BJ> 
BJ> Rhohh... Idée ! J'ai eu un truc similaire avec les concetés
BJ> debianesques. Il y a des chiffrements qui ont disparu de certaines
BJ> versions récentes d'OpenSSL qui m'empêchaient d'envoyer des mails à
BJ> certains (gros) domaines. Il m'a fallu patcher sendmail pour contourner
BJ> le problème !...
BJ> 
BJ> Peux-tu compiler un OpenSSL officiel (non patché par Debian) ?

Pas la peine, le pb ne peut pas venir de là car
- en imposant le cipher, on voit que le handshake ssh se passe bien donc
  ils ont trouvé un cipher commun
- ça fonctionne bien depuis mon portable, qui est aussi sous stretch, avec
  le même ssh/openssl/clé ssh (et la même connexion, j'ai même été jusqu'à
  lui coller même mac, en utilisant le même cable RJ45 sur le même port de
  la même box)

=> le pb vient donc de la gestion du réseau par mon desktop vs laptop. Vu
que les deux ont la même debian, reste 
- le driver de la carte réseau, et je comprends vraiment pas comment ça
  peut influer sur des échanges chiffrés (à priori lui n'agit que sur la
  couche réseau, pas applicative).
- le (dé)chiffrement AES par le cpu

Y'a moyen de changer des paramètres du kernel pour modifier la gestion AES
du cpu ?

Vous voyez une autre piste ?


BJ> Si c'est bien ce à quoi je pense, il faudrait que des gens qui
BJ> ne comprennent pas les implications de leurs patches arrêtent de les
BJ> imposer...

Sur la suppression de certains ciphers d'openssl, c'est un choix délibéré
je suppose, interdire les connexions qui paraissent sécurisées mais ne le
sont pas car utilisant des ciphers vulnérables.

C'est le choix de firefox & chrome par ex, ils refusent désormais les
connexions https vers des sites qui ne font pas de TLS ou utilisent des
ciphers trop faibles.

-- 
Daniel

Le philosophe cherche des solutions aux problèmes et
ne trouve que des problèmes sans solutions. 
Sim

Re: Plantage bizarre

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 10/04/18 à 15:43, BERTRAND Joël  a écrit :
> BJ>   Je ne sais pas sur quoi agit l'option -4 (hormis le fait
> BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que même
> BJ> interrogés en IPv4, certains DNS renvoient des résolutions IPv6 et
> BJ> c'est au soft de faire le tri dans les réponses. Mais encore une fois,
> BJ> je ne sais pas si ssh est assez subtil pour cela.
> 
> Je pense quand même que même si la requête dns lui renvoyait du , il
> n'utiliserait que les champs A pour se connecter.
> 
> BJ>   Peux-tu poster ici un dump réseau complet de quelque chose qui
> BJ> fonctionne et d'une transaction qui échoue ? Par complet, c'est avec les
> BJ> options -v et -e.
> 
> Avec git on ne peut pas activer -e

Je pensais à un tcpdump bien senti.

> La même commande
>   env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers=aes256-ctr" git pull
> sur le dépôt qui plante (1) et un qui fonctionne (à condition d'imposer
> le cipher) (2)

Rhohh... Idée ! J'ai eu un truc similaire avec les concetés
debianesques. Il y a des chiffrements qui ont disparu de certaines
versions récentes d'OpenSSL qui m'empêchaient d'envoyer des mails à
certains (gros) domaines. Il m'a fallu patcher sendmail pour contourner
le problème !...

Peux-tu compiler un OpenSSL officiel (non patché par Debian) ?

Si c'est bien ce à quoi je pense, il faudrait que des gens qui ne
comprennent pas les implications de leurs patches arrêtent de les imposer...

JKB

Re: Plantage bizarre

[Daniel Caillibaud]

Le 10/04/18 à 15:43, BERTRAND Joël  a écrit :
BJ> Je ne sais pas sur quoi agit l'option -4 (hormis le fait
BJ> s'utiliser IPv4 pour la connexion). Mais je puis t'assurer que même
BJ> interrogés en IPv4, certains DNS renvoient des résolutions IPv6 et
BJ> c'est au soft de faire le tri dans les réponses. Mais encore une fois,
BJ> je ne sais pas si ssh est assez subtil pour cela.

Je pense quand même que même si la requête dns lui renvoyait du , il
n'utiliserait que les champs A pour se connecter.

BJ> Peux-tu poster ici un dump réseau complet de quelque chose qui
BJ> fonctionne et d'une transaction qui échoue ? Par complet, c'est avec les
BJ> options -v et -e.

Avec git on ne peut pas activer -e

La même commande
  env GIT_SSH_COMMAND="ssh -4 -v -o Ciphers=aes256-ctr" git pull
sur le dépôt qui plante (1) et un qui fonctionne (à condition d'imposer
le cipher) (2)

Pour info, je viens de réinstaller une stretch toute fraîche, pensant 
que mes pbs divers étaient peut-être liés à de vieux résidus, des modules 
plus utiles, etc. (car c'est un PC qui a presque 10 ans et je me rappelle 
pas avoir fait de réinstall from scratch, donc il pouvait avoir des restes 
qui remontent à etch, et j'avais déjà eu des pbs d'hibernation avec lenny 
ou squeeze de mémoire), mais ça ne change absolument rien :-/

1) dépôt HS

OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l  25 May 2017
debug1: Reading configuration data /home/daniel/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to github.com [192.30.253.112] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/daniel/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-10+deb9u3
debug1: Remote protocol version 2.0, remote software version libssh_0.7.0
debug1: no match: libssh_0.7.0
debug1: Authenticating to github.com:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha...@libssh.org
debug1: kex: host key algorithm: ssh-rsa
debug1: kex: server->client cipher: aes256-ctr MAC: hmac-sha2-256 compression: 
none
debug1: kex: client->server cipher: aes256-ctr MAC: hmac-sha2-256 compression: 
none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ssh-rsa 
SHA256:nThbg6kXUpJWGl7E1IGOCspRomTxdCARLviKw6E5SY8
debug1: Host 'github.com' is known and matches the RSA host key.
debug1: Found key in /home/daniel/.ssh/known_hosts:596
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 4294967296 blocks
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: root@asus17
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: root@quad
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: dan...@lairdutemps.org
debug1: Authentications that can continue: publickey
debug1: Offering RSA public key: daniel.caillib...@sesamath.net
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: Authentication succeeded (publickey).
Authenticated to github.com ([192.30.253.112]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: pledge: network
debug1: Sending environment.
debug1: Sending env LANG = fr_FR.UTF-8
debug1: Sending command: git-upload-pack 'sesamath/sesalab.git'
debug1: channel 0: free: client-session, nchannels 1
debug1: fd 0 clearing O_NONBLOCK
debug1: fd 1 clearing O_NONBLOCK
Connection to github.com closed by remote host.
Transferred: sent 12336, received 73736 bytes, in 1.0 seconds
Bytes per second: sent 12674.8, received 75761.3
debug1: Exit status -1
fatal: The remote end hung up unexpectedly


2) Dépôt qui marche à condition de préciser un cipher aes

OpenSSH_7.4p1 Debian-10+deb9u3, OpenSSL 1.0.2l  25 May 2017
debug1: Reading configuration data 

Re: Plantage bizarre

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 10/04/18 à 10:47, BERTRAND Joël  a écrit :
> 
> BJ> Daniel Caillibaud a écrit :
> BJ> > Le 09/04/18 à 19:45, BERTRAND Joël  a
> BJ> > écrit :  
> BJ> > BJ> En d'autres termes, est-ce que le problème persiste en
> BJ> > BJ> désactivant IPv6 sur le poste en question ?  
> BJ> > 
> BJ> > Oui, pour éliminer ça dès le début tous les tests sont en ipv4, j'ai
> BJ> > désactivé l'ipv6 sur l'interface et je fais les tests en passant -4 à
> BJ> > ssh.  
> BJ> 
> BJ>   Même pour la résolution de nom ? Que renvoie un 'host' sur le
> BJ> domaine fautif ? J'ai déjà eu des cas bizarres où le resolver
> BJ> renvoyaient une réponse  sur une machine sans IPv6.
> 
> Oui, mais là dans les traces tcp on voit que la connexion est ouverte puis
> coupée en cours de route.
> 
> Par ailleurs, j'ai un unbound local pour la résolution (j'utilise le dhcp
> pour assigner l'ip uniquement), et le pb se pose sur du `ssh -4`.

Je ne sais pas sur quoi agit l'option -4 (hormis le fait s'utiliser
IPv4 pour la connexion). Mais je puis t'assurer que même interrogés en
IPv4, certains DNS renvoient des résolutions IPv6 et c'est au soft de
faire le tri dans les réponses. Mais encore une fois, je ne sais pas si
ssh est assez subtil pour cela.

Peux-tu poster ici un dump réseau complet de quelque chose qui
fonctionne et d'une transaction qui échoue ? Par complet, c'est avec les
options -v et -e.

Bien cordialement,

JKB

Re: Plantage bizarre

[Daniel Caillibaud]

Le 10/04/18 à 09:05, Eric Degenetais  a écrit :

ED> Le 10 avril 2018 à 08:47, BERTRAND Joël  a
ED> écrit :
ED> > Même pour la résolution de nom ?

ED> Surtout lié à un changement de FAI... j'ai désactivé IPV6 sur mes
ED> systèmes linux pendant plusieurs années parce que ma f... box ne gérait
ED> pas correctement le protocole de transition IPV4/IPV6, donc si pas de
ED> bol la réponse de la requête IPV6 arrivait en premier je me prenais le
ED> mur. Ça a pu s'améliorer ... ou pas en fonction des FAI.

C'est effectivement une piste plausible, mais avec avec du ssh -4 y'a
vraiment aucune raison que ssh utilise de l'ipv6, ou alors un truc
m'échappe (et même si l'appel dns n'était pas restreint à v4, ssh ne se
connecterait pas et le message serait différent).

Et dans mes traces tcpdump, je ne vois que l'ipv4, mais c'est vrai que ça
prouve rien vu que je filtre le snif sur l'ipv4 du host qui m'intéresse…

J'ai désactivé l'ipv6 dans network-manager, mais c'est vrai qu'un ifconfig
continuait de me donner une mac et une adresse ipv6.

Par acquis de conscience, j'ai donc re-testé après

sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.all.autoconf=0
sysctl -w net.ipv6.conf.default.disable_ipv6=1
sysctl -w net.ipv6.conf.default.autoconf=0

et avoir vérifié qu'un ifconfig ne donnait plus de trace d'ipv6 => c'est
pareil.

-- 
Daniel

Je pense qu'il y a sur le marché mondial place pour environ 
cinq ordinateurs. Président du Board of IBM (1943)

Re: Plantage bizarre

[Daniel Caillibaud]

Le 10/04/18 à 10:47, BERTRAND Joël  a écrit :

BJ> Daniel Caillibaud a écrit :
BJ> > Le 09/04/18 à 19:45, BERTRAND Joël  a
BJ> > écrit :  
BJ> > BJ>   En d'autres termes, est-ce que le problème persiste en
BJ> > BJ> désactivant IPv6 sur le poste en question ?  
BJ> > 
BJ> > Oui, pour éliminer ça dès le début tous les tests sont en ipv4, j'ai
BJ> > désactivé l'ipv6 sur l'interface et je fais les tests en passant -4 à
BJ> > ssh.  
BJ> 
BJ> Même pour la résolution de nom ? Que renvoie un 'host' sur le
BJ> domaine fautif ? J'ai déjà eu des cas bizarres où le resolver
BJ> renvoyaient une réponse  sur une machine sans IPv6.

Oui, mais là dans les traces tcp on voit que la connexion est ouverte puis
coupée en cours de route.

Par ailleurs, j'ai un unbound local pour la résolution (j'utilise le dhcp
pour assigner l'ip uniquement), et le pb se pose sur du `ssh -4`.

(mais merci pour la remarque, je tâcherai de m'en souvenir pour commencer
par regarder ça si un truc qui ressemble se produit).

-- 
Daniel

Il vaut mieux être saoul que con, ça dure moins longtemps.
Dicton Breton

Re: Plantage bizarre

[Eric Degenetais]

Le 10 avril 2018 à 08:47, BERTRAND Joël  a écrit
:
> Même pour la résolution de nom ?
Surtout lié à un changement de FAI... j'ai désactivé IPV6 sur mes systèmes
linux pendant plusieurs années parce que ma f... box ne gérait pas
correctement le protocole de transition IPV4/IPV6, donc si pas de bol la
réponse de la requête IPV6 arrivait en premier je me prenais le mur.
Ça a pu s'améliorer ... ou pas en fonction des FAI.
__
Éric Dégenètais

Re: Plantage bizarre

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 09/04/18 à 19:45, BERTRAND Joël  a écrit :
> BJ>   En d'autres termes, est-ce que le problème persiste en
> BJ> désactivant IPv6 sur le poste en question ?
> 
> Oui, pour éliminer ça dès le début tous les tests sont en ipv4, j'ai
> désactivé l'ipv6 sur l'interface et je fais les tests en passant -4 à ssh.

Même pour la résolution de nom ? Que renvoie un 'host' sur le domaine
fautif ? J'ai déjà eu des cas bizarres où le resolver renvoyaient une
réponse  sur une machine sans IPv6.

Bien cordialement,

JKB

Re: Plantage bizarre

[Daniel Caillibaud]

Le 09/04/18 à 19:45, BERTRAND Joël  a écrit :
BJ> En d'autres termes, est-ce que le problème persiste en
BJ> désactivant IPv6 sur le poste en question ?

Oui, pour éliminer ça dès le début tous les tests sont en ipv4, j'ai
désactivé l'ipv6 sur l'interface et je fais les tests en passant -4 à ssh.

-- 
Daniel

Dans la vie il faut faire ce que l'on aime. 
Ce n'est pas une garantie de réussite, mais au moins,
c'est une garantie de non-frustration.
Willy Rozenbaum

Re: Plantage bizarre

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 09/04/18 à 18:45, BERTRAND Joël  a écrit :
> BJ>   Avec un MTU de 1492, qu'est-ce que ça donne ? Ça fleure bon le
> BJ> ping bloqué quelque part.
> 
> Ça change rien, avec quelques valeurs inférieures non plus (testé 1400, 1200
> & 1000).
> 
> Merci pour la suggestion (j'aurais dû penser à essayer ça).

Bon. Quid de la résolution de nom IPv6 ? La plupart des opérateurs
(même pro), ne savent pas la gérer correctement. J'ai eu ce genre de
problème jusqu'à ce que j'ai collé en dur les chemins IPv6.

En d'autres termes, est-ce que le problème persiste en désactivant IPv6
sur le poste en question ?

Cordialement,

JKB

Re: Plantage bizarre

[Daniel Caillibaud]

Le 09/04/18 à 18:45, BERTRAND Joël  a écrit :
BJ> Avec un MTU de 1492, qu'est-ce que ça donne ? Ça fleure bon le
BJ> ping bloqué quelque part.

Ça change rien, avec quelques valeurs inférieures non plus (testé 1400, 1200
& 1000).

Merci pour la suggestion (j'aurais dû penser à essayer ça).

-- 
Daniel

L'eau conduit l'électricité, mais si tu mets du vin dedans, 
elle a plus le droit de conduire.
Brèves de comptoir (rapportée par Jean-Marie Gourio)

Re: Plantage bizarre

[BERTRAND Joël]

Daniel Caillibaud a écrit :
> Le 04/04/18 à 08:35, Daniel Caillibaud  a écrit :
> DC> Bonjour,
> DC> 
> DC> J'ai changé de FAI hier, ça n'a probablement rien à voir mais y'a quand
> DC> même un truc louche coté réseau [1].
> 
> C'est surtout lui qui me dérange au quotidien, difficile de bosser avec 
> d'autres sans avoir accès au dépôt de code commun.
> 
> J'ai pas réglé mon pb d'hibernation, ça refuse toujours de se réveiller de
> tps en tps, mais c'est pas très souvent, et ça arrivait déjà de temps à
> autres. 
> Et depuis qq jours j'ai eu un seul plantage violent (changer le câble 
> réseau de carte, cf +loin).
> 
> Ce qui est vraiment gênant pour moi, c'est l'impossibilité de causer à
> github :
> 
> - git+ssh : connexion coupée. github répond pas au handshake ssh (bloqué
>   sur "expecting SSH2_MSG_KEX_ECDH_REPLY"), si je force un cipher aes ça va
>   un peu plus loin et termine avec "Connection to github.com closed by
>   remote host" + "fatal: The remote end hung up unexpectedly"
> 
> - interface web : login impossible avec firefox, difficile avec chrome
>   (faut insister au login, et ensuite plein de requêtes se prennent du
>   net::ERR_CONNECTION_RESET)
> 
> mais
> 
> - ça fonctionne bien avec d'autres dépôts git (aussi en git+ssh avec la
>   même clé) depuis cette machine
> - pas vu d'autres pbs depuis le browser (testé d'autres trucs en https 
>   qui font pas mal d'ajax)
> - ça fonctionne bien depuis mon laptop, testé en filaire avec la même
>   debian stretch, même clé ssh, ipv4 forcé, j'ai même testé la modif de la
>   mac de mon desktop pour lui coller celle du portable, utilisé le même
>   câble RJ45 sur le même port de la box, rien n'y fait, **laptop ok et
>   desktop ko !**
> 
> Le seul truc qui change est le chipset de la carte réseau, mais pourquoi ça
> ne coince que vers github, et pourquoi ça marchait le matin et plus
> l'aprèm, mystère…
> 
> J'ai vérifié, les 2 PC ont la même conf réseau, tout en automatique, MTU à
> 1500.

Bonsoir,

Avec un MTU de 1492, qu'est-ce que ça donne ? Ça fleure bon le ping
bloqué quelque part.

Bien cordialement,

JKB

Re: Plantage bizarre

[Daniel Caillibaud]

Le 04/04/18 à 08:35, Daniel Caillibaud  a écrit :
DC> Bonjour,
DC> 
DC> J'ai changé de FAI hier, ça n'a probablement rien à voir mais y'a quand
DC> même un truc louche coté réseau [1].

C'est surtout lui qui me dérange au quotidien, difficile de bosser avec 
d'autres sans avoir accès au dépôt de code commun.

J'ai pas réglé mon pb d'hibernation, ça refuse toujours de se réveiller de
tps en tps, mais c'est pas très souvent, et ça arrivait déjà de temps à
autres. 
Et depuis qq jours j'ai eu un seul plantage violent (changer le câble 
réseau de carte, cf +loin).

Ce qui est vraiment gênant pour moi, c'est l'impossibilité de causer à
github :

- git+ssh : connexion coupée. github répond pas au handshake ssh (bloqué
  sur "expecting SSH2_MSG_KEX_ECDH_REPLY"), si je force un cipher aes ça va
  un peu plus loin et termine avec "Connection to github.com closed by
  remote host" + "fatal: The remote end hung up unexpectedly"

- interface web : login impossible avec firefox, difficile avec chrome
  (faut insister au login, et ensuite plein de requêtes se prennent du
  net::ERR_CONNECTION_RESET)

mais

- ça fonctionne bien avec d'autres dépôts git (aussi en git+ssh avec la
  même clé) depuis cette machine
- pas vu d'autres pbs depuis le browser (testé d'autres trucs en https 
  qui font pas mal d'ajax)
- ça fonctionne bien depuis mon laptop, testé en filaire avec la même
  debian stretch, même clé ssh, ipv4 forcé, j'ai même testé la modif de la
  mac de mon desktop pour lui coller celle du portable, utilisé le même
  câble RJ45 sur le même port de la box, rien n'y fait, **laptop ok et
  desktop ko !**

Le seul truc qui change est le chipset de la carte réseau, mais pourquoi ça
ne coince que vers github, et pourquoi ça marchait le matin et plus
l'aprèm, mystère…

J'ai vérifié, les 2 PC ont la même conf réseau, tout en automatique, MTU à
1500.

1) desktop

eth1: flags=4163  mtu 1500
inet 192.168.1.54  netmask 255.255.255.0  broadcast 192.168.1.255
inet6 fe80::3285:a9ff:fe05:ff91  prefixlen 64  scopeid 0x20
ether 30:85:a9:05:ff:91  txqueuelen 1000  (Ethernet)
RX packets 437534  bytes 439004723 (418.6 MiB)
RX errors 0  dropped 3  overruns 0  frame 0
TX packets 259013  bytes 63054413 (60.1 MiB)
TX errors 0  dropped 0 overruns 0  carrier 17  collisions 0


2) laptop

eth0: flags=4163  mtu 1500
inet 192.168.1.54  netmask 255.255.255.0  broadcast 192.168.1.255
inet6 fe80::3285:a9ff:fe05:ff91  prefixlen 64  scopeid 0x20
ether 30:85:a9:05:ff:91  txqueuelen 1000  (Ethernet)
RX packets 9512  bytes 10664033 (10.1 MiB)
RX errors 1  dropped 0  overruns 0  frame 1
TX packets 4932  bytes 647143 (631.9 KiB)
TX errors 0  dropped 0 overruns 0  carrier 5  collisions 0


Après pas mal de tests et qq échanges avec github, j'ai vu que git+ssh est
impossible sur un seul dépôt, sur les autres ça passe si je force le cipher
(mais pas sans le forcer) avec
  env GIT_SSH_COMMAND="ssh -v -o Ciphers=aes256-ctr" git maCommande

J'ai comme l'impression que github n'y est pas pour grand chose :
- je doute que leur sshd réagisse différement si c'est même ip, même clé,
  même mac
- en testant avec l'autre carte réseau (avant de l'enlever), le desktop 
  s'est figé complètement lorsque j'ai changé le cable de carte réseau, 
  rien dans les logs.
mais je comprends pas du tout comment un pb hard/soft sur mon desktop
pourrait donner ce comportement (≠ suivant dépôt et cipher)

J'ai ensuite viré l'autre carte réseau (PCI, qui servait pas avant ces tests) 
pour que cette carte intégrée se retrouve toute seule et en eth0, ça change 
rien (assez logique mais au moins c'est sûr).

J'ai ensuite désactivé dans le bios la carte réseau gigabit intégrée (realtek 
8139) et rebranché la vieille SMC1211 PCI (100Mbps), l'interface 
veut plus monter, dmesg raconte

[   33.425019] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
[   33.425072] genirq: Flags mismatch irq 0. 0080 (enp4s0) vs. 00015a00 
(timer)
[   64.164910] EXT4-fs (dm-8): mounted filesystem with ordered data mode. Opts: 
(null)
[  155.754405] IPv6: ADDRCONF(NETDEV_UP): enp4s0: link is not ready
[  155.754462] genirq: Flags mismatch irq 0. 0080 (enp4s0) vs. 00015a00 
(timer)

Donc y'aurait bien un pb soft ou hard autour du réseau sur cette machine, 
mais je vois pas trop quoi (ni pourquoi ce serait arrivé subitement au 
changement de box).

Je suis passé du kernel 4.9.0-4-amd64 à 4.13.0-0.bpo.1-amd64, ça change 
rien non plus…

Le pb tcp vu par wireshark, en résumé

1) browser
github => clientTLSv1.2 117 [TCP ACKed unseen segment] , Change 
Cipher Spec, Encrypted Handshake Message
TLSv1.2 97  [TCP ACKed unseen segment] , Encrypted 
Alert
TCP 66  [TCP ACKed unseen segment] 443 → 39226 
[RST, ACK] Seq=3692 Ack=3198 Win=35840 Len=0 

Re: Plantage bizarre

[Randy11]

Bonjour,

Avant hier, plantage machine complet sans que je fasse la moindre
intervention, pas d'action, pas d'autre utilisateur, "xscreensaver" présent,
pas de process sur "crontab" autres que ceux du système.

Impossible de reprendre la main, pas de réponse au 'ping', machine d
d'environ un an, carte mère Gigabyte GA-H270-HD3 avec un i5.

Seul truc qui fait chauffer les 4 coeurs : Captvty installé dans un 'chroot'
qui de temps en temps s'emballe.

J'ignore s'il existe un lien avec ton problème, la coïncidence est curieuse.

Les mises à jours automatiques sont activées sans restriction toutes les
nuits, le derniers "reboot" à plus de 3 semaines.

Je suis aussi très curieux de comprendre ce qui a pu se passer.

Pour info :
>lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description:Debian GNU/Linux 9.4 (stretch)
Release:9.4
Codename:   stretch

> 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64 GNU/Linux

Bonne journée.

Randy11.

Le 04/04/2018 à 08:35, Daniel Caillibaud a écrit :

Bonjour,

J'ai changé de FAI hier, ça n'a probablement rien à voir mais y'a quand
même un truc louche coté réseau [1].

Quelques heures plus tard, mon PC s'est figé (image fixe, plus de clavier
ni de souris), et les logs kernel sont curieux, on dirait une mise en
veille [2].
Pas moyen de le redémarrer au bouton en façade (ventilos mais pas l'image
habituelle du bios qui précède grub, écrans noirs), il a fallu couper
l'alim et redémarrer. Au redémarrage, j'ai comme l'impression que le bios
s'est remis avec ses réglages par défaut car il m'a affiché l'image du
constructeur au début du démarrage (que j'avais pas avant).

J'ai bossé qq heures, puis en rédigeant ce mail j'ai voulu faire un lshw
pour filer plus d'infos et il s'est de nouveau figé, mais sans rien raconter
dans les logs (plantage 10 à 20s après le lancement de `lshw -short`, je
viens de relancer la commande qui répond en 1~2s).

C'est une debian stretch classique, avec un 4.9.0-4-amd64, sur un vieux
coucou qui devrait fêter bientôt ses 10 ans, mais vu qu'il me suffit pour
mon taf quotidien je pensais pas le changer tout de suite :-/

C'est un cpu intel Q9550 avec une CM Asus P5QL PRO, et
network AR8121/AR8113/AR8114 Gigabit or Fast Ethernet
display GF119 [GeForce GT 610]

Une piste ?

[1] Pb github
Après changement de box fibre et avoir récupéré du réseau (en laissant
le dhcp gérer le fait que la connexion était revenue), tout fonctionnait
bien sauf github :
- git clone https://github… OK
- git clone g...@github.com… KO
- commandes git sur mes dépôts locaux avec un remote sur github HS
- commandes git sur mes dépôts locaux avec un autre remote OK
- github.com via un navigateur est chaotique (coupures tcp sur la plupart des
   requêtes, login difficile, coupure systématique sur les sockets http)
- depuis mon PC portable qui utilise la même box en wifi tout ça fonctionne
   normalement
Après 2h à chercher, tenté un reboot, ça n'a logiquement rien changé.
Modifier l'adresse mac de ma carte réseau non plus.

[2] logs kernel

Re: Plantage bizarre

[Daniel Caillibaud]

Le 04/04/18 à 09:29, Christophe De Natale  a
écrit :
CDN> Je me lance : 

Merci :-)

CDN> le pc n'a jamais été déconnecté du réseau électrique et
CDN> la pile 3 volts est à plat ?

C'est bien possible, mais l'heure était bonne lorsque je suis allé dans le
bios après avoir éteint l'alim, je vais tester de nouveau à la pause dej
en laissant l'alim coupée un moment.

CDN> Du coup les réglages du bios affectés à l'époque ont disparu ?
CDN> Du style le lien ahci passé en ide ou la gestion d'énergie modifiée...

Et ça expliquerait le plantage, pourquoi pas, sauf que je me souviens pas
du tout avoir modifié ces paramètres de gestion d'énergie…

Et ça n'explique pas vraiment mon pb réseau, car y'a pas eu de reboot entre
avant / après le changement de box (y'en a eu un hier soir, redémarrage
"propre" depuis debian, et j'ai pas eu l'image avant le bios à ce moment
là), le pb github est apparu après cette modif réseau, mais sans reboot.

J'ai eu un bios différent (avec l'image) après le boot qui m'a obligé à
éteindre l'alim, donc ça pourrait coller, sauf que le plantage a eu lieu
avant ce boot, donc y'aurait déjà eu un pb de bios avant ?

C'est possible d'avoir un bios qui reset certaines valeurs mais pas
toutes en cas de pile fatiguée ?

Il va falloir que je me replonge dans la doc pour comprendre chaque
param du bios, et le hardware est vraiment un truc qui m'intéresse pas :-/ 
(aussi pour ça que je garde mes machines aussi longtemps, le matériel
marche => on touche plus au hardware)

Je vais commencer par désinstaller mes paquets de gestion d'hibernation, et
remettre le bios par défaut, mais apparemment je peux pas désactiver l'acpi

- Suspend Mode [Auto]
  avec aussi S1 (power on suspend sleeping mode), et S3 (Suspend to RAM)
  P'tet forcer S3 ?

- ACPI 2.0 Support [Disabled] 
  Allows you to add more tables for Advanced Configuration and Power
  Interface (ACPI) 2.0 specifications.
  Je suppose que c'est mieux d'activer vu que debian gère ça depuis
  longtemps, mais j'en sais rien

- ACPI APIC Support [Enabled]
  Allows you to enable or disable the Advanced Configuration and Power
  Interface (ACPI) support in the Advanced Programmable Interrupt
  Controller (APIC). When set to Enabled, the ACPI APIC table pointer is
  included in the RSDT pointer list. 
  Idem…




-- 
Daniel

Un clavier azerty en vaut deux.

Re: Plantage bizarre

[Christophe De Natale]

Le 04/04/2018 à 08:35, Daniel Caillibaud a écrit :

Bonjour,


Bonjour,



J'ai changé de FAI hier, ça n'a probablement rien à voir mais y'a quand
même un truc louche coté réseau [1].

Quelques heures plus tard, mon PC s'est figé (image fixe, plus de clavier
ni de souris), et les logs kernel sont curieux, on dirait une mise en
veille [2].
Pas moyen de le redémarrer au bouton en façade (ventilos mais pas l'image
habituelle du bios qui précède grub, écrans noirs), il a fallu couper
l'alim et redémarrer. Au redémarrage, j'ai comme l'impression que le bios
s'est remis avec ses réglages par défaut car il m'a affiché l'image du
constructeur au début du démarrage (que j'avais pas avant).

[...]

Une piste ?

[...]
Je me lance : le pc n'a jamais été déconnecté du réseau électrique et la 
pile 3 volts est à plat ?

Du coup les réglages du bios affectés à l'époque ont disparu ?
Du style le lien ahci passé en ide ou la gestion d'énergie modifiée...

--
Christophe

Plantage bizarre

[Daniel Caillibaud]

Bonjour,

J'ai changé de FAI hier, ça n'a probablement rien à voir mais y'a quand
même un truc louche coté réseau [1].

Quelques heures plus tard, mon PC s'est figé (image fixe, plus de clavier
ni de souris), et les logs kernel sont curieux, on dirait une mise en
veille [2]. 
Pas moyen de le redémarrer au bouton en façade (ventilos mais pas l'image
habituelle du bios qui précède grub, écrans noirs), il a fallu couper
l'alim et redémarrer. Au redémarrage, j'ai comme l'impression que le bios
s'est remis avec ses réglages par défaut car il m'a affiché l'image du
constructeur au début du démarrage (que j'avais pas avant).

J'ai bossé qq heures, puis en rédigeant ce mail j'ai voulu faire un lshw
pour filer plus d'infos et il s'est de nouveau figé, mais sans rien raconter 
dans les logs (plantage 10 à 20s après le lancement de `lshw -short`, je 
viens de relancer la commande qui répond en 1~2s).

C'est une debian stretch classique, avec un 4.9.0-4-amd64, sur un vieux
coucou qui devrait fêter bientôt ses 10 ans, mais vu qu'il me suffit pour
mon taf quotidien je pensais pas le changer tout de suite :-/

C'est un cpu intel Q9550 avec une CM Asus P5QL PRO, et
network AR8121/AR8113/AR8114 Gigabit or Fast Ethernet
display GF119 [GeForce GT 610]

Une piste ?

[1] Pb github
Après changement de box fibre et avoir récupéré du réseau (en laissant
le dhcp gérer le fait que la connexion était revenue), tout fonctionnait
bien sauf github :
- git clone https://github… OK
- git clone g...@github.com… KO
- commandes git sur mes dépôts locaux avec un remote sur github HS
- commandes git sur mes dépôts locaux avec un autre remote OK
- github.com via un navigateur est chaotique (coupures tcp sur la plupart des
  requêtes, login difficile, coupure systématique sur les sockets http)
- depuis mon PC portable qui utilise la même box en wifi tout ça fonctionne
  normalement
Après 2h à chercher, tenté un reboot, ça n'a logiquement rien changé.
Modifier l'adresse mac de ma carte réseau non plus.

[2] logs kernel
Apr  4 03:25:43 quad kernel: [10946.508298] PM: Syncing filesystems ... done.
Apr  4 03:25:43 quad kernel: [10946.524369] PM: Preparing system for sleep (mem)
Apr  4 03:25:43 quad kernel: [10946.524561] Freezing user space processes ... 
(elapsed 0.002 seconds) done.
Apr  4 03:25:43 quad kernel: [10946.526759] Freezing remaining freezable tasks 
... (elapsed 0.001 seconds) done.
Apr  4 03:25:43 quad kernel: [10946.527954] PM: Suspending system (mem)
Apr  4 03:25:43 quad kernel: [10946.527988] Suspending console(s) (use 
no_console_suspend to debug)
Apr  4 03:25:43 quad kernel: [10946.531763] serial 00:06: disabled
Apr  4 03:25:43 quad kernel: [10946.531769] serial 00:06: System wakeup 
disabled by ACPI
Apr  4 03:25:43 quad kernel: [10946.532036] sd 2:0:0:0: [sda] Synchronizing 
SCSI cache
Apr  4 03:25:43 quad kernel: [10946.532056] sd 2:0:1:0: [sdb] Synchronizing 
SCSI cache
Apr  4 03:25:43 quad kernel: [10946.532668] nouveau :01:00.0: DRM: 
suspending console...
Apr  4 03:25:43 quad kernel: [10946.532672] nouveau :01:00.0: DRM: 
suspending display...
Apr  4 03:25:43 quad kernel: [10946.532730] nouveau :01:00.0: DRM: evicting 
buffers...
Apr  4 03:25:43 quad kernel: [10946.535273] sd 2:0:0:0: [sda] Stopping disk
Apr  4 03:25:43 quad kernel: [10946.535417] sd 2:0:1:0: [sdb] Stopping disk
Apr  4 03:25:43 quad kernel: [10947.677212] nouveau :01:00.0: DRM: waiting 
for kernel channels to go idle...
Apr  4 03:25:43 quad kernel: [10947.677253] nouveau :01:00.0: DRM: 
suspending client object trees...
Apr  4 03:25:43 quad kernel: [10947.677759] nouveau :01:00.0: DRM: 
suspending kernel object tree...
Apr  4 03:25:43 quad kernel: [10949.368231] PM: suspend of devices complete 
after 2839.975 msecs
Apr  4 03:25:43 quad kernel: [10949.368725] PM: late suspend of devices 
complete after 0.492 msecs
Apr  4 03:25:43 quad kernel: [10949.369073] ehci-pci :00:1d.7: System 
wakeup enabled by ACPI
Apr  4 03:25:43 quad kernel: [10949.369107] uhci_hcd :00:1d.2: System 
wakeup enabled by ACPI
Apr  4 03:25:43 quad kernel: [10949.369146] uhci_hcd :00:1d.1: System 
wakeup enabled by ACPI
Apr  4 03:25:43 quad kernel: [10949.369183] uhci_hcd :00:1d.0: System 
wakeup enabled by ACPI
Apr  4 03:25:43 quad kernel: [10949.369357] ehci-pci :00:1a.7: System 
wakeup enabled by ACPI
Apr  4 03:25:43 quad kernel: [10949.369358] uhci_hcd :00:1a.2: System 
wakeup enabled by ACPI
Apr  4 03:25:43 quad kernel: [10949.369411] uhci_hcd :00:1a.1: System 
wakeup enabled by ACPI
Apr  4 03:25:43 quad kernel: [10949.369426] uhci_hcd :00:1a.0: System 
wakeup enabled by ACPI
Apr  4 03:25:43 quad kernel: [10949.388047] PM: noirq suspend of devices 
complete after 19.319 msecs
Apr  4 03:25:43 quad kernel: [10949.388862] ACPI: Preparing to enter system 
sleep state S3
Apr  4 03:25:43 quad kernel: [10949.389127] PM: Saving platform NVS memory
Apr  4 03:25:43 quad kernel: [10949.389361] Disabling non-boot CPUs ...
Apr  4 

Re: amule plantage bizarre

[neo83.ath.cx]

 et mldonkey vous aimez pas?

Personnelement mldonkey je l'ai installer mais je n'est pas encore trouvé le
temp de le configurer, donc pour l'instant je ne l'utilise pas!

Re: amule plantage bizarre

[Jean-Luc Coulon (f5ibh)]

Le 18.05.2004 20:41:44, neo83.ath.cx a écrit :

 et mldonkey vous aimez pas?

Personnelement mldonkey je l'ai installer mais je n'est pas encore
trouvé le
temp de le configurer, donc pour l'instant je ne l'utilise pas!




mlonkey : je l'ai installé aussi

bilan :
positif : la consommation cpu qui est *beaucoup* mois importante.
(on n'a pas besoin de laisser touner le gui et les stats en permanence)

négatif : le temps mouen pour télécharger disons (par hasard) 700mo  
prend environ cinq fois plus de temps.


Mais peut-être que mldonkey a quelques astuces que je ne maîtrise  
pas...


--
- Jean-Luc


pgprhgntudGsW.pgp
Description: PGP signature

amule plantage bizarre

[neo83.ath.cx]

Salut la liste,

Parlons peu, mais parlons bien,
j'ai amule qui arrete pas de planter, j'ai pas trop souvent de crash
libwx_gtk2.4 mais j'ai une decharge complete du processeur, puis plus rien
( l'ecran d'amule reste figé mais le reste fonctionne quand meme), il ne
reste plus qu'à killer amule.
Est ce que quelqu'un à dejà eu ce probleme?? Et surtout est ce que quelqu'un
sait comment le resoudre ??

Ma config un PII 466 MMX 256Mo de Sdram Debian Sid noyau 2.6.4 recompilé
Connexion ADSL 1024

D'avance merci de votre aide

Jerome
Apprentis linuxien

Re: amule plantage bizarre

[Jean-Luc Coulon (f5ibh)]

Le 17.05.2004 13:27:05, neo83.ath.cx a écrit :

Salut la liste,

Parlons peu, mais parlons bien,
j'ai amule qui arrete pas de planter, j'ai pas trop souvent de crash
libwx_gtk2.4 mais j'ai une decharge complete du processeur, puis plus
rien
( l'ecran d'amule reste figé mais le reste fonctionne quand meme), il
ne
reste plus qu'à killer amule.
Est ce que quelqu'un à dejà eu ce probleme?? Et surtout est ce que
quelqu'un


J'ai déjà *eu* ce problème avec les versions précédentes d'amule.
(je ne sais pas quelle est votre version)


sait comment le resoudre ??


J'utilise en ce moment sous sid, la version 1.2.6+2.0.0rc3 et, en  
dehors de problèmes de locales, je n'ai plus de plantage. Il est vrai  
que je ne laisse pas touner la machine 7 jours sur 7 et je ne peux pas  
me prononcer sur son endurance.


J'utilise le dépotoir de Julien :
deb http://gunnm.org/~soda/ unstable main contrib
deb-src http://gunnm.org/~soda/ unstable main contrib

--
- Jean-Luc



Ma config un PII 466 MMX 256Mo de Sdram Debian Sid noyau 2.6.4
recompilé
Connexion ADSL 1024

D'avance merci de votre aide

Jerome
Apprentis linuxien



--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench

Pensez à rajouter le mot ``spam'' dans vos champs From et
Reply-To:

To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact
[EMAIL PROTECTED]




pgpDWpbwPRiyv.pgp
Description: PGP signature

Re: amule plantage bizarre

[neo83.ath.cx]

Bonsoir la liste,

Pour plus de précision, j'utilise Amule 2.0.0rc3, installer avec la commande
apt-get install.

~% amule -v
aMule 2.0.0rc3

 la version 1.2.6+2.0.0rc3

Que veut tu dire Jean Luc par la version 1.2.6? Est-ce une version de xmule
?

 J'utilise le dépotoir de Julien :
deb http://gunnm.org/~soda/ unstable main contrib
deb-src http://gunnm.org/~soda/ unstable main contrib

C'est deux ligne sont déjà mon /etc/apt/sources.list

Encore merci

Jerome
Apprentis Linuxien

Re: amule plantage bizarre

[f5ibh]

On Mon, May 17, 2004 at 08:13:31PM +0200, neo83.ath.cx wrote:
 Bonsoir la liste,
 
 Pour plus de précision, j'utilise Amule 2.0.0rc3, installer avec la commande
 apt-get install.
 
 ~% amule -v
 aMule 2.0.0rc3
 
  la version 1.2.6+2.0.0rc3
 
 Que veut tu dire Jean Luc par la version 1.2.6? Est-ce une version de xmule
 ?

Ben non, c'est ce que me retourne dpkg -l amule
de l'intérieur de amule, on doit voir 2.0.0rc3 mais le paquet s'appelle
comme ça ...

--
- Jean-Luc
 
  J'utilise le dépotoir de Julien :
 deb http://gunnm.org/~soda/ unstable main contrib
 deb-src http://gunnm.org/~soda/ unstable main contrib
 
 C'est deux ligne sont déjà mon /etc/apt/sources.list
 
 Encore merci
 
 Jerome
 Apprentis Linuxien


signature.asc
Description: Digital signature

Re: amule plantage bizarre

[neo83.ath.cx]

Ok j'ai bien la meme version alors


~%dpkg -l amule


|/ NomVersionDescription
+++-==-==-==
==
ii  amule  1.2.6+2.0.0rc3 aNOTHER eMule P2P Client

Mais a tu ( Jean Luc, je me permet de te tutoyer) une petite idée pour
resoudre mon probleme? Toi ou un autre bien sur?

Encore merci

Jerome
Apprentis linuxien