Troubleshooting the Tivoli Endpoint

 

Where to get endpoint information

There are several ways to find information about the endpoint.

 

Configuration and Logging files

There are three files that are important to the startup, configuration, and troubleshooting of the Tivoli (LCF) Endpoint.

LCF.DAT

The LCF.DAT file contains login information related to the endpoint and its connection with the gateway. This file created only when LCF is successfully logged into a gateway. It is encrypted and is read-only. If you successfully login to a gateway and you now want to login into another gateway you must remove this file and restart LCFD.EXE.

LAST.CFG

The LAST.CFG file contains the latest configuration information used by LCFD.EXE. LCF reads this file upon startup to set its options. To change the configuration of an endpoint, you either edit the LAST.CFG file or you can set the options on the command line. Type LCFD.EXE -s -D? to see the usage and default values. If you choose to edit the LAST.CFG file , the new configuration information is used when you restart the endpoint. After the LCF starts, the latest configuration information is again written to the LAST.CFG file.

LCFD.LOG

Endpoint messages are written to a message log file whose default name is LCFD.LOG.

The following table shows the five levels of messages generated by endpoints:

Message Level

Message Content

0

No message Logging

1

Minimal Logging

2

Tracing and moderate output

3

Detailed information and tight loops

4

Data Buffers

By default the message level is set to 1. You can reset the message level by restarting the endpoint with the –d option. Level 4 generates a very large amount of messages. Level 2 or 3 is sufficient for most troubleshooting .

 

Web Browser

LCF has an http server built-in. To access use the following URL:

http://hostname:port_number

where:

hostname is the name or IP address of the endpoint

port_number is the prot number the endpoint is listening on.

From this web page you will find the LCF status and links to LCF files.

 

wadminep command

From the Tivoli TME and administrator can use the wadminep command to query the endpoint in much the same way that the browser does. Type wadminep -? To view the usage.

 

Q &A

How can I manage multiple gateways on a subnet?

When lcfd is started using defaults, it sends its initial login request to the broadcast address. If you have an environment where there are multiple gateways in a single broadcast space (for example, on one subnet), you must provide gateway hints to lcfd when you start an endpoint. Providing gateway hints guarantees that the endpoint logs in to the gateway you intend.

You provide these gateway hints by using the -D lcs.login_interfaces option with the lcfd command and specifying the value for the gateway. You can also do this by editing the last.cfg file in the lcf home directory.

 

Can I force an endpoint to log in to a specific gateway?

Yes. Start lcfd with these options:

lcfd -Dlcs.login_interfaces=gateway_ip_address + gateway_port

Are there other ways to direct an endpoint's initial login to a particular gateway? For example, I want to configure lcfd to look for a particular DNS name. This DNS server belongs to a TMR that intercepts lcfd logins and redirects them to the right gateway.

Yes, you can use the select_gateway policy on the endpoint manager to implement this. By default, the policy is not set, and the intercepting gateway is also the login gateway. However, you can write a policy that lets you change this behavior. lcfd will get a packet back from the intercepting gateway that directs it to the gateway where it should log in.

Can an intercepting gateway redirect an endpoint to a gateway in a different TMR?

Yes. This feature is called TMR selection.

Your select_gateway policy can specify gateways in a different TMR than the intercepting gateway. For this to work, the TMRs must be connected. In this case, the intercepting endpoint manager will make an interregion objcall to get the network interfaces for the target gateway and returns these (via the intercepting gateway) to the endpoint. The endpoint begins the login process over, using the new interfaces, as if it had been invoked with -Dlcs.login_interfaces.

Note that the target gateway has not been selected in the usual sense; that is, the endpoint is not assigned to that gateway. The target gateway simply becomes the intercepting gateway in the restarted login process.

When the endpoint restarts its login process in the new TMR, if there is a select_gateway policy in the target region, it is honored. If there is no select_gateway policy the target region (or if it's null), then the intercepting gateway is selected by default.

 

Can I change the cache location and/or cache size?

Yes you can edit the last.cfg file or pass these options on the commnad line to lcfd.exe.

-Dcache_loc=absolute_path_to_cache_directory

-Dcache_size=size_in_bytes

The cache size value restricts the endpoint’s cache from growing any larger that the given size. The oldest file will be deleted to make room for the new download.

If lcfd is installed on an endpoint but the endpoint fails to locate a gateway, how can I correct this without physically going to the endpoint machine?

lcfd remains resident, listening on the default port, even if the endpoint's initial login attempt fails. You can use the web browser to access the daemon on the endpoint and have the endpoint log in to a corrected or new gateway. Use the Network Address Configuration page, enter the correct –Dlcs.login_interfaces=… option and press apply. This will cause the lcf endpoint to reexec and try to login to the newly specified gateway.

How do I broadcast to find a gateway in a different subnet?

Normally, the broadcast occurs within a subnet. You can force a directed broadcast by using -Dlcs.login_interfaces, which accepts a colon-delimited list of IP addresses and ports.

lcfd -Dlcs.login_interfaces=gateway_ip_address + gateway_port

Any of these addresses can be a directed broadcast address. This also enables you to prioritize gateways for initial logins.

If an endpoint is doing an initial login and no gateway is available within reach of the broadcast, how does the endpoint determine how to contact the rest of the TME?

There is a seed file (lcfd.cfg) that can be used to specify a series of IP addresses. If lcfd cannot log in, it still listens for http packets, and you can use a web browser to redirect the endpoint to a known gateway.

What happens if the last known gateway for an endpoint is down at downcall time?

If the gateway is down, the oserv will give a "dispatcher unavailable" message. This is E_DISP_UNAVAIL or an equivalent exception.