nmap laisse port TCP ouvert avec noyau 5.4.72

Le
Christophe PEREZ
[pas sÍ»r que le titre soit le plus adéquat]

Bonjour,

Depuis quelques temps, en fait depuis mon passage d'un noyau 5.4.60-gentoo
Í  un noyau 5.4.72-gentoo, j'ai un bizarrerie dont je ne trouve ni cause
ni explication, mais surtout, qu'il m'est très expliqué d'expliquer Í  mon
ami google pour qu'il m'aide Í  trouver une solution.
J'explique la situation :
Sur chaque machine de mon réseau tourne un service gkrellmd, avec la
config par défaut sous Gentoo (port 19150 etc)
Sur ma machine de travail, je lance un gkrellm -s machine_distante pour
monitorer tout ça.
Et comme j'ai voulu automatiser tout ça, j'ai fait un script, avec une
boucle temporisée, qui se charge de vérifier les machines accessibles
parmi une liste définie, pour lesquelles gkrellmd est lancé, et dans ce
cas, lance le gkrellm -s $machine.
Dans mes tests, en plus d'un ping, j'utilise
nmap -n -sT -p 19150 $machine
dont je vérifie la sortie pour savoir si le port est ouvert.
Ce script fonctionne de la sorte depuis plusieurs années, sans aucun
problème. Donc, Í  priori, le script en lui même n'est pas en cause.

Or, il s'avère que pour toutes ces machines clientes (serveur gkrellmd),
depuis qu'elles sont passées en noyau 5.4.72 (qui est la version stable
actuelle chez gentoo), le simple fait de lancer ce nmap au préalable,
"plante" le gkrellm derrière.
Je m'explique :
Si en terminal je me contente de lancer gkrellm -s machine_distante, je
peux le faire, autant de fois que je veux, tout fonctionne, bien que j'ai
un message d'erreur :
Thu Nov 12 13:52:31 2020 Name com.canonical.AppMenu.Registrar does not
exist on the session bus
A chaque fois que cela fonctionne, j'ai ce message d'erreur.

Mais si je lance au préalable un simple nmap -n -sT -p 19150
machine_distante, je n'ai pas de message d'erreur, et aucun affichage
gkrellm, bien que le processus tourne.
Et lÍ , je peux tenter autant de fois que je veux, ça ne fonctionnera
jamais, jusqu'Í  ce que je relance le service gkrellmd.

J'ai même l'impression qu'il y a une notion de durée d'indisponibilité
qui augmente, parce que j'ai testé de :
- lancer nmap, d'attendre 10sec, de lancer gkrellm, ça fonctionne.
- la même Í  5sec, fonctionne aussi
- la même Í  3sec, ne fonctionne pas (je relance le service)
- refaire Í  5sec, ne fonctionne toujours pas (je relance le service)
- refaire Í  10sec, toujours pas (je relance le service)
- et après toutes ces tentatives infructueuses, j'ai relancé le service,
et après plusieurs minutes, j'ai enfin pu m'y connecter.

Sur 2 machines, j'ai mis un noyau dit instable (au sens gentoo) 5.8.16,
et le problème ne se pose plus, avec aucune des 2 machines.

Il m'est évidemment très compliqué d'étudier tous les changelog entre les
version 5.4.60 et 5.4.72 pour savoir ce qui est apparu qui pourrait
générer ce défaut, ou encore entre 5.4.72 et 5.8.16 pour savoir ce qui a
changé pour que ça retombe en marche.

J'ai bien voulu essayer d'autres options nmap puisque ça serait la cause,
mais il est évidemment exclu d'être obligé de l'utiliser en root juste
pour ça.
Mais si je lance au préalable en root, un nmap -n -sS -p 19150, puis le
gkrellm en user, aucun problème.
Donc, l'option -sT de nmap ouvre une connexion TCP, qui, avec ce noyau,
n'est pas refermée.
Mais comment transposer ça en requête google ?

Ou alors, si vous avez une proposition Í  me faire pour vérifier
l'ouverture d'un port distant avec un outil de base linux, je suis
preneur.

Merci de m'avoir lu, et de me pardonner les approximations techniques.
Evidemment, si besoin, je peux compléter mes explications, même si j'ai
tenté de tout dire.
  • Partager ce contenu :
Vos réponses
Trier par : date / pertinence
Christophe PEREZ
Le #26559573
Le Thu, 12 Nov 2020 18:32:01 +0000, Christophe PEREZ a écrit :
mais il est évidemment exclu d'être obligé de l'utiliser en root juste
pour ça.

Quoi que...
Après réflexion, c'est peut-être l'option la plus naturelle et la plus
simple.
Matt
Le #26559581
On jeu. 12 novembre 2020 (19:32),
Christophe PEREZ
Bonjour,

Hallo,
Ou alors, si vous avez une proposition Í  me faire pour vérifier
l'ouverture d'un port distant avec un outil de base linux, je suis
preneur.

Normalement nc(1) (netcat) doit être inclus (sur FreeBSD et NetBSD
mais aussi Darwin/Mac OS X) :
#v+
% nc -z <ip> <port>
#v-
hth
--
MoK: vous savez que flagellation sans lag ca fait fellation ?
* bashfr.org
Christophe PEREZ
Le #26559589
Le Thu, 12 Nov 2020 20:44:07 +0000, Matt a écrit :
Normalement nc(1) (netcat) doit être inclus (sur FreeBSD et NetBSD mais
aussi Darwin/Mac OS X) :

Mais pas sur Gentoo Linux :
$ which nc
which: no nc in (/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/
bin:/opt/bin:/usr/lib/llvm/10/bin:/usr/lib/llvm/9/bin
Merci quand même.
Christophe PEREZ
Le #26559591
Le Thu, 12 Nov 2020 22:14:26 +0000, Christophe PEREZ a écrit :
Normalement nc(1) (netcat) doit être inclus (sur FreeBSD et NetBSD mais
aussi Darwin/Mac OS X) :

Mais pas sur Gentoo Linux :
$ which nc which: no nc in
(/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/
bin:/opt/bin:/usr/lib/llvm/10/bin:/usr/lib/llvm/9/bin

Mais, je m'en fiche, puisque je n'ai nmap sur cette machine que pour ce
scan, donc je remplace par netcat, et c'est réglé.
Merci !
Jo Engo
Le #26559715
Le Thu, 12 Nov 2020 22:14:26 +0000, Christophe PEREZ a écrit :
Mais pas sur Gentoo Linux :

Chez debian :
man nc
NC(1) General Commands Manual NC(1)
NAME
nc - TCP/IP swiss army knife

--
SPROTCH !
P : Non, y a rien de plus immonde que de chier sur la moquette...
M : Pas d'accord... A pire... Chier sous la moquette...
H : ?!!
Poster une réponse
Anonyme