IOCOMM does not Boot

Symptom	Front panel POWER indicator is not lit.
Action	Check that the power switch is on; check that the power cable is connected to the supply and that the supply is switched on. If still not lit, check the mains supply fuse. If LED is still unlit, the internal power supply or internal fuse may be at fault and the complete unit must be returned to your supplier, Chase Research or an Authorised Repair Centre. Note: Any attempt to remove the IOCOMM cover or effect a repair will invalidate the Chase Research warranty.
Symptom	Front panel monitoring LEDs have stopped mid sequence.
Action	Check the Error Codes section to determine at which point in the sequence it has stopped. Refer to the Bootstrap section for further details. If the bootstrap LEDs indicate an error early in the sequence, check the relevant hardware using the bootstrap diagnostics. If the bootstrap LEDs indicate an error late in the sequence, this could indicate corrupt FLASH memory or contents. See section on FLASH corruption below.
Symptom	Monitoring LEDs have completed the cycle but the IOCOMM is still not functional.
Action	Check the LAN connection. Attach a terminal to port A (or any other enabled serial port): you should see a login prompt. If not, the firmware image in IOCOMM's FLASH memory may be corrupt. See section on FLASH corruption below.
Symptom	FLASH appears to be corrupt.
Action	Check the currently installed firmware, attach a terminal to port A on the rear of the IOCOMM (with the settings 9600 baud, 8 data, no parity, 1 stop) and run the bootstrap manually (option q from the main menu) to check for error messages. If there are no error messages before the `Calling firmware' message, the original download may have been corrupted. Download replacement firmware (from either the original CD or from the Chase Research FTP site) to RAM and check if this runs successfully. If this version of the firmware is OK, download it to the IOCOMM FLASH. See Configuration for details of downloading and saving new firmware.
Symptom	Newly downloaded firmware not running correctly.
Action	This could be a configuration problem. Carry out a factory reset by powering on the unit with the TEST button held in and then select Option 3, then option s from the menu (note that this is not permanent until saved). If the unit now boots, upload the corrupt configuration to a network host for diagnosis and download and save the last known working configuration (from backup copies).
Symptom	IOCOMM still not booting correctly.
Action	If you have carried out all of the above tests and the IOCOMM will still not boot, contact your supplier for further assistance.

Serial Port(s) not Working

Symptom	Device connected to port is not functioning.
Action	Establish that it is the serial port which is at fault and not the connected device by attaching the device to a correctly configured and known working port, or attach a known working terminal and cable to the faulty port.
Symptom	Multiple ports not working.
Action	If it is multiple ports, the pattern of non-working ports could be useful in diagnosing the problem. The following combination of failed ports could suggest the shown faults:
	Port failures	Possible cause
	Block of four ports Block of eight ports All standard ports All ports	Faulty UART Faulty serial board Faulty bridge board Faulty power supply
	Note: Some software or configuration errors could produce a similar pattern of results.
Symptom	Single port not working.
Action	Check the wiring between the serial port and the connected device. Refer to the appropriate wiring specification given in Connectors & Cabling. Perform a software reset of the port(s) using the web browser or CLI hangup command. Substitute a terminal and known working cable and check if you get a login prompt. If you get `garbage' data, check baud rate and character framing settings. Garbage data is possibly a PPP start-up negotiation problem. Check the serial port network protocol configuration. Check the port configuration to ensure settings are correct, e.g. Access enabled. Copy the configuration from a known working port. Check the port using the Status and statistics display page. Check to see if any of the hardware lines are stuck in an unexpected state.
Symptom	None of the above checks fail to locate or resolve the problem.
Action	Reboot the IOCOMM and run the hardware diagnostics using a loop-back connector. Refer to Using the Diagnostic Menu section in Bootstrap. If any of the above faults are confirmed, the unit must be returned to Chase Research or an Authorised Repair Centre. Any attempt to remove the IOCOMM cover or effect a repair will invalidate the Chase Research warranty.

Printing not Working

Symptom	Unable to print using LPD
Action	First check the correct operation of the serial port. If these checks have been made and printing still does not work, check that the printer cable being used is correctly wired. Many printer problems arise from incorrectly wired cables or poor connections within the plug housing. The correct pin assignments are shown in Connectors & Cabling.
Symptom	Printer doesn't communicate with the host machine.
Action	Telnet from the host machine to the access server's LPD port. E.g: telnet fred 515 (connecting to the IOCOMM's LPD) The following message should be displayed: >>telnet fred 515 trying 194.32.85.44.. escape character is `^]'. Connection closed by foreign host If the telnet session will not connect, check that the network is performing correctly. If the telnet session still refuses to operate, re-configure the port for terminal operation and repeat the telnet operation. If this works, it confirms that the network is not at fault. Check if flow control is set to the same setting at both the printer and in IOCOMM Serial ports configuration. Check if the host software is configured correctly for printing.. Check the Status and statistics display page on the IOCOMM web interface and ensure that the table of all connections in the netstat utility shows that local address *.515 is in the listen state. Also check that the port is receiving data in Serial port of the Status and statistics display page. If the status does not indicate any sign of LPD and data transfer on the port, you need to reconfigure the serial port and LPD,
Symptom	Unable to print using iocommd.
Action	Many of the general issues raised above for LPD printing also apply here. Check cables, connections, network, etc. If a printing problem still exists, check to see if the daemon is running. On Unix this would be: ps -ef |grep iocommd This should show an iocommd daemon in the table for each printer. If it is not listed by this command, invoke it now. If it is listed, it is probably incorrectly configured. Kill iocommd using the Unix kill command, then run the command again. Check to see if the spooler is configured correctly. Test the printer without relying on your spooler by sending data direct to the port you created and named, if you ran the iocommd daemon, by typing: cat data_file > /dev/laser1 If the command returns, then the Unix system believes it has sent the data and there is a good chance it has been printed successfully. This would indicate that your print spooler has not been configured correctly. If you have checked all connections and tried all of the above tests and printing is still not working, you are advised to contact your supplier for further assistance.

IOCOMM Unable to Access Other Network Devices

Symptom

Unable to access a device on local and remote networks.

Action

Check that the cable / connector from the LAN is securely fastened into the correct port on the rear panel of the IOCOMM. If you have changed the type of LAN media / connector (e.g. from 10BASE2 to 10BASE-T), restart your access server. Check that the IP address for the access server has been set correctly. Set the correct IP address permanently using the IOCOMM web browser configuration page. Check also that the correct IP Netmask has been set. See Configuration for further information. Check that routing is configured correctly. If there is more than one IP network, routes to the other networks should be set-up. Routing information can be checked through the web browser pages. To check routing information: On the IOCOMM Main menu page, select Status and statistics display, then Netstat utility, then Routing information. The page will display all routes which have been set-up using the Static routes configuration page and all those identified through RIP (listening). Note: netstat can also be run on the CLI (Port A). If there are routes which are missing from the table, these can be entered using the Static routes configuration page or by ensuring that RIP is enabled and that RIP listening (minimum requirement) is selected (RIP will then learn the appropriate addresses). The RIP options are set-up on the Dynamic routing page. Check DNS host tables to ensure that all network server hostname entries are correct and up-to-date.

Symptom

Unable to access remote systems over a WAN interface, such as synchronous or asynchronous outgoing PPP/SLIP links.

Action

Check the Remote sites configuration pages to verify the correct configuration of the remote site information, including the log-in method, user name, password and if required, the log-in script. Check the Serial ports configuration pages to check that the ports which have been configured for remote sites are set to enable outgoing services. Also re-check the physical configuration for the port(s) to ensure that baud rate, word format and flow control settings are correct. Finally, re-check the modem initialisation and dialling strings. Check to see if the routing information table shows static routes to the remote host concerned using a serial link. This can be checked by either using netstat -r in the CLI or via the web browser by selecting Status and statistics display from the IOCOMM Main menu page, then Netstat utility then Routing information. Within the Routing information table, serial links are denoted by either ppp<n> or slp<n> , where <n> is the link number. If a route cannot be identified to the remote host concerned, go back and re-check the Remote sites configuration pages for the host. Check the System log file to identify any dial-out errors occurred when attempting to connect to the remote system. If the connection appears to be successful, check that the remote machines routing information is correct.

Dial-up User Unable to Access IOCOMM

Symptom

Unable to connect to the IOCOMM via a modem connection.

Action

Check the set-up on the user's remote machine. Check the IOCOMM System log file to see if there are any authentication failure messages for the user concerned. To do this, on the IOCOMM Main menu page, select Status and statistics display, then Event logging, then System log. If an authentication failure has been detected, check the RADIUS configuration and the login information for the user concerned on the RADIUS server. Check that the RADIUS server is accessible by the IOCOMM using the LAN or a configured WAN connection (try pinging it). Check that the settings in the Serial ports configuration page are correct, in particular the Access options settings. Check that the correct modem initialisation strings have been specified. Check the IOCOMM System log file to see if there are any modem initialisation and test failure messages. Check that the modem(s) are correctly connected to the telephone line and correctly configured for auto-answer.

Dialup User Can Connect to IOCOMM But Not Onwards (to other hosts)

Symptom

Unable to gain access to a host via the IOCOMM.

Action

If RADIUS authentication is being used, check that the user has the correct permissions, either login or admin on the RADIUS server. If local authentication is being used, check that the user has the required permissions for connecting to the local machines. To check this: On the IOCOMM Main menu page, select Global configuration then Local authentication to check if local authentication is being used. If it is, check the appropriate user entry to ensure that the permissions are correct. Check that the port has the necessary permissions set to allow the user to connect to the local machines. To check this: On the IOCOMM Main menu page, select Global configuration then Serial ports configuration, Access options, then Expert mode. Check the page settings for the port(s) in question.

Dialup User Unable to Access Remote Machines

Symptom	A remote machine is inaccesssible through IOCOMM.
Action	Check the items in IOCOMM Unable to Access Other Network Devices to establish that the remote machine is accessible . Check the routes on the dial-up user's machine. These should be configured to use the IOCOMM as the default gateway.

Configuration Web Pages Not Accesible

Symptom	Web browser cannot be used to access the IOCOMM configuration pages.
Action	Check if you can access the IOCOMM from your PC using other network protocols such as ping, finger and telnet. If these network protocols also fail, it is likely that you have a more general networking fault. See IOCOMM Unable to Access Other Network Devices.
Symptom	Proxy web server cannot reach the IOCOMM.
Action	Try using, ping, finger and telnet from the proxy server to check if this route works. If in doubt, disable the proxy server option on your web browser and see if this resolves the problem. DNS failure, either at the proxy or at your PC could also produce the same problem. To check this, substitute the IP address of the IOCOMM for the host name in the URL. If the IOCOMM web server has been configured for a non-standard (non-default) TCP port for web access, remember to add the new port number to the end of the URL. The HTTPD page provides an administration setting, enabling the web server port number to be changed from the default port number of 80. If you change the port number from 80, you will need to add the new port number to the end of the URL line for the IOCOMM when you try to connect using a web browser. If you change the port number, it is advisable to keep a note of it. However, if you forget the new port number, it can be checked using the netstat -a command from the IOCOMM CLI. Check that the firewall or other routing / bridging device is letting traffic through on the relevant TCP port. This is especially relevant if the IOCOMM web server is on a non-standard port. If you have checked all areas covered above and carried out all of the tests and IOCOMM is still not accessible from the web, contact your supplier.

Initial Bootstrap ARP Jamming

Symptom	Unable to use ARP Jamming. ARP is the protocol used to initially set the IP address of a newly installed IOCOMM. The procedure for this ARP jamming operation is covered in Getting Started. To use ARP jamming, the system whose ARP table you are using must be on the same LAN as the IOCOMM. If you are accessing the LAN via a router or other gateway, then it is this device's ARP table that should be jammed.
Action	Use the ARP command with the IOCOMM's host name or IP address to check the information that has been set. You can also add the pub flag to the jamming command to make sure that the information is broadcast for other devices on the LAN.
Symptom	You can ping the IOCOMM but cannot get web access
Action	It may indicate that the browser is using a proxy that cannot find the IOCOMM. Try jamming the ARP table on the proxy system or disable the proxy operation. See also Configuration Web Pages Not Accessible for more information.
Symptom	ARP Jamming still does not work.
Action	If after trying the above, ARP jamming still does not work, you can set the IOCOMM IP address using an attached terminal or PC on port A of the IOCOMM. See Getting Started for details.