LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (http://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   dmesg output sent to virtual terminals (http://www.linuxquestions.org/questions/linux-newbie-8/dmesg-output-sent-to-virtual-terminals-605476/)

szim90 12-08-2007 08:20 PM

dmesg output sent to virtual terminals
 
Hello.

If I run dmesg, I see this message repeated many times over:

Inbound IN=eth1 OUT= MAC=------- (what I imagine is my MAC address) SRC=192.168.0.5 DST=192.168.0.255 LEN=244 TOS=0x00 PREC=0x00 TTL=128 ID=46930 PROTO=UDP SPT=138 DPT=138 LEN=224

Though this creates a lot of entries on dmesg, it doesn't really bother me in itself, but if I switch to a virtual terminal, this message is every so often printed (for example, I might be logging in and typing my username, and this message might suddenly appear on the prompt, forcing me to delete the everything and retype) so it can be troublesome. If I switch to terminal 1 (where the system bootup messages are) I can see this message has been printed here often.

What does this message mean and is there a way to stop it from being printed on virtual terminals?

Thank you for any help.

Regards,
Sean

dkm999 12-09-2007 04:14 PM

I posted the answer to this a few days ago on one of these forum lists; a short search would probably turn up the answer. But here it is again:

The messages appearing on your screen are almost certainly generated by your firewall script (iptables, very likely). There are two ways to eliminate these messages from the display:

1. Remove the rule in the iptables configuration that generates the message (it will have the phrase -j LOG near the end of the line).

2. Fix the syslog configuration so that it does not send these messages to the virtual terminal, but only to the logfile. To do this, you need to alter the file /etc/syslog.conf. There will be a line in it that looks something like this
Code:

kern.*        /dev/console
This line says "Send all kernel messages to the console", which is probably not what you want if you are actually using the console for a user session. Instead, you might want something like this
Code:

kern.err    /dev/console
This only displays higher-priority error messages on the console.

If you adopt strategy #2, it is a good idea to make sure that the messages that you eliminate from the console are also being sent to some syslog file. Read the manpage for syslog.conf to work out what the rest of this file means.

szim90 12-09-2007 05:34 PM

I checked my /etc/syslog.conf file, and I found the two things that look like it
would send output to a terminal:

*.emerg *

daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn |/dev/xconsole

However, looking at my system log in gnome, I don't see anything that says what priority the message is, so I'm not sure which one of the two directives is causing all of the messages. Which should I edit? Also, will editing this file just stop the console output or all of the other messages as well?

I also checked iptables and found that four log items have the prefix "Inbound":

LOG tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x02 limit: avg 1/sec burst 5 LOG flags 0 level 6 prefix `Inbound '

LOG tcp -- 0.0.0.0/0 0.0.0.0/0 tcp flags:0x17/0x04 limit: avg 1/sec burst 5 LOG flags 0 level 6 prefix `Inbound '

LOG icmp -- 0.0.0.0/0 0.0.0.0/0 icmp type 8 limit: avg 1/sec burst 5 LOG flags 0 level 6 prefix `Inbound '

LOG all -- 0.0.0.0/0 0.0.0.0/0 limit: avg 5/sec burst 5 LOG flags 0 level 6 prefix `Inbound '

What are these designed to log and are they necessary?

Also, I did some searching and I found some posts that recommend adjusting the klogd setting. Would that help?

Thanks for your help,
Sean

dkm999 12-10-2007 02:46 PM

The part of your /etc/syslog.conf that is putting the messages up on your console is
Code:

daemon.*;mail.*;\
        news.err;\
        *.=debug;*.=info;\
        *.=notice;*.=warn      |/dev/xconsole

The syslog.conf manpage tells me that these entries consist of a facility and a priority. At present, your configuration is redundant and verbose; the first line says "all messages from daemons or mail", the next says "high-priority messages from news", the third and fourth say "all messages of priority debug, info, notice or warn", followed by "put them on the X console (your screen).

This set covers nearly all the sorts of messages that get put into the syslog. The only things that are not covered by this set of rules are of very high priority, but are rare: messages with priority err, crit, alert, or emerg from facilities other than daemon, mail, or news.

My personal taste would be to turn this configuration pretty nearly on its head, and display only those rare messages that actually mean trouble on the console; there is a program called logwatch which will run every night and e-mail you a digest of any other problems that have been logged in the last day.

Such an approach would eliminate most of the messages that you are seeing on your screen now.

Second, the four LOG rules that you found in your iptables configuration are set up to log various Internet attacks. The syslog priority is set to 6, which means they are crit(ical) in the view of the rule writer. The log messages will only be generated if the frequency of arrival is too high or a burst of 5 or more arrives at once.

Although such attacks can be debilitating, a properly-designed set of iptables rules will ward them off, and it is not clear what action you might take if you got the warning in real time anyway, because a really determined attack of this type is called a denial-of-service attack, since it swamps your Internet connection. Your only defense is to unplug the connection, which denies you access to the 'Net for any corrective action. Therefore, I would recommend just sending such messages to syslog, so that you will have a record of the IP address where such an attack originated. Once it is over, you can then send a complaint to abuse@whatever.com, if the address can be resolved to the name of some ISP that you think might do something about the offender. In my experience, this is pretty uncommon. Often the source IP address is bogus, or does not resolve to a name at all, and if you try to trace the packet back, you will end up at a blank wall somewhere along the line.

Therefore, I would reduce the loglevel to 4 (info), and set up /etc/syslog.conf to put all such messages into the logfile (probably /var/log/messages).


All times are GMT -5. The time now is 08:03 AM.