Re: 1.1 help
quick follow up, my TCP state understanding isn't that great, but all
my connections seem to end up sitting in fin_wait_2 instead of
closing, time_wait or closed. that doesn't seem quite right. I did
reboot the server, just to be sure, and that made no apparent
difference. thanks again for any ideas.
dclmr-buoy.10004 uic-node3-buoy.33358 24820 0 24820 0 FIN_WAIT_2
dclmr-buoy.10004 ral-buoy.scs.uiuc.edu.37303 24820 0 24820
0 FIN_WAIT_2
dclmr-buoy.10004 mnementh.ci.uiuc.edu.51095 65535 0 24616
0 FIN_WAIT_2
dclmr-buoy.10004 dmz-buoy.45058 24820 0 24820 0 FIN_WAIT_2
dclmr-buoy.10004 netbuoy1.uis.edu.43491 24840 0 24840 0
FIN_WAIT_2
dclmr-buoy.10004 cites-buoy.ncsa.uiuc.edu.64430 24820 0
24820 0 FIN_WAIT_2
dclmr-buoy.10004 hab-buoy.41946 24820 0 24820 0 FIN_WAIT_2
dclmr-buoy.10004 simmental.cvm.uiuc.edu.47806 24820 0 24820
0 FIN_WAIT_2
At 13:41 -0500 9/9/04, debbie fligor wrote:
>I need some help.
>
>my old problem is explained below this section for reference, I was
>just about to send it out to the list asking for help. then I tried
>restarting it again today after messing with the arrangement of the
>$server command (found an example that put the "new" in a different
>place). it didn't like that, but when I went back to what's written
>in the default code, it suddenly could bind, or at least that's what
>it says. the history file now shows some non "-l" entries for some
>other hosts's reports (although never in loss), but I'm getting
>screens full of this (and not a lot of updates):
>
>Listening as a Central Server - TCP Unicast reports coming back to port 10004.
>Listening on port 10004...
>Writing flat-text CSV history data out to history file "history.txt".
>
>Alarm/Notification notices will be sent to fligor@uiuc.edu
>when those features are implemented.
>
>Go to http://dclmr-buoy.gw.uiuc.edu to see this Beacon's output.
>
>
>843 dclmr-buoy> RECEIVE_TCP - 0x37e46602 | 0x0e358d3e: last_seq not defined!
>RECEIVE_TCP - 0x37e46602 | 0x0e358d3e: prev_seq not defined!
>RECEIVE_TCP - 0x37e46602 | 0x0e358d3e: prev_lost not defined!
>RECEIVE_TCP - 0x37e46602 | 0x0e358d3e: rtt not defined!
>RECEIVE_TCP - 0x4f92a949 | 0x4f92a949: prev_seq not defined!
>Use of uninitialized value in numeric eq (==) at ./beacon line 1287.
>Use of uninitialized value in localtime at
>/usr/local/encap/perl-5.6.1/lib/perl/5.6.1/ctime.pl line 43.
>Use of uninitialized value in numeric eq (==) at ./beacon line 1309.
>Use of uninitialized value in numeric eq (==) at ./beacon line 1309.
>Use of uninitialized value in numeric eq (==) at ./beacon line 1287.
>Use of uninitialized value in localtime at
>/usr/local/encap/perl-5.6.1/lib/perl/5.6.1/ctime.pl line 43.
>Use of uninitialized value in numeric eq (==) at ./beacon line 1309.
>Use of uninitialized value in numeric eq (==) at ./beacon line 1309.
>Use of uninitialized value in numeric eq (==) at ./beacon line 1287.
>Use of uninitialized value in localtime at
>/usr/local/encap/perl-5.6.1/lib/perl/5.6.1/ctime.pl line 43.
>Use of uninitialized value in numeric eq (==) at ./beacon line 1309.
>Use of uninitialized value in numeric eq (==) at ./beacon line 1309.
>Use of uninitialized value in numeric eq (==) at ./beacon line 1287.
>Use of uninitialized value in localtime at
>/usr/local/encap/perl-5.6.1/lib/perl/5.6.1/ctime.pl line 43.
>Use of uninitialized value in numeric eq (==) at ./beacon line 1309.
>Use of uninitialized value in numeric eq (==) at ./beacon line 1309.
>Use of uninitialized value in hash element at ./beacon line 3065,
><GEN13> line 3.
>Use of uninitialized value in hash element at ./beacon line 3065,
><GEN13> line 3.
>Use of uninitialized value in hash element at ./beacon line 3066,
><GEN13> line 3.
>Use of uninitialized value in hash element at ./beacon line 3067,
><GEN13> line 3.
>Use of uninitialized value in hash element at ./beacon line 3068,
><GEN13> line 3.
>Use of uninitialized value in hash element at ./beacon line 3069,
><GEN13> line 3.
>
>
>this doesn't seem to be affecting the local loss on the client-only
>boxes, if I pull up local_loss.html on my laptop, I get a nice 5x5
>green "0" matrix of the beacon's it is seeing, amusingly that
>includes the one that's the server that's not showing anything other
>than itself -- so it's talking fine to the other beacons and seeing
>the multicast fine (although that doesn't match this history file
>entries it's making).
>
>any thoughts or ideas of things to try are appreciated!
>
>---old problem info -----
>I upgraded all my "campus" beacons to 1.1 Wed. afternoon, and
>they're all showing up blind. Apparently the server can't start the
>port it's supposed to listen on:
>
>Listening as a Central Server - TCP Unicast reports coming back to port 10004.
>Couldn't bind TCP server Can't use an undefined value as a symbol
>reference at /services/beacon/sbin/beacon line 3467.
>
>
>
> $server = new IO::Socket::INET(Listen => SOMAXCONN,
> LocalPort => $SERVERTCPPORT,
> Reuse => 1);
>
> if (! defined $server) {
> print "Couldn't bind TCP server ";
> } else {
> print "Listening on port $SERVERTCPPORT...\n";
> $select = new IO::Select($server) || die "Can't get
>select for $!\n"
>;
> }
>
> # Get flags and make this connection non-blocking...
>
> my $flags = fcntl($server, F_GETFL, 0)
> ^^^^^ is 3467
>
>$server is coming up with no value, and printing the "Couldn't bind
>TCP server" message, then going on to fail the fcntl call. (I tried
>printing out the value of $server and get nothing at all)
>
>of course, I have no clue why $server doesn't have a value,
>everything was working fine with the 1.0 version. the host is a
>solaris 2.8 box. anyone got ideas on what I should be looking for?
>
>
>I'll chime in an opinion as well -- if you can't bind the TCP
>listening port for the central server, that should probably be a
>"die" failure. it took me a long time to figure out that I didn't
>have a multicast problem, that it was "just" my central server not
>taking reports (the error text was small and at the bottom of output
>that looked normal, and the server is happily updating web pages).
>I spent a lot of time chasing the red herring of multicast failure.
>
>--
>
>-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."
--
-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."