Comment déboguer la mise en réseau Linux: adresse déjà utilisée


10

J'ai une boîte Linux Slackware où je ne peux démarrer aucun service qui écoute sur un port particulier sur localhost. En utilisant strace, j'ai découvert que l'erreur se produit lors de l' bind()appel, et l'erreur est EADDRINUSE (Address already in use):

bind(3, {sa_family=AF_INET, sin_port=htons(874), sin_addr=inet_addr("127.0.0.1")}, 16) = -1 EADDRINUSE (Address already in use)

Cela se produit avec n'importe quel processus que j'essaie de commencer à écouter sur ce port, il n'est donc pas lié au processus lui-même. La sortie de strace ci-dessus provient de la commande strace -ff nc -l -p 874 -s 127.0.0.1.

Donc, cela suggère qu'il existe déjà un processus d'écoute sur le port localhost 874. Cependant, je n'arrive pas à le trouver. Les commandes suivantes ne renvoient toutes rien:

netstat -aplunt | grep :874
netstat -na | grep :874
lsof -i :874
lsof -i tcp | grep 874
fuser 874/tcp
socklist | grep 874
iptables -t filter -S | grep 874
iptables -t nat -S | grep 874
iptables -t mangle -S | grep 874
conntrack -L | grep 874

Si j'essaie d'écouter, 0.0.0.0:874il échoue avec la même erreur. L'écoute sur l'une des adresses IP configurées sur un nic fonctionne correctement, et l'écoute 127.0.0.2:874fonctionne également correctement. L'écoute sur un autre port fonctionne bien, également sur 127.0.0.1ou 0.0.0.0.

Donc, maintenant je suis curieux. Comment savoir pourquoi la pile réseau renvoie EADDRINUSE ici? Quelles autres choses pourrais-je regarder ou quelles autres commandes puis-je exécuter pour obtenir plus d'informations?

Information additionnelle:

  • Noyau 4.1.31.
  • Selinux n'est pas utilisé ici.
  • La tentative de connexion à 127.0.0.1 avec telnet renvoie "Connexion refusée"
  • J'exécute les commandes en tant que root

1
Le port est-il mentionné quelque part dans la iptables -Ssortie?
hertitu

1
Pouvez-vous également imprimer la sortie de strace -ff nc -l 874 également, celui que vous avez utilisé tente de se connecter avec 874 comme port source. Merci!
Anirudh Malhotra

2
AFAIK Linux nécessite des privilèges root lors de l'écoute d'un port <1000. C'est peut-être le problème ici.
Koraktor

2
Cet hôte est-il un client NFS? Il peut utiliser le port source 874 pour un montage NFS. Quoi qu'il en soit, j'essaierais netstat -na | grep 874au cas où vos netstatdrapeaux actuels seraient trop restrictifs.
Tom Shaw du

1
@TomShaw Vous venez de faire ma journée! C'était bien NFS . Je ne sais pas exactement comment cela s'est produit, mais après avoir démonté tous les montages NFS et redémarré les services RPC et NFS, le problème a disparu. Avec tcpdump, j'ai également vu du trafic du port 874 au port 111 (pourquoi n'y ai-je pas pensé auparavant), ce qui le confirme. Pouvez-vous poster ceci comme réponse s'il vous plaît?
roelvanmeer

Réponses:


4

Si votre hôte est un client NFS, il peut utiliser le port source 874 pour un montage NFS. Je soupçonne que parce que la connexion ne provient pas de l'espace utilisateur, elle peut ne pas être visible pour les outils que vous avez utilisés jusqu'à présent.

Considérez l'un des éléments suivants:

  • Ajustez les sysctls sunrpc.min_resvportet sunrpc.max_resvport(par défaut 665 et 1023) pour changer la plage de ports source que le client NFS utilise
  • Utilisez un port d'écoute en dehors de cette plage
  • Utilisez l' noresvportoption sur le montage NFS pour utiliser la plage non privilégiée (peut avoir des implications sur la sécurité)
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.