[Seq-cvs-commit] showeq BUGS,1.1.1.1.16.2,1.1.1.1.16.3 ChangeLog,1.1.2.27,1.1.2.28

[Chad M. <cmm...@us...>]

Update of /cvsroot/seq/showeq
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv20497

Modified Files:
      Tag: pre_5_0_beta
	BUGS ChangeLog 
Log Message:

Added two known bugs to BUGS.
Changed the Debug message about dropping packets to a Warning.
Added some debugging code to packetcapture that is turned off, just so you
    can watch and monitor the race between the packet capture thread taking in
    packets and the main thread processing them and changing the pcap filter.


Index: BUGS
===================================================================
RCS file: /cvsroot/seq/showeq/BUGS,v
retrieving revision 1.1.1.1.16.2
retrieving revision 1.1.1.1.16.3
diff -u -d -r1.1.1.1.16.2 -r1.1.1.1.16.3
--- BUGS	16 May 2005 23:39:21 -0000	1.1.1.1.16.2
+++ BUGS	19 Jun 2005 16:20:55 -0000	1.1.1.1.16.3
@@ -1,3 +1,89 @@
 
 Known bugs
 ----------
+
+1) Multiple EQ Clients on the Same Box
+
+Running showeq to monitor an EQ client on a machine which has multiple EQ
+clients running on it can result in crashes and mixed sessions. It is possible
+that if both EQ clients zone at the same time, showeq can mix up the sessions
+resulting in either showeq swapping which session it is watching or something
+crashes resulting from processing both clients at the same time. Using session
+tracking might help, but there is no workaround at this time to make showeq work
+properly in this configuration.
+
+
+2) !!!! EQPacketFragmentSequence::addFragment(): buffer overflow adding in
+new fragment
+
+In order to run, showeq needs the entire packet stream between the EQ client and
+the EQ servers. Packets are processed in order and if any packets are dropped,
+there may be problems decoding the stream causing showeq to crash or lose sync
+with the session. 
+
+Usually this condition is signalled by console messages like:
+Warning: SEQ: Giving up on finding arq 0085 in stream zone-client cache, skipping!
+Warning: SEQ: Giving up on finding arq 0086 in stream zone-client cache, skipping!
+Warning: SEQ: Giving up on finding arq 0087 in stream zone-client cache, skipping!
+Warning: SEQ: Giving up on finding arq 0088 in stream zone-client cache, skipping!
+
+This signifies packets being dropped and being skipped in processing, which may
+cause the session stream to corrupt if the skipped packets are important. Other
+messages which may result when the stream is corrupted are:
+
+Warning: Oversized packet fragment requested buffer of size 0 on stream 3 OpCode
+0000 seq 00a6
+
+Warning: !!!! EQPacketFragmentSequence::addFragment(): buffer overflow adding in
+new fragment to buffer with seq 00fb on stream 3, opcode 0000. Buffer is size 3
+8302 and has been filled up to 38302, but tried to add 505 more!
+
+Both these messages mean that packets are being dropped that are important to
+the reconstruction of oversized payloads in the session stream. These messages
+may appear like showeq is broken, but in reality, the problem is that packets
+are not being provided to showeq because they are being dropped by the kernel
+before being made available to the application layer.
+
+The kernel may drop packets when under heavy loads (either CPU loads or network
+loads). 
+
+When under high CPU utilization, the thread in showeq which reads from
+the kernel's receive buffers may be starved and not get enough processor time to
+empty the kernel receive buffers before those buffers run out of room and drop
+packets. To help this, you can set the showeq network thread to run "realtime"
+by turning on the Network->Real Time Thread option.
+
+When under high network traffic, the kernel's receive buffers may overflow
+before showeq gets a chance to empty the buffers, causing packets to be missed.
+This can happen when you have a lot of network traffic that is seen by the
+machine running showeq. The EQ client bursts a lot of traffic during zoning as
+well, so usually problems with high network traffic show themselves during
+zoning.
+
+To help this problem, try to narrow down the traffic that showeq watches by
+specifying the ip address of your EQ client on the commandline. Also, turn on
+Session Tracking using Network->Session Tracking. If problems persist after
+turning those options on, you may want to adjust kernel parameters to change how
+the kernel manages its receive buffers. Some parameters that may help you are:
+
+net.core.rmem_default (defaults to 65535, or 64k receive buffers)
+net.core.rmem_max (defaults to 131071, or 128k receive buffers)
+net.core.netdev_max_backlog (defaults to 300, or 300 packets can be input but
+    unprocessed before packets start being dropped)
+
+These parameters should be set with care, and take into account what other
+things the linux box you are running showeq on is used for. If it has a lot of
+server duties, setting rmem_default will increase system memory usage
+sigificantly.
+
+Suggested settings for a normally used machine are:
+net.core.rmem_default=524288 (512k for default receive buffers)
+net.core.rmem_max=2097152 (2M for max receive buffers)
+net.core.netdev_max_backlog=3000 (allow 3000 packets to be queued before
+    processing before dropping packets)
+
+If you still see problems, you may want to set these higher. Setting these may 
+be distribution specific. Check to see if you have sysctl (man sysctl) or 
+/etc/sysctl.conf, or these can be put directly into /proc by looking
+in /proc/sys/net/core.
+

Index: ChangeLog
===================================================================
RCS file: /cvsroot/seq/showeq/Attic/ChangeLog,v
retrieving revision 1.1.2.27
retrieving revision 1.1.2.28
diff -u -d -r1.1.2.27 -r1.1.2.28
--- ChangeLog	12 Jun 2005 14:33:36 -0000	1.1.2.27
+++ ChangeLog	19 Jun 2005 16:20:55 -0000	1.1.2.28
@@ -14,6 +14,7 @@
 	are propagated to the spawn list and the map
 + Filled in some missing races with artificial names not taken from the
 	.exe (thanks uRit1u2CBBA=)
++ Added two known bugs to BUGS with descriptions and workarounds
 
 purple (05/18/05)
 ---------------------