|  |  | 
|  | started by Ingo Molnar <mingo@redhat.com>, 2001.09.17 | 
|  | 2.6 port and netpoll api by Matt Mackall <mpm@selenic.com>, Sep 9 2003 | 
|  | IPv6 support by Cong Wang <xiyou.wangcong@gmail.com>, Jan 1 2013 | 
|  | Extended console support by Tejun Heo <tj@kernel.org>, May 1 2015 | 
|  |  | 
|  | Please send bug reports to Matt Mackall <mpm@selenic.com> | 
|  | Satyam Sharma <satyam.sharma@gmail.com>, and Cong Wang <xiyou.wangcong@gmail.com> | 
|  |  | 
|  | Introduction: | 
|  | ============= | 
|  |  | 
|  | This module logs kernel printk messages over UDP allowing debugging of | 
|  | problem where disk logging fails and serial consoles are impractical. | 
|  |  | 
|  | It can be used either built-in or as a module. As a built-in, | 
|  | netconsole initializes immediately after NIC cards and will bring up | 
|  | the specified interface as soon as possible. While this doesn't allow | 
|  | capture of early kernel panics, it does capture most of the boot | 
|  | process. | 
|  |  | 
|  | Sender and receiver configuration: | 
|  | ================================== | 
|  |  | 
|  | It takes a string configuration parameter "netconsole" in the | 
|  | following format: | 
|  |  | 
|  | netconsole=[+][src-port]@[src-ip]/[<dev>],[tgt-port]@<tgt-ip>/[tgt-macaddr] | 
|  |  | 
|  | where | 
|  | +             if present, enable extended console support | 
|  | src-port      source for UDP packets (defaults to 6665) | 
|  | src-ip        source IP to use (interface address) | 
|  | dev           network interface (eth0) | 
|  | tgt-port      port for logging agent (6666) | 
|  | tgt-ip        IP address for logging agent | 
|  | tgt-macaddr   ethernet MAC address for logging agent (broadcast) | 
|  |  | 
|  | Examples: | 
|  |  | 
|  | linux netconsole=4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc | 
|  |  | 
|  | or | 
|  |  | 
|  | insmod netconsole netconsole=@/,@10.0.0.2/ | 
|  |  | 
|  | or using IPv6 | 
|  |  | 
|  | insmod netconsole netconsole=@/,@fd00:1:2:3::1/ | 
|  |  | 
|  | It also supports logging to multiple remote agents by specifying | 
|  | parameters for the multiple agents separated by semicolons and the | 
|  | complete string enclosed in "quotes", thusly: | 
|  |  | 
|  | modprobe netconsole netconsole="@/,@10.0.0.2/;@/eth1,6892@10.0.0.3/" | 
|  |  | 
|  | Built-in netconsole starts immediately after the TCP stack is | 
|  | initialized and attempts to bring up the supplied dev at the supplied | 
|  | address. | 
|  |  | 
|  | The remote host has several options to receive the kernel messages, | 
|  | for example: | 
|  |  | 
|  | 1) syslogd | 
|  |  | 
|  | 2) netcat | 
|  |  | 
|  | On distributions using a BSD-based netcat version (e.g. Fedora, | 
|  | openSUSE and Ubuntu) the listening port must be specified without | 
|  | the -p switch: | 
|  |  | 
|  | 'nc -u -l -p <port>' / 'nc -u -l <port>' or | 
|  | 'netcat -u -l -p <port>' / 'netcat -u -l <port>' | 
|  |  | 
|  | 3) socat | 
|  |  | 
|  | 'socat udp-recv:<port> -' | 
|  |  | 
|  | Dynamic reconfiguration: | 
|  | ======================== | 
|  |  | 
|  | Dynamic reconfigurability is a useful addition to netconsole that enables | 
|  | remote logging targets to be dynamically added, removed, or have their | 
|  | parameters reconfigured at runtime from a configfs-based userspace interface. | 
|  | [ Note that the parameters of netconsole targets that were specified/created | 
|  | from the boot/module option are not exposed via this interface, and hence | 
|  | cannot be modified dynamically. ] | 
|  |  | 
|  | To include this feature, select CONFIG_NETCONSOLE_DYNAMIC when building the | 
|  | netconsole module (or kernel, if netconsole is built-in). | 
|  |  | 
|  | Some examples follow (where configfs is mounted at the /sys/kernel/config | 
|  | mountpoint). | 
|  |  | 
|  | To add a remote logging target (target names can be arbitrary): | 
|  |  | 
|  | cd /sys/kernel/config/netconsole/ | 
|  | mkdir target1 | 
|  |  | 
|  | Note that newly created targets have default parameter values (as mentioned | 
|  | above) and are disabled by default -- they must first be enabled by writing | 
|  | "1" to the "enabled" attribute (usually after setting parameters accordingly) | 
|  | as described below. | 
|  |  | 
|  | To remove a target: | 
|  |  | 
|  | rmdir /sys/kernel/config/netconsole/othertarget/ | 
|  |  | 
|  | The interface exposes these parameters of a netconsole target to userspace: | 
|  |  | 
|  | enabled		Is this target currently enabled?	(read-write) | 
|  | extended	Extended mode enabled			(read-write) | 
|  | dev_name	Local network interface name		(read-write) | 
|  | local_port	Source UDP port to use			(read-write) | 
|  | remote_port	Remote agent's UDP port			(read-write) | 
|  | local_ip	Source IP address to use		(read-write) | 
|  | remote_ip	Remote agent's IP address		(read-write) | 
|  | local_mac	Local interface's MAC address		(read-only) | 
|  | remote_mac	Remote agent's MAC address		(read-write) | 
|  |  | 
|  | The "enabled" attribute is also used to control whether the parameters of | 
|  | a target can be updated or not -- you can modify the parameters of only | 
|  | disabled targets (i.e. if "enabled" is 0). | 
|  |  | 
|  | To update a target's parameters: | 
|  |  | 
|  | cat enabled				# check if enabled is 1 | 
|  | echo 0 > enabled			# disable the target (if required) | 
|  | echo eth2 > dev_name			# set local interface | 
|  | echo 10.0.0.4 > remote_ip		# update some parameter | 
|  | echo cb:a9:87:65:43:21 > remote_mac	# update more parameters | 
|  | echo 1 > enabled			# enable target again | 
|  |  | 
|  | You can also update the local interface dynamically. This is especially | 
|  | useful if you want to use interfaces that have newly come up (and may not | 
|  | have existed when netconsole was loaded / initialized). | 
|  |  | 
|  | Extended console: | 
|  | ================= | 
|  |  | 
|  | If '+' is prefixed to the configuration line or "extended" config file | 
|  | is set to 1, extended console support is enabled. An example boot | 
|  | param follows. | 
|  |  | 
|  | linux netconsole=+4444@10.0.0.1/eth1,9353@10.0.0.2/12:34:56:78:9a:bc | 
|  |  | 
|  | Log messages are transmitted with extended metadata header in the | 
|  | following format which is the same as /dev/kmsg. | 
|  |  | 
|  | <level>,<sequnum>,<timestamp>,<contflag>;<message text> | 
|  |  | 
|  | Non printable characters in <message text> are escaped using "\xff" | 
|  | notation. If the message contains optional dictionary, verbatim | 
|  | newline is used as the delimeter. | 
|  |  | 
|  | If a message doesn't fit in certain number of bytes (currently 1000), | 
|  | the message is split into multiple fragments by netconsole. These | 
|  | fragments are transmitted with "ncfrag" header field added. | 
|  |  | 
|  | ncfrag=<byte-offset>/<total-bytes> | 
|  |  | 
|  | For example, assuming a lot smaller chunk size, a message "the first | 
|  | chunk, the 2nd chunk." may be split as follows. | 
|  |  | 
|  | 6,416,1758426,-,ncfrag=0/31;the first chunk, | 
|  | 6,416,1758426,-,ncfrag=16/31; the 2nd chunk. | 
|  |  | 
|  | Miscellaneous notes: | 
|  | ==================== | 
|  |  | 
|  | WARNING: the default target ethernet setting uses the broadcast | 
|  | ethernet address to send packets, which can cause increased load on | 
|  | other systems on the same ethernet segment. | 
|  |  | 
|  | TIP: some LAN switches may be configured to suppress ethernet broadcasts | 
|  | so it is advised to explicitly specify the remote agents' MAC addresses | 
|  | from the config parameters passed to netconsole. | 
|  |  | 
|  | TIP: to find out the MAC address of, say, 10.0.0.2, you may try using: | 
|  |  | 
|  | ping -c 1 10.0.0.2 ; /sbin/arp -n | grep 10.0.0.2 | 
|  |  | 
|  | TIP: in case the remote logging agent is on a separate LAN subnet than | 
|  | the sender, it is suggested to try specifying the MAC address of the | 
|  | default gateway (you may use /sbin/route -n to find it out) as the | 
|  | remote MAC address instead. | 
|  |  | 
|  | NOTE: the network device (eth1 in the above case) can run any kind | 
|  | of other network traffic, netconsole is not intrusive. Netconsole | 
|  | might cause slight delays in other traffic if the volume of kernel | 
|  | messages is high, but should have no other impact. | 
|  |  | 
|  | NOTE: if you find that the remote logging agent is not receiving or | 
|  | printing all messages from the sender, it is likely that you have set | 
|  | the "console_loglevel" parameter (on the sender) to only send high | 
|  | priority messages to the console. You can change this at runtime using: | 
|  |  | 
|  | dmesg -n 8 | 
|  |  | 
|  | or by specifying "debug" on the kernel command line at boot, to send | 
|  | all kernel messages to the console. A specific value for this parameter | 
|  | can also be set using the "loglevel" kernel boot option. See the | 
|  | dmesg(8) man page and Documentation/admin-guide/kernel-parameters.rst for details. | 
|  |  | 
|  | Netconsole was designed to be as instantaneous as possible, to | 
|  | enable the logging of even the most critical kernel bugs. It works | 
|  | from IRQ contexts as well, and does not enable interrupts while | 
|  | sending packets. Due to these unique needs, configuration cannot | 
|  | be more automatic, and some fundamental limitations will remain: | 
|  | only IP networks, UDP packets and ethernet devices are supported. |