So far the vanilla firmwares offered on OpenWrt utilize the
busybox-syslogd. Usually you can configure the syslog in
/etc/syslogd.conf but this busybox ignores this. log.overview
|busybox klogd||242620||Kernel logger|
|busybox syslogd||242620||System logging utility|
klogd klogd [-c n] [-n] Kernel logger. Options: -c n Sets the default log level of console messages to n -n Run as a foreground process
syslogd syslogd [OPTIONS] System logging utility. Note that this version of syslogd ignores /etc/syslog.conf. Options: -n Run in foreground -O FILE Log to given file (default:/var/log/messages) -l n Set local log level -S Smaller logging output -s SIZE Max size (KB) before rotate (default:200KB, 0=off) -b NUM Number of rotated logs to keep (default:1, max=99, 0=purge) -R HOST[:PORT] Log to IP or hostname on PORT (default PORT=514/UDP) -L Log locally and via network (default is network only if -R) -D Drop duplicates -C[size(KiB)] Log to shared mem buffer (read it using logread)
The "shared mem buffer" or ringbuffer is not a file on a tmpfs partition but just data in RAM. To read it, you have to use
you probably have syslogd running
ps aux | grep syslog:
381 root 1356 S syslogd -C16
16KB is a busybox default value. To change it, set
log_size option in
/etc/config/system (remember that the number must be in KB, not bytes). The buffer size must be at least 4KB, otherwise
syslogd fails to start.
Who logs? The syslogd acts as the server and any program can act as the client and send log messages to it. For example
logger can be used to manually write messages to the system log. Some scripts in
/etc/init.d/ actually use this.
Any program can act as the client and the syslogd acts as the server. Communication is prone to the syslog communications protocol.
Syslogd writes the log messages it receives into a file or into the RAM ringbuffer (option
-C). The file is a file, it can be accessed with
vi, etc. The data in the RAM ringbuffer should be accessed with
logread. You can of course use pipes, like
logread -f | nc 192.168.1.1 514 or
logread -f » /mnt/share/logfile (reasonable on non-flash media, see usb.storage or nfs.client) or pretty much whatever you want.
A log entry is maximal 1024 Bytes long and looks like this:
Feb 28 23:12:57 router user.notice kernel: the barmaid is the most beautiful woman in earth Month Day Time hostname facility.severity MESSAGE
The header contains a timestamp and a hostname (max 64 Byte) or an ip address.
The timestamp is set by the receiver of the log-message, the syslogd, not by the sender (for example
logger) and marks the Empfangszeitpunkt.
The hostname or the ip address belong to the sender of the message.
The first 24 values are predefined in RFC3164:
|5||messages generated internally by syslogd|
|6||line printer subsystem|
|7||network news subsystem|
The remaining 6 may be used to your liking.
|7||Debug||Such messages are usually not written to the log, turn them on|
Let's have a look at the MESSAGES different program produces: on OpenWrt they all start with the name of the program that send the message plus his PID.
Feb 4 21:45:43 openwrt user.info dropbear: Child connection from 192.168.1.1:46247 Feb 4 21:45:43 openwrt user.notice dropbear: password auth succeeded for 'username' from 192.168.1.1:46247 Feb 5 00:03:34 openwrt user.info dropbear: exit after auth (username): Exited normally Feb 5 03:13:39 openwrt user.warn dropbear: bad password attempt for 'root' from 192.168.1.1:51570 Feb 5 03:13:40 openwrt user.warn dropbear: bad password attempt for 'root' from 192.168.1.1:51570 Feb 5 03:13:42 openwrt user.warn dropbear: bad password attempt for 'root' from 192.168.1.1:51570 Feb 5 03:13:43 openwrt user.warn dropbear: bad password attempt for 'root' from 192.168.1.1:51570 Feb 5 03:13:45 openwrt user.warn dropbear: bad password attempt for 'root' from 192.168.1.1:51570 Feb 5 03:13:48 openwrt user.info dropbear: exit before auth (user 'root', 5 fails): Disconnect received
As you see, it is possible to try many many passwords. You can put an end to this by configuring dropbear or with netfilter. You can (and should) read your logs regularly, but of course you can also initiate thing with logs.
Yes, when you have any service running 24/7, you are responsible for it. "I didn't know" doesn't really count in court. It is your responsibility to keep yourself informed!
In the Debian repositories you will find
sysklogdinstead of now obsolete syslogd and klogd