The broadcast address in this case, I believe, is the one that is part of the 
AltAuth Sun Ray DHCP macro. If you answer yes to broad cast it adds 
255.255.255.255 to the macro. In your case, try utadm -A which will create 
macros to answer the dhcp inform, but don't tell it to serve ip's

Sent from my mobile.

On Oct 22, 2011, at 1:29 PM, "Jonathan C. Bailey" <[email protected]> 
wrote:

> Hmm... I'm not specifically setting a broadcast address in this subnet, 
> although ISC DHCPd may be doing that for me (may need to get out a sniffer).
> 
> That wiki page is a bit vague with "if a broadcast address was seen". It 
> almost makes me think the DTU would be looking for a broadcast packet from 
> one of the servers.
> 
> Hmmm...
> 
> -Jon
> 
> ----- Original Message -----
> From: "Cj Cant" <[email protected]>
> To: [email protected]
> Sent: Saturday, October 22, 2011 2:04:29 PM
> Subject: Re: [SunRay-Users] Broadcast Discovery
> 
> 
> 
> Jon, 
> 
> 
> I see now what you are trying to achieve...reading this: 
> 
> 
> http://wikis.sun.com/display/SRSS4dot2/Sun+Ray+Client+Boot+Process 
> 
> 
> (towards the bottom - section 6.5) it would seem to suggest that if the 
> broadcast 
> address is not supplied, then an attempt to use broadcast is not made. So if 
> all the 
> other mechanisms for configuring the DTU are broken and the broadcast address 
> is 
> missing, then the broadcast step is omitted and the DTU will reboot after 30 
> secs. 
> 
> 
> So you could try removing the broadcast address from your DHCP server for the 
> DTUs... 
> 
> 
> Cheers 
> 
> 
> 
> 
> Cj. 
> 
> 
>> Date: Fri, 21 Oct 2011 17:18:56 -0500 
>> From: [email protected] 
>> To: [email protected] 
>> Subject: Re: [SunRay-Users] Broadcast Discovery 
>> 
>> If I'm not mistaken, the setting you talk of is for FOG communications... 
>> 
>> I'm looking to disable broadcast discovery by the DTUs (or disable the 
>> server responses for this function). 
>> 
>> -Jon 
>> 
>> 
>> ----- Original Message ----- 
>> From: "Cj Cant" <[email protected]> 
>> To: [email protected] 
>> Sent: Friday, October 21, 2011 5:04:06 PM 
>> Subject: Re: [SunRay-Users] Broadcast Discovery 
>> 
>> 
>> 
>> Jon, 
>> 
>> 
>> You can disable the use of multicast by setting an option in 
>> /etc/opt/SUNWut/auth.props 
>> you will need to restart the server for the change to take effect I believe 
>> 
>> 
>> Cheers 
>> 
>> 
>> 
>> 
>> Cj. 
>> 
>> 
>> 
>> 
>> 
>>> Date: Fri, 21 Oct 2011 11:09:45 -0500 
>>> From: [email protected] 
>>> To: [email protected] 
>>> Subject: Re: [SunRay-Users] Broadcast Discovery 
>>> 
>>> Hmm.. I don't recall that question during setup. Since I don't use the 
>>> provided DHCP, all I do is a utadm -L on and never specify the network 
>>> details for the interconnect (since I'm not using the DHCP that SRS 
>>> configures). 
>>> 
>>> -Jon 
>>> 
>>> ----- Original Message ----- 
>>> From: "Matthew C. Aycock" <[email protected]> 
>>> To: [email protected] 
>>> Sent: Friday, October 21, 2011 10:11:58 AM 
>>> Subject: Re: [SunRay-Users] Broadcast Discovery 
>>> 
>>> On 10/21/2011 09:46 AM, Jonathan C. Bailey wrote: 
>>>> Hello, 
>>>> 
>>>> I've been looking through the documentation, man pages, etc, but haven't 
>>>> found an answer for this.. 
>>>> 
>>>> Is there any way to keep the DTUs from using broadcast discovery or keep 
>>>> the servers from responding to it? Right now, I'm using a parms file to 
>>>> specify servers for a DTU to connect to. If that file isn't available (or 
>>>> the servers specified are down), I'd like to "fail" and just keep trying 
>>>> rather than start broadcast discovery. 
>>>> 
>>>> Is this possible? 
>>> 
>>> There is a question about this when running utadm to add a network 
>>> interface. We have our configured as you are describing. I am not sure 
>>> if there is a way to configure this after the fact. 
>>> 
>>> 
>>> -- 
>>> Thanks, 
>>> 
>>> Matthew 
>>> ---------- 
>>> Matthew C. Aycock 
>>> Operating Systems Analyst/Developer, Lead 
>>> Dept Math/CS 
>>> Emory University, Atlanta, GA 
>>> Internet: [email protected] 
>>> 
>>> _______________________________________________ 
>>> SunRay-Users mailing list 
>>> [email protected] 
>>> http://www.filibeto.org/mailman/listinfo/sunray-users 
>>> _______________________________________________ 
>>> SunRay-Users mailing list 
>>> [email protected] 
>>> http://www.filibeto.org/mailman/listinfo/sunray-users 
>> 
>> _______________________________________________ 
>> SunRay-Users mailing list 
>> [email protected] 
>> http://www.filibeto.org/mailman/listinfo/sunray-users 
>> _______________________________________________ 
>> SunRay-Users mailing list 
>> [email protected] 
>> http://www.filibeto.org/mailman/listinfo/sunray-users 
> 
> _______________________________________________
> SunRay-Users mailing list
> [email protected]
> http://www.filibeto.org/mailman/listinfo/sunray-users
> _______________________________________________
> SunRay-Users mailing list
> [email protected]
> http://www.filibeto.org/mailman/listinfo/sunray-users
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users

Reply via email to