J'ai chang=C3=A9 de FAI hier, =C3=A7a n'a probablement rien =C3=A0 voir mai=
s y'a quand
m=C3=AAme un truc louche cot=C3=A9 r=C3=A9seau [1].
Quelques heures plus tard, mon PC s'est fig=C3=A9 (image fixe, plus de clav=
ier
ni de souris), et les logs kernel sont curieux, on dirait une mise en
veille [2].=20
Pas moyen de le red=C3=A9marrer au bouton en fa=C3=A7ade (ventilos mais pas=
l'image
habituelle du bios qui pr=C3=A9c=C3=A8de grub, =C3=A9crans noirs), il a fal=
lu couper
l'alim et red=C3=A9marrer. Au red=C3=A9marrage, j'ai comme l'impression que=
le bios
s'est remis avec ses r=C3=A9glages par d=C3=A9faut car il m'a affich=C3=A9 =
l'image du
constructeur au d=C3=A9but du d=C3=A9marrage (que j'avais pas avant).
J'ai boss=C3=A9 qq heures, puis en r=C3=A9digeant ce mail j'ai voulu faire =
un lshw
pour filer plus d'infos et il s'est de nouveau fig=C3=A9, mais sans rien ra=
conter=20
dans les logs (plantage 10 =C3=A0 20s apr=C3=A8s le lancement de `lshw -sho=
rt`, je=20
viens de relancer la commande qui r=C3=A9pond en 1~2s).
C'est une debian stretch classique, avec un 4.9.0-4-amd64, sur un vieux
coucou qui devrait f=C3=AAter bient=C3=B4t ses 10 ans, mais vu qu'il me suf=
fit 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=C3=A8s changement de box fibre et avoir r=C3=A9cup=C3=A9r=C3=A9 du r=C3=
=A9seau (en laissant
le dhcp g=C3=A9rer le fait que la connexion =C3=A9tait revenue), tout fonct=
ionnait
bien sauf github :
- git clone https://github=E2=80=A6 OK
- git clone git@github.com=E2=80=A6 KO
- commandes git sur mes d=C3=A9p=C3=B4ts locaux avec un remote sur github HS
- commandes git sur mes d=C3=A9p=C3=B4ts locaux avec un autre remote OK
- github.com via un navigateur est chaotique (coupures tcp sur la plupart d=
es
requ=C3=AAtes, login difficile, coupure syst=C3=A9matique sur les sockets=
http)
- depuis mon PC portable qui utilise la m=C3=AAme box en wifi tout =C3=A7a =
fonctionne
normalement
Apr=C3=A8s 2h =C3=A0 chercher, tent=C3=A9 un reboot, =C3=A7a n'a logiquemen=
t rien chang=C3=A9.
Modifier l'adresse mac de ma carte r=C3=A9seau non plus.
[2] logs kernel
Apr 4 03:25:43 quad kernel: [10946.508298] PM: Syncing filesystems ... don=
e.
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 ta=
sks ... (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_c=
onsole_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 dis=
abled 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 0000:01:00.0: DRM: susp=
ending console...
Apr 4 03:25:43 quad kernel: [10946.532672] nouveau 0000:01:00.0: DRM: susp=
ending display...
Apr 4 03:25:43 quad kernel: [10946.532730] nouveau 0000:01:00.0: DRM: evic=
ting 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 0000:01:00.0: DRM: wait=
ing for kernel channels to go idle...
Apr 4 03:25:43 quad kernel: [10947.677253] nouveau 0000:01:00.0: DRM: susp=
ending client object trees...
Apr 4 03:25:43 quad kernel: [10947.677759] nouveau 0000:01:00.0: DRM: susp=
ending 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 com=
plete after 0.492 msecs
Apr 4 03:25:43 quad kernel: [10949.369073] ehci-pci 0000:00:1d.7: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369107] uhci_hcd 0000:00:1d.2: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369146] uhci_hcd 0000:00:1d.1: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369183] uhci_hcd 0000:00:1d.0: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369357] ehci-pci 0000:00:1a.7: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369358] uhci_hcd 0000:00:1a.2: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369411] uhci_hcd 0000:00:1a.1: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.369426] uhci_hcd 0000:00:1a.0: System w=
akeup enabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.388047] PM: noirq suspend of devices co=
mplete 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 03:25:43 quad kernel: [10949.389640] Broke affinity for irq 16
Apr 4 03:25:43 quad kernel: [10949.389643] Broke affinity for irq 18
Apr 4 03:25:43 quad kernel: [10949.389647] Broke affinity for irq 19
Apr 4 03:25:43 quad kernel: [10949.390662] smpboot: CPU 1 is now offline
Apr 4 03:25:43 quad kernel: [10949.405114] Broke affinity for irq 16
Apr 4 03:25:43 quad kernel: [10949.405118] Broke affinity for irq 18
Apr 4 03:25:43 quad kernel: [10949.405121] Broke affinity for irq 19
Apr 4 03:25:43 quad kernel: [10949.406139] smpboot: CPU 2 is now offline
Apr 4 03:25:43 quad kernel: [10949.428756] Broke affinity for irq 16
Apr 4 03:25:43 quad kernel: [10949.428761] Broke affinity for irq 18
Apr 4 03:25:43 quad kernel: [10949.428764] Broke affinity for irq 19
Apr 4 03:25:43 quad kernel: [10949.429780] smpboot: CPU 3 is now offline
Apr 4 03:25:43 quad kernel: [10949.448219] ACPI: Low-level resume complete
Apr 4 03:25:43 quad kernel: [10949.448219] PM: Restoring platform NVS memo=
ry
Apr 4 03:25:43 quad kernel: [10949.448219] Suspended for 23415.025 seconds
Apr 4 03:25:43 quad kernel: [10949.448219] Enabling non-boot CPUs ...
Apr 4 03:25:43 quad kernel: [10949.460236] x86: Booting SMP configuration:
Apr 4 03:25:43 quad kernel: [10949.460237] smpboot: Booting Node 0 Process=
or 1 APIC 0x1
Apr 4 03:25:43 quad kernel: [10949.463266] cache: parent cpu1 should not =
be sleeping
Apr 4 03:25:43 quad kernel: [10949.463676] CPU1 is up
Apr 4 03:25:43 quad kernel: [10949.476270] smpboot: Booting Node 0 Process=
or 2 APIC 0x2
Apr 4 03:25:43 quad kernel: [10949.479317] cache: parent cpu2 should not =
be sleeping
Apr 4 03:25:43 quad kernel: [10949.479756] CPU2 is up
Apr 4 03:25:43 quad kernel: [10949.492300] smpboot: Booting Node 0 Process=
or 3 APIC 0x3
Apr 4 03:25:43 quad kernel: [10949.495346] cache: parent cpu3 should not =
be sleeping
Apr 4 03:25:43 quad kernel: [10949.495913] CPU3 is up
Apr 4 03:25:43 quad kernel: [10949.503132] ACPI: Waking up from system sle=
ep state S3
Apr 4 03:25:43 quad kernel: [10949.503632] uhci_hcd 0000:00:1a.0: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.503677] uhci_hcd 0000:00:1a.1: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.503721] uhci_hcd 0000:00:1a.2: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.503888] uhci_hcd 0000:00:1d.0: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.503907] uhci_hcd 0000:00:1d.1: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.503936] uhci_hcd 0000:00:1d.2: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.520143] ehci-pci 0000:00:1d.7: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.520250] ehci-pci 0000:00:1a.7: System w=
akeup disabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.524140] PM: noirq resume of devices com=
plete after 20.638 msecs
Apr 4 03:25:43 quad kernel: [10949.524570] PM: early resume of devices com=
plete after 0.405 msecs
Apr 4 03:25:43 quad kernel: [10949.524616] usb usb3: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524648] usb usb4: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524678] usb usb5: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524821] usb usb6: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524823] usb usb7: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524859] usb usb8: root hub lost power o=
r was reset
Apr 4 03:25:43 quad kernel: [10949.524881] nouveau 0000:01:00.0: DRM: resu=
ming kernel object tree...
Apr 4 03:25:43 quad kernel: [10949.525045] rtc_cmos 00:01: System wakeup d=
isabled by ACPI
Apr 4 03:25:43 quad kernel: [10949.525905] serial 00:06: activated
Apr 4 03:25:43 quad kernel: [10949.526788] i8042: No controller found
Apr 4 03:25:43 quad kernel: [10949.526793] dpm_run_callback(): platform_pm=
_resume+0x0/0x40 returns -19
Apr 4 03:25:43 quad kernel: [10949.526795] PM: Device i8042 failed to resu=
me: error -19
Apr 4 03:25:43 quad kernel: [10949.527415] sd 2:0:0:0: [sda] Starting disk
Apr 4 03:25:43 quad kernel: [10949.527441] sd 2:0:1:0: [sdb] Starting disk
Apr 4 03:25:43 quad kernel: [10949.691717] ata1.00: configured for UDMA/33
Apr 4 03:25:43 quad kernel: [10949.726166] nouveau 0000:01:00.0: DRM: resu=
ming client object trees...
Apr 4 03:25:43 quad kernel: [10949.726473] nouveau 0000:01:00.0: DRM: resu=
ming display...
Apr 4 03:25:43 quad kernel: [10949.764011] usb 1-1: reset high-speed USB d=
evice number 2 using ehci-pci
Apr 4 03:25:43 quad kernel: [10949.831657] nouveau 0000:01:00.0: DRM: resu=
ming console...
Apr 4 03:25:43 quad kernel: [10949.852703] ata6: SATA link down (SStatus 0=
SControl 300)
Apr 4 03:25:43 quad kernel: [10949.863288] ata5: SATA link down (SStatus 0=
SControl 300)
Apr 4 03:25:43 quad kernel: [10950.020025] usb 8-1: reset low-speed USB de=
vice number 2 using uhci_hcd
Apr 4 03:25:43 quad kernel: [10950.164789] ata4.00: SATA link down (SStatu=
s 0 SControl 300)
Apr 4 03:25:43 quad kernel: [10950.164800] ata4.01: SATA link down (SStatu=
s 0 SControl 300)
Apr 4 03:25:43 quad kernel: [10950.812023] usb 8-2: reset low-speed USB de=
vice number 3 using uhci_hcd
Apr 4 03:25:43 quad kernel: [10951.143131] PM: resume of devices complete =
after 1618.557 msecs
Apr 4 03:25:43 quad kernel: [10951.655081] PM: Finishing wakeup.
Apr 4 03:25:43 quad kernel: [10951.655082] Restarting tasks ... done.
Apr 4 03:25:44 quad kernel: [10952.684177] i8042: Can't write CTR while cl=
osing KBD port
Apr 4 03:25:45 quad kernel: [10953.195904] i8042: Can't reactivate KBD port
Apr 4 03:25:46 quad kernel: [10954.730859] i8042: Can't write CTR while cl=
osing AUX port
Apr 4 03:25:47 quad kernel: [10955.242606] i8042: Can't reactivate AUX port
Apr 4 03:25:47 quad kernel: [10955.756376] ata3.00: link is slow to respon=
d, please be patient (ready=3D0)
Apr 4 03:25:48 quad kernel: [10956.265912] i8042: Can't write CTR while cl=
osing AUX port
Apr 4 03:25:48 quad kernel: [10956.777557] i8042: Can't reactivate AUX port
Apr 4 03:25:49 quad kernel: [10958.168058] ata3.00: SATA link up 3.0 Gbps =
(SStatus 123 SControl 300)
Apr 4 03:25:49 quad kernel: [10958.168069] ata3.01: SATA link up 3.0 Gbps =
(SStatus 123 SControl 300)
Apr 4 03:25:49 quad kernel: [10958.170368] ata3.01: ACPI cmd ef/03:45:00:0=
0:00:b0 (SET FEATURES) filtered out
Apr 4 03:25:49 quad kernel: [10958.170371] ata3.01: ACPI cmd ef/03:0c:00:0=
0:00:b0 (SET FEATURES) filtered out
Apr 4 03:25:49 quad kernel: [10958.364702] ata3.01: ACPI cmd c6/00:10:00:0=
0:00:b0 (SET MULTIPLE MODE) succeeded
Apr 4 03:25:49 quad kernel: [10958.364704] ata3.01: ACPI cmd f5/00:00:00:0=
0:00:00 (SECURITY FREEZE LOCK) filtered out
Apr 4 03:25:49 quad kernel: [10958.369384] ata3.00: ACPI cmd ef/03:45:00:0=
0:00:a0 (SET FEATURES) filtered out
Apr 4 03:25:49 quad kernel: [10958.369386] ata3.00: ACPI cmd ef/03:0c:00:0=
0:00:a0 (SET FEATURES) filtered out
Apr 4 03:25:49 quad kernel: [10958.369452] ata3.00: ACPI cmd c6/00:10:00:0=
0:00:a0 (SET MULTIPLE MODE) succeeded
Apr 4 03:25:49 quad kernel: [10958.369455] ata3.00: ACPI cmd f5/00:00:00:0=
0:00:00 (SECURITY FREEZE LOCK) filtered out
Apr 4 03:25:49 quad kernel: [10958.371788] ata3.00: supports DRM functions=
and may not be fully accessible
Apr 4 03:25:49 quad kernel: [10958.377501] ata3.00: supports DRM functions=
and may not be fully accessible
Apr 4 03:25:49 quad kernel: [10958.380793] ata3.00: configured for UDMA/133
Apr 4 03:25:49 quad kernel: [10958.383291] ata3.01: configured for UDMA/133
Apr 4 03:25:49 quad kernel: [10958.441362] ata3.00: Enabling discard_zeroe=
s_data
Apr 4 03:25:50 quad kernel: [10958.556420] ata3.00: Enabling discard_zeroe=
s_data
Apr 4 03:25:50 quad kernel: [10958.626025] IPv6: ADDRCONF(NETDEV_UP): eth1=
: link is not ready
Apr 4 03:25:50 quad kernel: [10958.664130] IPv6: ADDRCONF(NETDEV_UP): eth1=
: link is not ready
Apr 4 03:25:52 quad kernel: [10961.338324] ATL1E 0000:02:00.0 eth1: NIC Li=
nk is Up <1000 Mbps Full Duplex>
Apr 4 03:25:52 quad kernel: [10961.338339] IPv6: ADDRCONF(NETDEV_CHANGE): =
eth1: link becomes ready
Apr 4 03:25:52 quad kernel: [10961.368834] IPv6: ADDRCONF(NETDEV_UP): eth1=
: link is not ready
Apr 4 03:25:52 quad kernel: [10961.369000] ATL1E 0000:02:00.0 eth1: NIC Li=
nk is Up <1000 Mbps Full Duplex>
Apr 4 03:25:52 quad kernel: [10961.369013] IPv6: ADDRCONF(NETDEV_CHANGE): =
eth1: link becomes ready
(ensuite c'est le boot)
--=20
Daniel
L'id=C3=A9e d'une arm=C3=A9e europ=C3=A9enne est vraiment int=C3=A9ressante,
mais pourquoi ne pas aller plus loin en cr=C3=A9ant une arm=C3=A9e
mondiale dont le principal int=C3=A9r=C3=AAt serait qu'elle n'aurait=20
pas d'ennemis.
Philippe Geluck, Le chat
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
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...
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
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
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 … 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
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
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 git@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.
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
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 … 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
BERTRAND Jo=c3=abl
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
Daniel Caillibaud a écrit :
Le 04/04/18 à 08:35, Daniel Caillibaud <ml@lairdutemps.org> 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.
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
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)
Le 09/04/18 à 18:45, BERTRAND Joël <joel.bertrand@systella.fr> 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)
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)
BERTRAND Jo=c3=abl
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
Daniel Caillibaud a écrit :
Le 09/04/18 à 18:45, BERTRAND Joël <joel.bertrand@systella.fr> 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 ?
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
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
Le 09/04/18 à 19:45, BERTRAND Joël <joel.bertrand@systella.fr> 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
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
BERTRAND Jo=c3=abl
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 AAAA sur une machine sans IPv6. Bien cordialement, JKB
Daniel Caillibaud a écrit :
Le 09/04/18 à 19:45, BERTRAND Joël <joel.bertrand@systella.fr> 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 AAAA sur une machine sans IPv6.
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 AAAA sur une machine sans IPv6. Bien cordialement, JKB
Eric Degenetais
--001a114da546ff4bea05697ad278 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le 10 avril 2018 à 08:47, BERTRAND Joël r> a écrit :
Même pour la résolution de nom ?
Surtout lié à un changement de FAI... j'ai désactivé IP V6 sur mes systèmes linux pendant plusieurs années parce que ma f... box ne gérait pa s 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 m ur. Ça a pu s'améliorer ... ou pas en fonction des FAI. ______________ Éric Dégenètais --001a114da546ff4bea05697ad278 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="ltr"><div><div>Le 10 avril 2018 à 08:47, BERTRAND Joë l <<a href="mailto:"> r</a>> a écrit :<br>> Même pour la résolution de nom ?<br></div>Surtout lié à un changement de FAI... j'ai désactivé IPV6 sur mes systèmes linux pe ndant plusieurs années parce que ma f... box ne gérait pas correc tement le protocole de transition IPV4/IPV6, donc si pas de bol la rép onse de la requête IPV6 arrivait en premier je me prenais le mur.<br>< /div>Ça a pu s'améliorer ... ou pas en fonction des FAI.<br>< div><div><div>______________<br>Éric Dégenètais<br></div></d iv></div></div> --001a114da546ff4bea05697ad278--
Le 10 avril 2018 à 08:47, BERTRAND Joël <joel.bertrand@systella.f r> a écrit
:
Même pour la résolution de nom ?
Surtout lié à un changement de FAI... j'ai désactivé IP V6 sur mes systèmes
linux pendant plusieurs années parce que ma f... box ne gérait pa s
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 m ur.
Ça a pu s'améliorer ... ou pas en fonction des FAI.
______________
Éric Dégenètais
<div dir="ltr"><div><div>Le 10 avril 2018 à 08:47, BERTRAND Joë l <<a href="mailto:joel.bertrand@systella.fr">joel.bertrand@systella.f r</a>> a écrit :<br>> Même pour la résolution de nom ?<br></div>Surtout lié à un changement de FAI... j'ai désactivé IPV6 sur mes systèmes linux pe ndant plusieurs années parce que ma f... box ne gérait pas correc tement le protocole de transition IPV4/IPV6, donc si pas de bol la rép onse de la requête IPV6 arrivait en premier je me prenais le mur.<br>< /div>Ça a pu s'améliorer ... ou pas en fonction des FAI.<br>< div><div><div>______________<br>Éric Dégenètais<br></div></d iv></div></div>
--001a114da546ff4bea05697ad278 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Le 10 avril 2018 à 08:47, BERTRAND Joël r> a écrit :
Même pour la résolution de nom ?
Surtout lié à un changement de FAI... j'ai désactivé IP V6 sur mes systèmes linux pendant plusieurs années parce que ma f... box ne gérait pa s 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 m ur. Ça a pu s'améliorer ... ou pas en fonction des FAI. ______________ Éric Dégenètais --001a114da546ff4bea05697ad278 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir="ltr"><div><div>Le 10 avril 2018 à 08:47, BERTRAND Joë l <<a href="mailto:"> r</a>> a écrit :<br>> Même pour la résolution de nom ?<br></div>Surtout lié à un changement de FAI... j'ai désactivé IPV6 sur mes systèmes linux pe ndant plusieurs années parce que ma f... box ne gérait pas correc tement le protocole de transition IPV4/IPV6, donc si pas de bol la rép onse de la requête IPV6 arrivait en premier je me prenais le mur.<br>< /div>Ça a pu s'améliorer ... ou pas en fonction des FAI.<br>< div><div><div>______________<br>Éric Dégenètais<br></div></d iv></div></div> --001a114da546ff4bea05697ad278--
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 fr> 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 pa ssant -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 res olver BJ> renvoyaient une réponse AAAA 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 d hcp 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 commen cer par regarder ça si un truc qui ressemble se produit). -- Daniel Il vaut mieux être saoul que con, ça dure moins longtemps. Dicton Breton
Le 10/04/18 à 10:47, BERTRAND Joël <joel.bertrand@systella.fr> a écrit :
BJ> Daniel Caillibaud a écrit :
BJ> > Le 09/04/18 à 19:45, BERTRAND Joël <joel.bertrand@systella. fr> 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 pa ssant -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 res olver
BJ> renvoyaient une réponse AAAA 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 d hcp
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 commen cer
par regarder ça si un truc qui ressemble se produit).
--
Daniel
Il vaut mieux être saoul que con, ça dure moins longtemps.
Dicton Breton
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 fr> 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 pa ssant -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 res olver BJ> renvoyaient une réponse AAAA 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 d hcp 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 commen cer par regarder ça si un truc qui ressemble se produit). -- Daniel Il vaut mieux être saoul que con, ça dure moins longtemps. Dicton Breton
BERTRAND Jo=c3=abl
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 AAAA 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
Daniel Caillibaud a écrit :
Le 10/04/18 à 10:47, BERTRAND Joël <joel.bertrand@systella.fr> a écrit :
BJ> Daniel Caillibaud a écrit :
BJ> > Le 09/04/18 à 19:45, BERTRAND Joël <joel.bertrand@systella.fr> 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 AAAA 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.
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 AAAA 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
