Que veulent dire toutes ces lignes au boot ?

Support Debian
#1

Depuis peu, au boot, j’ai un wagon de lignes qui défilent et dont je ne comprends pas ce qu’elles veulent dire.
Ça retarde énormément le chargement
ET
Qaund j’ouvre une console, Ctrl/Alt/F5, par exemple, au bout de quelques instant, j’ai ce même défilement du même genre de lignes. Là, c’est fortement gênant car ces lignes s’intercalent avec mes frappes et je ne sais plus où j’en suis.

May 25 00:42:55 localhost kernel: [ 2781.272761] IN=eth0 OUT= MAC=01:00:5e:7f:ff:fa:00:07:cb:c7:af:35:08:00 SRC=192.168.0.254 DST=239.255.255.250 LEN=257 TOS=0x00 PREC=0x00 TTL=2 ID=0 DF PROTO=UDP SPT=1900 DPT=1900 LEN=237 May 25 00:42:55 localhost kernel: [ 2781.273789] IN=eth0 OUT= MAC=01:00:5e:7f:ff:fa:00:07:cb:c7:af:35:08:00 SRC=192.168.0.254 DST=239.255.255.250 LEN=266 TOS=0x00 PREC=0x00 TTL=2 ID=0 DF PROTO=UDP SPT=1900 DPT=1900 LEN=246 May 25 00:42:55 localhost kernel: [ 2781.274914] IN=eth0 OUT= MAC=01:00:5e:7f:ff:fa:00:07:cb:c7:af:35:08:00 SRC=192.168.0.254 DST=239.255.255.250 LEN=329 TOS=0x00 PREC=0x00 TTL=2 ID=0 DF PROTO=UDP SPT=1900 DPT=1900 LEN=309 May 25 00:42:55 localhost kernel: [ 2781.275840] IN=eth0 OUT= MAC=01:00:5e:7f:ff:fa:00:07:cb:c7:af:35:08:00 SRC=192.168.0.254 DST=239.255.255.250 LEN=321 TOS=0x00 PREC=0x00 TTL=2 ID=0 DF PROTO=UDP SPT=1900 DPT=1900 LEN=301 May 25 00:42:55 localhost kernel: [ 2781.276841] IN=eth0 OUT= MAC=01:00:5e:7f:ff:fa:00:07:cb:c7:af:35:08:00 SRC=192.168.0.254 DST=239.255.255.250 LEN=305 TOS=0x00 PREC=0x00 TTL=2 ID=0 DF PROTO=UDP SPT=1900 DPT=1900 LEN=285 May 25 00:42:55 localhost kernel: [ 2781.277949] IN=eth0 OUT= MAC=01:00:5e:7f:ff:fa:00:07:cb:c7:af:35:08:00 SRC=192.168.0.254 DST=239.255.255.250 LEN=337 TOS=0x00 PREC=0x00 TTL=2 ID=0 DF PROTO=UDP SPT=1900 DPT=1900 LEN=317 May 25 00:42:55 localhost kernel: [ 2781.279244] IN=eth0 OUT= MAC=01:00:5e:7f:ff:fa:00:07:cb:c7:af:35:08:00 SRC=192.168.0.254 DST=239.255.255.250 LEN=325 TOS=0x00 PREC=0x00 TTL=2 ID=0 DF PROTO=UDP SPT=1900 DPT=1900 LEN=305 May 25 00:42:55 localhost kernel: [ 2781.280259] IN=eth0 OUT= MAC=01:00:5e:7f:ff:fa:00:07:cb:c7:af:35:08:00 SRC=192.168.0.254 DST=239.255.255.250 LEN=319 TOS=0x00 PREC=0x00 TTL=2 ID=0 DF PROTO=UDP SPT=1900 DPT=1900 LEN=299 May 25 00:43:04 localhost kernel: [ 2789.535090] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=319 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=42246 DPT=1900 LEN=299 May 25 00:43:04 localhost kernel: [ 2789.635326] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=328 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=42246 DPT=1900 LEN=308

Celles-là, viennent de kernlog et il y en a plusioeurs dizaines de pages :imp:

#2

Je n’ai pas ça en testing.
Peut étre ton syslog qui est cassé ?
Et au lieu d’écrire le journal sur le disque, il l’envoie sur STDOUT.

#3

Bonjour,

Au vu du port utilisé (1900), c’est un service Plug and Play qui tente d’interroger ta machine pour connaitre les services disponible sur celle-ci.

Si tu as une freebox, l’upnp a été mis en place recemment et ce doit être elle qui interroge ton PC mais elle se fait bloquer par ton pare feu et celui-ci t’informe du blocage sur stdout et dans la syslog normalement.

Il est possible d’eviter les messages sur stdout, il me semble, mais je ne sais plus comment.

#4

Ta piste doit être bonne Micky car en effet, j’ai une freebox et j’ai récemment “coché” l’UPNP pour faire des essais de video sur la TV via l’ordi.
Je vais “décocher” upnp et voir si j’ai toujours ces mêmes lignes en tty.
Je donne le résultat après.

EDIT :
J’ai aussi installé meditomb pour les mêmes essais et il y a certainement aussi un système de port qui cherche le branchement.

#5

Ces messages sont produits par une règle iptables avec la cible LOG.
Par défaut, les messages du noyau sont affichés sur la console active. Si ça t’ennuie, tu peux modifier la priorité des messages devant être affichés, par exemple :

Cf. /etc/sysctl.conf, il y a une ligne déjà prête qu’il suffit de décommenter.
Mais si c’est du trafic normal, le mieux est peut-être de modifier les règles iptables afin de ne pas logger ces paquets.

#6

[quote=“PascalHambourg”]Ces messages sont produits par une règle iptables avec la cible LOG.
Par défaut, les messages du noyau sont affichés sur la console active. Si ça t’ennuie, tu peux modifier la priorité des messages devant être affichés, par exemple :

echo "4 4 1 7" > /proc/sys/kernel/printk

Cf. /etc/sysctl.conf, il y a une ligne déjà prête qu’il suffit de décommenter.
Mais si c’est du trafic normal, le mieux est peut-être de modifier les règles iptables afin de ne pas logger ces paquets.[/quote]Alors, j’ai testé en “désélectionnant” l’upnp dans Free mais pas de changement, même après reboot freebox et machine.
J’ai “désinstallé” mediatomb et là, je n’ai plus ces lignes quand j’ouvre un tty MAIS, je ne peux plus me servir de l’avantage donné par upnp :cry:
J’aimerais bien essayer ton conseil, Pascal mais quoi et comment modifier :question:
Voici mes règles iptables, presque entièrement faites sous ta dictée.

[code]ricardo@Dell-sid:~$ sudo iptables-save
[sudo] password for ricardo:

Generated by iptables-save v1.4.3.2 on Mon May 25 14:25:02 2009

*filter
:INPUT DROP [2:656]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [2798:502139]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -j ACCEPT
-A INPUT -s 212.27.38.253/32 -m state --state NEW,RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p udp -m udp --dport 31336 -j ACCEPT
-A INPUT -j LOG
-A INPUT -s 192.168.0.0/24 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
COMMIT

Completed on Mon May 25 14:25:02 2009

Generated by iptables-save v1.4.3.2 on Mon May 25 14:25:02 2009

*nat
:PREROUTING ACCEPT [5:1112]
:POSTROUTING ACCEPT [8:456]
:OUTPUT ACCEPT [309:24997]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT

Completed on Mon May 25 14:25:02 2009

Generated by iptables-save v1.4.3.2 on Mon May 25 14:25:02 2009

*mangle
:PREROUTING ACCEPT [2801:2275453]
:INPUT ACCEPT [2801:2275453]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [2798:502139]
:POSTROUTING ACCEPT [2839:515651]
COMMIT

Completed on Mon May 25 14:25:02 2009

Generated by iptables-save v1.4.3.2 on Mon May 25 14:25:02 2009

*raw
:PREROUTING ACCEPT [2801:2275453]
:OUTPUT ACCEPT [2798:502139]
COMMIT

Completed on Mon May 25 14:25:02 2009

[/code]
Merci de ton aide, une fois de plus. :smt006

#7

Tu as essayé en modifiant la valeur de kernel.printk ? Parce que bon, même s’il peut être utile de logger des paquets, ça ne l’est pas forcément de l’afficher sur la console.

Concernant iptables, c’est là que ça se passe :

-A INPUT -j LOG                                                                 
-A INPUT -s 192.168.0.0/24 -j ACCEPT

Les paquets en question sont acceptés par la deuxième règle après avoir été loggés par la première.
Tu as plusieurs options. Tu peux insérer une règle qui les accepte avant la règle LOG, par exemple :

Tu peux aussi diminuer la priorité des messages produits par la cible LOG avec l’option --log-level (en augmentant la valeur numérique du niveau de priorité entre 5 et 7, de mémoire la priorité par défaut est 4). Mais attention, cela pourrait avoir pour conséquence que ces messages ne soient plus enregistrés par syslog s’ils n’ont pas une priorité suffisante (pas regardé, à vérifier).

#8

en décommentant la ligne dans kernel.printk, ça a fait effet, après un reboot.
Si ça n’a pas d’autres inconvénients, il est bien que je reste ainsi ou il est préférable de configurer iptables comme tu dis :question:

#9

Malgré tout, mais personnellement, ça ne me gêne pas, ça continue de “travailler” dans kernlog et on dirait que ça scanne toutes les minutes.

[quote]May 25 15:41:08 localhost kernel: [ 506.834573] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=385 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=50598 DPT=1900 LEN=365
May 25 15:41:08 localhost kernel: [ 506.934932] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=383 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=39956 DPT=1900 LEN=363
May 25 15:42:08 localhost kernel: [ 566.533739] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=319 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=57751 DPT=1900 LEN=299
May 25 15:42:08 localhost kernel: [ 566.634135] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=328 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=57751 DPT=1900 LEN=308
May 25 15:42:08 localhost kernel: [ 566.734550] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=371 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=57751 DPT=1900 LEN=351
May 25 15:42:08 localhost kernel: [ 566.834791] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=385 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=33564 DPT=1900 LEN=365
May 25 15:42:08 localhost kernel: [ 566.935191] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=383 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=43032 DPT=1900 LEN=363
May 25 15:43:08 localhost kernel: [ 626.533798] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=319 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=35751 DPT=1900 LEN=299
May 25 15:43:08 localhost kernel: [ 626.634206] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=328 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=35751 DPT=1900 LEN=308
May 25 15:43:08 localhost kernel: [ 626.734613] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=371 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=35751 DPT=1900 LEN=351
May 25 15:43:08 localhost kernel: [ 626.834967] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=385 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=60228 DPT=1900 LEN=365
May 25 15:43:08 localhost kernel: [ 626.935313] IN=eth0 OUT= MAC= SRC=192.168.0.10 DST=239.255.255.250 LEN=383 TOS=0x00 PREC=0x00 TTL=4 ID=0 DF PROTO=UDP SPT=36974 DPT=1900 LEN=363 [/quote]

#10

Pour un effet immédiat il fallait utiliser la commande sysctl ou l’écriture directe dans /proc/sys/.

L’“inconvénient” de la méthode, si on peut dire, c’est que les autres messages du noyau de priorité 4 (warning) ne sont plus affichés sur la console non plus. A toi de voir si c’est vraiment un inconvénient.

C’est normal, le paramètre printk n’agit que sur ce que le noyau affiche sur la console, pas sur ce qu’il envoie à klog/syslog. Si tu ne veux pas que ces paquets figurent dans kern.log et syslog, il ne faut pas les logger.

#11

Merci pour toutes ces explicvations, je vais rester comme ça donc.
C’est super d’avoir sur notre forum des personnes vraiment compétentes, comme toi, François, Matt et encore d’autres, que je ne citerai pas de peur d’en oublier.