Asset ID:	1-71-1003113.1
Update Date:	2011-03-17
Keywords:

---

Solution Type  Technical Instruction Sure

Solution  1003113.1 :   Sun Ray[TM] clients fail to boot after installing HP's JetAdmin Software  


PreviouslyPublishedAs
204261

Steps to Follow

When a Sun Ray[TM] client boots, it broadcast its' ID in the form of a token. The token is similar to what HP's bootp can understand. Instead of getting authorization to boot from DHCP on the Sun Ray's server, HP's bootpd intercepts the request causing the client not to boot.

This problem has just been identified. The only solution is to turnoff bootpd on the server from within /etc/inetd.conf, and then reboot. This is alright if the HP printers don't need bootp to download their IP address. Otherwise, each printer will need to have its IP address downloaded via DHCP or from the front panel.

Whether there is a possibility that Sun network services can provide both DHCP and BOOTP services (so they don't conflict) is under investigation.

Product
Solaris
Sun Ray 150 Ultra-Thin Client
Sun Ray 100 Ultra-Thin Client
Sun Ray 1 Ultra-Thin Client
Sun Ray 1g Ultra-Thin Client
Sun Ray 170 Ultra-Thin Client

Internal Comments

None.

jetadmin, dhcp, bootp, token, sunray, client, boot, bootpd, DISCOVER packet
Previously Published As
27830

Change History
Date: 2006-01-23
User Name: 31620
Action: Update Canceled
Comment: *** Restored Published Content *** SSH AUDIT
Version: 0
Date: 2006-01-23
User Name: 31620
Action: Update Started
Comment: SSH AUDIT
Version: 0
Date: 2006-01-18
User Name: 31620
Action: Update Canceled
Comment: *** Restored Published Content *** SSH AUDIT
Version: 0
Date: 2006-01-18
User Name: 31620
Action: Update Started
Comment: SSH AUDIT
Version: 0
Date: 2005-10-12
User Name: 26914
Action: Update Canceled
Comment: *** Restored Published Content *** There hasn't been any activity with this doc in past several years. Deleting.
Version: 0
Date: 2004-05-20
User Name: 75329
Action: Rejected
Comment: You will want to add some technical information, at least into the internal section. You can look at the comments section for help as to what you may want to add...
Version: 0
Date: 2004-05-14
User Name: 13128
Action: Rejected
Comment: Kenneth, you should be able to edit this doc and add what it is you feel appropriate, thx
Version: 0
Date: 2004-05-14
User Name: 13128
Action: Accepted
Comment:
Version: 0
Date: 2004-05-13
User Name: 75329
Action: Approved
Comment: The following needs to be added to the internal section of this infodoc.

The technical situation is this, during its bootup cycle, a Sun Ray appliance MUST get a DHCP address. (The sequence is as follows: - the SR appliance broadcasts a DHCPDISCOVER - active DHCP servers will respond with a DHCPOFFER - the SR appliance will accept the first DHCPOFFER it gets - the server confirms this DHCPREQUEST with a DHCPACK. In a snoop output, this looks similar to 12:12:51.97746 OLD-BROADCAST -> BROADCAST DHCP/BOOTP DHCPDISCOVER 12:12:52.98085 lab168-qfe0 -> 192.168.128.208 DHCP/BOOTP DHCPOFFER 12:12:52.98184 OLD-BROADCAST -> BROADCAST DHCP/BOOTP DHCPREQUEST 12:12:52.98330 lab168-qfe0 -> 192.168.128.208 DHCP/BOOTP DHCPACK 12:12:52.98727 192.168.128.208 -> (broadcast) ARP C Who is 192.168.128.1, lab168-qfe0 ? 12:12:52.98730 lab168-qfe0 -> 192.168.128.208 ARP R 192.168.128.1, lab168-qfe0 is 8:0:20:cd:1e:54 In this example snoop excerpt, lab168 is the server, and the Sun Ray appliance was offered address 192.168.128.208.)

If the Sun Ray appliance's attempt to get a DHCP address fails, the Sun Ray appliance will "hang" until it gets a DHCP address. With SRSS 1.x firmware, the appliance will display an hourglass with two dashes. With SRSS 2.0 firmware, the appliance will display error code 21. If bootpd is running, it will use the same ports 67 and 68 as in.dhcpd (DHCP is derived from BOOTP), and thus in.dhcpd cannot start up while bootpd is runing. Typical error messages in the /var/adm/messages in.dhcpd[1958]: (Address already in use) Error binding to UDP receive socket: Address already in use in.dhcpd[1958]: (Bad file number) Cannot configure any interfaces. or in.dhcpd[477]: (Address already in use) BIND: Address already in use in.dhcpd[477]: (Bad file number) Cannot configure any interfaces. If it isn't a bootpd which blocks port 67 or 68, you can use lsof to find out what process blocks these ports and prevents dhcp from starting. bootpd does not support the DHCP protocol, and thus will not provide DHCP addresses to Sun Ray appliances. So, the exact sequence of events is HP Jetadmin installed -> HP Jetadmin turns on bootpd -> bootpd prevents in.dhcpd from starting up -> Sun Ray appliances cannot get DHCP addresses, because in.dhcpd is not running, and bootpd does not provide them -> Sun Ray appliances stuck pending dhcp. nad perhaps add a line that says to make sure that if the bootp clients addresses are configured on the sunray server, to make sure that the bootp addresses are a seperate pool of addresses, so that the bootp clients do not take up sunray addresses
Version: 0
Date: 2003-11-24
User Name: 26914
Action: Approved
Comment: My initial intent when I created this doc was to identify a conflict between SUNRAY client booting and Jetadmin. Keep it simple. Unfortunately, I should have created an SRDB Vs Infodoc. At this point there are three options.
1.) Submit doc 'as is'.
2.) If changes need to be made I give permission to others to modify this doc. The doc should then be resubmitted for Tech Review.
3.) Delete this document so I can recreate as a simple SRDB.
I'm open for other suggestions.
Version: 0
Date: 2003-10-02
User Name: 124226
Action: Rejected
Comment: Spoke with Blane about this document. There is no way for me to test this here as I do not have access to the HP printer software. Blane put in the history that he thought that Richard P, should review this and I clarified that with him on the phone.
The issue, I think, is how much detail do we go into on this. Do we go over all the dhcp stuff or just give a brief resolution.
Putting back in tech review queqe without having modified and sending email to Richard P with request that he pick it up.
Sara Conrad 10/2/03 - total time spend 1.25 hours
Version: 0
Date: 2003-08-05
User Name: 26914
Action: Approved
Comment: Author request Tech Reviewer (Rich Pichette) update this document directly to avoid misinterpretting TR's extensive comments.
Version: 0
Date: 2003-07-10
User Name: 75629
Action: Rejected
Comment: As was suggested to me by Thomas Dehn:
The revised 27830 is less erroneous than the one currently
on Sunsolve, but it still could use some clarifications.
See also ID16134, which is technically correct,
but does not mention the Sun Ray angle.
The technical situation is as follows:
during its bootup cycle, a Sun Ray appliance
MUST get a DHCP address.
(The basic sequence is as follows:
- the appliance broadcasts a DHCPDISCOVER
- active DHCP servers will respond with a
DHCPOFFER
- the appliance will accept the first
DHCPOFFER it gets
- the server confirms this DHCPREQUEST with a DHCPACK.
In a snoop output, this looks similar to
12:12:51.97746 OLD-BROADCAST -> BROADCAST DHCP/BOOTP DHCPDISCOVER
12:12:52.98085 lab168-qfe0 -> 192.168.128.208 DHCP/BOOTP DHCPOFFER
12:12:52.98184 OLD-BROADCAST -> BROADCAST DHCP/BOOTP DHCPREQUEST
12:12:52.98330 lab168-qfe0 -> 192.168.128.208 DHCP/BOOTP DHCPACK
12:12:52.98727 192.168.128.208 -> (broadcast) ARP C Who is 192.168.128.1,
lab168-qfe0 ?
12:12:52.98730 lab168-qfe0 -> 192.168.128.208 ARP R 192.168.128.1, lab168-qfe0
is 8:0:20:cd:1e:54
In this example snoop excerpt, lab168 is
the server, and the Sun Ray appliance was offered address 192.168.128.208.
Depending on how you created the snoop,
you might also see an ICMP Echo request where the server
checks whether the DHCP address it wants to lease out
is already used by another system on the network.)
If the Sun Ray appliance's attempt to
get a DHCP address fails, the Sun Ray appliance will "hang"
until it gets a DHCP address. With SRSS 1.x firmware,
the appliance will display an hourglass with two dashes.
(internally, see http://pts.emea/dev/products/sunray/add/2dashes.html)
With SRSS 2.0 firmware, the appliance will display
error code 21
(internally, see http://pts.emea/dev/products/sunray/add/osdcodes.html)
If bootpd is running, it will use the same ports 67 and 68
as in.dhcpd (DHCP is derived from BOOTP),
and thus in.dhcpd cannot start up while
bootpd is runing.
Typical error messages in the /var/adm/messages
in.dhcpd[1958]: (Address already in use) Error binding to UDP
receive socket: Address already in use
in.dhcpd[1958]: (Bad file number) Cannot configure any interfaces.
or
in.dhcpd[477]: (Address already in use) BIND: Address already in use
in.dhcpd[477]: (Bad file number) Cannot configure any interfaces.
If it isn't a bootpd which blocks port 67 or 68, you
can use lsof to find out what process blocks these ports
and prevents dhcp from starting.
bootpd does not support the DHCP protocol, and thus will
not provide DHCP addresses to Sun Ray appliances.
So, the exact sequence of events is
HP Jetadmin installed
-> HP Jetadmin turns on bootpd
-> bootpd prevents in.dhcpd from starting up
-> Sun Ray appliances cannot get DHCP addresses,
because in.dhcpd is not running, and bootpd
does not provide them
-> Sun Ray appliances stuck pending dhcp.
nad perhaps add a line that says to make sure that if the bootp clients addresses are configured on the sunray server, to make sure that the bootp addresses are a seperate pool of addresses, so that the bootp clients do not take up sunray addresses
Regards
Rich
Version: 0
Date: 2003-07-09
User Name: 26914
Action: Approved
Comment: Replaced term 'token' with 'DISCOVER packet'. Bootpd does run on the SUN server. It gets installed (if option is selected) when a printer is configured with HP's Jetadmin for Solaris print management software.
Version: 0
Date: 2003-07-04
User Name: 92644
Action: Rejected
Comment: Hi Blane,
The document looks good.
A couple of minor points - I assume by token you mean DISCOVER packet, that term will be better understood. You might also want to change the wording to make it clear that bootpd is running on an HP server, rather tahn the SUN.
Cheers,
Nick
Version: 0
Date: 2003-07-01
User Name: 26914
Action: Approved
Comment: Doc updated. Needs to be reviewed then published.
Version: 0
Date: 2003-06-26
User Name: 26914
Action: Updated
Comment: Taken back for additional technical reviewing.
Version: 0
Date: 2003-05-20
User Name: Administrator
Action: Migration from KMSCreator
Comment: updated by : Wendy Bean
comment : incomplete workflow. issuing due to special
circumstances.
date : Apr 26, 2002
updated by : Blane V. Ferragamo
comment : Tpatches replaced by FCS release. Added patch 104596-14.
date : Apr 23, 2002
updated by : Blane V. Ferragamo
comment : Article created.
date : Jul 19, 2001
updated by : Blane V. Ferragamo
comment : No comment
date : Jul 19, 2001
Version: 0
Product_uuid
3285bfa4-224e-11d6-8eb3-843d3a923213|Solaris
2a1f4cc0-0a18-11d6-99d7-dc92ef4207a7|Sun Ray 150 Ultra-Thin Client
2a1a3906-0a18-11d6-99bc-99a2ccb5e0fb|Sun Ray 100 Ultra-Thin Client
2a10261e-0a18-11d6-8686-ca682ff2e4cc|Sun Ray 1 Ultra-Thin Client
17b4fb54-0ee3-11d7-91b0-934b10cdd83f|Sun Ray 1g Ultra-Thin Client
122e905b-cc49-11d8-ab52-080020a9ed93|Sun Ray 170 Ultra-Thin Client

Attachments

This solution has no attachment