Hmm that reminds me, I actually ran into a similar bug with the SDAC where if AMGH sends a use_firstserver=true, the SDAC attempts to access the IP in reverse (as seen in /var/adm/messages, d.c.b.a is attempted instead of a.b.c.d). Haven't had a chance to report it yet, but has anyone else noticed this issue?
William Yang > -----Original Message----- > From: [email protected] [mailto:sunray-users- > [email protected]] On Behalf Of Nico Behrent > Sent: Friday, May 07, 2010 1:22 PM > To: SunRay-Users mailing list > Subject: [SunRay-Users] **UPDATE** SRS5 / SRSS 4.2 FOG on SLES 10: > utdevmgr does not update /tmp/SUNWut/units > > > We are running SRSS 4.2 on SLES 10 SP3 32-bit with 3 hosts in a FOG and > > 49 SunRay2-P8-DTUs, FW 4.2_77_2009.10.19.17.01 on a dedicated > interconnect. > > A little update here: we missed to install patch 140995-01 - it included > a promising fix for bug '6918519 Restore "forced callme" feature to DM'. > > Unfortunately installing this patch did not resolve the problem (but at > least we now have a shiny new FW 4.2_140993-01_2010.01.21.17.35 on our > DTUs). > > But our firewalls detected strange traffic: > as mentioned above, we have a dedicated interconnect setup with > registered IPs for Sunray-traffic, so each of our FOG-hosts has two NICs > called eth0 and eth3, eth0 for normal lan traffic (with shared lan > interconnect turned off) and eth3 for Sunray-Traffic. > > Let's assume the following addresses: > > primary server: > eth0: x.y.z.151 > eth3: a.b.c.1 > > secondary server 1: > eth0: x.y.z.152 > eth3: a.b.c.2 > > secondary server 2: > eth0: x.y.z.153 > eth3: a.b.c.3 > > tcpdump on the primary server now shows various connection attempts of > the local utdevmgrd to 2.c.b.a:7011 and 3.c.b.a:7011, the secondary > server 1 tries to reach 1.c.b.a:7011 and 3.c.b.a:7011, finally secondary > server 2 pumps out connection attempts to 1.c.b.a:7011 and 2.c.b.a:7011. > > So every machine tries to connect to the utdevmgr of the other two peers > but uses a target IP with REVERSED byte order. > Of course this traffic leaves on the wrong interface via default route > and bothers helpless machines somewhere in the world, but never reaches > the intended target (in fact, it doesn't do so any longer, we blocked it > on our GW). > > Fixing this bug is beyond our capability (little-big-endian-problem > during SPARC-to-linux-port?), so I'd like to file a bug report, but > http://bugreport.sun.com seems to only be related to JAVA-stuff and > tells me to "review ... paid support options below". > > How do I properly submit this problem to someone able to help? > > Thanks in advance, > a nice weekend to the community, > > Nico > -- > Nico Behrent | University of Kaiserslautern > IT Administration - CTO | Department of Mathematics > [email protected] | Building 14 - Room 428 > phone +49 631 205-3925, fax -4737 | D-67653 Kaiserslautern > _______________________________________________ > 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
