RE: DAST: Multicast Beacon - Configuring a central server - raul.fernandez --at-- mci.com
Hi All
If the central beacon is receiving reports but ignoring them - (and if
you are feeling brave edit the beacon perl file and print out what it is
receiving in the receive_tcp_reports routine) - then it is a known issue
with the way the beacon handles incoming TCP packets.
A fix was mailed out by the beacon dudes - but maybe not to the list and
I know that there is nothing on the web page about this issue - which is
a rather big one and appears to affect quite a range of machines.
Another fix was mailed to the list by someone else?
One way to prove it is to add the line:
Select(undef, undef, undef, 0.2);
just after the opening bracket of the first 'while' statement in the
receive_tcp_reports routine - before the 'foreach' statement.
Cheers
Steve
-----------------------------------------------
Steve Williams
Technical Specialist Measurement and Monitoring
Advanced Technology Group
UKERNA
Atlas Centre, Chilton, Didcot, Oxon OX11 0QS
-----------------------------------------------
S.Williams@ukerna.ac.uk
Tel: +44 (0)1235 822245
GDS Video: 0044 01100 107
> -----Original Message-----
> From: owner-beacon@dast.nlanr.net [mailto:owner-beacon@dast.nlanr.net]
On
> Behalf Of debbie fligor
> Sent: 21 October 2005 21:01
> To: Mitch Kutzko
> Cc: raul.fernandez@mci.com; NLANR Multicast Beacon
> Subject: Re: DAST: Multicast Beacon - Configuring a central server -
> raul.fernandez --at-- mci.com
>
> I was speaking with Mitch earlier today regarding what is probably
> the same problem. I just set up a central server on a Mac OS 10.4
> box and am seeing the same issue -- it wont even see it's own client
> reliably on central loss, but does see all the clients (including
> it's own) in local loss.
>
> the reports are making it to the central server, but it's not
> accepting them, as if they were a wrong version or wrong port number,
> but they aren't -- occasionally both the local-to-the-server client
> and at least one of my other clients does display -- when the TCP
> connection is accepted correctly. but then they go away again. I saw
> something like this in 1.1 as well, which is why I had backed off to
> 1.0 for my campus beacon.
>
> I've offered them access to my server, since I'm not good enough at
> perl/tcp to even know where to start debugging this. hopefully there
> will be something they can find.
>
> At 19:14 -0500 10/15/05, Mitch Kutzko wrote:
> >Hi, Raul -- This error means that the Beacon can't open a TCP
connection
> to
> >the Central Server. Could be a firewall issue, could be a network
> problem,
> >but for whatever reason, your local Beacon is trying to open a TCP
> >connection back to the Central Server and it's failing.
> >
> >Hope this helps!
> >
> >Mitch
> >
> >At 10:24 AM 10/15/2005 -0500, you wrote:
> >>
> >> Contacting DAST re: Request for information about Multicast Beacon
> >> From: Raul Fernandez <raul.fernandez --at-- mci.com>
> >>
> >> Subject: Configuring a central server
> >>
> >> Question/Comment:
> >> Mitch et al,
> >>
> >> I have configured a box a as central server. I have another box
> >connectiong to it. I changed the necessary parameters in beacon.conf
for
> >the client and the server.
> >>
> >> On the client I changed the group, kept default rtp port of 10002,
and
> the
> >> central server name.
> >>
> >> On the central server I changed the group, kept default port,
changed
> the
> >central server name, and activated the BECENTRALSERVER option.
> >>
> >> I am getting some noise form the client:
> >>
> >> "client not defined"
> >> and I cant see the client on the central_loss html output on the
> central
> >server nor can I see the client on the beacon_info html output. I do
see
> >the client on the local_loss. Any ideas on what maybe causing this?
> >>
> >> We are running the lastest version of Beacon 1.3 on FreeBSD.
> >>
> >> Very Respectfully,
> >>
> >> Raul F. Fernandez
> >> MCI
> >>
> >>
> >>
> >--
> >Mitch Kutzko | mitch@dast.nlanr.net | mitch@ncsa.uiuc.edu |
217-333-1199
> >http://hobbes.ncsa.uiuc.edu/
>
>
> --
>
> -debbie
> Debbie Fligor, n9dn Network Engineer, CITES, Univ. of Il
> email: fligor@uiuc.edu <http://www.uiuc.edu/ph/www/fligor>
> "Every keystroke can be monitored. And the computers never forget."