https://wiki.csimn.com/api.php?action=feedcontributions&user=Jimhogenson&feedformat=atomControl Solutions IoTServer Documentation - User contributions [en]2024-03-29T13:48:24ZUser contributionsMediaWiki 1.32.0https://wiki.csimn.com/index.php?title=Network&diff=1454Network2022-04-20T13:58:11Z<p>Jimhogenson: </p>
<hr />
<div>== Default Settings ==<br />
<br />
When the device is initially booted, eth0 will default to a static IPv4 address of 10.0.0.101. Eth1 will be set dynamically by your DHCP server on your network.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Interface !! Default IP<br />
|-<br />
| eth0 || 10.0.0.101<br />
|-<br />
| eth1 || DHCP/Dynamic<br />
|}<br />
<br />
== Network Settings ==<br />
[[File:Network settings page 1.jpg|850px]]<br />
<br />
Each device has two Ethernet ports called "eth0" and "eth1" on the device (eth0 illustrated above, both are available on the Networks page). The Ethernet ports support both IPv4 and IPV6. To change port settings, select Mode from the list. If static is selected, enter the IP address, netmask, and gateway. Then click Submit. Changes apply upon reboot of the IoTServer.<br />
<br />
IMPORTANT: You cannot put both Ethernet ports on the same subnet. When there are 2 interfaces on the same subnet there is no assurance as to which interface will be used to transmit traffic and the machine will accept traffic for either IP on either interface. This is because in Linux the IP address belongs to the host and is not associated with the interface.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Agent_Device_Edit&diff=1453SNMP Agent Device Edit2022-04-20T13:54:23Z<p>Jimhogenson: </p>
<hr />
<div>The DEVICES section in the SNMP server (agent) specify which remote SNMP devices traps or informs should be sent to as a result of the trap send rules.<br />
<br />
[[File:Snmp agent device edit 1.jpg]]<br />
<br />
'''Number''' – A number ranging from 1 to device table size, and was historically referenced in read and write maps as the device to which the map applied. However, with the implementation of device mask in the SNMP agent, the mask is what actually determines which device(s) the trap is sent to, and the same trap may be sent to multiple devices with only one trap rule as a result of the mask implementation. This number is therefore simply a row number on the list for database reference. <br />
<br />
[[File:Snmp agent device edit 2.jpg]]<br />
<br />
'''Name''' – Simply a reference in the web UI for the user to identify this device.<br />
<br />
[[File:Snmp agent device edit 3.jpg]]<br />
<br />
'''PeerName''' – Provides a definition of where on the network to find the device. The peername in simplest form will be an IP address as illustrated in the XML file example above. However, if the network has access to a DNS server and that server is configured in the network settings of the local device, then peername may be any name that can be found via DNS lookup.<br />
<br />
[[File:Snmp agent device edit 4.jpg]]<br />
<br />
'''Device Group''' – Select which groups this device is a member of. The device group allows selectively sending the same trap to multiple devices. Both the trap send rules and the trap devices have a group association. When the group association of a trap rule matches the groups that the device is a member of, the trap will be sent to that device, and all devices included in the group. <br />
<br />
The group selection is made as a bit mask labeled "DevMask" in CSV and XML files. Group "A" is bit 0 or value of 1. Group "B" is bit 1 or value of 2. Group "C" is bit 2 or value of 4, and so on. The mask is the summation of the groups. Only the first 8 bits are used in the web UI for ease of use. Internally, the test for group membership is a simple logical AND of the mask values found in the trap rule and the device configuration. <br />
<br />
[[File:Snmp agent device edit 5.jpg]]<br />
<br />
'''Version''' – Specifies what SNMP version should be used to send the trap, which in turn determines certain aspects of how the trap message is formatted. Version may be 1, 2, or 3 where 2 really means v2c.<br />
<br />
'''Community''' – Is the community string as defined for SNMP v1 and v2c.<br />
<br />
== SNMPv3 Configuration - The following parameters are used only for v3 ==<br />
<br />
[[File:Snmp agent device edit 6.jpg]]<br />
<br />
'''Security Level''' - Sets security level, 1=noAuthNoPriv, 2=authNoPriv, 3=authPriv. Those are the SNMP acronyms meaning (1) no authentication or privacy, (2) authentication required but privacy is not, (3) both authentication and privacy are required. The term “privacy” means encryption. <br />
<br />
'''User Name''' - Sets the SNMP security name, analogous to username in SNMP terms. <br />
<br />
'''Authentication Type''' - Sets the authentication type, may be “NOAUTH”, “MD5”, or “SHA”. It determines how the username (security name) is hashed when transmitted. <br />
<br />
'''Authentication Phrase''' - Sets the authentication phrase, analogous to an SNMP password. IMPORTANT: This string must be a minimum of 8 characters long. If less than 8 characters, authentication is guaranteed to fail. <br />
<br />
'''Privacy Type''' - Sets the privacy type, may be “NOPRIV”, “DES”, or “AES”. This determines which encryption algorithm will be used. <br />
<br />
'''Privacy Phrase''' - Sets the privacy phrase which is used as the encryption key. IMPORTANT: This string must be a minimum of 8 characters long. If less than 8 characters, decryption is guaranteed to fail. <br />
<br />
'''EngineId''' - Sets the engine ID that will be sent with the trap message if SNMPv3. (Used only for SNMPv3.)<br />
<br />
NOTE: The engine ID will be taken as a literal ASCII string (and probably not work) if it does not begin with “0x”. The recipient of an SNMPv3 trap will generally discard the message if the engine ID does not match its own engine ID. It is necessary to know quite a bit about where you are sending traps with v3.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Agent_Device_Edit&diff=1452SNMP Agent Device Edit2022-04-20T13:53:56Z<p>Jimhogenson: </p>
<hr />
<div>The DEVICES section in the SNMP server (agent) specify which remote SNMP devices traps or informs should be sent to as a result of the trap send rules.<br />
<br />
[[File:Snmp agent device edit 1.jpg]]<br />
<br />
'''Number''' – A number ranging from 1 to device table size, and was historically referenced in read and write maps as the device to which the map applied. However, with the implementation of device mask in the SNMP agent, the mask is what actually determines which device(s) the trap is sent to, and the same trap may be sent to multiple devices with only one trap rule as a result of the mask implementation. This number is therefore simply a row number on the list for database reference. <br />
<br />
[[File:Snmp agent device edit 2.jpg]]<br />
<br />
'''Name''' – Simply a reference in the web UI for the user to identify this device.<br />
<br />
[[File:Snmp agent device edit 3.jpg]]<br />
<br />
'''PeerName''' – Provides a definition of where on the network to find the device. The peername in simplest form will be an IP address as illustrated in the XML file example above. However, if the network has access to a DNS server and that server is configured in the network settings of the local device, then peername may be any name that can be found via DNS lookup.<br />
<br />
[[File:Snmp agent device edit 4.jpg]]<br />
<br />
'''Device Group''' – Select which groups this device is a member of. The device group allows selectively sending the same trap to multiple devices. Both the trap send rules and the trap devices have a group association. When the group association of a trap rule matches the groups that the device is a member of, the trap will be sent to that device, and all devices included in the group. <br />
<br />
The group selection is made as a bit mask labeled "DevMask" in CSV and XML files. Group "A" is bit 0 or value of 1. Group "B" is bit 1 or value of 2. Group "C" is bit 2 or value of 4, and so on. The mask is the summation of the groups. Only the first 8 bits are used in the web UI for ease of use. Internally, the test for group membership is a simple logical AND of the mask values found in the trap rule and the device configuration. <br />
<br />
[[File:Snmp agent device edit 5.jpg]]<br />
<br />
'''Version''' – Specifies what SNMP version should be used to send the trap, which in turn determines certain aspects of how the trap message is formatted. Version may be 1, 2, or 3 where 2 really means v2c.<br />
<br />
'''Community''' – Is the community string as defined for SNMP v1 and v2c.<br />
<br />
== SNMPv3 Configuration - The following parameters are used only for v3 ==<br />
<br />
[[File:Snmp agent device edit 6.jpg]]<br />
<br />
'''Security Level''' - Sets security level, 1=noAuthNoPriv, 2=authNoPriv, 3=authPriv. Those are the SNMP acronyms meaning (1) no authentication or privacy, (2) authentication required but privacy is not, (3) both authentication and privacy are required. The term “privacy” means encryption. <br />
<br />
'''User Name''' - Sets the SNMP security name, analogous to username in SNMP terms. <br />
<br />
'''Authentication Type''' - Sets the authentication type, may be “NOAUTH”, “MD5”, or “SHA”. It determines how the username (security name) is hashed when transmitted. <br />
<br />
'''Authentication Phrase''' - Sets the authentication phrase, analogous to an SNMP password. IMPORTANT: This string must be a minimum of 8 characters long. If less than 8 characters, authentication is guaranteed to fail. <br />
<br />
'''Privacy Type''' - Sets the privacy type, may be “NOPRIV”, “DES”, or “AES”. This determines which encryption algorithm will be used. <br />
<br />
'''Privacy Phrase''' - Sets the privacy phrase which is used as the encryption key. This string must be a minimum of 8 characters long. If less than 8 characters, decryption is guaranteed to fail. <br />
<br />
'''EngineId''' - Sets the engine ID that will be sent with the trap message if SNMPv3. (Used only for SNMPv3.)<br />
<br />
NOTE: The engine ID will be taken as a literal ASCII string (and probably not work) if it does not begin with “0x”. The recipient of an SNMPv3 trap will generally discard the message if the engine ID does not match its own engine ID. It is necessary to know quite a bit about where you are sending traps with v3.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=User_Settings&diff=1451User Settings2021-05-19T13:16:38Z<p>Jimhogenson: </p>
<hr />
<div>== User Settings ==<br />
[[File:User settings edit 1.jpg]]<br />
<br />
Local users can be edited by choosing their name from the list found in System->Users, or they can edit themselves by clicking on "User Settings" in the top right corner of any web page.<br />
<br />
[[File:User settings edit 2.jpg]]<br />
<br />
A password and username can be set on this page. Users will be assigned access permissions, or "roles," as well. A user that logs into the local web interface would be required to have "Web" permissions.<br />
<br />
== Modbus User Settings ==<br />
[[File:User settings edit 2a.jpg]]<br />
<br />
Every local user has the option of setting the display settings for Modbus registers. The user can select:<br />
* Address<br />
* Number<br />
* Modicon<br />
<br />
Once a local user selects a format, all Modbus registers will be formatted as such throughout the web UI.<br />
<br />
== SNMP Settings ==<br />
[[File:User settings edit 3.jpg]]<br />
<br />
Any user that will be accessing the IoTServer using SNMPv3 will require additional settings for authentication and privacy. Those are provided here. The definition of "user" can include other machines that wish to query the MIB in the IoTServer. IMPORTANT: Use a passphrase of at least 10 characters. A very short phrase will be rejected by the encryption algorithm and be indicated as an encryption error.<br />
<hr><br />
[[File:User settings edit 4.jpg]]<br />
<br />
Any device that will be sending SNMPv3 traps to this IoTServer will require its own user credentials. In addition to the authentication and privacy settings required for any SNMPv3 user, the trap receiver user must also include the Engine ID of the device that will be sending traps to this IoTServer. If all credentials including Engine ID do not match, then the received trap will be discarded. <br />
<br />
== Other Notes ==<br />
<br />
Note: Users logging in via RADIUS will not have the opportunity to edit their profiles. In this case, they are defaulted to web only users with a default Modbus number display format. Passwords and usernames are controlled by the registered RADIUS server.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Client_Device_Edit&diff=1450SNMP Client Device Edit2021-05-19T13:15:11Z<p>Jimhogenson: </p>
<hr />
<div>This page is where you set up the devices that will be polled (SNMP Get, Set, Get-Next) as defined by the read maps, write maps, and table walk rules. The full set of parameters required for each device is set up once here, and then referenced by device number in any number of maps and rules. <br />
<br />
[[File:Snmp client device edit 1.jpg]]<br />
<br />
'''Device Number''' – A number ranging from 1 to device table size, and is referenced in read and write maps, and table walk rules, as the device to which the map applies.<br />
<br />
[[File:Snmp client device edit 2.jpg]]<br />
<br />
'''Name''' – Simply provides a reference name for use in the web UI.<br />
<br />
[[File:Snmp client device edit 3.jpg]]<br />
<br />
'''Peer Name''' – Provides a definition of where on the network to find the device. The peername in simplest form will be an IP address as illustrated in the XML file example above. However, if the network has access to a DNS server and that server is configured in the network settings of the local device, then peername may be any name that can be found via DNS lookup. <br />
<br />
[[File:Snmp client device edit 4.jpg]]<br />
<br />
'''Version''' – Specifies what SNMP version should be used to send the SNMP Get or Set, which in turn determines certain aspects of how the message is formatted. Version may be 1, 2, or 3 where 2 means v2c.<br />
<br />
'''Rate''' – Real or integer poll time in seconds, can be fractional. Used as default when read, write, or walk rule does not have a poll time specified.<br />
<br />
[[File:Snmp client device edit 5.jpg]]<br />
<br />
'''Timeout''' – Integer number of seconds for session timeout.<br />
<br />
'''Retries''' – Number of times that the SNMP engine should automatically retry a Get or Set if it fails. <br />
<br />
[[File:Snmp client device edit 6.jpg]]<br />
<br />
'''Max Var Binds''' – Specifies the maximum number of varbinds that may be included in the same request. When multiple values are requested from the same device, the client will attempt to group them into a single SNMP Get or Set for efficiency (less network traffic). The client will group up to this many varbinds into the same request. <br />
<br />
'''Poll Tolerance''' – Real or integer poll tolerance in seconds, can be fractional. Poll tolerance refers to the amount of time overlap permitted when the client is attempting to group varbinds into a single Get or Set. In other words, if a map or rule timeout is not quite zero but is less than the poll tolerance, it will be treated as zero and grouped into the Get or Set that is already under way.<br />
<br />
== SNMPv2 Configuration - The following parameters are used only for v1/v2c ==<br />
<br />
[[File:Snmp client device edit 7.jpg]]<br />
<br />
'''Max Receive Size''' – Provides a limit on the maximum message size that should be accepted, defaults to 1500 if omitted (recommended). <br />
<br />
'''Max Send Size''' – Provides a limit on the maximum message size that should be sent, defaults to 1500 if omitted (recommended). The maxVarBinds should be set to 1 if the maxSendSize is reduced. <br />
<br />
'''Community''' – The community string as defined for SNMP v1 and v2c.<br />
<br />
== SNMPv3 Configuration - The following parameters are used only for v3 ==<br />
<br />
[[File:Snmp client device edit 8.jpg]]<br />
<br />
'''Security Level''' - Sets security level, 1=noAuthNoPriv, 2=authNoPriv, 3=authPriv. Those are the SNMP acronyms meaning (1) no authentication or privacy, (2) authentication required but privacy is not, (3) both authentication and privacy are required. The term “privacy” means encryption. <br />
<br />
'''User Name''' - Sets the SNMP security name, analogous to username in SNMP terms. <br />
<br />
'''Authentication Type''' - Sets the authentication type, may be “NOAUTH”, “MD5”, or “SHA”. It determines how the username (security name) is hashed when transmitted. <br />
<br />
'''Authentication Phrase''' - Sets the authentication phrase, analogous to an SNMP password. IMPORTANT: Use a phrase of at least 10 characters. A very short phrase will be rejected by the encryption algorithm and be indicated as an encryption error. <br />
<br />
'''Privacy Type''' - Sets the privacy type, may be “NOPRIV”, “DES”, or “AES”. This determines which encryption algorithm will be used. <br />
<br />
'''Privacy Phrase''' - Sets the privacy phrase which is used as the encryption key. IMPORTANT: Use a phrase of at least 10 characters. A very short phrase will be rejected by the encryption algorithm and be indicated as an encryption error.<br />
<br />
Note: For sending traps with SNMPv3, you must know the engine ID of the recipient. The SNMPv3 client, however, will query the remote agent to learn engine ID as well as engine time and boots. It will then use this information to do the actual data query.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Trap_Receiver_Task&diff=1449SNMP Trap Receiver Task2020-04-16T01:57:20Z<p>Jimhogenson: </p>
<hr />
<div>[[File:Task manager config snmp trap receiver.jpg]]<br />
<br />
The maximum table sizes for the SNMP Trap Receiver are defined here. Keeping the tables set to a range that you will actually use will improve efficiency.<br />
<br />
The default XML configuration file is entered here. This is the file that the SNMP Trap Receiver will attempt to automatically load upon first time startup. After that, settings are retained in the database, and further file activity can be managed on the Config File page for the SNMP Trap Receiver.<br />
<br />
Activity timeout is a form of watchdog. If the task manager does not see the SNMP Trap Receiver task update its activity indicator within this amount of time, the task manager will restart the SNMP Trap Receiver. If set to zero, the watchdog is disabled. The task manager itself is restarted by the Linux cron if it stops responding.<br />
<br />
IMPORTANT: Do not set the activity timeout for SNMP to less than 120 seconds. While the SNMP functions will update their timers much faster during normal operation, they will time out during startup while waiting for all of the background SNMP tasks and daemons to start. Setting the activity timeout too short for SNMP tasks will result in a system that can never fully start up.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Agent_Task&diff=1448SNMP Agent Task2020-04-16T01:56:53Z<p>Jimhogenson: </p>
<hr />
<div>[[File:Task manager config snmp agent.jpg|850px]]<br />
<br />
There are four branches in the IoTServer's MIB where you can map data objects. All four tables will be set to the same length that you specify as MIB Table Size here. <br />
<br />
If you will be mapping floating point data in your MIB, you must select how you would like it to be encoded. There is no universally recognized representation of floating point in SNMP, but there are de facto standards to choose from. The floating point encodings available are included in the drop-down list. ASN Opaque refers to the Net-SNMP definition for floating point.<br />
<br />
The maximum table sizes for the trap sender are defined here. Keeping the tables set to a range that you will actually use will improve efficiency.<br />
<br />
The default XML configuration file is entered here. This is the file that the SNMP Agent will attempt to automatically load upon first time startup. After that, settings are retained in the database, and further file activity can be managed on the Config File page for the SNMP Agent.<br />
<br />
Activity timeout is a form of watchdog. If the task manager does not see the SNMP Agent task update its activity indicator within this amount of time, the task manager will restart the SNMP Agent. If set to zero, the watchdog is disabled. The task manager itself is restarted by the Linux cron if it stops responding.<br />
<br />
IMPORTANT: Do not set the activity timeout for SNMP to less than 120 seconds. While the SNMP functions will update their timers much faster during normal operation, they will time out during startup while waiting for all of the background SNMP tasks and daemons to start. Setting the activity timeout too short for SNMP tasks will result in a system that can never fully start up.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Client_Task&diff=1447SNMP Client Task2020-04-16T01:55:13Z<p>Jimhogenson: </p>
<hr />
<div>[[File:Task manager config snmp client.jpg]]<br />
<br />
The maximum table sizes for the SNMP Client are defined here. Keeping the tables set to a range that you will actually use will improve efficiency.<br />
<br />
The default XML configuration file is entered here. This is the file that the SNMP Client will attempt to automatically load upon first time startup. After that, settings are retained in the database, and further file activity can be managed on the Config File page for the SNMP Client.<br />
<br />
Activity timeout is a form of watchdog. If the task manager does not see the SNMP Client task update its activity indicator within this amount of time, the task manager will restart the SNMP Client. If set to zero, the watchdog is disabled. The task manager itself is restarted by the Linux cron if it stops responding.<br />
<br />
IMPORTANT: Do not set the activity timeout for SNMP to less than 120 seconds. While the SNMP functions will update their timers much faster during normal operation, they will time out during startup while waiting for all of the background SNMP tasks and daemons to start. Setting the activity timeout too short for SNMP tasks will result in a system that can never fully start up.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Client_Task&diff=1446SNMP Client Task2020-04-16T01:53:12Z<p>Jimhogenson: </p>
<hr />
<div>[[File:Task manager config snmp client.jpg]]<br />
<br />
The maximum table sizes for the SNMP Client are defined here. Keeping the tables set to a range that you will actually use will improve efficiency.<br />
<br />
The default XML configuration file is entered here. This is the file that the SNMP Client will attempt to automatically load upon first time startup. After that, settings are retained in the database, and further file activity can be managed on the Config File page for the SNMP Client.<br />
<br />
Activity timeout is a form of watchdog. If the task manager does not see the SNMP Client task update its activity indicator within this amount of time, the task manager will restart the SNMP Client. If set to zero, the watchdog is disabled. The task manager itself is restarted by the Linux cron if it stops responding.<br />
<br />
IMPORTANT: Do not set the activity timeout for SNMP to less than 120 seconds. While the client will update its timer much faster than that during normal operation, it will time out during startup while it waits for all of the SNMP tasks to start. Setting the activity timeout too short on the SNMP client will result in a system that can never fully start up.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Hardware_Details&diff=1445Hardware Details2019-06-12T15:59:03Z<p>Jimhogenson: </p>
<hr />
<div>== Communication Port Designations ==<br />
[[File:BB4-8422 ports.jpg]]<br />
<br />
Port numbers are sometimes referred to generically just by number in the web UI in the BB4-8422. Ports 0 and 1 will always refer to Ethernet. Ports 2 and 3 will always refer to serial ports 2 and 3. <br />
<br />
Connect power with V+ of a DC supply connected to the V+ terminal and V- or ground/common to the GND termainal of the power connector. If connecting an AC supply, connect one terminal of the AC supply to V+ and the other to GND making sure any other instances of using the same AC supply connect the same side of AC to GND (ground/common). <br />
<br />
The BB4-8422 will operate on 12 to 24 VDC or 24 VAC. Power requirement at 24VDC is 0.5A. Power requirement at 12VDC would be 1.0A. <br />
<br />
== Connectors and Pin-Outs ==<br />
[[File:BB4-8422 back side.jpg]]<br />
<br />
The connector pin-outs for the 3-position screw terminals are displayed on the back side of the BB4-8422. The D+ and D- are the positive and negative pins for RS-485 (EIA-485). These ports are electrically isolated from each other and from power. <br />
<br />
Both Ethernet ports support full duplex 100BaseT. Only eth0 supports half duplex 10BaseT. <br />
<br />
== USB Port ==<br />
<br />
Any standard Flash drive (FAT32 format) plugged into the USB port will automatically mount at /home/customer/usb/. Software updates for Babel Buster 4 will be loaded via the Flash drive with the support of the [[Software]] web page. <br />
<br />
Theoretically you could transfer configuration files using a Flash drive; however, it is actually going to be quicker to use the file management provided via the Config File page in the web UI. To access the USB drive as just an ordinary drive would require logging in via SSH and using standard Linux shell commands. Accessing the USB Flash drive this way should be reserved for "experts only". <br />
<br />
== IoTServer Communication LED Indications ==<br />
<br />
The LEDs labeled RQ2 and RP2 indicate communication on serial port 2 while RQ3 and RP3 indicate communication on serial port 3. <br />
<br />
Behavior of the communication LEDs may vary by protocol, but in general, RQx will flash yellow (amber) when a client or master sends a request, or when a server or slave receives a request. Generally whether acting as client or server (master or slave), the RPx will flash green indicating a good response or red indicating an error response or timeout.<br />
<br />
== IoTServer Status LED Indications and Reset Button Handling ==<br />
<br />
LED indications on STA (yellow/green) and STB (red/green) provide a very simplistic user interface for the reset button, progress indication during bootup, and status or error indications during normal operation. <br />
<br />
Operating sequence starting from bootup:<br />
<br />
(a) If button down, enter button down mode.<br><br />
(b) If bootup in progress, process bootup mode until complete.<br><br />
(c) Enter normal mode.<br><br />
(d) While in normal mode, if button pressed, enter button down mode.<br><br />
<br />
== Bootup Mode ==<br />
<br />
Bootup mode indication codes:<br />
* Boot code will turn on STA yellow solid, STB red solid<br />
* Upon successful bootup, STA, STB flash inverse heartbeat pattern of off with brief green flash on once a second.<br />
<br />
Bootup mode operation:<br />
<br />
Upon task manager startup, it must check to see if the reset button is being held down during boot. This is done as follows: Task manager spawns indicator thread, then waits for thread to set indicator mode to either preboot or boot. If preboot, then wait for option to get set and execute it. If boot, load task array from DB or XML and then set boot ready flag in indicator structure. <br />
<br />
Following bootup, during normal operation, the task manager will check the indicator mode for postboot and check for postboot selection. If selection has been made, then execute it. <br />
<br />
Boot mode exits when all tasks with nonzero process key have a nonzero process status.<br />
Task errors will be indicated in task structure status and picked up by Normal Mode.<br />
<br />
== Normal Mode ==<br />
<br />
Normal mode indication codes:<br />
<br />
Yellow codes (STA):<br />
* 1 = Modbus TCP comm error exists (RTU not indicated here, they have own LEDs)<br />
* 2 = SNMP comm error exists<br />
<br />
Red codes (STB):<br />
* 1 = Error indicated in errval[3] - initialization error, coprocessor fail, etc.<br />
* 2 = Task status indicates fault<br />
* 3 = Update fail (can be firmware update fail, or failure of other requested action e.g. IP address reset)<br />
<br />
Note: Red codes are not likely to go away until reboot, and may return upon reboot if there is a serious problem with the system. Yellow codes will go away if the problem goes away (e.g. Modbus wasn’t talking but is now). <br />
<br />
Normal mode operation:<br />
<br />
If there is a red code, STA will be off while STB blinks the red code.<br />
If no red code, STB will be off and STA will blink the yellow code(s).<br />
If no red or yellow codes, both STA and STB will flash the green heartbeat pattern.<br />
<br />
Code is off with brief flashes on to count out code.<br />
Heartbeat is both STA and STB green, with brief flash off once a second.<br />
<br />
Yellow codes will be all flashed in sequence.<br />
Red code will flash only highest numbered code.<br />
<br />
During normal mode, the LED thread will routinely scan task status structures checking for errors/faults.<br />
<br />
<br />
== Button-Down Mode ==<br />
<br />
There is a hidden reset button accessible through a tiny hole in the top of the IoTServer (Babel Buster 4) enclosure. Use a small tool or paper clip to press and hold the button until the desired code is being flashed. Release the button to select that code. The available codes will flash in sequence. Count the flashes between longer pauses. Pre-boot means hold the button down while applying power to the IoTServer. Post-boot means allow the IoTServer to fully boot up, and then press the button. See additional notes below.<br />
<br />
Button-down indication codes:<br />
<br />
Pre-boot options:<br />
* 1: start with no tasks, task manager only (red code 1)<br />
* 2: clear all configuration (red code 2)<br />
<br />
Post-boot options:<br />
* 1: reboot system (green code 1)<br />
* 2: shut down all tasks (green code 2)<br />
* 3: reset Admin password for web UI (green code 3) <br />
* 4: reset root password for SSH login (green code 4)<br />
* 5: reset IP address to IPv4 10.0.0.101 (green code 5) <br />
<br />
Button-down operation:<br />
<br />
Button down is indicated by STA flashing yellow rapidly. Codes are indicated on STB.<br />
<br />
(a) Pre-boot flashes yellow rapidly on STA while blinking red code on STB while button down.<br><br />
(b) Post-boot flashes yellow rapidly on STA while blinking green code on STB while button down. <br><br />
(c) Button up: Flashes green rapidly on STA while flashing same code on STB (red or green as applicable)<br><br />
<br />
STA will flash yellow rapidly while STB is cycling through button codes while button is held down. After button released, STA will flash rapid green while STB blinks selected code for 5 full sequences. If button is pressed again during this time, action is cancelled. If not cancelled, then after 5th sequence, STA & STB both go off until finished with requested action. Then STA green solid while flashing STB red with single sequence of code just completed. <br />
<br />
Note: For long operations such as coprocessor firmware update, blinking selected code on STB once every 5 seconds along with STA blinking green in sync with STB. Only the pre-boot options would take time, so this means STA blinks green while STB blinks red for 1-4 times, once every 5 seconds. <br />
<br />
Note: Server software updates will be implemented via startup script and USB flash drive. No button mode is required for server updates. <br />
<br />
== Mounting Bracket ==<br />
[[File:BB4-8422-bracket-view-1.jpg]]<br />
<br />
The BB4-8422 comes with a mounting bracket that can be used for either DIN rail mounting or wall mounting. To wall mount, start by screwing the bracket to the wall using the two screw holes in the bracket. Screws with washers are recommended (not included). To DIN rail mount, start by pressing the mounting bracket into the clips on the enclosure (this is normally the way the BB2-8422 will be shipped).<br />
<br />
[[File:BB4-8422-bracket-view-2.jpg]]<br />
<br />
The BB4-8422 enclosure should look like the above photo when ready to DIN rail mount. Note that the “spring” in the clip is toward the bottom. To mount on the rail, hook the top of the clip in the rail, and push on the bottom of the enclosure until the bottom snaps in place on the rail. <br />
<br />
To remove from the DIN rail, push up on the bottom while pulling out at the top. Do the same if wall mounted. Generally the mounting clip will come off the DIN rail. If wall mounted, then the clip remains on the wall while the enclosure snaps off the clip. <br />
<br />
[[File:BB4-8422-bracket-view-3.jpg]]</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=File:BB4-8422-bracket-view-3.jpg&diff=1444File:BB4-8422-bracket-view-3.jpg2019-06-12T15:57:22Z<p>Jimhogenson: </p>
<hr />
<div></div>Jimhogensonhttps://wiki.csimn.com/index.php?title=File:BB4-8422-bracket-view-2.jpg&diff=1443File:BB4-8422-bracket-view-2.jpg2019-06-12T15:57:13Z<p>Jimhogenson: </p>
<hr />
<div></div>Jimhogensonhttps://wiki.csimn.com/index.php?title=File:BB4-8422-bracket-view-1.jpg&diff=1442File:BB4-8422-bracket-view-1.jpg2019-06-12T15:57:01Z<p>Jimhogenson: </p>
<hr />
<div></div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Hardware_Details&diff=1441Hardware Details2019-05-30T01:08:56Z<p>Jimhogenson: /* Normal Mode */</p>
<hr />
<div>== Communication Port Designations ==<br />
[[File:BB4-8422 ports.jpg]]<br />
<br />
Port numbers are sometimes referred to generically just by number in the web UI in the BB4-8422. Ports 0 and 1 will always refer to Ethernet. Ports 2 and 3 will always refer to serial ports 2 and 3. <br />
<br />
Connect power with V+ of a DC supply connected to the V+ terminal and V- or ground/common to the GND termainal of the power connector. If connecting an AC supply, connect one terminal of the AC supply to V+ and the other to GND making sure any other instances of using the same AC supply connect the same side of AC to GND (ground/common). <br />
<br />
The BB4-8422 will operate on 12 to 24 VDC or 24 VAC. Power requirement at 24VDC is 0.5A. Power requirement at 12VDC would be 1.0A. <br />
<br />
== Connectors and Pin-Outs ==<br />
[[File:BB4-8422 back side.jpg]]<br />
<br />
The connector pin-outs for the 3-position screw terminals are displayed on the back side of the BB4-8422. The D+ and D- are the positive and negative pins for RS-485 (EIA-485). These ports are electrically isolated from each other and from power. <br />
<br />
Both Ethernet ports support full duplex 100BaseT. Only eth0 supports half duplex 10BaseT. <br />
<br />
== USB Port ==<br />
<br />
Any standard Flash drive (FAT32 format) plugged into the USB port will automatically mount at /home/customer/usb/. Software updates for Babel Buster 4 will be loaded via the Flash drive with the support of the [[Software]] web page. <br />
<br />
Theoretically you could transfer configuration files using a Flash drive; however, it is actually going to be quicker to use the file management provided via the Config File page in the web UI. To access the USB drive as just an ordinary drive would require logging in via SSH and using standard Linux shell commands. Accessing the USB Flash drive this way should be reserved for "experts only". <br />
<br />
== IoTServer Communication LED Indications ==<br />
<br />
The LEDs labeled RQ2 and RP2 indicate communication on serial port 2 while RQ3 and RP3 indicate communication on serial port 3. <br />
<br />
Behavior of the communication LEDs may vary by protocol, but in general, RQx will flash yellow (amber) when a client or master sends a request, or when a server or slave receives a request. Generally whether acting as client or server (master or slave), the RPx will flash green indicating a good response or red indicating an error response or timeout.<br />
<br />
== IoTServer Status LED Indications and Reset Button Handling ==<br />
<br />
LED indications on STA (yellow/green) and STB (red/green) provide a very simplistic user interface for the reset button, progress indication during bootup, and status or error indications during normal operation. <br />
<br />
Operating sequence starting from bootup:<br />
<br />
(a) If button down, enter button down mode.<br><br />
(b) If bootup in progress, process bootup mode until complete.<br><br />
(c) Enter normal mode.<br><br />
(d) While in normal mode, if button pressed, enter button down mode.<br><br />
<br />
== Bootup Mode ==<br />
<br />
Bootup mode indication codes:<br />
* Boot code will turn on STA yellow solid, STB red solid<br />
* Upon successful bootup, STA, STB flash inverse heartbeat pattern of off with brief green flash on once a second.<br />
<br />
Bootup mode operation:<br />
<br />
Upon task manager startup, it must check to see if the reset button is being held down during boot. This is done as follows: Task manager spawns indicator thread, then waits for thread to set indicator mode to either preboot or boot. If preboot, then wait for option to get set and execute it. If boot, load task array from DB or XML and then set boot ready flag in indicator structure. <br />
<br />
Following bootup, during normal operation, the task manager will check the indicator mode for postboot and check for postboot selection. If selection has been made, then execute it. <br />
<br />
Boot mode exits when all tasks with nonzero process key have a nonzero process status.<br />
Task errors will be indicated in task structure status and picked up by Normal Mode.<br />
<br />
== Normal Mode ==<br />
<br />
Normal mode indication codes:<br />
<br />
Yellow codes (STA):<br />
* 1 = Modbus TCP comm error exists (RTU not indicated here, they have own LEDs)<br />
* 2 = SNMP comm error exists<br />
<br />
Red codes (STB):<br />
* 1 = Error indicated in errval[3] - initialization error, coprocessor fail, etc.<br />
* 2 = Task status indicates fault<br />
* 3 = Update fail (can be firmware update fail, or failure of other requested action e.g. IP address reset)<br />
<br />
Note: Red codes are not likely to go away until reboot, and may return upon reboot if there is a serious problem with the system. Yellow codes will go away if the problem goes away (e.g. Modbus wasn’t talking but is now). <br />
<br />
Normal mode operation:<br />
<br />
If there is a red code, STA will be off while STB blinks the red code.<br />
If no red code, STB will be off and STA will blink the yellow code(s).<br />
If no red or yellow codes, both STA and STB will flash the green heartbeat pattern.<br />
<br />
Code is off with brief flashes on to count out code.<br />
Heartbeat is both STA and STB green, with brief flash off once a second.<br />
<br />
Yellow codes will be all flashed in sequence.<br />
Red code will flash only highest numbered code.<br />
<br />
During normal mode, the LED thread will routinely scan task status structures checking for errors/faults.<br />
<br />
<br />
== Button-Down Mode ==<br />
<br />
There is a hidden reset button accessible through a tiny hole in the top of the IoTServer (Babel Buster 4) enclosure. Use a small tool or paper clip to press and hold the button until the desired code is being flashed. Release the button to select that code. The available codes will flash in sequence. Count the flashes between longer pauses. Pre-boot means hold the button down while applying power to the IoTServer. Post-boot means allow the IoTServer to fully boot up, and then press the button. See additional notes below.<br />
<br />
Button-down indication codes:<br />
<br />
Pre-boot options:<br />
* 1: start with no tasks, task manager only (red code 1)<br />
* 2: clear all configuration (red code 2)<br />
<br />
Post-boot options:<br />
* 1: reboot system (green code 1)<br />
* 2: shut down all tasks (green code 2)<br />
* 3: reset Admin password for web UI (green code 3) <br />
* 4: reset root password for SSH login (green code 4)<br />
* 5: reset IP address to IPv4 10.0.0.101 (green code 5) <br />
<br />
Button-down operation:<br />
<br />
Button down is indicated by STA flashing yellow rapidly. Codes are indicated on STB.<br />
<br />
(a) Pre-boot flashes yellow rapidly on STA while blinking red code on STB while button down.<br><br />
(b) Post-boot flashes yellow rapidly on STA while blinking green code on STB while button down. <br><br />
(c) Button up: Flashes green rapidly on STA while flashing same code on STB (red or green as applicable)<br><br />
<br />
STA will flash yellow rapidly while STB is cycling through button codes while button is held down. After button released, STA will flash rapid green while STB blinks selected code for 5 full sequences. If button is pressed again during this time, action is cancelled. If not cancelled, then after 5th sequence, STA & STB both go off until finished with requested action. Then STA green solid while flashing STB red with single sequence of code just completed. <br />
<br />
Note: For long operations such as coprocessor firmware update, blinking selected code on STB once every 5 seconds along with STA blinking green in sync with STB. Only the pre-boot options would take time, so this means STA blinks green while STB blinks red for 1-4 times, once every 5 seconds. <br />
<br />
Note: Server software updates will be implemented via startup script and USB flash drive. No button mode is required for server updates. </div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Hardware_Details&diff=1440Hardware Details2019-05-29T15:35:23Z<p>Jimhogenson: /* Normal Mode */</p>
<hr />
<div>== Communication Port Designations ==<br />
[[File:BB4-8422 ports.jpg]]<br />
<br />
Port numbers are sometimes referred to generically just by number in the web UI in the BB4-8422. Ports 0 and 1 will always refer to Ethernet. Ports 2 and 3 will always refer to serial ports 2 and 3. <br />
<br />
Connect power with V+ of a DC supply connected to the V+ terminal and V- or ground/common to the GND termainal of the power connector. If connecting an AC supply, connect one terminal of the AC supply to V+ and the other to GND making sure any other instances of using the same AC supply connect the same side of AC to GND (ground/common). <br />
<br />
The BB4-8422 will operate on 12 to 24 VDC or 24 VAC. Power requirement at 24VDC is 0.5A. Power requirement at 12VDC would be 1.0A. <br />
<br />
== Connectors and Pin-Outs ==<br />
[[File:BB4-8422 back side.jpg]]<br />
<br />
The connector pin-outs for the 3-position screw terminals are displayed on the back side of the BB4-8422. The D+ and D- are the positive and negative pins for RS-485 (EIA-485). These ports are electrically isolated from each other and from power. <br />
<br />
Both Ethernet ports support full duplex 100BaseT. Only eth0 supports half duplex 10BaseT. <br />
<br />
== USB Port ==<br />
<br />
Any standard Flash drive (FAT32 format) plugged into the USB port will automatically mount at /home/customer/usb/. Software updates for Babel Buster 4 will be loaded via the Flash drive with the support of the [[Software]] web page. <br />
<br />
Theoretically you could transfer configuration files using a Flash drive; however, it is actually going to be quicker to use the file management provided via the Config File page in the web UI. To access the USB drive as just an ordinary drive would require logging in via SSH and using standard Linux shell commands. Accessing the USB Flash drive this way should be reserved for "experts only". <br />
<br />
== IoTServer Communication LED Indications ==<br />
<br />
The LEDs labeled RQ2 and RP2 indicate communication on serial port 2 while RQ3 and RP3 indicate communication on serial port 3. <br />
<br />
Behavior of the communication LEDs may vary by protocol, but in general, RQx will flash yellow (amber) when a client or master sends a request, or when a server or slave receives a request. Generally whether acting as client or server (master or slave), the RPx will flash green indicating a good response or red indicating an error response or timeout.<br />
<br />
== IoTServer Status LED Indications and Reset Button Handling ==<br />
<br />
LED indications on STA (yellow/green) and STB (red/green) provide a very simplistic user interface for the reset button, progress indication during bootup, and status or error indications during normal operation. <br />
<br />
Operating sequence starting from bootup:<br />
<br />
(a) If button down, enter button down mode.<br><br />
(b) If bootup in progress, process bootup mode until complete.<br><br />
(c) Enter normal mode.<br><br />
(d) While in normal mode, if button pressed, enter button down mode.<br><br />
<br />
== Bootup Mode ==<br />
<br />
Bootup mode indication codes:<br />
* Boot code will turn on STA yellow solid, STB red solid<br />
* Upon successful bootup, STA, STB flash inverse heartbeat pattern of off with brief green flash on once a second.<br />
<br />
Bootup mode operation:<br />
<br />
Upon task manager startup, it must check to see if the reset button is being held down during boot. This is done as follows: Task manager spawns indicator thread, then waits for thread to set indicator mode to either preboot or boot. If preboot, then wait for option to get set and execute it. If boot, load task array from DB or XML and then set boot ready flag in indicator structure. <br />
<br />
Following bootup, during normal operation, the task manager will check the indicator mode for postboot and check for postboot selection. If selection has been made, then execute it. <br />
<br />
Boot mode exits when all tasks with nonzero process key have a nonzero process status.<br />
Task errors will be indicated in task structure status and picked up by Normal Mode.<br />
<br />
== Normal Mode ==<br />
<br />
Normal mode indication codes:<br />
<br />
Yellow codes (STA):<br />
* 1 = Modbus TCP comm error exists (RTU not indicated here, they have own LEDs)<br />
* 2 = SNMP comm error exists<br />
<br />
Red codes (STB):<br />
* 1 = Error indicated in errval[3] - initialization error, coprocessor fail, etc.<br />
* 2 = Task status indicates fault<br />
* 3 = Update fail (can be firmware update fail, or failure of other requested action e.g. IP address reset)<br />
<br />
Note: Red codes are not likely to go away until reboot, and may return upon reboot if there is a serious problem with the system. Yellow codes will go away if the problem goes away (e.g. Modbus wasn’t talking but is now). <br />
<br />
Normal mode operation:<br />
<br />
If there is a red code, STA will flash yellow rapidly while STB blinks the red code(s).<br />
If no red code, STB will be off and STA will blink the yellow code(s).<br />
If no red or yellow codes, flash both STA and STB green heartbeat pattern.<br />
<br />
Code is off with brief flashes on to count out code.<br />
Heartbeat is both STA and STB green, with brief flash off once a second.<br />
<br />
Yellow codes will be all flashed in sequence.<br />
Red code will flash only highest numbered code.<br />
<br />
During normal mode, the LED thread will routinely scan task status structures checking for errors/faults.<br />
<br />
<br />
== Button-Down Mode ==<br />
<br />
There is a hidden reset button accessible through a tiny hole in the top of the IoTServer (Babel Buster 4) enclosure. Use a small tool or paper clip to press and hold the button until the desired code is being flashed. Release the button to select that code. The available codes will flash in sequence. Count the flashes between longer pauses. Pre-boot means hold the button down while applying power to the IoTServer. Post-boot means allow the IoTServer to fully boot up, and then press the button. See additional notes below.<br />
<br />
Button-down indication codes:<br />
<br />
Pre-boot options:<br />
* 1: start with no tasks, task manager only (red code 1)<br />
* 2: clear all configuration (red code 2)<br />
<br />
Post-boot options:<br />
* 1: reboot system (green code 1)<br />
* 2: shut down all tasks (green code 2)<br />
* 3: reset Admin password for web UI (green code 3) <br />
* 4: reset root password for SSH login (green code 4)<br />
* 5: reset IP address to IPv4 10.0.0.101 (green code 5) <br />
<br />
Button-down operation:<br />
<br />
Button down is indicated by STA flashing yellow rapidly. Codes are indicated on STB.<br />
<br />
(a) Pre-boot flashes yellow rapidly on STA while blinking red code on STB while button down.<br><br />
(b) Post-boot flashes yellow rapidly on STA while blinking green code on STB while button down. <br><br />
(c) Button up: Flashes green rapidly on STA while flashing same code on STB (red or green as applicable)<br><br />
<br />
STA will flash yellow rapidly while STB is cycling through button codes while button is held down. After button released, STA will flash rapid green while STB blinks selected code for 5 full sequences. If button is pressed again during this time, action is cancelled. If not cancelled, then after 5th sequence, STA & STB both go off until finished with requested action. Then STA green solid while flashing STB red with single sequence of code just completed. <br />
<br />
Note: For long operations such as coprocessor firmware update, blinking selected code on STB once every 5 seconds along with STA blinking green in sync with STB. Only the pre-boot options would take time, so this means STA blinks green while STB blinks red for 1-4 times, once every 5 seconds. <br />
<br />
Note: Server software updates will be implemented via startup script and USB flash drive. No button mode is required for server updates. </div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Hardware_Details&diff=1439Hardware Details2019-05-28T15:54:34Z<p>Jimhogenson: /* IoTServer Communication LED Indications */</p>
<hr />
<div>== Communication Port Designations ==<br />
[[File:BB4-8422 ports.jpg]]<br />
<br />
Port numbers are sometimes referred to generically just by number in the web UI in the BB4-8422. Ports 0 and 1 will always refer to Ethernet. Ports 2 and 3 will always refer to serial ports 2 and 3. <br />
<br />
Connect power with V+ of a DC supply connected to the V+ terminal and V- or ground/common to the GND termainal of the power connector. If connecting an AC supply, connect one terminal of the AC supply to V+ and the other to GND making sure any other instances of using the same AC supply connect the same side of AC to GND (ground/common). <br />
<br />
The BB4-8422 will operate on 12 to 24 VDC or 24 VAC. Power requirement at 24VDC is 0.5A. Power requirement at 12VDC would be 1.0A. <br />
<br />
== Connectors and Pin-Outs ==<br />
[[File:BB4-8422 back side.jpg]]<br />
<br />
The connector pin-outs for the 3-position screw terminals are displayed on the back side of the BB4-8422. The D+ and D- are the positive and negative pins for RS-485 (EIA-485). These ports are electrically isolated from each other and from power. <br />
<br />
Both Ethernet ports support full duplex 100BaseT. Only eth0 supports half duplex 10BaseT. <br />
<br />
== USB Port ==<br />
<br />
Any standard Flash drive (FAT32 format) plugged into the USB port will automatically mount at /home/customer/usb/. Software updates for Babel Buster 4 will be loaded via the Flash drive with the support of the [[Software]] web page. <br />
<br />
Theoretically you could transfer configuration files using a Flash drive; however, it is actually going to be quicker to use the file management provided via the Config File page in the web UI. To access the USB drive as just an ordinary drive would require logging in via SSH and using standard Linux shell commands. Accessing the USB Flash drive this way should be reserved for "experts only". <br />
<br />
== IoTServer Communication LED Indications ==<br />
<br />
The LEDs labeled RQ2 and RP2 indicate communication on serial port 2 while RQ3 and RP3 indicate communication on serial port 3. <br />
<br />
Behavior of the communication LEDs may vary by protocol, but in general, RQx will flash yellow (amber) when a client or master sends a request, or when a server or slave receives a request. Generally whether acting as client or server (master or slave), the RPx will flash green indicating a good response or red indicating an error response or timeout.<br />
<br />
== IoTServer Status LED Indications and Reset Button Handling ==<br />
<br />
LED indications on STA (yellow/green) and STB (red/green) provide a very simplistic user interface for the reset button, progress indication during bootup, and status or error indications during normal operation. <br />
<br />
Operating sequence starting from bootup:<br />
<br />
(a) If button down, enter button down mode.<br><br />
(b) If bootup in progress, process bootup mode until complete.<br><br />
(c) Enter normal mode.<br><br />
(d) While in normal mode, if button pressed, enter button down mode.<br><br />
<br />
== Bootup Mode ==<br />
<br />
Bootup mode indication codes:<br />
* Boot code will turn on STA yellow solid, STB red solid<br />
* Upon successful bootup, STA, STB flash inverse heartbeat pattern of off with brief green flash on once a second.<br />
<br />
Bootup mode operation:<br />
<br />
Upon task manager startup, it must check to see if the reset button is being held down during boot. This is done as follows: Task manager spawns indicator thread, then waits for thread to set indicator mode to either preboot or boot. If preboot, then wait for option to get set and execute it. If boot, load task array from DB or XML and then set boot ready flag in indicator structure. <br />
<br />
Following bootup, during normal operation, the task manager will check the indicator mode for postboot and check for postboot selection. If selection has been made, then execute it. <br />
<br />
Boot mode exits when all tasks with nonzero process key have a nonzero process status.<br />
Task errors will be indicated in task structure status and picked up by Normal Mode.<br />
<br />
== Normal Mode ==<br />
<br />
Normal mode indication codes:<br />
<br />
Yellow codes (STA):<br />
* 1 = Modbus TCP comm error exists (RTU not indicated here, they have own LEDs)<br />
* 2 = SNMP comm error exists<br />
<br />
Red codes (STB):<br />
* 1 = Error indicated in errval[3] - initialization error, coprocessor fail, etc.<br />
* 2 = Task status indicates fault<br />
* 3 = Update fail (can be firmware update fail, or failure of other requested action e.g. IP address reset)<br />
<br />
Note: Red codes are not likely to go away until reboot, and may return upon reboot if there is a serious problem with the system. Yellow codes will go away if the problem goes away (e.g. Modbus wasn’t talking but is now). <br />
<br />
Normal mode operation:<br />
<br />
If there is a red code, flash it on STB, leaving STA off.<br />
If no red code, flash yellow code on STA if there is a yellow code.<br />
If no red or yellow codes, flash both STA and STB green heartbeat pattern.<br />
<br />
Code is off with brief flashes on to count out code.<br />
Heartbeat is both STA and STB green, with brief flash off once a second.<br />
<br />
Yellow codes will be all flashed in sequence.<br />
Red code will flash only highest numbered code.<br />
<br />
During normal mode, the LED thread will routinely scan task status structures checking for errors/faults.<br />
<br />
== Button-Down Mode ==<br />
<br />
There is a hidden reset button accessible through a tiny hole in the top of the IoTServer (Babel Buster 4) enclosure. Use a small tool or paper clip to press and hold the button until the desired code is being flashed. Release the button to select that code. The available codes will flash in sequence. Count the flashes between longer pauses. Pre-boot means hold the button down while applying power to the IoTServer. Post-boot means allow the IoTServer to fully boot up, and then press the button. See additional notes below.<br />
<br />
Button-down indication codes:<br />
<br />
Pre-boot options:<br />
* 1: start with no tasks, task manager only (red code 1)<br />
* 2: clear all configuration (red code 2)<br />
<br />
Post-boot options:<br />
* 1: reboot system (green code 1)<br />
* 2: shut down all tasks (green code 2)<br />
* 3: reset Admin password for web UI (green code 3) <br />
* 4: reset root password for SSH login (green code 4)<br />
* 5: reset IP address to IPv4 10.0.0.101 (green code 5) <br />
<br />
Button-down operation:<br />
<br />
Button down is indicated by STA flashing yellow rapidly. Codes are indicated on STB.<br />
<br />
(a) Pre-boot flashes yellow rapidly on STA while blinking red code on STB while button down.<br><br />
(b) Post-boot flashes yellow rapidly on STA while blinking green code on STB while button down. <br><br />
(c) Button up: Flashes green rapidly on STA while flashing same code on STB (red or green as applicable)<br><br />
<br />
STA will flash yellow rapidly while STB is cycling through button codes while button is held down. After button released, STA will flash rapid green while STB blinks selected code for 5 full sequences. If button is pressed again during this time, action is cancelled. If not cancelled, then after 5th sequence, STA & STB both go off until finished with requested action. Then STA green solid while flashing STB red with single sequence of code just completed. <br />
<br />
Note: For long operations such as coprocessor firmware update, blinking selected code on STB once every 5 seconds along with STA blinking green in sync with STB. Only the pre-boot options would take time, so this means STA blinks green while STB blinks red for 1-4 times, once every 5 seconds. <br />
<br />
Note: Server software updates will be implemented via startup script and USB flash drive. No button mode is required for server updates. </div>Jimhogensonhttps://wiki.csimn.com/index.php?title=File:BB4-8422_ports.jpg&diff=1438File:BB4-8422 ports.jpg2019-05-28T15:52:42Z<p>Jimhogenson: Jimhogenson uploaded a new version of File:BB4-8422 ports.jpg</p>
<hr />
<div></div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Resetting_Defaults&diff=1437Resetting Defaults2019-05-24T20:19:14Z<p>Jimhogenson: </p>
<hr />
<div>== Reset to Factory Default ==<br />
<br />
The definition of "resetting defaults" can have quite a few meanings in a device as complex as the IoTServer (Babel Buster 4). Completely resetting everything to factory defaults may require several steps. But resetting defaults sometimes only means "I lost my IP address, how do I get it back?"<br />
<br />
== Reset IP Address ==<br />
<br />
A number of reset options, including resetting the IP address, are attached to the hidden reset button. These are discussed on the '''[[Hardware Details]]''' page. If you use the reset button to reset the IP address, the IPv4 address will become 10.0.0.101 after reboot. <br />
<br />
== Reset Configuration ==<br />
<br />
[[File:Task manager buttons force reconfig.jpg]]<br />
<br />
You will find these two buttons at the bottom of the '''[[Task Configuration]]''' page. Force Reconfig means wipe out the databases, and reload everything from the XML files that are displayed for the various tasks within the task configuration page and task selections. After clearing out all of the existing databases, then click Reboot Device to force a reboot, at which time it will reload the databases from the XML files provided.<br />
<br />
More detail about the use of the Force Reconfig button or hidden reset button to clear configuration is provided on the '''[[Reconfiguring the System]]''' page.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Resetting_Defaults&diff=1436Resetting Defaults2019-05-24T20:18:47Z<p>Jimhogenson: </p>
<hr />
<div>== Reset to Factory Default ==<br />
<br />
The definition of "resetting defaults" can have quite a few meanings in a device as complex as the IoTServer (Babel Buster 4). Completely resetting everything to factory defaults may require several steps. But resetting defaults sometimes only means "I lost my IP address, how do I get it back?"<br />
<br />
== Reset IP Address ==<br />
<br />
A number of reset options, including resetting the IP address, are attached to the hidden reset button. These are discussed on the '''[[Hardware Details]]''' page. If you use the reset button to reset the IP address, the IPv4 address will become 10.0.0.101 after reboot. <br />
<br />
== Reset Configuration ==<br />
<br />
[[File:Task manager buttons force reconfig.jpg]]<br />
<br />
You will find these two buttons at the bottom of the [[Task Configuration]] page. Force Reconfig means wipe out the databases, and reload everything from the XML files that are displayed for the various tasks within the task configuration page and task selections. After clearing out all of the existing databases, then click Reboot Device to force a reboot, at which time it will reload the databases from the XML files provided.<br />
<br />
More detail about the use of the Force Reconfig button or hidden reset button to clear configuration is provided on the '''[[Reconfiguring the System]]''' page.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Hardware_Details&diff=1435Hardware Details2019-05-22T21:41:55Z<p>Jimhogenson: </p>
<hr />
<div>== Communication Port Designations ==<br />
[[File:BB4-8422 ports.jpg]]<br />
<br />
Port numbers are sometimes referred to generically just by number in the web UI in the BB4-8422. Ports 0 and 1 will always refer to Ethernet. Ports 2 and 3 will always refer to serial ports 2 and 3. <br />
<br />
Connect power with V+ of a DC supply connected to the V+ terminal and V- or ground/common to the GND termainal of the power connector. If connecting an AC supply, connect one terminal of the AC supply to V+ and the other to GND making sure any other instances of using the same AC supply connect the same side of AC to GND (ground/common). <br />
<br />
The BB4-8422 will operate on 12 to 24 VDC or 24 VAC. Power requirement at 24VDC is 0.5A. Power requirement at 12VDC would be 1.0A. <br />
<br />
== Connectors and Pin-Outs ==<br />
[[File:BB4-8422 back side.jpg]]<br />
<br />
The connector pin-outs for the 3-position screw terminals are displayed on the back side of the BB4-8422. The D+ and D- are the positive and negative pins for RS-485 (EIA-485). These ports are electrically isolated from each other and from power. <br />
<br />
Both Ethernet ports support full duplex 100BaseT. Only eth0 supports half duplex 10BaseT. <br />
<br />
== USB Port ==<br />
<br />
Any standard Flash drive (FAT32 format) plugged into the USB port will automatically mount at /home/customer/usb/. Software updates for Babel Buster 4 will be loaded via the Flash drive with the support of the [[Software]] web page. <br />
<br />
Theoretically you could transfer configuration files using a Flash drive; however, it is actually going to be quicker to use the file management provided via the Config File page in the web UI. To access the USB drive as just an ordinary drive would require logging in via SSH and using standard Linux shell commands. Accessing the USB Flash drive this way should be reserved for "experts only". <br />
<br />
== IoTServer Communication LED Indications ==<br />
<br />
The LEDs labeled RQ2 and RP2 indicate communication on serial port 2 while RQ3 and RP3 indicate communication on serial port 3. <br />
<br />
Behavior of the communication LEDs may vary by protocol, but in general, RPx will flash yellow (amber) when a client or master sends a request, or when a server or slave receives a request. Generally whether acting as client or server (master or slave), the RPx will flash green indicating a good response or red indicating an error response or timeout. <br />
<br />
== IoTServer Status LED Indications and Reset Button Handling ==<br />
<br />
LED indications on STA (yellow/green) and STB (red/green) provide a very simplistic user interface for the reset button, progress indication during bootup, and status or error indications during normal operation. <br />
<br />
Operating sequence starting from bootup:<br />
<br />
(a) If button down, enter button down mode.<br><br />
(b) If bootup in progress, process bootup mode until complete.<br><br />
(c) Enter normal mode.<br><br />
(d) While in normal mode, if button pressed, enter button down mode.<br><br />
<br />
== Bootup Mode ==<br />
<br />
Bootup mode indication codes:<br />
* Boot code will turn on STA yellow solid, STB red solid<br />
* Upon successful bootup, STA, STB flash inverse heartbeat pattern of off with brief green flash on once a second.<br />
<br />
Bootup mode operation:<br />
<br />
Upon task manager startup, it must check to see if the reset button is being held down during boot. This is done as follows: Task manager spawns indicator thread, then waits for thread to set indicator mode to either preboot or boot. If preboot, then wait for option to get set and execute it. If boot, load task array from DB or XML and then set boot ready flag in indicator structure. <br />
<br />
Following bootup, during normal operation, the task manager will check the indicator mode for postboot and check for postboot selection. If selection has been made, then execute it. <br />
<br />
Boot mode exits when all tasks with nonzero process key have a nonzero process status.<br />
Task errors will be indicated in task structure status and picked up by Normal Mode.<br />
<br />
== Normal Mode ==<br />
<br />
Normal mode indication codes:<br />
<br />
Yellow codes (STA):<br />
* 1 = Modbus TCP comm error exists (RTU not indicated here, they have own LEDs)<br />
* 2 = SNMP comm error exists<br />
<br />
Red codes (STB):<br />
* 1 = Error indicated in errval[3] - initialization error, coprocessor fail, etc.<br />
* 2 = Task status indicates fault<br />
* 3 = Update fail (can be firmware update fail, or failure of other requested action e.g. IP address reset)<br />
<br />
Note: Red codes are not likely to go away until reboot, and may return upon reboot if there is a serious problem with the system. Yellow codes will go away if the problem goes away (e.g. Modbus wasn’t talking but is now). <br />
<br />
Normal mode operation:<br />
<br />
If there is a red code, flash it on STB, leaving STA off.<br />
If no red code, flash yellow code on STA if there is a yellow code.<br />
If no red or yellow codes, flash both STA and STB green heartbeat pattern.<br />
<br />
Code is off with brief flashes on to count out code.<br />
Heartbeat is both STA and STB green, with brief flash off once a second.<br />
<br />
Yellow codes will be all flashed in sequence.<br />
Red code will flash only highest numbered code.<br />
<br />
During normal mode, the LED thread will routinely scan task status structures checking for errors/faults.<br />
<br />
== Button-Down Mode ==<br />
<br />
There is a hidden reset button accessible through a tiny hole in the top of the IoTServer (Babel Buster 4) enclosure. Use a small tool or paper clip to press and hold the button until the desired code is being flashed. Release the button to select that code. The available codes will flash in sequence. Count the flashes between longer pauses. Pre-boot means hold the button down while applying power to the IoTServer. Post-boot means allow the IoTServer to fully boot up, and then press the button. See additional notes below.<br />
<br />
Button-down indication codes:<br />
<br />
Pre-boot options:<br />
* 1: start with no tasks, task manager only (red code 1)<br />
* 2: clear all configuration (red code 2)<br />
<br />
Post-boot options:<br />
* 1: reboot system (green code 1)<br />
* 2: shut down all tasks (green code 2)<br />
* 3: reset Admin password for web UI (green code 3) <br />
* 4: reset root password for SSH login (green code 4)<br />
* 5: reset IP address to IPv4 10.0.0.101 (green code 5) <br />
<br />
Button-down operation:<br />
<br />
Button down is indicated by STA flashing yellow rapidly. Codes are indicated on STB.<br />
<br />
(a) Pre-boot flashes yellow rapidly on STA while blinking red code on STB while button down.<br><br />
(b) Post-boot flashes yellow rapidly on STA while blinking green code on STB while button down. <br><br />
(c) Button up: Flashes green rapidly on STA while flashing same code on STB (red or green as applicable)<br><br />
<br />
STA will flash yellow rapidly while STB is cycling through button codes while button is held down. After button released, STA will flash rapid green while STB blinks selected code for 5 full sequences. If button is pressed again during this time, action is cancelled. If not cancelled, then after 5th sequence, STA & STB both go off until finished with requested action. Then STA green solid while flashing STB red with single sequence of code just completed. <br />
<br />
Note: For long operations such as coprocessor firmware update, blinking selected code on STB once every 5 seconds along with STA blinking green in sync with STB. Only the pre-boot options would take time, so this means STA blinks green while STB blinks red for 1-4 times, once every 5 seconds. <br />
<br />
Note: Server software updates will be implemented via startup script and USB flash drive. No button mode is required for server updates. </div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Hardware_Details&diff=1434Hardware Details2019-05-22T21:40:46Z<p>Jimhogenson: </p>
<hr />
<div>== Communication Port Designations ==<br />
[[File:BB4-8422 ports.jpg]]<br />
<br />
Port numbers are sometimes referred to generically just by number in the web UI in the BB4-8422. Ports 0 and 1 will always refer to Ethernet. Ports 2 and 3 will always refer to serial ports 2 and 3. <br />
<br />
Connect power with V+ of a DC supply connected to the V+ terminal and V- or ground/common to the GND termainal of the power connector. If connecting an AC supply, connect one terminal of the AC supply to V+ and the other to GND making sure any other instances of using the same AC supply connect the same side of AC to GND (ground/common). <br />
<br />
The BB4-8422 will operate on 12 to 24 VDC or 24 VAC. Power requirement at 24VDC is 0.5A. Power requirement at 12VDC would be 1.0A. <br />
<br />
== Connectors and Pin-Outs ==<br />
[[File:BB4-8422 back side.jpg]]<br />
<br />
The connector pin-outs for the 3-position screw terminals are displayed on the back side of the BB4-8422. The D+ and D- are the positive and negative pins for RS-485 (EIA-485). These ports are electrically isolated from each other and from power. <br />
<br />
Both Ethernet ports support full duplex 100BaseT. Only eth0 supports half duplex 10BaseT. <br />
<br />
== USB Port ==<br />
<br />
Any standard Flash drive (FAT32 format) plugged into the USB port will automatically mount at /home/customer/usb/. Software updates for Babel Buster 4 will be loaded via the Flash drive with the support of the [[Software]] web page. <br />
<br />
Theoretically you could transfer configuration files using a Flash drive; however, it is actually going to be quicker to use the file management provided via the Config File page in the web UI. To access the USB drive as just an ordinary drive would require logging in via SSH and using standard Linux shell commands. <br />
<br />
== IoTServer Communication LED Indications ==<br />
<br />
The LEDs labeled RQ2 and RP2 indicate communication on serial port 2 while RQ3 and RP3 indicate communication on serial port 3. <br />
<br />
Behavior of the communication LEDs may vary by protocol, but in general, RPx will flash yellow (amber) when a client or master sends a request, or when a server or slave receives a request. Generally whether acting as client or server (master or slave), the RPx will flash green indicating a good response or red indicating an error response or timeout. <br />
<br />
== IoTServer Status LED Indications and Reset Button Handling ==<br />
<br />
LED indications on STA (yellow/green) and STB (red/green) provide a very simplistic user interface for the reset button, progress indication during bootup, and status or error indications during normal operation. <br />
<br />
Operating sequence starting from bootup:<br />
<br />
(a) If button down, enter button down mode.<br><br />
(b) If bootup in progress, process bootup mode until complete.<br><br />
(c) Enter normal mode.<br><br />
(d) While in normal mode, if button pressed, enter button down mode.<br><br />
<br />
== Bootup Mode ==<br />
<br />
Bootup mode indication codes:<br />
* Boot code will turn on STA yellow solid, STB red solid<br />
* Upon successful bootup, STA, STB flash inverse heartbeat pattern of off with brief green flash on once a second.<br />
<br />
Bootup mode operation:<br />
<br />
Upon task manager startup, it must check to see if the reset button is being held down during boot. This is done as follows: Task manager spawns indicator thread, then waits for thread to set indicator mode to either preboot or boot. If preboot, then wait for option to get set and execute it. If boot, load task array from DB or XML and then set boot ready flag in indicator structure. <br />
<br />
Following bootup, during normal operation, the task manager will check the indicator mode for postboot and check for postboot selection. If selection has been made, then execute it. <br />
<br />
Boot mode exits when all tasks with nonzero process key have a nonzero process status.<br />
Task errors will be indicated in task structure status and picked up by Normal Mode.<br />
<br />
== Normal Mode ==<br />
<br />
Normal mode indication codes:<br />
<br />
Yellow codes (STA):<br />
* 1 = Modbus TCP comm error exists (RTU not indicated here, they have own LEDs)<br />
* 2 = SNMP comm error exists<br />
<br />
Red codes (STB):<br />
* 1 = Error indicated in errval[3] - initialization error, coprocessor fail, etc.<br />
* 2 = Task status indicates fault<br />
* 3 = Update fail (can be firmware update fail, or failure of other requested action e.g. IP address reset)<br />
<br />
Note: Red codes are not likely to go away until reboot, and may return upon reboot if there is a serious problem with the system. Yellow codes will go away if the problem goes away (e.g. Modbus wasn’t talking but is now). <br />
<br />
Normal mode operation:<br />
<br />
If there is a red code, flash it on STB, leaving STA off.<br />
If no red code, flash yellow code on STA if there is a yellow code.<br />
If no red or yellow codes, flash both STA and STB green heartbeat pattern.<br />
<br />
Code is off with brief flashes on to count out code.<br />
Heartbeat is both STA and STB green, with brief flash off once a second.<br />
<br />
Yellow codes will be all flashed in sequence.<br />
Red code will flash only highest numbered code.<br />
<br />
During normal mode, the LED thread will routinely scan task status structures checking for errors/faults.<br />
<br />
== Button-Down Mode ==<br />
<br />
There is a hidden reset button accessible through a tiny hole in the top of the IoTServer (Babel Buster 4) enclosure. Use a small tool or paper clip to press and hold the button until the desired code is being flashed. Release the button to select that code. The available codes will flash in sequence. Count the flashes between longer pauses. Pre-boot means hold the button down while applying power to the IoTServer. Post-boot means allow the IoTServer to fully boot up, and then press the button. See additional notes below.<br />
<br />
Button-down indication codes:<br />
<br />
Pre-boot options:<br />
* 1: start with no tasks, task manager only (red code 1)<br />
* 2: clear all configuration (red code 2)<br />
<br />
Post-boot options:<br />
* 1: reboot system (green code 1)<br />
* 2: shut down all tasks (green code 2)<br />
* 3: reset Admin password for web UI (green code 3) <br />
* 4: reset root password for SSH login (green code 4)<br />
* 5: reset IP address to IPv4 10.0.0.101 (green code 5) <br />
<br />
Button-down operation:<br />
<br />
Button down is indicated by STA flashing yellow rapidly. Codes are indicated on STB.<br />
<br />
(a) Pre-boot flashes yellow rapidly on STA while blinking red code on STB while button down.<br><br />
(b) Post-boot flashes yellow rapidly on STA while blinking green code on STB while button down. <br><br />
(c) Button up: Flashes green rapidly on STA while flashing same code on STB (red or green as applicable)<br><br />
<br />
STA will flash yellow rapidly while STB is cycling through button codes while button is held down. After button released, STA will flash rapid green while STB blinks selected code for 5 full sequences. If button is pressed again during this time, action is cancelled. If not cancelled, then after 5th sequence, STA & STB both go off until finished with requested action. Then STA green solid while flashing STB red with single sequence of code just completed. <br />
<br />
Note: For long operations such as coprocessor firmware update, blinking selected code on STB once every 5 seconds along with STA blinking green in sync with STB. Only the pre-boot options would take time, so this means STA blinks green while STB blinks red for 1-4 times, once every 5 seconds. <br />
<br />
Note: Server software updates will be implemented via startup script and USB flash drive. No button mode is required for server updates. </div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1433Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:54:38Z<p>Jimhogenson: /* Two-Level Trap Logging */</p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
We should also note that SNMP v1/v2 was illustrated here for simplicity. The same approach would be used for SNMP v3 with the difference being the authentication and privacy parameters listed per user following the #Users... line. These are pulled in automatically from the User List when the Generate button is clicked. <br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Two Level Trap Logging ==<br />
<br />
[[File:Snmp trap receiver config file 5.jpg]]<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
* 1) Enter csiTrapReceiver_info_log in the Log file window, select Yes, and click Select Logging Options.<br />
* 2) Without disabling logging, enter a different filename in the Log file window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file, whatever it is named, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).<br />
<br />
Both of these log files can be very useful diagnostic tools to help get your trap receiver rules figured out. If traps do not appear in the log file for snmptrapd, check your authentication settings. The traps will not appear in the csiTrapHandler file if they do not first appear in the snmptrapd log file. If traps appear in the snmptrapd log file but not the csiTrapHandler log file, you may need to add additional filters to the snmptrapd.conf file. The logging done by csiTrapHandler goes one step further and inserts comments such as "Found IP address", "Found trap OID", and "Found var OID" indicating its progress and success (or not) in matching rules to the trap.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1432Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:54:23Z<p>Jimhogenson: /* Dual Trap Logging */</p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
We should also note that SNMP v1/v2 was illustrated here for simplicity. The same approach would be used for SNMP v3 with the difference being the authentication and privacy parameters listed per user following the #Users... line. These are pulled in automatically from the User List when the Generate button is clicked. <br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Two-Level Trap Logging ==<br />
<br />
[[File:Snmp trap receiver config file 5.jpg]]<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
* 1) Enter csiTrapReceiver_info_log in the Log file window, select Yes, and click Select Logging Options.<br />
* 2) Without disabling logging, enter a different filename in the Log file window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file, whatever it is named, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).<br />
<br />
Both of these log files can be very useful diagnostic tools to help get your trap receiver rules figured out. If traps do not appear in the log file for snmptrapd, check your authentication settings. The traps will not appear in the csiTrapHandler file if they do not first appear in the snmptrapd log file. If traps appear in the snmptrapd log file but not the csiTrapHandler log file, you may need to add additional filters to the snmptrapd.conf file. The logging done by csiTrapHandler goes one step further and inserts comments such as "Found IP address", "Found trap OID", and "Found var OID" indicating its progress and success (or not) in matching rules to the trap.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1431Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:48:01Z<p>Jimhogenson: </p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
We should also note that SNMP v1/v2 was illustrated here for simplicity. The same approach would be used for SNMP v3 with the difference being the authentication and privacy parameters listed per user following the #Users... line. These are pulled in automatically from the User List when the Generate button is clicked. <br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Dual Trap Logging ==<br />
<br />
[[File:Snmp trap receiver config file 5.jpg]]<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
* 1) Enter csiTrapReceiver_info_log in the Log file window, select Yes, and click Select Logging Options.<br />
* 2) Without disabling logging, enter a different filename in the Log file window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file, whatever it is named, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).<br />
<br />
Both of these log files can be very useful diagnostic tools to help get your trap receiver rules figured out. If traps do not appear in the log file for snmptrapd, check your authentication settings. The traps will not appear in the csiTrapHandler file if they do not first appear in the snmptrapd log file. If traps appear in the snmptrapd log file but not the csiTrapHandler log file, you may need to add additional filters to the snmptrapd.conf file. The logging done by csiTrapHandler goes one step further and inserts comments such as "Found IP address", "Found trap OID", and "Found var OID" indicating its progress and success (or not) in matching rules to the trap.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1430Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:47:11Z<p>Jimhogenson: </p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
We should also note that SNMP v1/v2 was illustrated here for simplicity. The same approach would be used for SNMP v3 with the difference being the authentication and privacy parameters listed per user following the #Users... line.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Dual Trap Logging ==<br />
<br />
[[File:Snmp trap receiver config file 5.jpg]]<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
* 1) Enter csiTrapReceiver_info_log in the Log file window, select Yes, and click Select Logging Options.<br />
* 2) Without disabling logging, enter a different filename in the Log file window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file, whatever it is named, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).<br />
<br />
Both of these log files can be very useful diagnostic tools to help get your trap receiver rules figured out. If traps do not appear in the log file for snmptrapd, check your authentication settings. The traps will not appear in the csiTrapHandler file if they do not first appear in the snmptrapd log file. If traps appear in the snmptrapd log file but not the csiTrapHandler log file, you may need to add additional filters to the snmptrapd.conf file. The logging done by csiTrapHandler goes one step further and inserts comments such as "Found IP address", "Found trap OID", and "Found var OID" indicating its progress and success (or not) in matching rules to the trap.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1429Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:46:29Z<p>Jimhogenson: </p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
We should also note that SNMP v1/v2 was illustrated here for simplicity. The same approach would be used for SNMP v3 with the difference being the authentication and privacy parameters listed per user under <br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Dual Trap Logging ==<br />
<br />
[[File:Snmp trap receiver config file 5.jpg]]<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
* 1) Enter csiTrapReceiver_info_log in the Log file window, select Yes, and click Select Logging Options.<br />
* 2) Without disabling logging, enter a different filename in the Log file window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file, whatever it is named, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).<br />
<br />
Both of these log files can be very useful diagnostic tools to help get your trap receiver rules figured out. If traps do not appear in the log file for snmptrapd, check your authentication settings. The traps will not appear in the csiTrapHandler file if they do not first appear in the snmptrapd log file. If traps appear in the snmptrapd log file but not the csiTrapHandler log file, you may need to add additional filters to the snmptrapd.conf file. The logging done by csiTrapHandler goes one step further and inserts comments such as "Found IP address", "Found trap OID", and "Found var OID" indicating its progress and success (or not) in matching rules to the trap.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Trap_Receiver_Config_File&diff=1428SNMP Trap Receiver Config File2019-05-22T01:41:33Z<p>Jimhogenson: </p>
<hr />
<div>[[File:Snmp trap receiver config file 1.jpg]]<br />
<br />
All of your configuration information is stored in an internal database each time you click the Save button on any page where configuration entries may be made. To make configuration portable from one device to another, and for purposes of retaining a backup copy, the configuration information may be exported and imported as XML or CSV files. This page is where your configuration file management takes place. <br />
<br />
It is important to note that the XML file saved within any one client/server function will contain the configuration information for only that function. Depending on overall system configuration, a complete backup may involve more than one XML or CSV file. <br />
<br />
[[File:Snmp trap receiver config file 2a.jpg]]<br />
<br />
'''XML Files:''' When an XML file has been selected, click the Load button to clear the configuration database and reload configuration from the given XML file.<br />
<br />
Select an existing name to overwrite or enter a new file name, and then click Save to write the current configuration to the file in XML format. <br />
<br />
You may type in a new name in the file name window for purposes of saving a new file. If you click the Refresh button, the file name will be restored to the name currently loaded into the client. The name could have been changed by selecting a file from the list below, or by typing in a new name. If the displayed name has not yet been used, then Refresh will restore the file name to what was most recently loaded. <br />
<br />
[[File:Snmp trap receiver config file 2b.jpg]]<br />
<br />
'''CSV Files:''' If a CSV file is selected, the Load and Save buttons will change into load/save CSV buttons. When a CSV file has been selected, click the Load button to clear the configuration database and reload configuration from the given CSV file.<br />
<br />
Select an existing name to overwrite or enter a new file name, and then click Save to write the current configuration to the file in CSV format. <br />
<br />
[[File:Snmp trap receiver config file 2c.jpg]]<br />
<br />
'''Snmptrapd.conf Files:''' Any time the snmptrapd.conf file is regenerated on the Snmptrapd.conf page, you will need to come here to transfer that generated file into the SNMP engine. Select the generated .conf file from the drop-down list below, and then click the Load button. You can also retrieve a copy of the snmptrapd.conf file actually in use by clicking the Save button. The content of the currently in-use snmptrapd.conf file will be transferred to the file name you have entered.<br />
<br />
NOTE: Any time you reload the snmptrapd.conf file here, you also need to click the Restart SNMP button at the bottom of this page. <br />
<br />
[[File:Snmp trap receiver config file 3.jpg]]<br />
<br />
The drop-down list will show a list of all configuration files currently found in the device's configuration folder. When you select an XML or CSV file from this list, the name will be copied to the Load/Save section of this page for pending load or save.<br />
<br />
You may view the selected file by simply clicking View. You can delete the file by clicking Delete. <br />
<br />
You may upload files to the IoTServer from your PC. Start by clicking Browse, and then use the browser's file dialog to locate the file on your PC. Once a file is selected on your PC, click the "Start upload" button to initiate the transfer. <br />
<br />
You may also download files from the IoTServer to your PC. Click the Download button to transfer the selected file to your PC. <br />
<br />
[[File:Snmp trap receiver config file 4.jpg]]<br />
<br />
Any time an XML or CSV file is loaded, an error log file is generated. The error log file will be given the same name as the loaded file, but with ".err" as the suffix instead of ".xml" or ".csv". You may view the error log by selecting it from the list and clicking View.<br />
<br />
Status is normally displayed in a message box at the top of the screen when the load or save operation is complete. But if you want to double check the status of the previous file operation, click Check Status.<br />
<br />
[[File:Snmp trap receiver config file 5.jpg]]<br />
<br />
Select Yes to enable logging, or No to disable. When selecting Yes, provide a log name in the /home/customer/logs/ directory. All accesses to the MIB by external managers are logged here. It is recommended that you enable logging only temporarily for diagnostic purposes to avoid eventually running out of file space. NOTE: The log file enabled here is not the same log file as enabled for the SNMP Agent. <br />
<br />
Because the snmptrapd.service does not log SNMPv3 traps to the log file, additional logging has been added to the csiTrapHandler application. If the file csiTrapReceiver_info_log is found in the /home/customer/logs/ directory, the SNMPv3 traps will be logged there instead of snmptrapd.log. <br />
<br />
The log files can be viewed on the System -> Logs page. <br />
<br />
[[File:Snmp trap receiver config file 6.jpg]]<br />
<br />
The SNMP Trap Receiver task needs to be suspended while a file load operation is in progress to prevent acting on any partial configurations. This suspend/resume operation will normally happen automatically as part of the sequence invoked by the Load button when loading an XML file. The task must be explicitly suspended here for importing a CSV file. The Suspend button will become a Resume button when the task is suspended. Click Resume to continue operation. The current status is always displayed here.<br />
<br />
The SNMP Trap Receive task suspended via the Suspend button is the API task that provides the interface between the web UI and the internal task management. The SNMP Trap Engine itself is another process. Any time the trap receive rules are altered, it is necessary to restart the SNMP trap receiver (snmptrapd service). Click Restart SNMP to reload Snmptrapd with the new definition of receive rules.<br />
<br />
=== [[Additional SNMP Trap Receiver Tips and Techniques]] ===</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Trap_Receiver_Snmptrapd.conf_File&diff=1427SNMP Trap Receiver Snmptrapd.conf File2019-05-22T01:40:53Z<p>Jimhogenson: </p>
<hr />
<div>[[File:Snmp trap receiver snmptrapd 1.jpg]]<br />
<br />
The SNMP Trap engine that responds to Trap messages requires a configuration file named snmptrapd.conf to direct its functionality, primarily in terms of authorization. This page allows automated generation of that file, but with the option to manually edit it. <br />
<br />
The SNMP engine in this IoTServer is the widely used open source Net-SNMP package. If you are concerned about manually editing the snmptrapd.conf file, simple search the Internet for Net-SNMP documentation - there is much to be found. <br />
<br />
[[File:Snmp trap receiver snmptrapd 2.jpg]]<br />
<br />
The port on which SNMP listens for Trap messages defaults to the standard port 162. You may change it here if you wish. <br />
<br />
Authorization for access in SNMPv1 and SNMPv2 is very simply. You only need to match the community names which are treated sort of like a password. If using SNMP v1 or v2 (v2c), enter your community strings here. Trap messages received as v1 or v2 will be expected to match this community.<br />
<hr><br />
[[File:Snmp trap receiver snmptrapd 3.jpg]]<br />
<br />
Click the Generate Config button to auto-generate an snmptrapd.conf file. Parameters included in the file will be taken from two places: (1) The entries showing above on this page. (2) User settings from the System -> Users page (if SNMPv3).<br />
<br />
SNMPv3 enforces access only by known users. These users may be a person or may be anther machine, but must be defined as a "user" either way. To permit SNMPv3 Traps (or Informs) to be received, go to the System -> Users page and create a "user" for each person or machine that will send Traps to this IoTServer. Once the users are created, and they have been selected for SNMPv3 Trap access, they will be automatically included in the snmptrapd.conf file generated here.<br />
<hr><br />
[[File:Snmp trap receiver snmptrapd 4.jpg]]<br />
<br />
Once the interim snmptrapd.conf file is generated, it may be viewed and optionally edited here. The file content displayed here is not actually saved to a file until you click the Save button at the bottom. When Save is clicked, the file name given will be created or overwritten with the content currently displayed. <br />
<br />
There are two more steps required to complete the reconfiguration of the SNMP Trap Receiver. Go to the SNMP Trap Receiver Config File page, select the newly created interim snmptrapd.conf file, and click the Load button (as discussed on the [[SNMP Trap Receiver Config File]] page). Finally, after loading the new snmptrapd.conf file, click Restart SNMP at the bottom of the Config File page.<br />
<br />
=== [[Additional SNMP Trap Receiver Tips and Techniques]] ===</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Trap_Receiver_Snmptrapd.conf_File&diff=1426SNMP Trap Receiver Snmptrapd.conf File2019-05-22T01:40:36Z<p>Jimhogenson: </p>
<hr />
<div>[[File:Snmp trap receiver snmptrapd 1.jpg]]<br />
<br />
The SNMP Trap engine that responds to Trap messages requires a configuration file named snmptrapd.conf to direct its functionality, primarily in terms of authorization. This page allows automated generation of that file, but with the option to manually edit it. <br />
<br />
The SNMP engine in this IoTServer is the widely used open source Net-SNMP package. If you are concerned about manually editing the snmptrapd.conf file, simple search the Internet for Net-SNMP documentation - there is much to be found. <br />
<br />
[[File:Snmp trap receiver snmptrapd 2.jpg]]<br />
<br />
The port on which SNMP listens for Trap messages defaults to the standard port 162. You may change it here if you wish. <br />
<br />
Authorization for access in SNMPv1 and SNMPv2 is very simply. You only need to match the community names which are treated sort of like a password. If using SNMP v1 or v2 (v2c), enter your community strings here. Trap messages received as v1 or v2 will be expected to match this community.<br />
<hr><br />
[[File:Snmp trap receiver snmptrapd 3.jpg]]<br />
<br />
Click the Generate Config button to auto-generate an snmptrapd.conf file. Parameters included in the file will be taken from two places: (1) The entries showing above on this page. (2) User settings from the System -> Users page (if SNMPv3).<br />
<br />
SNMPv3 enforces access only by known users. These users may be a person or may be anther machine, but must be defined as a "user" either way. To permit SNMPv3 Traps (or Informs) to be received, go to the System -> Users page and create a "user" for each person or machine that will send Traps to this IoTServer. Once the users are created, and they have been selected for SNMPv3 Trap access, they will be automatically included in the snmptrapd.conf file generated here.<br />
<hr><br />
[[File:Snmp trap receiver snmptrapd 4.jpg]]<br />
<br />
Once the interim snmptrapd.conf file is generated, it may be viewed and optionally edited here. The file content displayed here is not actually saved to a file until you click the Save button at the bottom. When Save is clicked, the file name given will be created or overwritten with the content currently displayed. <br />
<br />
There are two more steps required to complete the reconfiguration of the SNMP Trap Receiver. Go to the SNMP Trap Receiver Config File page, select the newly created interim snmptrapd.conf file, and click the Load button (as discussed on the [[SNMP Trap Receiver Config File]] page). Finally, after loading the new snmptrapd.conf file, click Restart SNMP at the bottom of the Config File page.<br />
<br />
=== Additional SNMP Trap Receiver Tips and Techniques ===</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Trap_Receiver_Snmptrapd.conf_File&diff=1425SNMP Trap Receiver Snmptrapd.conf File2019-05-22T01:39:32Z<p>Jimhogenson: </p>
<hr />
<div>[[File:Snmp trap receiver snmptrapd 1.jpg]]<br />
<br />
The SNMP Trap engine that responds to Trap messages requires a configuration file named snmptrapd.conf to direct its functionality, primarily in terms of authorization. This page allows automated generation of that file, but with the option to manually edit it. <br />
<br />
The SNMP engine in this IoTServer is the widely used open source Net-SNMP package. If you are concerned about manually editing the snmptrapd.conf file, simple search the Internet for Net-SNMP documentation - there is much to be found. <br />
<br />
[[File:Snmp trap receiver snmptrapd 2.jpg]]<br />
<br />
The port on which SNMP listens for Trap messages defaults to the standard port 162. You may change it here if you wish. <br />
<br />
Authorization for access in SNMPv1 and SNMPv2 is very simply. You only need to match the community names which are treated sort of like a password. If using SNMP v1 or v2 (v2c), enter your community strings here. Trap messages received as v1 or v2 will be expected to match this community.<br />
<hr><br />
[[File:Snmp trap receiver snmptrapd 3.jpg]]<br />
<br />
Click the Generate Config button to auto-generate an snmptrapd.conf file. Parameters included in the file will be taken from two places: (1) The entries showing above on this page. (2) User settings from the System -> Users page (if SNMPv3).<br />
<br />
SNMPv3 enforces access only by known users. These users may be a person or may be anther machine, but must be defined as a "user" either way. To permit SNMPv3 Traps (or Informs) to be received, go to the System -> Users page and create a "user" for each person or machine that will send Traps to this IoTServer. Once the users are created, and they have been selected for SNMPv3 Trap access, they will be automatically included in the snmptrapd.conf file generated here.<br />
<hr><br />
[[File:Snmp trap receiver snmptrapd 4.jpg]]<br />
<br />
Once the interim snmptrapd.conf file is generated, it may be viewed and optionally edited here. The file content displayed here is not actually saved to a file until you click the Save button at the bottom. When Save is clicked, the file name given will be created or overwritten with the content currently displayed. <br />
<br />
There are two more steps required to complete the reconfiguration of the SNMP Trap Receiver. Go to the SNMP Trap Receiver Config File page, select the newly created interim snmptrapd.conf file, and click the Load button (as discussed on the [[SNMP Trap Receiver Config File]] page). Finally, after loading the new snmptrapd.conf file, click Restart SNMP at the bottom of the Config File page.<br />
<br />
'''[[Additional SNMP Trap Receiver Tips and Techniques]]'''</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Trap_Receiver_Snmptrapd.conf_File&diff=1424SNMP Trap Receiver Snmptrapd.conf File2019-05-22T01:39:12Z<p>Jimhogenson: </p>
<hr />
<div>[[File:Snmp trap receiver snmptrapd 1.jpg]]<br />
<br />
The SNMP Trap engine that responds to Trap messages requires a configuration file named snmptrapd.conf to direct its functionality, primarily in terms of authorization. This page allows automated generation of that file, but with the option to manually edit it. <br />
<br />
The SNMP engine in this IoTServer is the widely used open source Net-SNMP package. If you are concerned about manually editing the snmptrapd.conf file, simple search the Internet for Net-SNMP documentation - there is much to be found. <br />
<br />
[[File:Snmp trap receiver snmptrapd 2.jpg]]<br />
<br />
The port on which SNMP listens for Trap messages defaults to the standard port 162. You may change it here if you wish. <br />
<br />
Authorization for access in SNMPv1 and SNMPv2 is very simply. You only need to match the community names which are treated sort of like a password. If using SNMP v1 or v2 (v2c), enter your community strings here. Trap messages received as v1 or v2 will be expected to match this community.<br />
<hr><br />
[[File:Snmp trap receiver snmptrapd 3.jpg]]<br />
<br />
Click the Generate Config button to auto-generate an snmptrapd.conf file. Parameters included in the file will be taken from two places: (1) The entries showing above on this page. (2) User settings from the System -> Users page (if SNMPv3).<br />
<br />
SNMPv3 enforces access only by known users. These users may be a person or may be anther machine, but must be defined as a "user" either way. To permit SNMPv3 Traps (or Informs) to be received, go to the System -> Users page and create a "user" for each person or machine that will send Traps to this IoTServer. Once the users are created, and they have been selected for SNMPv3 Trap access, they will be automatically included in the snmptrapd.conf file generated here.<br />
<hr><br />
[[File:Snmp trap receiver snmptrapd 4.jpg]]<br />
<br />
Once the interim snmptrapd.conf file is generated, it may be viewed and optionally edited here. The file content displayed here is not actually saved to a file until you click the Save button at the bottom. When Save is clicked, the file name given will be created or overwritten with the content currently displayed. <br />
<br />
There are two more steps required to complete the reconfiguration of the SNMP Trap Receiver. Go to the SNMP Trap Receiver Config File page, select the newly created interim snmptrapd.conf file, and click the Load button (as discussed on the [[SNMP Trap Receiver Config File]] page). Finally, after loading the new snmptrapd.conf file, click Restart SNMP at the bottom of the Config File page.<br />
<br />
== [[Additional SNMP Trap Receiver Tips and Techniques]] ==</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1423Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:38:06Z<p>Jimhogenson: /* Dual Trap Logging */</p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Dual Trap Logging ==<br />
<br />
[[File:Snmp trap receiver config file 5.jpg]]<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
* 1) Enter csiTrapReceiver_info_log in the Log file window, select Yes, and click Select Logging Options.<br />
* 2) Without disabling logging, enter a different filename in the Log file window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file, whatever it is named, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).<br />
<br />
Both of these log files can be very useful diagnostic tools to help get your trap receiver rules figured out. If traps do not appear in the log file for snmptrapd, check your authentication settings. The traps will not appear in the csiTrapHandler file if they do not first appear in the snmptrapd log file. If traps appear in the snmptrapd log file but not the csiTrapHandler log file, you may need to add additional filters to the snmptrapd.conf file. The logging done by csiTrapHandler goes one step further and inserts comments such as "Found IP address", "Found trap OID", and "Found var OID" indicating its progress and success (or not) in matching rules to the trap.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1422Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:33:55Z<p>Jimhogenson: /* Dual Trap Logging */</p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Dual Trap Logging ==<br />
<br />
[[File:Snmp trap receiver config file 5.jpg]]<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
* 1) Enter csiTrapReceiver_info_log in the Log file window, select Yes, and click Select Logging Options.<br />
* 2) Without disabling logging, enter a different filename in the Log file window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file, whatever it is named, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1421Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:33:18Z<p>Jimhogenson: /* Dual Trap Logging */</p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Dual Trap Logging ==<br />
<br />
[[File:Snmp trap receiver config file 5.jpg]]<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
* 1) Enter csiTrapReceiver_info_log in the Log file window, select Yes, and click Select Logging Options.<br />
* 2) Without disabling logging, enter a different filename in the Log file window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file named, whatever it is, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1420Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:32:27Z<p>Jimhogenson: /* Dual Trap Logging */</p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Dual Trap Logging ==<br />
<br />
[[File:Snmp trap receiver config file 5.jpg]]<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
* 1) Enter csiTrapReceiver_info_log in the filename window, select Yes, and click Select Logging Options.<br />
* 2) Without disabling logging, enter a different filename in the filename window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file named, whatever it is, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1419Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:31:22Z<p>Jimhogenson: /* Dual Trap Logging */</p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Dual Trap Logging ==<br />
<br />
[[File:Snmp trap receiver config file 5.jpg]]<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
1) Enter csiTrapReceiver_info_log in the filename window, select Yes, and click Select Logging Options.<br />
2) Without disabling logging, enter a different filename in the filename window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file named, whatever it is, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1418Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:30:05Z<p>Jimhogenson: /* Dual Trap Logging */</p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Dual Trap Logging ==<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, a second level will be the logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
1) Enter csiTrapReceiver_info_log in the filename window, select Yes, and click Select Logging Options.<br />
2) Without disabling logging, enter a different filename in the filename window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file named, whatever it is, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1417Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:29:40Z<p>Jimhogenson: /* Dual Trap Logging */</p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Dual Trap Logging ==<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged as a minimum. With additional steps, the second level will be logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
1) Enter csiTrapReceiver_info_log in the filename window, select Yes, and click Select Logging Options.<br />
2) Without disabling logging, enter a different filename in the filename window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file named, whatever it is, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1416Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:28:48Z<p>Jimhogenson: /* Receiving SNMPv1 Generic Traps */</p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in.<br />
<br />
== Dual Trap Logging ==<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged. With additional steps, the second level will be logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
1) Enter csiTrapReceiver_info_log in the filename window, select Yes, and click Select Logging Options.<br />
2) Without disabling logging, enter a different filename in the filename window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file named, whatever it is, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1415Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:26:57Z<p>Jimhogenson: </p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter "default". This is equivalent to '''.1.3.6.1.4.1*''' as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in. <br />
<br />
== Dual Trap Logging ==<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged. With additional steps, the second level will be logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
1) Enter csiTrapReceiver_info_log in the filename window, select Yes, and click Select Logging Options.<br />
2) Without disabling logging, enter a different filename in the filename window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file named, whatever it is, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1414Additional SNMP Trap Receiver Tips and Techniques2019-05-22T01:25:45Z<p>Jimhogenson: </p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 1.jpg]]<br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter “default”. This is equivalent to “.1.3.6.1.4.1*” as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
[[File:Snmptrapd-conf edit detail 2.jpg]]<br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in. <br />
<br />
== Dual Trap Logging ==<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged. With additional steps, the second level will be logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
1) Enter csiTrapReceiver_info_log in the filename window, select Yes, and click Select Logging Options.<br />
2) Without disabling logging, enter a different filename in the filename window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file named, whatever it is, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=File:Snmptrapd-conf_edit_detail_2.jpg&diff=1413File:Snmptrapd-conf edit detail 2.jpg2019-05-22T00:58:44Z<p>Jimhogenson: </p>
<hr />
<div></div>Jimhogensonhttps://wiki.csimn.com/index.php?title=File:Snmptrapd-conf_edit_detail_1.jpg&diff=1412File:Snmptrapd-conf edit detail 1.jpg2019-05-22T00:58:28Z<p>Jimhogenson: </p>
<hr />
<div></div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Additional_SNMP_Trap_Receiver_Tips_and_Techniques&diff=1411Additional SNMP Trap Receiver Tips and Techniques2019-05-22T00:54:42Z<p>Jimhogenson: Created page with "== Trap Filters == The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows: <hr> <br> snmpTrapdAddr 162<br> <br> #Trap handler - Do not change thi..."</p>
<hr />
<div>== Trap Filters ==<br />
<br />
The minimum snmptrapd.conf file for receiving SNMPv1 or SNMPv2 traps is as follows:<br />
<br />
<hr><br />
<br><br />
snmpTrapdAddr 162<br><br />
<br><br />
#Trap handler - Do not change this next line<br><br />
traphandle default /usr/bin/csiTrapHandler<br><br />
<br><br />
#SNMP V1/V2 Specific settings<br><br />
disableAuthorization yes<br><br />
authCommunity execute oakpark<br><br />
<br><br />
<hr><br />
<br />
This example assumes an SNMP community of “oakpark”. Yours will be different and set to what you have chosen. The “traphandle” tells the snmptrapd service what to do with the trap. In this case, it will be passed to the csiTrapHandler for further processing against the trap receive rules. <br />
<br />
The traphandle includes the trap filter “default”. This is equivalent to “.1.3.6.1.4.1*” as defined in the snmptrapd.conf manual available at net-snmp.org. An example that requires additional filters is the UPS MIB defined by RFC 1628. Its traps have a trap OID such as 1.3.6.1.2.1.33.2.0.1. To include these in our filter, it is necessary to manually edit the snmptrapd.conf file ad add one more filter line as illustrated below. After clicking the Generate Config button on the Snmptrapd.conf page, you can freely edit the content of the window where its generated content is displayed. When you click the Save button at the bottom of that window, all content including your edited content is saved. This can then be loaded into the trap receiver.<br />
<br />
<hr><br />
<br><br />
snmpTrapdAddr 162<br><br />
<br><br />
#Trap handler - Do not change this next line<br><br />
traphandle .1.3.6.1.2.1* /usr/bin/csiTrapHandler<br><br />
traphandle default /usr/bin/csiTrapHandler<br><br />
<br><br />
#SNMP V1/V2 Specific settings<br><br />
disableAuthorization yes<br><br />
authCommunity execute oakpark<br><br />
<br><br />
<hr><br />
The comment says "do not change this next line". We didn't change it. We inserted a line before it. You don't want to omit the default line. But you can add additional lines.<br />
<br />
== Receiving SNMPv1 Generic Traps ==<br />
<br />
There are a number of generic traps which do not have traditional SNMP trap OIDs. These are encoded by snmptrapd per RFC 2576 and then forwarded to csiTrapHandler. In particular, the traps are as follows:<br />
<br />
{| class="wikitable"<br />
|-<br />
! generic-trap parameter !! snmpTrapOID.0<br />
|-<br />
| 0 || 1.3.6.1.6.3.1.1.5.1 (coldStart)<br />
|-<br />
| 1 || 1.3.6.1.6.3.1.1.5.2 (warmStart)<br />
|-<br />
| 2 || 1.3.6.1.6.3.1.1.5.3 (linkDown)<br />
|-<br />
| 3 || 1.3.6.1.6.3.1.1.5.4 (linkUp)<br />
|-<br />
| 4 || 1.3.6.1.6.3.1.1.5.5 (authenticationFailure)<br />
|-<br />
| 5 || 1.3.6.1.6.3.1.1.5.6 (egpNeighborLoss)<br />
|}<br />
<br />
If you wish to receive these traps, you may need to add a filter line as illustrated above. Then use the OIDs indicated here as the Trap OID. For the Var OID, simply use the sender community OID 1.3.6.1.6.3.18.1.4.0 to give the trap receiver something to look for. There is no real data payload in this type of trap. You would configure the receive rule to set a fixed value upon receipt of this trap since the trap itself is really the value you are interested in. <br />
<br />
== Dual Trap Logging ==<br />
<br />
When you enable trap logging, there are actually two levels of logging available. Traps received by snmptrapd are logged. With additional steps, the second level will be logging of traps handled by the csiTrapHandler. The snmptrapd service is responsible for receiving traps at the protocol stack level. It then hands off received traps to the trap handler for further processing that includes matching OIDs to trap receive rules and potentially placing received data in local data objects.<br />
<br />
The trap handler logging is enabled by the existence of a log file named “csiTrapReceiver_info_log” in the /home/customer/logs/ directory. The snmptrapd service logging is enabled by the “enable logging” selection at the bottom of the SNMP Trap Receiver’s Config File page. Any filename can be used for snmptrapd logging. <br />
<br />
There is one catch to the dual logging. If you use only csiTrapReceiver_info_log to enable logging, then both snmptrapd and csiTrapHandler will be writing to the same file, and they will overwrite each other. To avoid this, do the following at the bottom of the Trap Reciever’s Config File page:<br />
1) Enter csiTrapReceiver_info_log in the filename window, select Yes, and click Select Logging Options.<br />
2) Without disabling logging, enter a different filename in the filename window, keep Yes selected, and click Select Logging Options again. <br />
You now have two logging files active. The csiTrapReceiver_info_log file will be used by csiTrapHandler, and the second file named, whatever it is, will be used by the snmptrapd service.<br />
<br />
Selecting No and clicking Select Logging Options will disable logging to both files. The csiTrapReceiver_info_log will be renamed expiredTrap_info_log when logging is disabled (since the mere existence of csiTrapReceiver_info_log will trigger logging by csiTrapHandler).</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Trap_Receiver_Snmptrapd.conf_File&diff=1410SNMP Trap Receiver Snmptrapd.conf File2019-05-22T00:48:33Z<p>Jimhogenson: </p>
<hr />
<div>[[File:Snmp trap receiver snmptrapd 1.jpg]]<br />
<br />
The SNMP Trap engine that responds to Trap messages requires a configuration file named snmptrapd.conf to direct its functionality, primarily in terms of authorization. This page allows automated generation of that file, but with the option to manually edit it. <br />
<br />
The SNMP engine in this IoTServer is the widely used open source Net-SNMP package. If you are concerned about manually editing the snmptrapd.conf file, simple search the Internet for Net-SNMP documentation - there is much to be found. <br />
<br />
[[File:Snmp trap receiver snmptrapd 2.jpg]]<br />
<br />
The port on which SNMP listens for Trap messages defaults to the standard port 162. You may change it here if you wish. <br />
<br />
Authorization for access in SNMPv1 and SNMPv2 is very simply. You only need to match the community names which are treated sort of like a password. If using SNMP v1 or v2 (v2c), enter your community strings here. Trap messages received as v1 or v2 will be expected to match this community.<br />
<hr><br />
[[File:Snmp trap receiver snmptrapd 3.jpg]]<br />
<br />
Click the Generate Config button to auto-generate an snmptrapd.conf file. Parameters included in the file will be taken from two places: (1) The entries showing above on this page. (2) User settings from the System -> Users page (if SNMPv3).<br />
<br />
SNMPv3 enforces access only by known users. These users may be a person or may be anther machine, but must be defined as a "user" either way. To permit SNMPv3 Traps (or Informs) to be received, go to the System -> Users page and create a "user" for each person or machine that will send Traps to this IoTServer. Once the users are created, and they have been selected for SNMPv3 Trap access, they will be automatically included in the snmptrapd.conf file generated here.<br />
<hr><br />
[[File:Snmp trap receiver snmptrapd 4.jpg]]<br />
<br />
Once the interim snmptrapd.conf file is generated, it may be viewed and optionally edited here. The file content displayed here is not actually saved to a file until you click the Save button at the bottom. When Save is clicked, the file name given will be created or overwritten with the content currently displayed. <br />
<br />
There are two more steps required to complete the reconfiguration of the SNMP Trap Receiver. Go to the SNMP Trap Receiver Config File page, select the newly created interim snmptrapd.conf file, and click the Load button (as discussed on the [[SNMP Trap Receiver Config File]] page). Finally, after loading the new snmptrapd.conf file, click Restart SNMP at the bottom of the Config File page.<br />
<br />
'''[[Additional SNMP Trap Receiver Tips and Techniques]]'''</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Agent_CSV_Files&diff=1409SNMP Agent CSV Files2019-05-21T13:35:08Z<p>Jimhogenson: </p>
<hr />
<div>== SNMP Agent CSV Files ==<br />
<br />
A CSV file may be imported to configure various aspects of the IoTServer (or Babel Buster gateway). A single CSV file may contain multiple sections. When a file including an “Objects” section is imported by the Data Engine, local objects will be configured. When a file including one or more “Modbus” sections is imported by an instance of the Modbus Engine, Modbus gateway functionality will be configured. The same Modbus file may be imported by a Modbus Client or Modbus Server, and either RTU or TCP, and only those sections of interest to that Modbus function will be imported. The CSV file may also contain one or more SNMP sections, and so forth.<br />
<br />
A section begins when the word “Begin” appears in the first column of a line. All lines up to and including a line that begins with the word “End” will be taken to be part of that section. <br />
<br />
The line immediately following the “Begin” line must be a header line. A Header line is one which labels the columns of data that will follow the Header line. <br />
<br />
All lines following the Header line are data lines that are expected to contain the same number of columns as the Header line, and whose contents are defined by the labels found in each column of the Header line.<br />
<br />
Labels in the section Begin and End lines, and labels in the Header line are NOT case sensitive and will be interpreted equally whether upper case, lower case, or some combination of both (for readability). <br />
<br />
Labels may NOT contain embedded spaces. A label is terminated by a comma, line-end, or space. Labels may not be encapsulated in quote characters; however, data content in data lines may be encapsulated in quote characters and may contain embedded spaces or blanks if quoted. <br />
<br />
Some labels in the Header line may be considered optional. The minimum required columns are indicated in the definition of each data section. <br />
<br />
Columns in the Header line do not have to follow any particular order. They may be rearranged to the user’s liking. The only restriction is that data in subsequent data lines must match up with the labels placed in the Header line. Data lines may contain fewer columns than the Header line, but may not contain more. Data columns that the user wishes to deliberately omit, but omit between included columns, should be indicated by place holder commas (which will simply appear as blank cells in a spread sheet program). <br />
<br />
A Begin line will contain three columns:<br><br />
Column 1: BEGIN<br><br />
Column 2: Function as noted below<br><br />
Column 3: Sub-function as noted in definition of the Function.<br />
<br />
Functions may be any of the following (with this listed expanded from time to time):<br><br />
* LOCALDATA<br />
* MODBUS<br />
* SNMP<br />
<br />
Sub-functions:<br><br />
SNMP (client)<br />
* DEVICES<br />
* READMAPS<br />
* WRITEMAPS<br />
* WALKRULES<br />
SNMP (agent)<br />
* MIBVARS<br />
* DEVICES<br />
* TRAPSENDRULES<br />
SNMP (trap receiver)<br />
* TRAPRECVRULES<br />
<br />
NOTE: The same SNMP CSV file may NOT contain both client and server sections as DEVICES becomes ambiguous. SNMP requires different applications for different purposes (csiSnmpClient, csiSnmpAgent, csiSnmpTrapRecv). A fourth application, csiTrapHandler, is also associated with csiSnmpAgent.<br />
<br />
== SNMP Agent (Server) Example ==<br />
<br />
BEGIN,SNMP,MIBVARS<br><br />
BRANCH,INDEX,OBJECT,SCALE<br><br />
1,1,1,0.000000<br><br />
1,2,2,0.000000<br><br />
1,3,3,0.000000<br><br />
1,4,4,10.000000<br><br />
1,5,5,100.000000<br><br />
2,1,3,0.000000<br><br />
3,1,4,10.000000<br><br />
3,2,5,100.000000<br><br />
4,1,6,0.000000<br><br />
4,2,7,0.000000<br><br />
END<br><br />
BEGIN,SNMP,DEVICES<br><br />
NUMBER,PEERNAME,VERSION,COMMUNITY,DEVMASK,NAME<br><br />
1,192.168.1.109,2,special,0001,Dell<br><br />
END<br><br />
BEGIN,SNMP,TRAPSENDRULES<br><br />
BRANCH,INDEX,TEST,SENDONTRUE,SENDONFALSE,CONDOBJ,CONDVAL,HYST,DEVMASK,REPTRUE,REPFALSE,REPTIME,ONTIME,OFFTIME,TRUEMSG,FALSEMSG<br><br />
1,1,GT,Y,Y,0,10.000000,0.000000,0001,0,0,0.000000,0.000000,0.000000,Value is up,value is down<br><br />
END<br />
<br />
== SNMP (agent/server) MIBVARS Section ==<br />
<br />
'''Branch''' – Specifies which of the 4 data branches of the MIB this object should be made available in. Data will be automatically converted as necessary. Object type does not matter. Regardless of the local object’s native data type, the data will be presented to SNMP according to the format for that branch.<br />
<br />
{| class="wikitable"<br />
|-<br />
! Branch number !! Data format <br />
|-<br />
| 1 || Signed 32-bit integer (INTEGER) <br />
|-<br />
| 2 || Unsigned 64-bit integer (COUNTER64)<br />
|-<br />
| 3 || 32-bit or 64-bit floating point (see note)<br />
|-<br />
| 4 || Octet String<br />
|}<br />
<br />
Note: The floating point branch (3) will default to OPAQUE DOUBLE (Net-SNMP type), but may be configured to be 32-bit or 64-bit Opaque Float or Double, or the 32-bit or 64-bit version of RFC 6340 Octet String interpretation. This selection is a configuration property of the SNMP agent task. <br />
<br />
'''Index''' – Refers to the row number in the MIB table, ranging from 1 to maximum table size as set in the agent task configuration at startup.<br />
<br />
'''Object''' – Refers to the local object number mapped at this location (branch and index) in the MIB.<br />
<br />
'''Scale''' – Applies to integer branches only (disregarded otherwise), and provides the scale factor by which the local object value is multiplied when responding to an SNMP Get, or by which the incoming value from an SNMP Set is divided before placing it into the local object.<br />
<br />
== SNMP (agent/server) DEVICES Section ==<br />
<br />
The DEVICES section in the SNMP server (agent) specify which remote SNMP devices traps or informs should be sent to as a result of the trap send rules.<br />
<br />
'''Number''' – A number ranging from 1 to device table size, and was historically referenced in read and write maps as the device to which the map applied. However, with the implementation of device mask in the SNMP agent, the mask is what actually determines which device(s) the trap is sent to, and the same trap may be sent to multiple devices with only one trap rule as a result of the mask implementation. This number is therefore simply a row number on the list for database reference. <br />
<br />
'''PeerName''' – Provides a definition of where on the network to find the device. The peername in simplest form will be an IP address as illustrated in the XML file example above. However, if the network has access to a DNS server and that server is configured in the network settings of the local device, then peername may be any name that can be found via DNS lookup.<br />
<br />
'''Version''' – Specifies what SNMP version should be used to send the trap, which in turn determines certain aspects of how the trap message is formatted. Version may be 1, 2, or 3 where 2 really means v2c.<br />
<br />
'''Community''' – Is the community string as defined for SNMP v1 and v2c.<br />
<br />
'''DevMask''' – A 32-bit bit mask that allows sending the same trap to multiple devices. Both the trap send rules and the trap devices have a “device mask” (DevMask). This effectively creates device groups in a very simple manner. The bit mask found in the trap send rule is logically ANDed with the bit mask in the device table entry. If the result is non-zero, then the trap is sent to this device.<br />
<br />
'''Name''' – Simply a reference in the web UI for the user to identify this device.<br />
<br />
'''SecLevel''' - Sets security level, 1=noAuthNoPriv, 2=authNoPriv, 3=authPriv. Those are the SNMP acronyms meaning (1) no authentication or privacy, (2) authentication required but privacy is not, (3) both authentication and privacy are required. The term “privacy” means encryption. (Used only for SNMPv3.)<br />
<br />
'''Username''' - Sets the SNMP security name, analogous to username in SNMP terms. (Used only for SNMPv3.)<br />
<br />
'''AuthType''' - Sets the authentication type, may be “NOAUTH”, “MD5”, or “SHA”. It determines how the username (security name) is hashed when transmitted. (Used only for SNMPv3.)<br />
<br />
'''AuthPhrase''' - Sets the authentication phrase, analogous to an SNMP password. (Used only for SNMPv3.)<br />
<br />
'''PrivType''' - Sets the privacy type, may be “NOPRIV”, “DES”, or “AES”. This determines which encryption algorithm will be used. (Used only for SNMPv3.)<br />
<br />
'''PrivPhrase''' - Sets the privacy phrase which is used as the encryption key. (Used only for SNMPv3.)<br />
<br />
'''EngineId''' - Sets the engine ID that will be sent with the trap message if SNMPv3. (Used only for SNMPv3.)<br />
<br />
NOTE: The engine ID will be taken as a literal ASCII string (and probably not work) if it does not begin with “0x”. The recipient of an SNMPv3 trap will generally discard it if the engine ID does not match its own engine ID. It is necessary to know quite a bit about where you are sending traps with v3. <br />
<br />
== SNMP (agent/server) TRAPSENDRULES Section ==<br />
<br />
'''Branch''' – Specifies which branch in the MIB that this trap rule applies to, and primarily provides the means to look up the local object number that should be evaluated.<br />
<br />
'''Index''' – Specifies the index or row number in the given branch for looking up the local object nubmer.<br />
<br />
'''Test''' – Defines the test that should be performed to determine if the trap send rule state is true or false. Trap state is considered “true” when this condition is met <br />
<br />
{| class="wikitable"<br />
|-<br />
! Test label !! Test performed on object versus threshold<br />
|-<br />
| GT || Object greater than threshold <br />
|-<br />
| GE || Object greater than or equal threshold <br />
|-<br />
| LT || Object less than threshold <br />
|-<br />
| LE || Object is less than or equal threshold <br />
|-<br />
| EQ || Object is equal threshold <br />
|-<br />
| NE || Object is not equal threshold <br />
|-<br />
| DEV || Object deviates from threshold by hysteresis amount <br />
|-<br />
| DELTA || Object has changed by threshold amount <br />
|}<br />
<br />
'''SendOnTrue''' – Enter “N” to disable, or “Y” to enable the sending of a trap when the condition specified by this rule tests “true”.<br />
<br />
'''SendOnFalse''' – Enter “N” to disable, or “Y” to enable the sending of a trap when the condition specified by this rule tests “false”.<br />
<br />
'''SendInform''' – Enter “N” to send the message as an SNMP Trap, or “Y” to send the message as an SNMP Inform.<br />
<br />
'''CondObj''' – Overrides the conditional value when given (non-zero), and provides the local object from which a test threshold should be retrieved.<br />
<br />
'''CondVal''' – Provided no conditional object number is given, this becomes the threshold value for test purposes.<br />
<br />
'''Hyst''' – Specifies the hysteresis value to be applied in the test process (see API notes).<br />
<br />
'''DevMask''' – A 32-bit bit mask that allows sending the same trap to multiple devices. Both the trap send rules and the trap devices have a “device mask” (devMask). This effectively creates device groups in a very simple manner. The bit mask found in the trap send rule is logically ANDed with the bit mask in the device table entry. If the result is non-zero, then the trap is sent to this device.<br />
<br />
'''RepTrue''' – Used to repeat the trap this number of times when true. Traps are not acknowledged, so this provides a means of repeating the same Trap message to better ensure delivery. Set to -1 to repeat indefinitely while condition tests true.<br />
<br />
'''RepFalse''' – Used to repeat the trap this number of times when false. Traps are not acknowledged, so this provides a means of repeating the same Trap message to better ensure delivery. Set to -1 to repeat indefinitely while condition tests false.<br />
<br />
'''RepTime''' – Specifies the amount of time in seconds to wait in between repeated sending of the same Trap message as indicated by the repeat count attributes above.<br />
<br />
'''OnTime''' – Specifies a minimum amount of time in seconds that the “true” state must exist before the trap state will be fully regarded as true and “true” trap sent. If the condition tests true, and within this time period returns to false, no “true” trap will be sent.<br />
<br />
'''OffTime''' – Specifies the minimum amount of time in seconds that the “false” state must exist before the trap state will be fully regarded as false and the “false” trap sent. If the condition tests false, and within this time period returns to true, no “false” trap will be sent.<br />
<br />
'''TrueMsg''' – Provides a user defined message that will be delivered as one of the varbinds in any “true” Trap or Inform message sent.<br />
<br />
'''FalseMsg''' – Provides a user defined message that will be delivered as one of the varbinds in any “false” Trap or Inform message sent.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Agent_XML_Files&diff=1408SNMP Agent XML Files2019-05-21T13:33:42Z<p>Jimhogenson: </p>
<hr />
<div>== SNMP Agent XML Files ==<br />
<br />
'''Example XML File'''<br />
<br />
&lt;?xml version="1.0" encoding="ISO-8859-1" ?&gt;<br><br />
&lt;!-- IoT Server SNMP Agent configuration file --&gt;<br />
<br />
&lt;configuration&gt;<br />
<br />
&lt;mib_vars_int32&gt;<br><br />
&lt;var index="1" object="1"/&gt;<br><br />
&lt;var index="2" object="2"/&gt;<br><br />
&lt;var index="3" object="3"/&gt;<br><br />
&lt;var index="4" object="4" scale="10"/&gt;<br><br />
&lt;var index="5" object="5" scale="100"/&gt;<br><br />
&lt;/mib_vars_int32&gt;<br><br />
<br />
&lt;mib_vars_uint64&gt;<br><br />
&lt;var index="1" object="3"/&gt;<br><br />
&lt;/mib_vars_uint64&gt;<br />
<br />
&lt;mib_vars_double&gt;<br><br />
&lt;var index="1" object="4"/&gt;<br><br />
&lt;var index="2" object="5"/&gt;<br><br />
&lt;/mib_vars_double&gt;<br />
<br />
&lt;mib_vars_charstr&gt;<br><br />
&lt;var index="1" object="6"/&gt;<br><br />
&lt;var index="2" object="7"/&gt;<br><br />
&lt;/mib_vars_charstr&gt;<br />
<br />
&lt;trap_devices&gt;<br><br />
&lt;dev id="1" version="3" secLevel="3" peername="192.168.1.109:162" name="Dell" devMask="1" username="jim" authType="MD5" authPhrase="jimsAuthPhrase" privType="DES" privPhrase="jimsPrivPhrase" engineId="0x80000ee7031803731a2386"/&gt;<br><br />
&lt;/trap_devices&gt;<br />
<br />
&lt;trap_rules&gt;<br><br />
&lt;rule branch="1" index="1" test="gt" condval="10" sendOnTrue="1" sendOnFalse="1" devMask="1" truemsg="Value is up" falsemsg="value is down"/&gt;<br><br />
&lt;/trap_rules&gt; <br />
<br />
&lt;/configuration&gt;<br />
<br />
== &lt;mib_vars_xxx&gt; section ==<br />
<br />
There will be up to four &lt;mib_vars_xxx&gt; sections in the XML file referring to the branches of the MIB. The Json setMibVars API call specifies the branch by number in the call. The contents of each MIB var entry are as listed below - a simple mapping of object to MIB index.<br />
<br />
'''index=”n”''' – Refers to the row number in the MIB table, ranging from 1 to maximum table size as set in the agent task configuration at startup.<br />
<br />
'''object=”n”''' – Refers to the local object number mapped at this location (branch and index) in the MIB.<br />
<br />
'''scale=”n.nn”''' – Applies to integer branches only (disregarded otherwise), and provides the scale factor by which the local object value is multiplied when responding to an SNMP Get, or by which the incoming value from an SNMP Set is divided before placing it into the local object. <br />
<br />
== &lt;trap_devices&gt; section ==<br />
<br />
'''id=”n”''' – A number ranging from 1 to device table size, and was historically referenced in read and write maps as the device to which the map applied. However, with the implementation of device mask in the SNMP agent, the mask is what actually determines which device(s) the trap is sent to, and the same trap may be sent to multiple devices with only one trap rule as a result of the mask implementation. <br />
<br />
'''peername=”xxxx”''' – Provides a definition of where on the network to find the device. The peername in simplest form will be an IP address as illustrated in the XML file example above. However, if the network has access to a DNS server and that server is configured in the network settings of the local device, then peername may be any name that can be found via DNS lookup. <br />
<br />
'''version=”n”''' – Specifies what SNMP version should be used to send the trap, which in turn determines certain aspects of how the trap message is formatted. Version may be 1, 2, or 3 where 2 really means v2c. <br />
<br />
'''devMask=”x”''' – A 32-bit bit mask that allows sending the same trap to multiple devices. Both the trap send rules and the trap devices have a “device mask” (devMask). This effectively creates device groups in a very simple manner. The bit mask found in the trap send rule is logically ANDed with the bit mask in the device table entry. If the result is non-zero, then the trap is sent to this device. <br />
<br />
'''community=”xxxx”''' – Is the community string as defined for SNMP v1 and v2c.<br />
<br />
'''name=”xxxx”''' – Simply a reference in the web UI for the user to identify this device. <br />
<br />
'''secLevel=”n”''' - Sets security level, 1=noAuthNoPriv, 2=authNoPriv, 3=authPriv. Those are the SNMP acronyms meaning (1) no authentication or privacy, (2) authentication required but privacy is not, (3) both authentication and privacy are required. The term “privacy” means encryption. (Used only for SNMPv3.)<br />
<br />
'''username=”xxxx”''' - Sets the SNMP security name, analogous to username in SNMP terms. (Used only for SNMPv3.)<br />
<br />
'''authType=”xxx”''' - Sets the authentication type, may be “NOAUTH”, “MD5”, or “SHA”. It determines how the username (security name) is hashed when transmitted. (Used only for SNMPv3.)<br />
<br />
'''authPhrase=”xxx”''' - Sets the authentication phrase, analogous to an SNMP password. (Used only for SNMPv3.)<br />
<br />
'''privType=”xxx”''' - Sets the privacy type, may be “NOPRIV”, “DES”, or “AES”. This determines which encryption algorithm will be used. (Used only for SNMPv3.)<br />
<br />
'''privPhrase=”xxx”''' - Sets the privacy phrase which is used as the encryption key. (Used only for SNMPv3.)<br />
<br />
'''engineId=”xxx”''' - Sets the engine ID that will be sent with the trap message if SNMPv3. (Used only for SNMPv3.)<br />
<br />
Note: The engine ID will be taken as a literal ASCII string (and probably not work) if it does not begin with “0x”. The recipient of an SNMPv3 trap will generally discard it if the engine ID does not match its own engine ID. It is necessary to know quite a bit about where you are sending traps with v3. <br />
<br />
== &lt;trap_rules&gt; section ==<br />
<br />
'''branch=”n”''' – Specifies which branch in the MIB that this trap rule applies to, and primarily provides the means to look up the local object number that should be evaluated. <br />
<br />
'''index=”n”''' – Specifies the index or row number in the given branch for looking up the local object nubmer.<br />
<br />
'''condval=”n.nn”''' – Provided no conditional object number is given, this becomes the threshold value for test purposes.<br />
<br />
'''condobj=”n”''' – Overrides the conditional value when given (non-zero), and provides the local object from which a test threshold should be retrieved.<br />
<br />
'''test=”xxx”''' – Defines the test that should be performed to determine if the trap send rule state is true or false.<br />
<br />
Trap state is considered “true” when this condition is met <br />
{| class="wikitable"<br />
|-<br />
! XML Label !! Test Code !! Rest performed on object versus threshold<br />
|-<br />
| “none” || 0 || No trap sent <br />
|-<br />
| “gt” || 1 || Object greater than threshold <br />
|-<br />
| “ge” || 2 || Object greater than or equal to threshold <br />
|-<br />
| “lt” || 3 || Object less than threshold <br />
|-<br />
| “le” || 4 || Object is less than or equal to threshold <br />
|-<br />
| “eq” || 5 || Object is equal to threshold <br />
|-<br />
| “ne” || 6 || Object is not equal to threshold <br />
|-<br />
| “dev” || 7 || Object deviates from threshold by hysteresis amount <br />
|-<br />
| “delta” || 8 || Object has changed by threshold amount <br />
|}<br />
Threshold is either the fixed value given by “condval”, or the value found in the object given as “condobj”. <br />
<br />
For most tests, the object is simply compared to the threshold value. The delta test is a special case. The threshold specifies an amount by which the local object needs to change before the rule test will be flagged as true. However, this “true” state is only temporary. Once the trap is sent, the new object value is now saved for subsequent tests of “changed by”. Every time the local object changes by the threshold amount, a new trap will be sent. <br />
<br />
Test type delta with threshold of zero is a special case within the special case. If the test type is delta and the threshold value is zero, then the trap will be sent any time the local object (found by looking it up in the MIB) has been updated or changed by some other action in the system, without any regard for what the actual value of the object is.<br />
<br />
'''hyst=”n.nn”''' – Specifies the hysteresis value to be applied in the test process. Hysteresis is used to prevent a flood of trap messages when the object is hovering near the threshold but fluctuating frequently. For ‘greater than’ type tests, once the rule state becomes true, the object value must fall below the threshold by the hysteresis amount before the rule state will return to false. For ‘less than’ type tests, once the rule state becomes true, the object value must rise above the threshold by the hysteresis amount before the rule state will return to false. For example, if the rule threshold is 10, and the test is ‘greater than’, then the rule state will become true when the object value exceeds 10. If the hysteresis value is 2, then the object value must now fall below 8 before the rule state will return to false.<br />
<br />
The hysteresis value takes on a special role when the test type is “deviates by”. The rule state will be true when the difference between object value and threshold exceeds the hysteresis amount in either direction, high or low. <br />
<br />
'''ontime=”n.nn”''' – Specifies a minimum amount of time that the “true” state must exist before the trap state will be fully regarded as true and “true” trap sent. If the condition tests true, and within this time period returns to false, no “true” trap will be sent. <br />
<br />
'''offtime=”n.nn”''' – Specifies the minimum amount of time that the “false” state must exist before the trap state will be fully regarded as false and the “false” trap sent. If the condition tests false, and within this time period returns to true, no “false” trap will be sent. <br />
<br />
'''sendOnTrue=”x”''' – Expects a value of 0 to disable, or 1 to enable the sending of a trap when the condition specified by this rule tests “true”. <br />
<br />
'''sendOnFalse=”x”''' – Expects a value of 0 to disable, or 1 to enable the sending of a trap when the condition specified by this rule tests “false”. <br />
<br />
'''sendInform=”x”''' – Expects a value of 0 to send the message as an SNMP Trap, or value of 1 to send the message as an SNMP Inform. <br />
<br />
'''devMask=”x”''' – A 32-bit bit mask that allows sending the same trap to multiple devices. Both the trap send rules and the trap devices have a “device mask” (devMask). This effectively creates device groups in a very simple manner. The bit mask found in the trap send rule is logically ANDed with the bit mask in the device table entry. If the result is non-zero, then the trap is sent to this device. <br />
<br />
'''repcounttrue=”n”''' – Used to repeat the trap this number of times when true. Traps are not acknowledged, so this provides a means of repeating the same Trap message to better ensure delivery. Set to -1 to repeat indefinitely while condition tests true.<br />
<br />
'''repcountfalse=”n”''' – Used to repeat the trap this number of times when false. Traps are not acknowledged, so this provides a means of repeating the same Trap message to better ensure delivery. Set to -1 to repeat indefinitely while condition tests false.<br />
<br />
'''reptime=”n.nn”''' – Specifies the amount of time to wait in between repeated sending of the same Trap message as indicated by the repcount attributes above. <br />
<br />
'''truemsg=”xxxx”''' – Provides a user defined message that will be delivered as one of the varbinds in any “true” Trap or Inform message sent.<br />
<br />
'''falsemsg=”xxxx”''' – Provides a user defined message that will be delivered as one of the varbinds in any “false” Trap or Inform message sent.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=SNMP_Agent_Trap_Send_Rule_Edit&diff=1407SNMP Agent Trap Send Rule Edit2019-05-21T13:32:15Z<p>Jimhogenson: </p>
<hr />
<div>SNMP Trap or Inform messages sent by this IoTServer are defined by rules outlined here. Traps may be sent as v1, v2c, or v3, and this selection is made in the SNMP Trap Destination Device configuration. The same trap may be sent to different devices as both v2c and v3 at the same time using the same Trap Send Rule.<br />
<br />
[[File:Snmp agent trap rule edit 1.jpg]]<br />
<br />
'''Rule Number''' – Used as a reference in the rule list for ordering the rules.<br />
<br />
[[File:Snmp agent trap rule edit 2.jpg]]<br />
<br />
'''Branch''' – Specifies which branch in the MIB that this trap rule applies to, and primarily provides the means to look up the local object number that should be evaluated.<br />
<br />
'''Index''' – Specifies the index or row number in the given branch for looking up the local object nubmer.<br />
<br />
[[File:Snmp agent trap rule edit 3.jpg]]<br />
<br />
'''Test''' – Defines the test that should be performed to determine if the trap send rule state is true or false. Trap state is considered “true” when this condition is met <br />
<br />
{| class="wikitable"<br />
|-<br />
! Test label !! Test performed on object versus threshold<br />
|-<br />
| GT || Object greater than threshold <br />
|-<br />
| GE || Object greater than or equal threshold <br />
|-<br />
| LT || Object less than threshold <br />
|-<br />
| LE || Object is less than or equal threshold <br />
|-<br />
| EQ || Object is equal threshold <br />
|-<br />
| NE || Object is not equal threshold <br />
|-<br />
| DEV || Object deviates from threshold by hysteresis amount <br />
|-<br />
| DELTA || Object has changed by threshold amount <br />
|}<br />
<br />
For most tests, the object is simply compared to the threshold value. The delta test is a special case. The threshold specifies an amount by which the local object needs to change before the rule test will be flagged as true. However, this “true” state is only temporary. Once the trap is sent, the new object value is now saved for subsequent tests of “changed by”. Every time the local object changes by the threshold amount, a new trap will be sent. <br />
<br />
Test type delta with threshold of zero is a special case within the special case. If the test type is delta and the threshold value is zero, then the trap will be sent any time the local object (found by looking it up in the MIB) has been updated or changed by some other action in the system, without any regard for what the actual value of the object is.<br />
<br />
[[File:Snmp agent trap rule edit 4.jpg]]<br />
<br />
'''Threshold Value''' (CSV "CondVal") – Provided no threshold object number is given, this becomes the threshold value for test purposes. <br />
<br />
'''Threshold Object''' (CSV "CondObj")– Overrides the threshold value when given (non-zero), and provides the local object from which a test threshold should be retrieved.<br />
<br />
'''Hysteresis''' (CSV "Hyst") – Specifies the hysteresis value to be applied in the test process. Hysteresis is used to prevent a flood of trap messages when the object is hovering near the threshold but fluctuating frequently. For ‘greater than’ type tests, once the rule state becomes true, the object value must fall below the threshold by the hysteresis amount before the rule state will return to false. For ‘less than’ type tests, once the rule state becomes true, the object value must rise above the threshold by the hysteresis amount before the rule state will return to false. For example, if the rule threshold is 10, and the test is ‘greater than’, then the rule state will become true when the object value exceeds 10. If the hysteresis value is 2, then the object value must now fall below 8 before the rule state will return to false.<br />
<br />
The hysteresis value takes on a special role when the test type is “deviates by”. The rule state will be true when the difference between object value and threshold exceeds the hysteresis amount in either direction, high or low. <br />
<br />
[[File:Snmp agent trap rule edit 5.jpg]]<br />
<br />
'''SendOnTrue''' – Select (use Y/N in CSV) to enable the sending of a trap when the condition specified by this rule tests “true”.<br />
<br />
'''SendOnFalse''' – Select (use Y/N in CSV) to enable the sending of a trap when the condition specified by this rule tests “false”.<br />
<br />
[[File:Snmp agent trap rule edit 6.jpg]]<br />
<br />
'''Device Group''' – The device group allows selectively sending the same trap to multiple devices. Both the trap send rules and the trap devices have a group association. When the group association of a trap rule matches the groups that the device is a member of, the trap will be sent to that device, and all devices included in the group. <br />
<br />
The group selection is made as a bit mask labeled "DevMask" in CSV and XML files. Group "A" is bit 0 or value of 1. Group "B" is bit 1 or value of 2. Group "C" is bit 2 or value of 4, and so on. The mask is the summation of the groups. Only the first 8 bits are used in the web UI for ease of use. Internally, the test for group membership is a simple logical AND of the mask values found in the trap rule and the device configuration. <br />
<br />
[[File:Snmp agent trap rule edit 7.jpg]]<br />
<br />
'''SendInform''' – Uncheck box (default) to send the message as an SNMP Trap. Check box to send the message as an SNMP Inform. In the CSV or XML file, use "Y" to send as Inform, "N" to send as trap. If omitted, the default is to send an SNMP Trap. <br />
<br />
[[File:Snmp agent trap rule edit 8.jpg]]<br />
<br />
'''OnTime''' – Specifies a minimum amount of time in seconds that the “true” state must exist before the trap state will be fully regarded as true and “true” trap sent. If the condition tests true, and within this time period returns to false, no “true” trap will be sent.<br />
<br />
'''OffTime''' – Specifies the minimum amount of time in seconds that the “false” state must exist before the trap state will be fully regarded as false and the “false” trap sent. If the condition tests false, and within this time period returns to true, no “false” trap will be sent.<br />
<br />
[[File:Snmp agent trap rule edit 9.jpg]]<br />
<br />
'''TrueMsg''' – Provides a user defined message that will be delivered as one of the varbinds in any “true” Trap or Inform message sent.<br />
<br />
'''FalseMsg''' – Provides a user defined message that will be delivered as one of the varbinds in any “false” Trap or Inform message sent.<br />
<br />
[[File:Snmp agent trap rule edit 10.jpg]]<br />
<br />
'''RepTrue''' – Used to repeat the trap this number of times when true. Traps are not acknowledged, so this provides a means of repeating the same Trap message to better ensure delivery. Set to -1 to repeat indefinitely while condition tests true.<br />
<br />
'''RepFalse''' – Used to repeat the trap this number of times when false. Traps are not acknowledged, so this provides a means of repeating the same Trap message to better ensure delivery. Set to -1 to repeat indefinitely while condition tests false.<br />
<br />
'''RepTime''' – Specifies the amount of time in seconds to wait in between repeated sending of the same Trap message as indicated by the repeat count attributes above.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Modbus_TCP_Client_Error_Counts&diff=1406Modbus TCP Client Error Counts2019-05-21T03:29:38Z<p>Jimhogenson: </p>
<hr />
<div>[[File:Modbus TCP client status error counts.jpg|850px]]<br />
* Click the Clear Counts to reset the counts to zero. <br />
* Click the Refresh button to update the counts.<br />
<br />
This page shows an error summary on a device by device basis. There will be one line per each device configured for access by the Modbus TCP Client. If there is a non-zero error count for a device, you can begin to track down where this error is occurring by viewing the Read and Write Data pages for the Modbus TCP Client.<br />
<br />
Socket errors will be an error code reported by the system if nonzero. Refer to the '''[[Socket Errors]]''' list for these errors.</div>Jimhogensonhttps://wiki.csimn.com/index.php?title=Socket_Errors&diff=1405Socket Errors2019-05-21T03:27:08Z<p>Jimhogenson: </p>
<hr />
<div>The following is the full list of standard operating system error codes. Only some of these are applicable to sockets. <br />
{| class="wikitable"<br />
|-<br />
! Symbolic !! Numeric !! Description<br />
|-<br />
| EPERM || 1 || Operation not permitted <br />
|-<br />
| ENOENT || 2 || No such file or directory <br />
|-<br />
| ESRCH || 3 || No such process <br />
|-<br />
| EINTR || 4 || Interrupted system call <br />
|-<br />
| EIO || 5 || I/O error <br />
|-<br />
| ENXIO || 6 || No such device or address <br />
|-<br />
| E2BIG || 7 || Argument list too long <br />
|-<br />
| ENOEXEC || 8 || Exec format error <br />
|-<br />
| EBADF || 9 || Bad file number <br />
|-<br />
| ECHILD || 10 || No child processes <br />
|-<br />
| EAGAIN || 11 || Try again <br />
|-<br />
| ENOMEM || 12 || Out of memory <br />
|-<br />
| EACCES || 13 || Permission denied <br />
|-<br />
| EFAULT || 14 || Bad address <br />
|-<br />
| ENOTBLK || 15 || Block device required <br />
|-<br />
| EBUSY || 16 || Device or resource busy <br />
|-<br />
| EEXIST || 17 || File exists <br />
|-<br />
| EXDEV || 18 || Cross-device link <br />
|-<br />
| ENODEV || 19 || No such device <br />
|-<br />
| ENOTDIR || 20 || Not a directory <br />
|-<br />
| EISDIR || 21 || Is a directory <br />
|-<br />
| EINVAL || 22 || Invalid argument <br />
|-<br />
| ENFILE || 23 || File table overflow <br />
|-<br />
| EMFILE || 24 || Too many open files <br />
|-<br />
| ENOTTY || 25 || Not a typewriter <br />
|-<br />
| ETXTBSY || 26 || Text file busy <br />
|-<br />
| EFBIG || 27 || File too large <br />
|-<br />
| ENOSPC || 28 || No space left on device <br />
|-<br />
| ESPIPE || 29 || Illegal seek <br />
|-<br />
| EROFS || 30 || Read-only file system <br />
|-<br />
| EMLINK || 31 || Too many links <br />
|-<br />
| EPIPE || 32 || Broken pipe <br />
|-<br />
| EDOM || 33 || Math argument out of domain of func <br />
|-<br />
| ERANGE || 34 || Math result not representable <br />
|-<br />
| EDEADLK || 35 || Resource deadlock would occur <br />
|-<br />
| ENAMETOOLONG || 36 || File name too long <br />
|-<br />
| ENOLCK || 37 || No record locks available <br />
|-<br />
| ENOSYS || 38 || Invalid system call number <br />
|-<br />
| ENOTEMPTY || 39 || Directory not empty <br />
|-<br />
| ELOOP || 40 || Too many symbolic links encountered <br />
|-<br />
| EWOULDBLOCK || EAGAIN (11) || Operation would block <br />
|-<br />
| ENOMSG || 42 || No message of desired type <br />
|-<br />
| EIDRM || 43 || Identifier removed <br />
|-<br />
| ECHRNG || 44 || Channel number out of range <br />
|-<br />
| EL2NSYNC || 45 || Level 2 not synchronized <br />
|-<br />
| EL3HLT || 46 || Level 3 halted <br />
|-<br />
| EL3RST || 47 || Level 3 reset <br />
|-<br />
| ELNRNG || 48 || Link number out of range <br />
|-<br />
| EUNATCH || 49 || Protocol driver not attached <br />
|-<br />
| ENOCSI || 50 || No CSI structure available <br />
|-<br />
| EL2HLT || 51 || Level 2 halted <br />
|-<br />
| EBADE || 52 || Invalid exchange <br />
|-<br />
| EBADR || 53 || Invalid request descriptor <br />
|-<br />
| EXFULL || 54 || Exchange full <br />
|-<br />
| ENOANO || 55 || No anode <br />
|-<br />
| EBADRQC || 56 || Invalid request code <br />
|-<br />
| EBADSLT || 57 || Invalid slot <br />
|-<br />
| EDEADLOCK || EDEADLK (35) || Resource deadlock would occur<br />
|-<br />
| EBFONT || 59 || Bad font file format <br />
|-<br />
| ENOSTR || 60 || Device not a stream <br />
|-<br />
| ENODATA || 61 || No data available <br />
|-<br />
| ETIME || 62 || Timer expired <br />
|-<br />
| ENOSR || 63 || Out of streams resources <br />
|-<br />
| ENONET || 64 || Machine is not on the network <br />
|-<br />
| ENOPKG || 65 || Package not installed <br />
|-<br />
| EREMOTE || 66 || Object is remote <br />
|-<br />
| ENOLINK || 67 || Link has been severed <br />
|-<br />
| EADV || 68 || Advertise error <br />
|-<br />
| ESRMNT || 69 || Srmount error <br />
|-<br />
| ECOMM || 70 || Communication error on send <br />
|-<br />
| EPROTO || 71 || Protocol error <br />
|-<br />
| EMULTIHOP || 72 || Multihop attempted <br />
|-<br />
| EDOTDOT || 73 || RFS specific error <br />
|-<br />
| EBADMSG || 74 || Not a data message <br />
|-<br />
| EOVERFLOW || 75 || Value too large for defined data type <br />
|-<br />
| ENOTUNIQ || 76 || Name not unique on network <br />
|-<br />
| EBADFD || 77 || File descriptor in bad state <br />
|-<br />
| EREMCHG || 78 || Remote address changed <br />
|-<br />
| ELIBACC || 79 || Can not access a needed shared library <br />
|-<br />
| ELIBBAD || 80 || Accessing a corrupted shared library <br />
|-<br />
| ELIBSCN || 81 || .lib section in a.out corrupted <br />
|-<br />
| ELIBMAX || 82 || Attempting to link in too many shared libraries <br />
|-<br />
| ELIBEXEC || 83 || Cannot exec a shared library directly <br />
|-<br />
| EILSEQ || 84 || Illegal byte sequence <br />
|-<br />
| ERESTART || 85 || Interrupted system call should be restarted <br />
|-<br />
| ESTRPIPE || 86 || Streams pipe error <br />
|-<br />
| EUSERS || 87 || Too many users <br />
|-<br />
| ENOTSOCK || 88 || Socket operation on non-socket <br />
|-<br />
| EDESTADDRREQ || 89 || Destination address required <br />
|-<br />
| EMSGSIZE || 90 || Message too long <br />
|-<br />
| EPROTOTYPE || 91 || Protocol wrong type for socket <br />
|-<br />
| ENOPROTOOPT || 92 || Protocol not available <br />
|-<br />
| EPROTONOSUPPORT || 93 || Protocol not supported <br />
|-<br />
| ESOCKTNOSUPPORT || 94 || Socket type not supported <br />
|-<br />
| EOPNOTSUPP || 95 || Operation not supported on transport endpoint <br />
|-<br />
| EPFNOSUPPORT || 96 || Protocol family not supported <br />
|-<br />
| EAFNOSUPPORT || 97 || Address family not supported by protocol <br />
|-<br />
| EADDRINUSE || 98 || Address already in use <br />
|-<br />
| EADDRNOTAVAIL || 99 || Cannot assign requested address <br />
|-<br />
| ENETDOWN || 100 || Network is down <br />
|-<br />
| ENETUNREACH || 101 || Network is unreachable <br />
|-<br />
| ENETRESET || 102 || Network dropped connection because of reset <br />
|-<br />
| ECONNABORTED || 103 || Software caused connection abort <br />
|-<br />
| ECONNRESET || 104 || Connection reset by peer <br />
|-<br />
| ENOBUFS || 105 || No buffer space available <br />
|-<br />
| EISCONN || 106 || Transport endpoint is already connected <br />
|-<br />
| ENOTCONN || 107 || Transport endpoint is not connected <br />
|-<br />
| ESHUTDOWN || 108 || Cannot send after transport endpoint shutdown <br />
|-<br />
| ETOOMANYREFS || 109 || Too many references: cannot splice <br />
|-<br />
| ETIMEDOUT || 110 || Connection timed out <br />
|-<br />
| ECONNREFUSED || 111 || Connection refused <br />
|-<br />
| EHOSTDOWN || 112 || Host is down <br />
|-<br />
| EHOSTUNREACH || 113 || No route to host <br />
|-<br />
| EALREADY || 114 || Operation already in progress <br />
|-<br />
| EINPROGRESS || 115 || Operation now in progress <br />
|-<br />
| ESTALE || 116 || Stale file handle <br />
|-<br />
| EUCLEAN || 117 || Structure needs cleaning <br />
|-<br />
| ENOTNAM || 118 || Not a XENIX named type file <br />
|-<br />
| ENAVAIL || 119 || No XENIX semaphores available <br />
|-<br />
| EISNAM || 120 || Is a named type file <br />
|-<br />
| EREMOTEIO || 121 || Remote I/O error <br />
|-<br />
| EDQUOT || 122 || Quota exceeded <br />
|-<br />
| ENOMEDIUM || 123 || No medium found <br />
|-<br />
| EMEDIUMTYPE || 124 || Wrong medium type <br />
|-<br />
| ECANCELED || 125 || Operation Canceled <br />
|-<br />
| ENOKEY || 126 || Required key not available <br />
|-<br />
| EKEYEXPIRED || 127 || Key has expired <br />
|-<br />
| EKEYREVOKED || 128 || Key has been revoked <br />
|-<br />
| EKEYREJECTED || 129 || Key was rejected by service <br />
|-<br />
| EOWNERDEAD || 130 || Owner died <br />
|-<br />
| ENOTRECOVERABLE || 131 || State not recoverable <br />
|-<br />
| ERFKILL || 132 || Operation not possible due to RF-kill <br />
|-<br />
| EHWPOISON || 133 || Memory page has hardware error <br />
|}</div>Jimhogenson