I've finally had a chance to put Wireshark on it and see what exactly is happening.
My network is (anonymized) is 99.99.0.0/16. I split it off into multiple /24s with DTUs for each FOG in their own /24. I then use ISC DHCPd (on a server unrelated to the Sun Ray environment) to issue IPs and hand out a "tftp-server-name" appropriate for each subnet. Normally the DTUs grab the parms file off the specified TFTP server (which contains server IPs), and everything is happy. If the TFTP server is down, however, then they go into broadcast mode looking for *any* FOG in the /16. >From the discussions here, it sounds like broadcast discovery has to be >explicitly enabled (by adding a wildcard to the AltAuth list). I'm only doing >"utadm -L on" on the hosts and not configuring an interconnect (and by >extension, DHCPd) that would publish the AltAuth list. This makes it seem that >broadcast discovery is default if no AltAuth list exists and the config server >can't be reached. This is the specific behavior I would like to disable. I may just end up opening a SR for this, but I want to bring this to the public list first to help people in the future that have the same situation. Thanks! -Jon ----- Original Message ----- From: "Brad Lackey" <[email protected]> To: "SunRay-Users mailing list" <[email protected]> Cc: "SunRay-Users mailing list" <[email protected]> Sent: Saturday, October 22, 2011 7:37:36 PM Subject: Re: [SunRay-Users] Broadcast Discovery 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 _______________________________________________ SunRay-Users mailing list [email protected] http://www.filibeto.org/mailman/listinfo/sunray-users
