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

 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 logread. 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 cat, less, 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 women 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:

The remaining 6 may be used to your liking.

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.

log.messages

Feb  4 21:45:43 openwrt user.info dropbear[9815]: Child connection from 192.168.1.1:46247
Feb  4 21:45:43 openwrt user.notice dropbear[9815]: password auth succeeded for 'username' from 192.168.1.1:46247
Feb  5 00:03:34 openwrt user.info dropbear[9815]: exit after auth (username): Exited normally
Feb  5 03:13:39 openwrt user.warn dropbear[10221]: bad password attempt for 'root' from 192.168.1.1:51570
Feb  5 03:13:40 openwrt user.warn dropbear[10221]: bad password attempt for 'root' from 192.168.1.1:51570
Feb  5 03:13:42 openwrt user.warn dropbear[10221]: bad password attempt for 'root' from 192.168.1.1:51570
Feb  5 03:13:43 openwrt user.warn dropbear[10221]: bad password attempt for 'root' from 192.168.1.1:51570
Feb  5 03:13:45 openwrt user.warn dropbear[10221]: bad password attempt for 'root' from 192.168.1.1:51570
Feb  5 03:13:48 openwrt user.info dropbear[10221]: exit before auth (user 'root', 5 fails): Disconnect received

• dropbear[PID]: dropbear with the PID 999 is running all the time. This instance (PID=9815) has been spawn for this ssh session.
• password auth succeeded for 'username' from 192.168.1.1:46247: \\this is going to spawn an ash instance with the PID 9687

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.

• When you debug, you should create a lot of logs.
• During normal service, you should create logs
  • to WARN you read them regularly
  • LOGs in order to be able to reconstruct things. read them when need it

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

• busybox
• sysklogd instead of now obsolete syslogd and klogd
• rsyslog
• syslogd-ng

log.overview