Re: GRUB : listes de blocs, erreur : résolu

[Pascal Hambourg]

Le 11/04/2018 à 11:38, Klaus Becker a écrit :

Le mercredi 11 avril 2018, 11:31:27 CEST andre_deb...@numericable.fr a écrit :

# grub-install /dev/sda1
me donne ce long message :
"Le système de fichiers NTFS ne prend ps en charge l'empaquetage.


"empaquetage", vraiment ? Ce n'est pas plutôt "embarquage" (embedding) ?


Grub ne doit pas être installé sur cette configuration qu'en utilisant la
liste de blocs, qui ne sont pas FIABLES donc déconseillées.
Erreur, refus de continuer avec les listes de blocs"


Il fallait taper :
# grub-install /dev/sda

Je ne me souviens plus si avant je tapais /dev/sda1,
peut-être une modification du dernier paquet grub ?


Non, GRUB a toujours réagi ainsi avec un type de système de fichier ne 
permettant pas l'embarquage (en gros : tous sauf btrfs). De toute façon, 
je ne suis même pas sûr qu'on puisse installer GRUB dans une partition NTFS.



Pour installer grub, il faut toujours /dev/sdx


Non, c'est faux.

Re: Pilote carte vidéo AMD Radeon 6550M stretch

[andre_debian]

On Wednesday 11 April 2018 20:46:25 Étienne Mollier wrote:
> On 04/11/2018 08:38 PM, andre_deb...@numericable.fr wrote:
> > $ lsmod | grep radeon ne répond rien.

> Ça, ce n'est pas normal.  Vous pouvez déjà vérifier deux points.
> Est-ce que le module radeon est bien configuré dans votre kernel :

>   $ grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)"
>   CONFIG_DRM_RADEON=m

Je reçois la réponse : "aucun fichier ou dossier de ce type"

> Normalement le noyau par défaut de Debian devrait l'embarquer en
> tant que module comme dans la copie ci-dessus.
> Est ce que le module fglrx est toujour présent ?

>$ lsmod | grep fglrx
Aucune réponse.

# apt-cache search fglrx
Aucune réponse;

> Si oui, les deux pilotes sont probablement en conflit et il faut
> évacuer toute trace du pilote propriétaire.  Le désinstaller et
> redémarrer devrait suffire.  À plus,

Ni radeon ni fglrx ne semblent installés,
Je suis perdu...

Vais je devoir retourner à Jessie ?

Bonne fin de soirée,

André

Re: dual screen avec intel UHD 630 possible sur stretch ?

[Daniel Caillibaud]

Le 11/04/18 à 20:57, "JF Straeten"  a écrit :
JS> > Est-ce que qqun parmi vous a fait fonctionner sur une stretch du
JS> > dual screen avec les processeurs intel récent (coffee lake, les
JS> > 8xxx) et leur chipset graphique intégré (intel UHD 630) ?  
JS> 
JS> Oui. Sur un NUC7i3DNKE. Enfin, c'est une buster actuellement, mais la
JS> stretch marchait sans problème aussi avec le dual screen et le chipset
JS> UHD 620 (c'est un i3).

Merci bcp pour cette confirmation !

(et je n'ai pas oublié tes galères à cause des câbles, j'y ferai attention !)

-- 
Daniel

Une pomme par jour éloigne le médecin,
pourvu que l'on vise bien.
Winston Churchill

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: dual screen avec intel UHD 630 possible sur stretch ?

[JF Straeten]

Hello Daniel,


On Wed, Apr 11, 2018 at 08:43:42PM +0200, Daniel Caillibaud wrote:

[...]
> Est-ce que qqun parmi vous a fait fonctionner sur une stretch du
> dual screen avec les processeurs intel récent (coffee lake, les
> 8xxx) et leur chipset graphique intégré (intel UHD 630) ?

Oui. Sur un NUC7i3DNKE. Enfin, c'est une buster actuellement, mais la
stretch marchait sans problème aussi avec le dual screen et le chipset
UHD 620 (c'est un i3).

Le 630 étant plus capable, j'imagine qu'il ne peut que fonctionner
aussi (et mieux ?).


[...]
> Est-ce qu'il y a d'autres pbs à prévoir ? (autour d'autres trucs
> récents comme usb-C, nvme/pci-e, etc. avec un chipset Z370)

J'en fais une utilisation super basique (client léger LTSP, choisi
justement pour avoir un double écran potable en remplacement du
limaçon précédent) et RAS jusqu'ici.

Hih,


-- 

JFS.

Re: Pilote carte vidéo AMD Radeon 6550M stretch

[Étienne Mollier]

On 04/11/2018 08:38 PM, andre_deb...@numericable.fr wrote:
> $ lsmod | grep radeon ne répond rien.

Ça, ce n'est pas normal.  Vous pouvez déjà vérifier deux points.


Est-ce que le module radeon est bien configuré dans votre kernel :

$ grep CONFIG_DRM_RADEON= "/boot/config-$(uname -r)"
CONFIG_DRM_RADEON=m

Normalement le noyau par défaut de Debian devrait l'embarquer en
tant que module comme dans la copie ci-dessus.


Est ce que le module fglrx est toujour présent ?

$ lsmod | grep fglrx

Si oui, les deux pilotes sont probablement en conflit et il faut
évacuer toute trace du pilote propriétaire.  Le désinstaller et
redémarrer devrait suffire.


À plus,
-- 
Étienne Mollier 

dual screen avec intel UHD 630 possible sur stretch ?

[Daniel Caillibaud]

Bonjour,

Est-ce que qqun parmi vous a fait fonctionner sur une stretch du dual screen 
avec les
processeurs intel récent (coffee lake, les 8xxx) et leur chipset graphique 
intégré (intel UHD
630) ?

Installer un noyau récent pose pas de pb mais ce sera impérativement sur une 
stretch.

À priori c'est reconnu
(https://unix.stackexchange.com/questions/405453/debian-9-with-intel-i7-8700) 
mais je me
demande si le dual-screen peut poser pb.

Est-ce qu'il y a d'autres pbs à prévoir ?
(autour d'autres trucs récents comme usb-C, nvme/pci-e, etc. avec un chipset 
Z370)

J'ai fouillé sur https://certification.ubuntu.com/catalog/ pour me donner une 
idée, mais c'est
compliqué de s'y retrouver, y'a bien le HD 630 mais c'est évidemment pas le 
même chipset que
UHD 630…

Merci

-- 
Daniel

Il faut toute une vie pour apprendre à vivre.
Sénèque.

Re: Pilote carte vidéo AMD Radeon 6550M stretch

[andre_debian]

On Wednesday 11 April 2018 19:55:55 Étienne Mollier wrote:
> On 04/11/2018 04:14 PM, andre_deb...@numericable.fr wrote:

> Bonjour André,

> > Depuis l'upgrade de Jessie vers Stretch,
> > je n'arrive plus à faire fonctionner ma carte graphique
> > AMD Radeon 6550M.

> J'utilise une carte AMD Radeon HD5770 sous Sid.  À la fin de l'année
> 2015, après sortie de Jessie, AMD a sorti son dernier driver fglrx,
> qui n'a pas reçu de mise à jour depuis, d'où le manque de support.
> Le driver libre alternatif est le pilote radeon, les cartes gpu plus
> récentes peuvent aussi avoir besoin du pilote amdgpu:
> $ lsmod | grep radeon
> radeon

Merci Étienne pour votre aide.
$ lsmod | grep radeon ne répond rien.

> > J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfree"
> > et "xserver-xorg-video-ati".

> Avec une HD6550M, le paquet xserver-xorg-video-radeon devrait résoudre
> votre problème.

J'ai bien installé le paquet "xserver-xorg-video-radeon",
ainsi que le pilote "xserver-xorg-video-amdgpu".

> En espérant que ça aide,  À plus,

Oui, ça aide, bons tuyaux mais toujours pas de vidéo... :-)

Il me semble avoir vu passer un mail sur la ML sur ce même sujet,
il y a environ 6 mois, mais pas retrouvé...

Bonne soirée,

André

Re: Pilote carte vidéo AMD Radeon 6550M stretch

[Étienne Mollier]

On 04/11/2018 04:14 PM, andre_deb...@numericable.fr wrote:
> Bonjour,

Bonjour André,

> Depuis l'upgrade de Jessie vers Stretch,
> je n'arrive plus à faire fonctionner ma carte graphique
> AMD Radeon 6550M.
>
> Aussi, plus de fglrx sous stretch.

J'utilise une carte AMD Radeon HD5770 sous Sid.  À la fin de l'année
2015, après sortie de Jessie, AMD a sorti son dernier driver fglrx,
qui n'a pas reçu de mise à jour depuis, d'où le manque de support.

Le driver libre alternatif est le pilote radeon, les cartes gpu plus
récentes peuvent aussi avoir besoin du pilote amdgpu:

$ lsmod | grep radeon
radeon

> J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfree"
> et "xserver-xorg-video-ati".

Avec une HD6550M, le paquet xserver-xorg-video-radeon devrait résoudre
votre problème.

En espérant que ça aide,
À plus,
-- 
Étienne Mollier 

Pilote carte vidéo AMD Radeon 6550M stretch

[andre_debian]

Bonjour,

Depuis l'upgrade de Jessie vers Stretch,
je n'arrive plus à faire fonctionner ma carte graphique
AMD Radeon 6550M.

Aussi, plus de fglrx sous stretch.

J'ai bien installé "firmware-amd-graphics" , "firmware-linux-nonfree"
et "xserver-xorg-video-ati".

Les pilotes sur le site AMD ne veulent pas s'installer,
car déclarés non compatible avec xorg.

Que faire ? et merci...

André

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: GRUB : listes de blocs, erreur : résolu

[Klaus Becker]

Le mercredi 11 avril 2018, 11:31:27 CEST andre_deb...@numericable.fr a écrit :
> On Tuesday 10 April 2018 18:50:13 andre_deb...@numericable.fr wrote:
> > # grub-install /dev/sda1
> > me donne ce long message :
> > "Le système de fichiers NTFS ne prend ps en charge l'empaquetage.
> > Grub ne doit pas être installé sur cette configuration qu'en utilisant la
> > liste de blocs, qui ne sont pas FIABLES donc déconseillées.
> > Erreur, refus de continuer avec les listes de blocs"
> 
> Il fallait taper :
> # grub-install /dev/sda
> 
> Désolé pour mon alerte.
> 
> Je ne me souviens plus si avant je tapais /dev/sda1,
> peut-être une modification du dernier paquet grub ?


Salut,

Pour installer grub, il faut toujours /dev/sdx, ce n'est pas nouveau

Klaus

Re: GRUB : listes de blocs, erreur : résolu

[andre_debian]

On Tuesday 10 April 2018 18:50:13 andre_deb...@numericable.fr wrote:
> # grub-install /dev/sda1
> me donne ce long message :
> "Le système de fichiers NTFS ne prend ps en charge l'empaquetage.
> Grub ne doit pas être installé sur cette configuration qu'en utilisant la 
> liste de blocs, qui ne sont pas FIABLES donc déconseillées.
> Erreur, refus de continuer avec les listes de blocs"

Il fallait taper :
# grub-install /dev/sda

Désolé pour mon alerte.

Je ne me souviens plus si avant je tapais /dev/sda1,
peut-être une modification du dernier paquet grub ?

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