Phil,
Just found a fix that works for me :)
I've been having difficulties setting up the bbwin client (ver 0.13
going to xymon 4.3.10 server) running on win7 sp1, 2008r2 and win2012
boxes in central mode. I've had zero response from the bbwin-help
forum for this, so please bear with me.
For background: I can't get the bbwin client to stop sending all the
logs, it ignores any maxdata parameters I use. Eg:
eventlog:system:1024
It sends everything anyway. If I use log:system:1024, the bbwin client
throws an error that it can't find the system log file. It does find
the file without the maxdata parameter.
One problem with the settings in client-local.cfg on the xymon server is
that they only propagate to the client after a successful sending of a
client message. The mechanics is that after the client message has been
sent, BBWin does a shutdown on the write socket and then reads from the
read socket until EOF. If the write socket is never shutdown because the
server breaks the connection due to flooding, then the client-local.cfg
section will never be sent to the client.
I've previously attempted to manually create C:\Program
Files(x86)\BBWin\tmp\clientlocal.cfg to trick it, but with limited
success. Just played around with it again - with client reporting to my
primary server I just got it going - previously I was reporting to 2
servers. The trick seems to be in having logfetch.status also created. I
then modified my BBWin.cfg back to 2 servers and it broke again. Maybe
the 2nd server is responding differently. It is undefined which server's
clientlocal.cfg to believe anyway :) Swapped the order of the servers
around and it seems stable.
If the server just discarded all the flooding data beyond MAXMSG_* and
then returned the client config section anyway maybe it could be made to
work, but there may be good reasons why that would not be sensible.
This aside, I do need to get this working as I have to start
monitoring 10 new windows servers and have to monitor the event logs,
so I can't just stop sending them as has been suggested. Yes I could
do some powershell scripts and send them via bbwincmd but the bbwin
client is made for this task.....
So, looking at this from the other side, the xymon server appears to
be resetting the session after about 22MB of data has been sent (I
know, this is ludicrous, but it is windows). Nothing in the xymond
logs (except for the occasional data flooding error ("1st line
client", always)); on the client side it reports it can't send the
data to the xymon server.
Depending on what auditting you have enabled, 22MB is very easy to
achieve! Turn on Security event logging including success and failure
and it's almost guaranteed :)
David.
I've set the MAXMSG_* to quite silly levels:
# ipcs
------ Shared Memory Segments --------
key shmid owner perms bytes
nattch status
0x01034be7 16908288 xymon 600 102400000 2
0x02034be7 16941057 xymon 600 102400000 2
0x03034be7 16973826 xymon 600 102400000 2
0x04034be7 17006595 xymon 600 102400000 2
0x05034be7 17039364 xymon 600 262144 1
0x06034be7 17072133 xymon 600 32768 1
0x07034be7 17104902 xymon 600 102400000 2
0x08034be7 17137671 xymon 600 102400000 2
0x09034be7 17170440 xymon 600 131072 1
Anything up to and including this size has no effect on the problem.
Looking at the tcpdump stream, the bbwin client sends data normally
with regular ACKs from xymond till around that 22MB mark then xymond
responds with a FIN packet, then with RST packets and the session
shuts down. Nothing in the packets themselves indicate what the
problem is.
If anyone can help with this, please, it would be great.
thanks, Phil
*Please consider the environment before printing this e-mail*
This message from ORIX Australia may contain confidential and/or
privileged information. If you are not the intended recipient, any
use, disclosure or copying of this message (or of any attachments to
it) is not authorised. If you have received this message in error,
please notify the sender immediately and delete the message and any
attachments from your system. Please inform the sender if you do not
wish to receive further communications by email. ORIX handles personal
information according to a Privacy Policy that is consistent with the
National Privacy Principles. Please let us know if you would like a copy.
It is also available at www.orix.com.au <http://www.orix.com.au>;
--
David Baldwin - Senior Systems Administrator (Datacentres + Networks)
Information and Communication Technology Services
Australian Sports Commission http://ausport.gov.au
Tel 02 62147830 Fax 02 62141830 PO Box 176 Belconnen ACT 2616
user-cbbf693f2c89@xymon.invalid Leverrier Street Bruce ACT 2617
Keep up to date with what's happening in Australian sport visit http://www.ausport.gov.au
This message is intended for the addressee named and may contain confidential and privileged information. If you are not the intended recipient please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you receive this message in error, please delete it and notify the sender.