Sun Microsystems, Inc.  Sun System Handbook - ISO 3.4 June 2011 Internal/Partner Edition
   Home | Current Systems | Former STK Products | EOL Systems | Components | General Info | Search | Feedback

Asset ID: 1-75-1005063.1
Update Date:2011-03-17
Keywords:

Solution Type  Troubleshooting Sure

Solution  1005063.1 :   Sun Ray[TM]: The Sun Ray[TM] appliance does not get over the 22B icon state  


Related Items
  • Sun Ray Hardware
  •  
  • Sun Ray Software
  •  
Related Categories
  • GCS>Sun Microsystems>Desktops>Desktop Virtualization>Sun Ray Hardware
  •  

PreviouslyPublishedAs
207119


Description
One or more Sun Ray[TM] appliances do not get a session, but in their bootup cycle get to the 22B OSD icon only.


Steps to Follow
Sun Ray[TM]: The Sun Ray[TM] appliance does not get over the 22B icon state

Background:

The 22B icon shows that the Sun Ray[TM] appliance received a DHCP address, but did not receive all Sun Ray[TM] specific DHCP vendor tags, and then subsequently could not get a connection to a Sun Ray[TM] server. These might be two separate issues, or the lack of DHCP parameters might be the root cause that the appliance could not get a connection to the Sun Ray[TM] server.

Sun Ray[TM] appliances running 2.0 and higher firmware use a two-step approach to obtain a DHCP address, and the Sun Ray[TM] specific DHCP vendor tags.

  • First, standard DHCP requests are used to obtain a DHCP address.
    The Sun Ray[TM] appliance will accept the first DHCP address it is being offered.
  • The Sun Ray[TM] appliance then checks whether it received all Sun Ray[TM] specific DHCP vendor tags.
    If not, it will send a DHCPINFORM request to obtain the missing tags.
    Only if the initial DHCP response did not provide all Sun Ray[TM] specific DHCP vendor tags,
    and the subsequent DHCPINFORM request did not succeed in obtaining the missing tags, will there be a "B" in the OSD icon.

It also is possible to use other configurations, such as DHCP option 49, to point the Sun Ray[TM] appliances to an authentication manager. Please refer to chapter 7 of the Sun Ray Server Software's Administrator's Guide for further information, section "Sun Ray DTU Initialization Requirements".

Troubleshooting Steps:

1.) Find out which DHCP server is supposed to provide DHCP addresses to the Sun Ray[TM] appliances, and which DHCP server is supposed to provide Sun Ray[TM] specific DHCP vendor tags. In a Sun Ray[TM] LAN configuration, usually the Sun Ray[TM] server will provide Sun Ray[TM] specific DHCP vendor tags, but frequently an existing corporate DHCP server will provide DHCP addresses.

2.) Check which DHCP vendor tags the Sun Ray[TM] appliance received. If you have multiple Sun Ray[TM] appliances showing 22 B, collect information from a few appliances.

  • The 22 B icon will show the appliance's MAC address in the top line, the appliance's current DHCP address in the second line, and possibly a Sun Ray[TM] server IP address in the bottom line.
  • With the appliance's current DHCP address, get the whole list of DHCP vendor tags the appliance received by running
       # /opt/SUNWut/sbin/utquery -d <MAC address>
  • Alternatively, if you know the subnet in which appliances show the 22 B icon, run
       # /opt/SUNWut/sbin/utquery -d <netmask>  (or utquery -d <subnet>)

Note: utquery might fail if there is a router or a NAT (Network address translation) between the Sun Ray[TM] server and the Sun Ray[TM] appliances.

3.) Check the DHCP address, and the DHCPServer tag in utquery output. Is this a DHCP address served by a DHCP server which is supposed to provide DHCP addresses to the Sun Ray[TM] appliances? If no, the Sun Ray[TM] appliance failed to connect to the Sun Ray[TM] server because it got its DHCP address from a rogue or misconfigured DHCP server, rather than from the DHCP server intended to provide DHCP addresses to the Sun Ray[TM] appliances.

4.) Check the Sun Ray[TM] server IP address the appliance received. If the Sun Ray[TM] appliance does not show the IP address of a Sun Ray[TM] server in the bottom line of the 22 B OSD icon, it did not obtain one through DHCP. In that case, check in utquery output whether the Sun Ray[TM] appliance received the following tags:

  • AuthSrvr: if this tag is provided, but AltAuth is not provided, the Sun Ray[TM] appliance will try to get an initial connection to this authentication manager. If that fails, the appliance will use broadcast to find an authentication manager, while displaying OSD error code 22. If the broadcast also fails, the appliance will go through its boot cycle again.
  • AltAuth: if this tag is provided, the AuthSrvr tag will be ignored. The Sun Ray[TM] appliance will go through the list of IP addresses provided in the AltAuth tag, and try to get an initial connection, while displaying OSD error code 22. If the appliance cannot get a connection on any of the IP addresses provided in the AltAuth tag, the appliance will go through its boot cycle again.

If these tags are configured, but the appliance did not obtain them, the DHCPINFORM request must have failed. Possible reasons for DHCPINFORM failure are

  • the DHCP server which provided the DHCP address directed the Sun Ray[TM] appliance to a wrong network.
  • there is a router between the Sun Ray[TM] appliance and the DHCP server providing Sun Ray[TM] specific DHCP vendor tags, and the router configuration fails to redirect the DHCPINFORM request to this DHCP server.
  • the DHCP server providing Sun Ray[TM] specific DHCP vendor tags is down, or unresponsive.

Example:

In this example, the Sun Ray[TM] server's IP address is 10.128.200.12, and it is serving sessions for the 10.128.200.255 network. The Sun Ray[TM] server also is supposed to act as a DHCP server. The DHCP configuration on the server looks fine:

::::::::::::::
excerpt from dhtadm -P output
::::::::::::::

 Name                    Type            Value
==================================================
10.128.212.0            Macro        :Include=SunRay-10.128.212.0:Subnet=255.255.254.0:FWSrvr=10.128.200.12:Broadcst=10.128.200.255:MTU=1500:Router=10.128.200.1: NewTVer="3.0_51,REV=2004.11.10.16.18":
SunRay-10.128.200.0     Macro         :Include=SunRay:AuthSrvr=10.128.200.12:
SunRay                  Macro         :LeaseTim=86400:LeaseNeg:AuthPort=7009:LogHost=10.128.200.12:LogKern=6:LogNet=6:LogUSB=6:LogVid=6:LogAppl=6:

::::::::::::::
excerpt from utquery d 10.128.200.0.output
::::::::::::::
An appliance which did not get over the 22 B icon:

       terminalID=0003ba0d1234
terminalIPA=10.0.1.7 <----- Not in 10.128.200.0 network!
Subnet=255.255.255.0
Router=10.0.1.1
LeaseTim=14400
DHCPServer=10.0.1.1 <----- Another DHCP server!
currentAuth=0.0.0.0 <----- Appliance did not receive an IP address of a Sun Ray[TM] server
currentFW=3.0_51,REV=2004.11.10.16.18

An appliance which got a session:

       terminalID=0003ba264321
terminalIPA=10.128.200.230
Subnet=255.255.254.0
Router=10.128.200.1
MTU=1500
Broadcst=10.128.200.255
LeaseTim=86400
DHCPServer=10.128.200.12 <---- DHCP server is the Sun Ray[TM] server
AuthSrvr=10.128.200.12   <---- Points the appliance to the correct server
AuthPort=7009
LogHost=10.128.200.12
FwSrvr=10.128.200.12
NewTVer=3.0_51,REV=2004.11.10.16.18
currentAuth=10.128.200.12 <---- Appliance connects to this Sun Ray[TM] server
currentFW=3.0_51,REV=2004.11.10.16.18

The example illustrates

  • The appliance 0003ba0d1234 did not get the Sun Ray[TM] specific DHCP vendor tags.
  • It did not get the Sun Ray[TM] specific DHCP vendor tags because it received its DHCP address from a rogue DHCP server with IP address 10.0.1.1.
  • DHCPINFORM then failed because the appliance has an IP address 10.0.1.7 in the wrong network 10.0.1.0/24 instead of 10.128.200.0/24, and uses that as the source address of its DHCPINFORM request.
  • With an IP address in the wrong network, and no setting for AuthSrvr, the appliance then was unable to get a connection to the Sun Ray[TM] server.

5.) If the Sun Ray[TM] appliance does show the IP address of a Sun Ray[TM] server in the bottom line, the 22 B icon means that the appliance is unable to get a connection to an authentication manager running on that IP address. In this case, the lack missing DHCP vendor tags are unlikely to be the root cause for the failure to get a session. Possible root causes are firewalls preventing a connection to the authentication manager, the Sun Ray[TM] server being down or unreachable, the utauthd on that server being down or unresponsive, or a misconfigured AuthSrvr tag, AltAuth tag, resp. DHCP option 49 pointing the Sun Ray[TM] appliances to a Sun Ray[TM] server which is down.

See problem resolution <Document: 1007713.1> "Sun Ray[TM]: The Sun Ray[TM] appliance does not get over the 22D icon state" for detailed troubleshooting instructions.



Product
Sun Ray Server Software 3.0
Sun Ray Server Software 2.0
Sun Ray 1g Ultra-Thin Client
Sun Ray 150 Ultra-Thin Client
Sun Ray 1 Ultra-Thin Client
Sun Ray 100 Ultra-Thin Client
Sun Ray 170 Ultra-Thin Client
Sun Ray Server Software 3.1
Sun Ray 2FS Virtual Display Client
Sun Ray 2 Virtual Display Client

Internal Comments
The following is strictly for the use of Sun employees:

currency review 4/16/10

ut_gather collects DHCP information from the Sun Ray server. It does not collect, though, any configuration information of 3rd party DHCP servers, nor any router configuration information.


See also Product Page at

http://software-support/products/SunRayServerSoftware


22B, 22 B, sunray, Sun Ray
Previously Published As
80411

Change History
Date: 2007-03-08
User Name: 95826
Action: Approved
Comment: - verified metadata
- changed review date to 2008-03-08
- checked for TM - none added
- checked audience : contract
Publishing
Version: 6
Date: 2007-03-08
Product_uuid
bdec8c12-4b81-11d8-99fc-080020a9ed93 | Sun Ray Server Software 3.0

c9ce6c09-cf3d-44f8-8ecd-a5d8347f7a5d | Sun Ray Server Software 2.0

17b4fb54-0ee3-11d7-91b0-934b10cdd83f | Sun Ray 1g Ultra-Thin Client

Attachments
This solution has no attachment
  Copyright © 2011 Sun Microsystems, Inc.  All rights reserved.
 Feedback