Seven Solutions WR SW v5 User Manual

White Rabbit Switch: User’s Manual

Information about conﬁguring the White Rabbit switch, for ﬁnal users

August 2017 (wr-switch-sw-v5.0.1)

Alessandro Rubini, Adam Wujek, Benoit Rat, Federico Vaga, ...

Table of Contents

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1 WRS Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1 The Oﬃcial Manuals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Supported Hardware Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Upgrading WRS Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Upgrade from pre-v5.0 to v5.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.2 hwinfo for pre-v4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.3 Upgrading from v4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3.1 Upgrading from v4.0 with the USB cable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.3.2 Upgrading from v4.0 remotely . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.4 Upgrading from v3.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3 Conﬁguration of the Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1 Dynamic WRS Conﬁguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.2 The Conﬁguration File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.3 Conﬁguration Items that Apply at Build Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.4 Conﬁguration Items that Apply at Run Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.5 Timing Conﬁguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.6 VLANs Conﬁguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.6.1 Example VLAN conﬁguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.6.1.1 Example VLAN conﬁguration by dot-conﬁg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.6.1.2 Example VLAN conﬁguration by tools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.7 Front panel’s LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.7.1 Status LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.7.2 Ports’ LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Booting with Barebox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 Description of the menus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.2 Using wrboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4.3 Creating an NFS-Root Environment for WRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5 WRS Command-Line Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1 sdb-read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

5.2 wrs vlans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

5.3 wrs auxclk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6 SNMP Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.1 The WRS MIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.2 show-pstats. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Appendix A Bugs and Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . 29

Introduction

The White Rabbit switch (or wrs) is a major component of the White Rabbit (wr) network. Like any modern managed switch, the wrs includes a CPU with its own operating system.

This manual is for people installing wrs devices, who need to conﬁgure them in their network.

1 WRS Documentation

Up to and including release v4.0 of wrs software this manual didn’t exist, and the “WRS Build Manual” included some information about conﬁguration.

1.1 The Oﬃcial Manuals

This is the current set of manuals that accompany the wrs:

• White Rabbit Switch: Startup Guide : hardware installation instructions. This manual is provided by the manufacturer: it describes handling measures, the external connectors, hardware features and the initial bring-up of the device.

• White Rabbit Switch: User’s Manual: documentation about conﬁguring the wrs, at soft- ware level. This guide is maintained by software developers. The manual describes conﬁguration in a deployed network, either as a standalone device or as network-booted equipment. The guide also describes how to upgrade the switch, because we’ll release new oﬃcial ﬁrmware images over time, as new features are implemented.

• White Rabbit Switch: Developer’s Manual : it describes the build procedure and how inter- nals work; use of scripts and wrs-speciﬁc programs etc. The manual is by developers and for developers. This is the document to check if you need to customize your wrs rebuild software from new repository commits that are not an oﬃcial release point, or just install your wrs with custom conﬁguration values.

• White Rabbit Switch: Failures and Diagnostics: describes various failure scenarios of a switch and ways how to recognize them. Additionally, it describes SNMP exports of a switch (WR-SWITCH-MIB).

The oﬃcial pdf copy of these manuals at each release is published in the ﬁles tab of the software project in ohwr.org: (http://www.ohwr.org/projects/wr-switch-sw/files). This doesn’t apply to release v4.0 and earlier.

The source form of all four manuals is maintained in wr-switch-sw/doc. Within the repository, three of them the User’s Manual, the Developer’s Manual and the Failures and Diagnostics are always tracking the software commits, while the Startup Guide may not be authoritative because it is bound to device shipping rather than software development.

1.2 Supported Hardware Versions

This document applies to versions 3.3 and 3.4 of the wrs device.

Very few specimens of wrs 3.0 though 3.2 were manufactured; if you are the owner of one of them, please refer to version 3.3 of the wrs-build document, that includes appendixes about using older versions. As usual, it is in the ﬁles tab of ohwr.org.

V1 and V2 were development items, never shipped.

2 Upgrading WRS Software

The wrs is shipped with a current version of its software image, which is sometimes called ﬁrmware. If your devices are running a previous version of the software you may want to upgrade, or you may want to replace the ﬁrmware images after rebuilding your own, as explained in the Developer’s Manual.

If you run version 4.1 or later please copy wrs-firmware.tar ﬁle into the /update partition via scp or web-interface and restart your switch.

When the running version during the update is at least v5.0, then update script performs the check of md5 sums of all ﬁles inside the wrs-firmware.tar. If at least one checksum is incorrect, the update is aborted and an error is reported via SNMP (object wrsFwUpdateStatus) until the next successful update. Additionally, the wrs-firmware.tar containing corrupted ﬁle is renamed to wrs-firmware.tar.checksum_error. This ﬁle is automatically removed during the next successful update.

When checksums in the wrs-firmware.tar are not available (for example during downgrading to version pre-5.0) appropriate warning message is printed to the console.

If this method of upgrading ﬁrmware works for you, you can ignore the rest of this chapter, which explains a transition between the initial way we passed MAC addresses and the safer approach we introduced in v4.1

2.1 Upgrade from pre-v5.0 to v5.0

During the update from the pre-v5.0 ﬁrmware to v5.0 (or later) you might see the following errors on the console.

/wr/bin/sdb-read: can’t load library ’libm.so.1’ Creating SDB filesystem in /dev/mtd5 cp: can’t stat ’/wr/etc/sdb-for-dataflash’: No such file or directory

done

Please ignore this message, no real error occurred nor hwinfo partition (/dev/mtd5) was overwritten. The error is caused by an old ﬁrmware trying to run a binary (sdb-read to be precise) from the new ﬁrmware image. The problem became visible now, because between v4.2 and v5.0 we uplifted the buildroot, which changed the version of libm library from libm.so.0 to libm.so.1.

2.2 hwinfo for pre-v4.1

Version 4.1 (October 2014) and later ones use a new way to pass hardware information to all levels of software, such information includes the MAC addresses for the management Ethernet and the sfp ports. Information is now stored in a Flash partition called hwinfo, using the sdb ﬁle format. sdb is deﬁned in the fpga-configuration-space within ohwr.org. Before using sdb we used to edit the boot loader’s conﬁguration at ﬂash time.

The hwinfo structure is written to dataﬂash by the manufacturer. It is never changed even when performing a complete re-ﬂash of the device, because the ﬂashing scripts preserve the hwinfo memory area.

When upgrading from a pre-4.1 switch software, you need to create this hwinfo data structure. The procedure is mostly automatic, but you need to be aware of the steps involved, in case something goes wrong.

Chapter 2: Upgrading WRS Software 3

2.3 Upgrading from v4.0

Version 4.0 and later of wr-switch-sw are able to upgrade themselves if you place the proper ﬁles in the /update directory of the wrs. However, in version 4.0 we forgot to provide for an upgrade of the boot loader and didn’t note that if the front USB cable is not plugged, the upgrade procedure blocks.

This latter problem happens because messages are written to the management USB port, to help people ﬂashing from scratch, and the write is a blocking one by default: if nobody collects the USB data, the system waits for a recipient. With version 4.1.1 the problem was ﬁxed using non-blocking operations (it is better to loose messages than to block the installation because nobody is reading).

Thus, there are two diﬀerent ways to upgrade; which one you prefer we can’t tell. Both work, each with its own drawbacks. Each of them preserves the current MAC addresses.

2.3.1 Upgrading from v4.0 with the USB cable

This is the procedure if you are able to walk to your wrs and connect to the management USB port, even if the port is not actually used:

• Copy your own wrs-firmware.tar for at least v4.1 into the /update partition. This can be the oﬃcial ﬁrmware or one you built yourself. Then reboot and wait for everything to settle (the system will reboot once more by itself).

• Copy wrs-firmware.tar again. And reboot again. The system will reboot once more by itself.

• Now you have a running updated version with your hwinfo in place and the old MAC addresses preserved.

We save you from the long description of what is happening in the various steps. If needed, it is in the git history of wr-switch-sw, at release point v4.1.

2.3.2 Upgrading from v4.0 remotely

If you can’t walk to the switch, the procedure is faster but more commands need to be typed on the root shell of the switch. We support a single upgrade provided you change the kernel and initial ﬁlesystem before rebooting.

• Copy your own wrs-firmware.tar for at least v4.1 into the /update partition. This can be the oﬃcial ﬁrmware or one you built yourself.

• Create and mount /boot within the switch. This means running the following commands in ssh :

mkdir /boot

mount -t ubifs ubi0:boot /boot

• Copy wrs-initramfs.gz (which is to be found inside wrs-firmware.tar) to the /boot partition just mounted. This ensures the new upgrade procedure will run, the one that doesn’t block if the USB cable is unplugged.

• Copy zImage (again, to be found inside wrs-firmware.tar) to the /boot partition. This is need to be able to access the hwinfo partition at next boot.

• Reboot and wait for everything to settle (the system will reboot once more by itself after upgrading everything). The MAC addresses will be saved to hwinfo during the update procedure, thanks to the new kernel and new boot procedure you manually copied to /boot.

Note: if you forget to place the new kernel or wrs-initramfs.gz in /boot, no big damage will happen, but you’ll have lost your MAC address for the wr ports. You’ll ﬁnd a randomly-chosen value, that will however be persistent over reboot (because it is saved to hwinfo after you boot with the new kernel.

Chapter 3: Conﬁguration of the Device 4

2.4 Upgrading from v3.x

Upgrading from versions older than v4.0 (August 2014) requires physical access to the device and, unfortunately, requires some extra steps especially if you want to preserve your MAC addresses.

One possible path is ﬂashing version 4.0 (please refer to v4.0 manuals) and then proceed as described in Section 2.3 [Upgrading from v4.0], page 3. When ﬂashing version 4.0 you’ll need to pass your MAC addresses on the command line of the ﬂasher, so please take note of what they are.

Another option is ﬂashing the latest ﬁrmware version and then build your own hwinfo structure by specifying your MAC addresses. wr-switch-sw includes speciﬁc tools for both steps. They are described in the Developer’s Manual, because they are expected to only be performed by the manufacturer, not the ﬁnal user.

3 Conﬁguration of the Device

After release v3.3 of this software package, we added Kconﬁg support to wr-switch-sw. If you build your software image (as documented in the wrs Developer’s Manual ), you can make some conﬁguration choices for your customized ﬁrmware image. But most users are not expected to rebuild.

After release v4.1, we moved most of the conﬁguration to run-time (rather than build-time): the .config ﬁle that you create with a “make menuconfig” or equivalent command, is now copied to the wrs ﬁlesystem and used during boot. Moreover, the switch can download a new conﬁguration at boot time, if so conﬁgured. This allows customization of each installed switch through a central server, without modifying the ﬁlesystem image in each specimen.

Starting with release v4.2, we added “make config” support at run time, to be run in /wr/etc; the ﬁle is called dot-config, and not .config. This is meant to be useful for developers, when testing diﬀerent conﬁgurations in the lab, rather than in production. We also support “make config”, “make defconfig”, make oldconfig”, from v5.0 “make menuconfig” and “make nconfig”.

3.1 Dynamic WRS Conﬁguration

The switch can boot using its internal nand memory or as an NFS-Root host. In the latter case conﬁguration can be changed on the server, and if a unit is replaced, a change in the dhcp database is all that’s needed to recover network operation. But this option implies some network traﬃc on your management network, as well as an NFS server able to host all of your switches.

When a switch is booted from internal storage, we used to rely on internal conﬁguration (either selected at build time or modiﬁed using ssh or the web interface). This approach doesn’t scale well to large installation, because if a device needs to be replaced, its own conﬁguration is lost.

With dynamic conﬁguration, each wrs device loads its own conﬁguration ﬁle each time it is booted, and applies the choices before starting any service. The name of the conﬁguration ﬁle can include the mac, ip address or hostname of the device, to allow running several switches with diﬀerent conﬁgurations in the same network. The location of the conﬁguration ﬁle can be stored in the dot-config or be retrieved from DHCP server.

3.2 The Conﬁguration File

The main conﬁguration ﬁle for the wrs is /wr/etc/dot-config. You create this ﬁle by running “make menuconfig” within wr-switch-sw repo, and making your choices. You can also edit

Chapter 3: Conﬁguration of the Device 5

the text ﬁle, or run other conﬁgurators: make config, make xconfig, make gconfig, make nconfig.

The conﬁguration step creates .config, that you can copy to your wrs as /wr/etc/dot-config. After reboot, you’ll see your choices in eﬀect.

The ﬁrst three conﬁguration items are free-text ﬁelds which are intended for dot-conﬁg management purposed. As now (v5.0.1) these ﬁelds are not used for any functionality on the switch.

CONFIG_DOTCONF_FW_VERSION CONFIG_DOTCONF_HW_VERSION

Free-text items to describe switch’s ﬁrmware CONFIG_DOTCONF_FW_VERSION and hardware CONFIG_DOTCONF_HW_VERSION version. Additionally, the default value of

CONFIG_DOTCONF_FW_VERSION can be used as a version of a Kconﬁg ﬁle.

CONFIG_DOTCONF_INFO

Free-text item to descibe additional information about dot-conﬁg.

The next conﬁguration item is a choice about source of the dot-config ﬁle (items starting with CONFIG_DOTCONF_SOURCE_). The following dot-config sources are implemented in current version:

CONFIG_DOTCONF_SOURCE_LOCAL

Use local dot-config ﬁle stored in /wr/etc/dot-config. In this case no network access is performed.

CONFIG_DOTCONF_SOURCE_REMOTE

Get a dot-config ﬁle from the URL provided in CONFIG_DOTCONF_URL.

CONFIG_DOTCONF_SOURCE_FORCE_DHCP

Get a network location of a dot-config ﬁle from a DHCP server. Server can be conﬁgured in a way to provide the entire URL to the dot-config in the “filename” conﬁguration ﬁeld of the DHCP server. In this case, provided URL has to be in the same form as CONFIG_DOTCONF_URL.

As an alternative, “filename” can be conﬁgured only as a path. It will be then interpreted as a path on a TFTP server, which IP address is taken from the conﬁguration ﬁeld “The BOOTP next server option” of a DHCP server.

CONFIG_DOTCONF_SOURCE_TRY_DHCP

The same as CONFIG_DOTCONF_SOURCE_FORCE_DHCP, but this option does not cause errors in SNMP’s objects if switch fails to retrieve the URL to the dot-config via DHCP. Note that syntax and download errors of dot-config are notiﬁed in the same way as for other choices.

If the selected option triggers wrs to download a new dot-config ﬁle and it passes the validation process, the new dot-config will replace a local copy. In case there are errors or unknown conﬁguration entries in the retrieved ﬁle, the old one will be used.

The URL (stored in CONFIG_DOTCONF_URL or retrieved via DHCP) is of the form “proto- col://host /pathname”. The special upper-case strings HOSTNAME, IPADDR and MACADDR are substituted with the current hostname, IP address or MAC address of the management port of the switch. By this, the same conﬁguration string can be used to set up a batch of switches with diﬀerent conﬁgurations.

The three parts of the URL are as follows:

protocol

We support http, ftp and tftp. Any other protocols result in an error, and the dot-config ﬁle is not replaced.

Chapter 3: Conﬁguration of the Device 6

host

The host can be an IP address, or a name. In order to use a name you must specify a valid CONFIG_DNS_SERVER and optionally CONFIG_DNS_DOMAIN. Alternatively DNS conﬁguration can be taken from the DHCP server. The values in the current dot-config are used to load the new ﬁle.

path

The pathname can include directory components and any of HOSTNAME, IPADDR, MACADDR.

For example this is a valid conﬁguration for run-time update:

CONFIG_DOTCONF_SOURCE_REMOTE=y CONFIG_DOTCONF_URL="tftp://morgana/wrs-config-IPADDR" CONFIG_DNS_SERVER="192.168.16.1" CONFIG_DNS_DOMAIN="i.gnudd.com"

It results in wrs-config-192.168.16.9 being served to the wrs. Please remember, that the new dot-config should include a valid CONFIG_DOTCONF_SOURCE_*

setting, or you won’t be able to update the conﬁguration at the next boot. In any case, you can always copy a conﬁguration ﬁle using ssh, or use the web interface to change the conﬁguration. Changes performed using the web interface are immediately active, because the web server takes proper action; the new ﬁle copied over with ssh, or any hand-edits, are only eﬀective at next boot, unless overwritten by a remote conﬁguration ﬁle. In case there are errors or unknown conﬁguration entries in the retrieved ﬁle, the old one will be used.

3.3 Conﬁguration Items that Apply at Build Time

The following items in dot-config are used at build time; changing them in the installed version has no eﬀect:

CONFIG_BR2_CONFIGFILE

This string option lists a ﬁle to be used as Buildroot (BR2) conﬁguration. A simple ﬁlename or relative pathname refers to the configs/buildroot directory; an absolute pathname is used unchanged.

CONFIG_KEEP_ROOTFS

A boolean option for developers: if set the build script does not delete the temporary copy of the generated ﬁlesystem and reports its pathname in the build messages.

3.4 Conﬁguration Items that Apply at Run Time

The following items in dot-config are used at run time: at every boot the value (the old one or the just-downloaded one) is used in the appropriate way, before the respective service is started.

CONFIG_DOTCONF_SOURCE_LOCAL CONFIG_DOTCONF_SOURCE_REMOTE CONFIG_DOTCONF_SOURCE_FORCE_DHCP CONFIG_DOTCONF_SOURCE_TRY_DHCP CONFIG_DOTCONF_URL

The source and location of a conﬁg ﬁle to be used at a replacement the next time the system boots. See Section 3.1 [Dynamic WRS Conﬁguration], page 4, and Section 3.2 [The Conﬁguration File], page 4, for details.

CONFIG_ETH0_DHCP CONFIG_ETH0_DHCP_ONCE CONFIG_ETH0_STATIC

Conﬁguration of management port’s (eth0) IP. When CONFIG_ETH0_DHCP is used, then switch tries to obtain IP via DHCP forever. For option

Chapter 3: Conﬁguration of the Device 7

CONFIG_ETH0_DHCP_ONCE switch tries to get IP via DHCP once, if this try is unsuccessful then switch uses static IP. CONFIG_ETH0_STATIC forces switch to use provided static IP address.

CONFIG_ETH0_IP CONFIG_ETH0_MASK CONFIG_ETH0_NETWORK CONFIG_ETH0_BROADCAST CONFIG_ETH0_GATEWAY

Management port’s (eth0) static IP conﬁguration when CONFIG_ETH0_DHCP_ONCE or CONFIG_ETH0_STATIC parameter is used.

CONFIG_HOSTNAME_DHCP CONFIG_HOSTNAME_STATIC CONFIG_HOSTNAME_STRING

These options describe how to set hostname of the switch. From DHCP (CONFIG_HOSTNAME_DHCP) or use a predeﬁned value (CONFIG_HOSTNAME_STATIC) deﬁned in option CONFIG_HOSTNAME_STRING.

CONFIG_ROOT_PWD_IS_ENCRYPTED CONFIG_ROOT_PWD_CLEAR CONFIG_ROOT_PWD_CYPHER

This set of options allow setting the password for the “root” user (the administrator). The password is used to login to your switch using ssh (secure shell). If you choose CONFIG_ROOT_PWD_IS_ENCRYPTED, you will be prompted for a text version of a preencrypted password (CONFIG_ROOT_PWD_CYPHER). To encrypt your magic string, you must run “mkpasswd --method=md5 magic” on your Linux host (or switch). If you choose to conﬁgure an unencrypted password, then you are asked to specify it as CONFIG_ROOT_PWD_CLEAR. In this latter case encryption is performed at run-time to use the normal ssh authentication, but the clear-text password will remain in dot-config. By default the root password is an empty string, like in the initial wr-switch-sw releases.

CONFIG_NTP_SERVER

The NTP server used to prime White Rabbit time, at system boot. The option can be an IP address or a host name, if DNS is properly conﬁgured. The conﬁguration value is stored in /etc/wr_date.conf. An empty string (default) disables NTP access at boot time.

CONFIG_DNS_SERVER CONFIG_DNS_DOMAIN

The DNS server (as an IP address) and default domain. The values end up in /etc/resolv.conf of the runtime ﬁlesystem. By default the two strings are empty. If CONFIG_ETH0_DHCP or CONFIG_ETH0_DHCP_ONCE is used, /etc/resolv.conf ﬁle will be populated with DNS settings received from the DHCP server. If conﬁguration items for static (CONFIG_DNS_*) and dynamic (CONFIG_ETH0_DHCP) DNS conﬁguration are used simultaneously then information from both sources end up in the /etc/resolv.conf ﬁle. However, information from CONFIG_DNS_* is placed ﬁrst.

CONFIG_REMOTE_SYSLOG_SERVER CONFIG_REMOTE_SYSLOG_UDP

Conﬁguration for system log. The name (or IP address) of the server is stored in /etc/rsyslog.conf of the runtime ﬁlesystem. The UDP option, set by default, chooses UDP transmission; if unset it selects TCP communication.

Chapter 3: Conﬁguration of the Device 8

CONFIG_WRS_LOG_HAL CONFIG_WRS_LOG_RTU CONFIG_WRS_LOG_PTP CONFIG_WRS_LOG_OTHER

Logging options for the three main WRS processes and other programs. CONFIG_WRS_LOG_OTHER is currently used by:

• wrs_watchdog daemon

• wrs_throttling executed once at boot up

• wrs_auxclk executed once at boot up

• wrs_custom_boot_script.sh executed once at boot up

• Setting VLANs with vlan.sh at boot up

Each value can be a pathname, either to a ﬁle (e.g. /dev/kmsg is a possible “ﬁle” target) or a facility.level string, like daemon.debug, for syslog-based logging. An empty strings selects no logging at all. Please note, that unknown facility names will generate a runtime error on the switch. All four strings default to “daemon.info”.

Note: all messages produced by these programs if syslog is conﬁgured will be passed to the syslog at the same conﬁgured <facility>.<level>, no matter of verbosity of a message. To change the verbosity of programs please use CONFIG_WRS_LOG_LEVEL_*.

CONFIG_WRS_LOG_LEVEL_HAL CONFIG_WRS_LOG_LEVEL_RTU CONFIG_WRS_LOG_LEVEL_OTHER

Specify verbosity of programs as a string or number. The following levels are supported:

• ALERT or 1

• ERROR or 3

• WARNING or 4

• INFO or 6

• DEBUG or 7

Not supported levels are ceiled to the valid one. By leaving this item empty, programs will use its default verbosity level (INFO). Note: all messages produced by these programs if syslog is conﬁgured will be passed

to the syslog at the same conﬁgured <facility>.<level>, no matter of verbosity of a message.

CONFIG_WRS_LOG_LEVEL_PTP

Specify verbosity of PPSi daemon as a string. This string will be passed to the PPSI after -d parameter. Please refer to the PPSI’s documentation for more details.

By leaving this item empty, PPSi daemon will use its default verbosity level. Note: all messages produced by PPSi if syslog is conﬁgured will be passed to the

syslog at the same conﬁgured <facility>.<level>, no matter of verbosity of a message.

CONFIG_WRS_LOG_SNMPD

Value can be a pathname, either to a ﬁle (e.g. /dev/kmsg is a possible “ﬁle” target) or a valid snmpd log option (without -L). Allowed strings are in the format “S level facility” (e.g. “S 2 daemon”). For example, “s daemon” will forward messages to syslog with daemon as facility. To set level (i.e. 5) use “S 5 daemon”. For details please check man snmpcmd. An empty strings selects no logging at all. Please note that unknown facility names will generate a runtime error on the switch. NOTE: It looks like Notice is not a default logging priority as written in net-snmp manual.

+ 21 hidden pages