Il semblerait que SSH2 (ssh2-nox11-3.2.9.1_3 Secure shell client and
server for V.2 SSH protocol) ne fonctionne pas sur l'architecture amd64
(nocona).
Voici ce que donne une tentative de connexion SSH.
#ssh localhost -p 23 -l apn
apn@localhost's password:
buffer_get_ret: trying to get more bytes 1 than in buffer 0
buffer_get_char_ret: buffer_get_ret failed
buffer_get_char: buffer error
La compilation via les ports et la version binaires du package donnent
la même erreur.
J'ai tenté d'analyser brièvement le code du source incriminé
(/usr/src/crypto/openssh/buffer.c) mais sans résultat probant.
Voici la version du noyau de la machine:
# uname -a
FreeBSD bep-pc1.ulb.ac.be 6.0-RC1 FreeBSD 6.0-RC1 #2: Wed Oct 26
03:27:08 CEST 2005
apn@bep-pc1.ulb.ac.be:/usr/obj/usr/src/sys/BEPkernel amd64
Est-ce que quelqu'un à déjà eu ce problème ? Google semble assez
taciturne à ce propos...
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
F. Senault
Merci pour toute aide,
Des variables particulières dans make.conf ? Idem pour le kernel - quelles sont les options actives ? C'est reproductible avec GENERIC ?
Fred -- See the man with the blue guitar Maybe one day he'll be a star Give him your ice cream and I'll give him the keys to my car There's so much hate goin' round Hard to not let it get you down Least we can do is make a joyful sound, oh yeah (Prince, Strollin')
Merci pour toute aide,
Des variables particulières dans make.conf ? Idem pour le kernel -
quelles sont les options actives ? C'est reproductible avec GENERIC ?
Fred
--
See the man with the blue guitar Maybe one day he'll be a star
Give him your ice cream and I'll give him the keys to my car
There's so much hate goin' round Hard to not let it get you down
Least we can do is make a joyful sound, oh yeah (Prince, Strollin')
Des variables particulières dans make.conf ? Idem pour le kernel - quelles sont les options actives ? C'est reproductible avec GENERIC ?
Fred -- See the man with the blue guitar Maybe one day he'll be a star Give him your ice cream and I'll give him the keys to my car There's so much hate goin' round Hard to not let it get you down Least we can do is make a joyful sound, oh yeah (Prince, Strollin')
Arnaud de Prelle
F. Senault wrote:
Des variables particulières dans make.conf ? Idem pour le kernel - quelles sont les options actives ? C'est reproductible avec GENERIC ?
Hello,
En effet, il y a de ca;
Je viens de recompiler le monde sans les flags C que j'avais modifiés dans /etc/make.conf, et là, la phase de connexion SSH passe sans problème. Néanmoins, je me fais kicker après quelques minutes d'activités sur cette connexion ssh avec les mêmes messages d'erreurs du buffer_get_ret.
Pour info j'ai(avais) comme flags: CPUTYPE?=nocona (car bi-proc xeon (EMT64)) CFLAGS= -O2 -pipe
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas une bonne idée ?
Arnaud.
F. Senault wrote:
Des variables particulières dans make.conf ? Idem pour le kernel -
quelles sont les options actives ? C'est reproductible avec GENERIC ?
Hello,
En effet, il y a de ca;
Je viens de recompiler le monde sans les flags C que j'avais modifiés
dans /etc/make.conf, et là, la phase de connexion SSH passe sans problème.
Néanmoins, je me fais kicker après quelques minutes d'activités sur
cette connexion ssh avec les mêmes messages d'erreurs du buffer_get_ret.
Pour info j'ai(avais) comme flags:
CPUTYPE?=nocona (car bi-proc xeon (EMT64))
CFLAGS= -O2 -pipe
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas
une bonne idée ?
Des variables particulières dans make.conf ? Idem pour le kernel - quelles sont les options actives ? C'est reproductible avec GENERIC ?
Hello,
En effet, il y a de ca;
Je viens de recompiler le monde sans les flags C que j'avais modifiés dans /etc/make.conf, et là, la phase de connexion SSH passe sans problème. Néanmoins, je me fais kicker après quelques minutes d'activités sur cette connexion ssh avec les mêmes messages d'erreurs du buffer_get_ret.
Pour info j'ai(avais) comme flags: CPUTYPE?=nocona (car bi-proc xeon (EMT64)) CFLAGS= -O2 -pipe
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas une bonne idée ?
Arnaud.
Machin Chose
F. Senault wrote:
Pour info j'ai(avais) comme flags: CPUTYPE?=nocona (car bi-proc xeon (EMT64))
j'ai loupé un truc où un moment tu cause d'architecture AMD64 et l'autre, EMT64 (ia64 j'imagine) ?
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas une bonne idée ?
Il me semble que sur la 5.4/amd64, les optimisations sse, sse2, etc.. étaient désactivées car pas très stables sur le gcc 3.4.x livré avec, peut être une piste a voir ?
Z.
F. Senault wrote:
Pour info j'ai(avais) comme flags:
CPUTYPE?=nocona (car bi-proc xeon (EMT64))
j'ai loupé un truc où un moment tu cause d'architecture AMD64 et
l'autre, EMT64 (ia64 j'imagine) ?
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas
une bonne idée ?
Il me semble que sur la 5.4/amd64, les optimisations sse, sse2, etc..
étaient désactivées car pas très stables sur le gcc 3.4.x livré avec,
peut être une piste a voir ?
Pour info j'ai(avais) comme flags: CPUTYPE?=nocona (car bi-proc xeon (EMT64))
j'ai loupé un truc où un moment tu cause d'architecture AMD64 et l'autre, EMT64 (ia64 j'imagine) ?
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas une bonne idée ?
Il me semble que sur la 5.4/amd64, les optimisations sse, sse2, etc.. étaient désactivées car pas très stables sur le gcc 3.4.x livré avec, peut être une piste a voir ?
Z.
Eric Masson
Machin Chose writes:
j'ai loupé un truc où un moment tu cause d'architecture AMD64 et l'autre, EMT64 (ia64 j'imagine) ?
em64t est le nom donné par Intel aux extensions compatibles amd64 qu'ils ont ajouté aux P4 et Xeon.
Il me semble que sur la 5.4/amd64, les optimisations sse, sse2, etc.. étaient désactivées car pas très stables sur le gcc 3.4.x livré avec, peut être une piste a voir ?
Ben, à la base, il vaut mieux éviter de toucher aux CFLAGS à moins de savoir vraiment ce que l'on fait.
-- Salut, Je ne reçoit plus de messages de la mailing-list des nordistes. -+- SG in: GNU - Un ch'ti coup d'fufe pour la route ? -+-
Machin Chose <utilisateur@exemple.fr> writes:
j'ai loupé un truc où un moment tu cause d'architecture AMD64 et
l'autre, EMT64 (ia64 j'imagine) ?
em64t est le nom donné par Intel aux extensions compatibles amd64 qu'ils
ont ajouté aux P4 et Xeon.
Il me semble que sur la 5.4/amd64, les optimisations sse, sse2, etc..
étaient désactivées car pas très stables sur le gcc 3.4.x livré avec,
peut être une piste a voir ?
Ben, à la base, il vaut mieux éviter de toucher aux CFLAGS à moins de
savoir vraiment ce que l'on fait.
--
Salut,
Je ne reçoit plus de messages de la mailing-list des nordistes.
-+- SG in: GNU - Un ch'ti coup d'fufe pour la route ? -+-
j'ai loupé un truc où un moment tu cause d'architecture AMD64 et l'autre, EMT64 (ia64 j'imagine) ?
em64t est le nom donné par Intel aux extensions compatibles amd64 qu'ils ont ajouté aux P4 et Xeon.
Il me semble que sur la 5.4/amd64, les optimisations sse, sse2, etc.. étaient désactivées car pas très stables sur le gcc 3.4.x livré avec, peut être une piste a voir ?
Ben, à la base, il vaut mieux éviter de toucher aux CFLAGS à moins de savoir vraiment ce que l'on fait.
-- Salut, Je ne reçoit plus de messages de la mailing-list des nordistes. -+- SG in: GNU - Un ch'ti coup d'fufe pour la route ? -+-
F. Senault
F. Senault wrote:
Des variables particulières dans make.conf ? Idem pour le kernel - quelles sont les options actives ? C'est reproductible avec GENERIC ?
Hello,
En effet, il y a de ca;
Je viens de recompiler le monde sans les flags C que j'avais modifiés dans /etc/make.conf, et là, la phase de connexion SSH passe sans problème. Néanmoins, je me fais kicker après quelques minutes d'activités sur cette connexion ssh avec les mêmes messages d'erreurs du buffer_get_ret.
Au fait, question suivant. C'est une idée, ou tu utilises le port ssh2-nox11 ? Il y a quelque chose dans le serveur ssh du système de base qui ne convient pas ?
Pour info j'ai(avais) comme flags: CPUTYPE?=nocona (car bi-proc xeon (EMT64))
Xeon ou amd64 ?
CFLAGS= -O2 -pipe
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas une bonne idée ?
Devrait pas être un problème. Par contre, la confusion au niveau des archis, clairement, c'est moins idéal.
Arnaud.
Fred -- Lecturer: Is there some problem down the back? Zen-Master Greg: There is no problem. L: Then what was that noise? ZMG: Problem resolution. (http://www.guild.uwa.edu.au/users/greg/)
F. Senault wrote:
Des variables particulières dans make.conf ? Idem pour le kernel -
quelles sont les options actives ? C'est reproductible avec GENERIC ?
Hello,
En effet, il y a de ca;
Je viens de recompiler le monde sans les flags C que j'avais modifiés
dans /etc/make.conf, et là, la phase de connexion SSH passe sans problème.
Néanmoins, je me fais kicker après quelques minutes d'activités sur
cette connexion ssh avec les mêmes messages d'erreurs du buffer_get_ret.
Au fait, question suivant. C'est une idée, ou tu utilises le port
ssh2-nox11 ? Il y a quelque chose dans le serveur ssh du système de
base qui ne convient pas ?
Pour info j'ai(avais) comme flags:
CPUTYPE?=nocona (car bi-proc xeon (EMT64))
Xeon ou amd64 ?
CFLAGS= -O2 -pipe
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas
une bonne idée ?
Devrait pas être un problème. Par contre, la confusion au niveau des
archis, clairement, c'est moins idéal.
Arnaud.
Fred
--
Lecturer: Is there some problem down the back?
Zen-Master Greg: There is no problem.
L: Then what was that noise?
ZMG: Problem resolution. (http://www.guild.uwa.edu.au/users/greg/)
Des variables particulières dans make.conf ? Idem pour le kernel - quelles sont les options actives ? C'est reproductible avec GENERIC ?
Hello,
En effet, il y a de ca;
Je viens de recompiler le monde sans les flags C que j'avais modifiés dans /etc/make.conf, et là, la phase de connexion SSH passe sans problème. Néanmoins, je me fais kicker après quelques minutes d'activités sur cette connexion ssh avec les mêmes messages d'erreurs du buffer_get_ret.
Au fait, question suivant. C'est une idée, ou tu utilises le port ssh2-nox11 ? Il y a quelque chose dans le serveur ssh du système de base qui ne convient pas ?
Pour info j'ai(avais) comme flags: CPUTYPE?=nocona (car bi-proc xeon (EMT64))
Xeon ou amd64 ?
CFLAGS= -O2 -pipe
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas une bonne idée ?
Devrait pas être un problème. Par contre, la confusion au niveau des archis, clairement, c'est moins idéal.
Arnaud.
Fred -- Lecturer: Is there some problem down the back? Zen-Master Greg: There is no problem. L: Then what was that noise? ZMG: Problem resolution. (http://www.guild.uwa.edu.au/users/greg/)
F. Senault
Machin Chose writes:
j'ai loupé un truc où un moment tu cause d'architecture AMD64 et l'autre, EMT64 (ia64 j'imagine) ?
em64t est le nom donné par Intel aux extensions compatibles amd64 qu'ils ont ajouté aux P4 et Xeon.
Mais mettre une version amd64 sur un intel emt64, ce n'est pas un peu osé ?
Fred -- Don't these people watch Jackie Chan movies? *Everything*'s a weapon! Next thing, they'll ban ballpoint pens, 'coz you can stab somebody with them. Or laptops, because you could force someone to install Windows 3.1. With a ballpoint pen, presumably. (Eric The Read in the SDM)
Machin Chose <utilisateur@exemple.fr> writes:
j'ai loupé un truc où un moment tu cause d'architecture AMD64 et
l'autre, EMT64 (ia64 j'imagine) ?
em64t est le nom donné par Intel aux extensions compatibles amd64 qu'ils
ont ajouté aux P4 et Xeon.
Mais mettre une version amd64 sur un intel emt64, ce n'est pas un peu
osé ?
Fred
--
Don't these people watch Jackie Chan movies? *Everything*'s a weapon!
Next thing, they'll ban ballpoint pens, 'coz you can stab somebody with
them. Or laptops, because you could force someone to install Windows
3.1. With a ballpoint pen, presumably. (Eric The Read in the SDM)
j'ai loupé un truc où un moment tu cause d'architecture AMD64 et l'autre, EMT64 (ia64 j'imagine) ?
em64t est le nom donné par Intel aux extensions compatibles amd64 qu'ils ont ajouté aux P4 et Xeon.
Mais mettre une version amd64 sur un intel emt64, ce n'est pas un peu osé ?
Fred -- Don't these people watch Jackie Chan movies? *Everything*'s a weapon! Next thing, they'll ban ballpoint pens, 'coz you can stab somebody with them. Or laptops, because you could force someone to install Windows 3.1. With a ballpoint pen, presumably. (Eric The Read in the SDM)
Eric Masson
"F. Senault" writes:
Mais mettre une version amd64 sur un intel emt64, ce n'est pas un peu osé ?
Euh, tu trolles ? http://www.freebsd.org/releases/6.0R/hardware-amd64.html#PROC
Éric
-- Il n'est pas question de modération !!! Les gens ont à se prononcer sur les caractéristiques d'une robot-modération -+- BC in Guide du Neuneu Usenet - C'est robot pour être vrai -+-
"F. Senault" <fred@lacave.net> writes:
Mais mettre une version amd64 sur un intel emt64, ce n'est pas un peu
osé ?
Euh, tu trolles ?
http://www.freebsd.org/releases/6.0R/hardware-amd64.html#PROC
Éric
--
Il n'est pas question de modération !!!
Les gens ont à se prononcer sur les caractéristiques d'une
robot-modération
-+- BC in Guide du Neuneu Usenet - C'est robot pour être vrai -+-
Mais mettre une version amd64 sur un intel emt64, ce n'est pas un peu osé ?
Euh, tu trolles ? http://www.freebsd.org/releases/6.0R/hardware-amd64.html#PROC
Éric
-- Il n'est pas question de modération !!! Les gens ont à se prononcer sur les caractéristiques d'une robot-modération -+- BC in Guide du Neuneu Usenet - C'est robot pour être vrai -+-
F. Senault
"F. Senault" writes:
Mais mettre une version amd64 sur un intel emt64, ce n'est pas un peu osé ?
Euh, tu trolles ? http://www.freebsd.org/releases/6.0R/hardware-amd64.html#PROC
Non, non, c'était pure ignorance.
C'est pas comme si j'avais les budgets pour du matos aussi moderne, aussi, 'faut dire... :/
Éric
Fred -- Feel the bile rising From your guilty past With your nerves in tatters As the cockleshell shatters And the hammers batter Down your door /You better run !/ (Pink Floyd, Run Like Hell)
"F. Senault" <fred@lacave.net> writes:
Mais mettre une version amd64 sur un intel emt64, ce n'est pas un peu
osé ?
Euh, tu trolles ?
http://www.freebsd.org/releases/6.0R/hardware-amd64.html#PROC
Non, non, c'était pure ignorance.
C'est pas comme si j'avais les budgets pour du matos aussi moderne,
aussi, 'faut dire... :/
Éric
Fred
--
Feel the bile rising From your guilty past
With your nerves in tatters As the cockleshell shatters
And the hammers batter Down your door
/You better run !/ (Pink Floyd, Run Like Hell)
Mais mettre une version amd64 sur un intel emt64, ce n'est pas un peu osé ?
Euh, tu trolles ? http://www.freebsd.org/releases/6.0R/hardware-amd64.html#PROC
Non, non, c'était pure ignorance.
C'est pas comme si j'avais les budgets pour du matos aussi moderne, aussi, 'faut dire... :/
Éric
Fred -- Feel the bile rising From your guilty past With your nerves in tatters As the cockleshell shatters And the hammers batter Down your door /You better run !/ (Pink Floyd, Run Like Hell)
Eric Masson
"F. Senault" writes:
Non, non, c'était pure ignorance.
Désolé, vu que tu es développeur, je pensais que tu avais accès à ce type de matos.
C'est pas comme si j'avais les budgets pour du matos aussi moderne, aussi, 'faut dire... :/
Ben, mon amd64 2800+ a remplacé un K6II350 qui a rendu l'âme début janvier, et en termes de budget, j'ai réussi à m'en sortir pour un peu moins de 300 ¤
Éric
-- Je profite de cet AAD pour faire un hors-sujet car je ne sais où poser la question. Je cherche un Web qui explique le mode de transcription qui permet de transcrire la plupart des alphabets en alphabet latin. -+- PG in <http://www.le-gnu.net> : transcrire la charte en neuneu -+-
"F. Senault" <fred@lacave.net> writes:
Non, non, c'était pure ignorance.
Désolé, vu que tu es développeur, je pensais que tu avais accès à ce
type de matos.
C'est pas comme si j'avais les budgets pour du matos aussi moderne,
aussi, 'faut dire... :/
Ben, mon amd64 2800+ a remplacé un K6II350 qui a rendu l'âme début
janvier, et en termes de budget, j'ai réussi à m'en sortir pour un peu
moins de 300 ¤
Éric
--
Je profite de cet AAD pour faire un hors-sujet car je ne sais où poser
la question. Je cherche un Web qui explique le mode de transcription
qui permet de transcrire la plupart des alphabets en alphabet latin.
-+- PG in <http://www.le-gnu.net> : transcrire la charte en neuneu -+-
Désolé, vu que tu es développeur, je pensais que tu avais accès à ce type de matos.
C'est pas comme si j'avais les budgets pour du matos aussi moderne, aussi, 'faut dire... :/
Ben, mon amd64 2800+ a remplacé un K6II350 qui a rendu l'âme début janvier, et en termes de budget, j'ai réussi à m'en sortir pour un peu moins de 300 ¤
Éric
-- Je profite de cet AAD pour faire un hors-sujet car je ne sais où poser la question. Je cherche un Web qui explique le mode de transcription qui permet de transcrire la plupart des alphabets en alphabet latin. -+- PG in <http://www.le-gnu.net> : transcrire la charte en neuneu -+-
Arnaud de Prelle
F. Senault wrote:
F. Senault wrote:
Des variables particulières dans make.conf ? Idem pour le kernel - quelles sont les options actives ? C'est reproductible avec GENERIC ?
Hello,
En effet, il y a de ca;
Je viens de recompiler le monde sans les flags C que j'avais modifiés dans /etc/make.conf, et là, la phase de connexion SSH passe sans problème. Néanmoins, je me fais kicker après quelques minutes d'activités sur cette connexion ssh avec les mêmes messages d'erreurs du buffer_get_ret.
Au fait, question suivant. C'est une idée, ou tu utilises le port ssh2-nox11 ? Il y a quelque chose dans le serveur ssh du système de base qui ne convient pas ?
Oui apparemment le port ssh2-nox11 doit utiliser une bib partagée provenant du système de base car les fonction buffer_get* n'apparaîssent pas dans les sources du port ssh2-nox11, en fait elle n'apparaissent selon mes greps barbares que dans /usr/src/crypto/openssh/buffer.c (l.129-l.147).
Pour info j'ai(avais) comme flags: CPUTYPE?=nocona (car bi-proc xeon (EMT64))
Xeon ou amd64 ?
C'est bien un Xeon avec les extensions 64bits donc et dont le nom de code serait bien nocona selon /usr/src/examples/etc/make.conf.
CFLAGS= -O2 -pipe
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas une bonne idée ?
Devrait pas être un problème. Par contre, la confusion au niveau des archis, clairement, c'est moins idéal.
Je crois que niveau des archis tout est bien configuré sur cette machine ;-) Cfr lien d'Eric Masson.
Pour continuer la suite des aventures, j'ai recompilé le noyau dans tous les sens (GENRIC, SMP+GENERIC, mon noyau néttoyé) et toujours mêmes genre de problèmes ...
A noter que ça diffère selon les clients utilisés ...
-) En local ca semble passer et tourner de facon satisafaisante mais usage très limité car ... en local: #ssh localhost -p 23 -l apn 's password: Last login: Fri Nov 11 2005 02:27:30 +0100 from pnserver.bsdvaul Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved.
FreeBSD 6.0-STABLE (BEPkernel) #5: Thu Nov 10 02:26:56 CET 2005
|101#
-) Sous putty (win32) message étrange après avoir envoyé le password: "Strange packet received: type XX" où X est un digit
-) Sous Navicat (win32): Gros freeze direct
-) Sous Navicat (Mac OS X): Pas de problème, ca marche bien
-) Sous le terminal Mac OS X, même problème qu'initialement: mac:~ apn$ ssh bep-pc1 -p 23 's password: buffer_get: trying to get more bytes 1 than in buffer 0 mac:~ apn$
-) Sous le terminal xterm de X11 pour Mac OS X (v1.1): même erreur que le terminal de mac os x.
Voilà où j'en suis, Très hétérogène dans les résultats et donc pas vraiment exploitable ...
J'ai bien trouvé la solution de tout faire tourner avec le SSH natif de FreeBSD où là tout fonctionne nickel en fait sauf Navicat win32 qui fait des siennes et pour lequel l'option du tunnel "local" (option de putty expliquée pour ce cas particulier à cette adresse : http://forum.textdrive.com/viewtopic.php?pidA207) arrange le problème mais pas vraiment très pratique pour un usager de base (pour ne pas dire n00b en informatique) de navicat.
Je suis preneur pour tout éclaircissement supplémentaire au problème ;-)
Arnaud.
F. Senault wrote:
F. Senault wrote:
Des variables particulières dans make.conf ? Idem pour le kernel -
quelles sont les options actives ? C'est reproductible avec GENERIC ?
Hello,
En effet, il y a de ca;
Je viens de recompiler le monde sans les flags C que j'avais modifiés
dans /etc/make.conf, et là, la phase de connexion SSH passe sans problème.
Néanmoins, je me fais kicker après quelques minutes d'activités sur
cette connexion ssh avec les mêmes messages d'erreurs du buffer_get_ret.
Au fait, question suivant. C'est une idée, ou tu utilises le port
ssh2-nox11 ? Il y a quelque chose dans le serveur ssh du système de
base qui ne convient pas ?
Oui apparemment le port ssh2-nox11 doit utiliser une bib partagée
provenant du système de base car les fonction buffer_get* n'apparaîssent
pas dans les sources du port ssh2-nox11, en fait elle n'apparaissent
selon mes greps barbares que dans /usr/src/crypto/openssh/buffer.c
(l.129-l.147).
Pour info j'ai(avais) comme flags:
CPUTYPE?=nocona (car bi-proc xeon (EMT64))
Xeon ou amd64 ?
C'est bien un Xeon avec les extensions 64bits donc et dont le nom de
code serait bien nocona selon /usr/src/examples/etc/make.conf.
CFLAGS= -O2 -pipe
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas
une bonne idée ?
Devrait pas être un problème. Par contre, la confusion au niveau des
archis, clairement, c'est moins idéal.
Je crois que niveau des archis tout est bien configuré sur cette machine
;-) Cfr lien d'Eric Masson.
Pour continuer la suite des aventures, j'ai recompilé le noyau dans tous
les sens (GENRIC, SMP+GENERIC, mon noyau néttoyé) et toujours mêmes
genre de problèmes ...
A noter que ça diffère selon les clients utilisés ...
-) En local ca semble passer et tourner de facon satisafaisante mais
usage très limité car ... en local:
#ssh localhost -p 23 -l apn
apn@localhost's password:
Last login: Fri Nov 11 2005 02:27:30 +0100 from pnserver.bsdvaul
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 6.0-STABLE (BEPkernel) #5: Thu Nov 10 02:26:56 CET 2005
apn@bep-pc1|101#
-) Sous putty (win32) message étrange après avoir envoyé le password:
"Strange packet received: type XX" où X est un digit
-) Sous Navicat (win32): Gros freeze direct
-) Sous Navicat (Mac OS X): Pas de problème, ca marche bien
-) Sous le terminal Mac OS X, même problème qu'initialement:
mac:~ apn$ ssh bep-pc1 -p 23
apn@bep-pc1's password:
buffer_get: trying to get more bytes 1 than in buffer 0
mac:~ apn$
-) Sous le terminal xterm de X11 pour Mac OS X (v1.1): même erreur que
le terminal de mac os x.
Voilà où j'en suis,
Très hétérogène dans les résultats et donc pas vraiment exploitable ...
J'ai bien trouvé la solution de tout faire tourner avec le SSH natif de
FreeBSD où là tout fonctionne nickel en fait sauf Navicat win32 qui fait
des siennes et pour lequel l'option du tunnel "local" (option de putty
expliquée pour ce cas particulier à cette adresse :
http://forum.textdrive.com/viewtopic.php?pidA207) arrange le problème
mais pas vraiment très pratique pour un usager de base (pour ne pas dire
n00b en informatique) de navicat.
Je suis preneur pour tout éclaircissement supplémentaire au problème ;-)
Des variables particulières dans make.conf ? Idem pour le kernel - quelles sont les options actives ? C'est reproductible avec GENERIC ?
Hello,
En effet, il y a de ca;
Je viens de recompiler le monde sans les flags C que j'avais modifiés dans /etc/make.conf, et là, la phase de connexion SSH passe sans problème. Néanmoins, je me fais kicker après quelques minutes d'activités sur cette connexion ssh avec les mêmes messages d'erreurs du buffer_get_ret.
Au fait, question suivant. C'est une idée, ou tu utilises le port ssh2-nox11 ? Il y a quelque chose dans le serveur ssh du système de base qui ne convient pas ?
Oui apparemment le port ssh2-nox11 doit utiliser une bib partagée provenant du système de base car les fonction buffer_get* n'apparaîssent pas dans les sources du port ssh2-nox11, en fait elle n'apparaissent selon mes greps barbares que dans /usr/src/crypto/openssh/buffer.c (l.129-l.147).
Pour info j'ai(avais) comme flags: CPUTYPE?=nocona (car bi-proc xeon (EMT64))
Xeon ou amd64 ?
C'est bien un Xeon avec les extensions 64bits donc et dont le nom de code serait bien nocona selon /usr/src/examples/etc/make.conf.
CFLAGS= -O2 -pipe
PS: Le noyau a été compilé avec l'optimisation 2, peut-être n'est pas une bonne idée ?
Devrait pas être un problème. Par contre, la confusion au niveau des archis, clairement, c'est moins idéal.
Je crois que niveau des archis tout est bien configuré sur cette machine ;-) Cfr lien d'Eric Masson.
Pour continuer la suite des aventures, j'ai recompilé le noyau dans tous les sens (GENRIC, SMP+GENERIC, mon noyau néttoyé) et toujours mêmes genre de problèmes ...
A noter que ça diffère selon les clients utilisés ...
-) En local ca semble passer et tourner de facon satisafaisante mais usage très limité car ... en local: #ssh localhost -p 23 -l apn 's password: Last login: Fri Nov 11 2005 02:27:30 +0100 from pnserver.bsdvaul Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved.
FreeBSD 6.0-STABLE (BEPkernel) #5: Thu Nov 10 02:26:56 CET 2005
|101#
-) Sous putty (win32) message étrange après avoir envoyé le password: "Strange packet received: type XX" où X est un digit
-) Sous Navicat (win32): Gros freeze direct
-) Sous Navicat (Mac OS X): Pas de problème, ca marche bien
-) Sous le terminal Mac OS X, même problème qu'initialement: mac:~ apn$ ssh bep-pc1 -p 23 's password: buffer_get: trying to get more bytes 1 than in buffer 0 mac:~ apn$
-) Sous le terminal xterm de X11 pour Mac OS X (v1.1): même erreur que le terminal de mac os x.
Voilà où j'en suis, Très hétérogène dans les résultats et donc pas vraiment exploitable ...
J'ai bien trouvé la solution de tout faire tourner avec le SSH natif de FreeBSD où là tout fonctionne nickel en fait sauf Navicat win32 qui fait des siennes et pour lequel l'option du tunnel "local" (option de putty expliquée pour ce cas particulier à cette adresse : http://forum.textdrive.com/viewtopic.php?pidA207) arrange le problème mais pas vraiment très pratique pour un usager de base (pour ne pas dire n00b en informatique) de navicat.
Je suis preneur pour tout éclaircissement supplémentaire au problème ;-)
