Error: permission denied on key 'net.ipv4.route.flush'

Support Debian
#1

Hello,

Je travaillais mes rules, quand je me suis aperçu que j’obtenais ceci :

root@Monstre:/proc/sys/net/ipv4# sysctl -a | grep flush
vm.nr_pdflush_threads = 2
error: permission denied on key 'net.ipv4.route.flush’
error: permission denied on key 'net.ipv6.route.flush’
root@Monstre:/proc/sys/net/ipv4#

La seule chose que j’ai faite, pour l’instant, c’est de modifier mon ip_forward et de le recharger avec le sysctl, et de créer / supprimer des routes (actuellement, les routes sont telles qu’elles étaient initialement).

En vérifiant sur une autre machine, je ne vois pas de type de problème.
Pour l’instant je ne vois pas non plus d’impact, mais le message me laisse imaginer que cela est en relation avec le cache des tables, qu’apparememnt, je devrais pouvoir vider.
J’ai essayer un “ip route flush cache” mais le message d’erreur est tjs là.

Sur l’autre machine, que j’ai regardé pour comparaison, le fichier “flush” est le même : mêmes configuration des droits, notamment.

Du coup :
-Dans quel cas de figure, cela vaut-il la peine de vider ce cache ? (je n’en vois pas bien la raison, à priori, car l’ajout d’une route est immédiat)
-Et par dessus tout : sauriez vous ce qui provoque ce fameux message, quel pourrait en être l’impact et si je dois le solutionner ?
error: permission denied on key ‘net.ipv6.route.flush’

Ca fait une plombe :slightly_smiling: que je regarde sur la toile et je n’ai rien croisé de très parlant, quand à ce message.

Amicalement,
Chris

#2

net.ipv4.route.flush et net.ipv6.route.flush sont en écriture seule, ce que montre

$ ls -l /proc/sys/net/ipv4/route/flush --w------- 1 root root 0 Oct 20 15:51 /proc/sys/net/ipv4/route/flush

Quelles versions de noyau sur les deux machines ?
Selon la version du noyau, le message d’erreur diffère légèrement quand on essaie de lire ces paramètres :

  • 2.4.37 : error: “Invalid argument” reading key “net.ipv4.route.flush”
  • 2.6.20 : error: operation not permited reading key ‘net.ipv4.route.flush’
  • 2.6.24 : error: permission denied on key ‘net.ipv4.route.flush’

Avec un noyau 2.4.37, ls rapporte que /proc/sys/net/ipv4/route/flush a les attributs ‘r’ mais une tentative de lecture se solde néanmoins par l’erreur citée ci-dessus car de toute façon il n’y a rien à lire.

Bref, rien d’anormal dans ce message.

Il peut être nécessaire de vider le cache de routage quand on fait du routage avancé avec des règles (ip rule) pour que les modifications soient prises en compte immédiatement. C’est inutile si on ne fait qu’ajouter ou supprimer des routes dans la table de routage normale.

#3

Salut Pascal,

Oui j’ai aussi vérifié ça - le fait qu’il soit en écriture - mais sur l’autre machine c’était le cas aussi et je n’avais pas ce type de message (dans les deux cas, j’étais connecté en root, soit dit en passant).

Autrement :

uname -a

Linux Monstre 2.6.24-etchnhalf.1-amd64 #1 SMP Mon Jul 21 10:36:02 UTC 2008 x86_64 GNU/Linux

4# cat /proc/sys/net/ipv4/route/flush
cat: /proc/sys/net/ipv4/route/flush: Permission non accordée
(le résultat correspond en effet à ce que tu me décris)

Je dois supposer que si cela dépends de la version du noyau, il y a des versions qui ne renvoie pas de message (vu que ce n’était pas le cas sur l’autre bécane).

Donc :
“Il peut être nécessaire de vider le cache de routage quand on fait du routage avancé avec des règles (ip rule) pour que les modifications soient prises en compte immédiatement. C’est inutile si on ne fait qu’ajouter ou supprimer des routes dans la table de routage normale.”

Tu veux dire : faire un “ip rule flush” ?

Je dois t’avouer que je ne connais que la table de routage, que l’on voit via un “route -n”. Je ne comprends pas trop, là.

Danke, en tout cas!

Rgs,
Chris

#4

Par curiosité, quelle est la version du noyau de “l’autre bécane” ?

Vider le cache de routage IPv4 se fait avec “ip route flush cache” ou en écrivant dans net.ipv4.route.flush.

“route -n” (ou “ip route”) n’affiche que la table de routage principale (“main”). Il y en a d’autres, 256 en tout. Notamment la table “local”, qui contient les routes pour les destinations locales et broadcast. Les autres tables sont utilisables pour faire du routage avancé en relation avec des règles de routage (ip rule). Une règle de routage permet de spécifier la table de routage à appliquer à un paquet s’il correspond à certains critères : adresse source, adresse destination, interface d’entrée, marque posée par iptables… Voir la page de manuel de la commande “ip” et le LARTC (Linux Advanced Routing and Traffic Control) howto.

#5

Hello,

ip route flush cache

sysctl -a | grep flush

vm.nr_pdflush_threads = 2
error: permission denied on key 'net.ipv4.route.flush’
error: permission denied on key 'net.ipv6.route.flush’
root@Monstre:/home/vsftpd#

“L’autre” était une machine virtuelle :

uname -a

Kernel : 2.6.9-89.0.3.EL
x86_64 x86_64 x86_64 GNU/Linux

Mais bon, le problème doit se manifester quand on fait une modif’ dans la table, ce que je n’avais pas fait, en l’occurence (ce que je viens de réaliser). Il doit donc être normal de ne pas avoir eu ce message.

Quand tu dis “écrire”, est-ce à dire que ce fichier flush devrait être “vidé”, après avoir lancé la commande “ip route flush cache” ? Dans ce cas, je suppose que, le fichier étant en “write”, le message n’a pour effet que de m’indiquer que je ne peux pas lire le fichier, ce qui ne veut pas dire qu’il n’a pas été vidé, notamment. S’il était positionné sur rw-, je n’aurais donc pas ce message, finalement.

Pour résumer :

  • Supposons que je fasse une modification de route (Disons que j’en ajoute une).
    Je suis supposer appliquer un “route add” (jusque là, ok).

-si je modifie mon fichier ip_forward pour faire du routage (le positionner sur 1), je dois faire un “sysctl -p” pour que le kernel en tienne compte (a priori, jusque là, ok).

  • Si je modifie la table de routage - la main - suis-je supposé systématiquement vider ledit cache (ip route flush cache) pour que les modifications soit prisent en compte ? Et si c’est le cas, supposons qu’une machine n’ait pas le paquetage iproute2 : dans cette situation, laisse-moi deviner, la solution alternative serait de rebooter la machine ?

Je suis en train de regarder pour la commande IP. Il y a bcp de choses, visiblement.

Amicalement,
Chris

#6

[quote=“sonador”][code]# ip route flush cache

sysctl -a | grep flush

vm.nr_pdflush_threads = 2
error: permission denied on key 'net.ipv4.route.flush’
error: permission denied on key ‘net.ipv6.route.flush’[/code][/quote]
Que cherches-tu à montrer ? Il n’y a aucun rapport entre les deux commandes. Quoi que tu fasses avant, pendant ou après, on ne peut pas lire net.ipv4.route.flush parce qu’il n’a pas de contenu. C’est juste un déclencheur.

[quote=“sonador”]“L’autre” était une machine virtuelle :
Kernel : 2.6.9-89.0.3.EL[/quote]
Pas tout jeune comme noyau. Et la distribution qui va avec non plus, je suppose. Je viens de tester sur une Debian sarge avec un noyau 2.6.8 qui doit donc être à peu près de la même époque, et sysctl ne renvoie rien quand on essaie de lire net.ipv4.route.flush, ni valeur ni message d’erreur. Les attributs de lecture de /proc/sys/net/ipv4/route/flush sont les mêmes qu’avec le noyau 2.4.37, et le message d’erreur est le même si on essaie de le lire avec cat. A mon avis, l’absence de message d’erreur vient simplement de la version différente de sysctl (j’ai fait mes tests sous etch).

Non, strictement aucun rapport.

Je dis que cela consiste à écrire n’importe quoi dedans OU à exécuter “ip route flush cache”. Pas les deux à la fois puisqu’ils font la même chose.

[code]echo foo > /proc/sys/net/ipv4/route/flush

OU

sysctl -w net.ipv4.route.flush=bar

OU

ip route flush cache[/code]

Quel rapport entre la modification du (pseudo-)fichier ip_forward et “sysctl -p” ? Tu veux dire si tu modifies le fichier /etc/sysctl.conf en ajoutant “net.ipv4.ip_forward=1” ? Alors oui, puisque ce fichier n’est automatiquement pris en compte qu’au démarrage. Si tu modifies directement net.ipv4.ip_forward avec sysctl ou /proc/sys/net/ipv4/ip_forward avec echo, alors non.

J’ai déjà répondu que non. Seulement quand on crée des règles de routage avancé.

Non, il reste possible de vider le cache de routage sans iproute avec sysctl ou echo comme indiqué plus haut.

#7

Oki!

Merci pour tes explications!

Amicalement,
Chris