ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-users: Re: [Wireshark-users] Will EMF interference show up in Wireshark?

From: Paula Dufour <psdufour@xxxxxxxxx>
Date: Sat, 12 Mar 2011 12:17:16 -0500
Larry> Will EMF interference show up in Wireshark?
 
EMF power fluctuates, so if the power is high when critical functions are active then that could cause a problem with an application.  The issue is the likelihood that the power will only be high when Helix is making critical decisions.
 
Larry>I'm troubleshooting a crashing Helix database server
 
I am also troubleshooting a crashing Helix server which provides streaming video to several hundred users.
 
My network is wired and consists of both fiber and copper connections.  All the clients have fiber connections and the servers have copper connections.  Clients have 100 Mbps NICs.  Servers have 1 Gbps NICs.  The servers are in a climate controlled room along with their foundry network switches and routers.  Clients are in normal office spaces.
 
As in your case, the OS doesn't crash and all other services continue without interruption.
 
Larry>I am sniffing the wire connection to the server, looking for network-related causes of the crashes.
 
I have the OpNet Capture Agent installed on the server.
 
Larry>Currently, the Helix server crashes show on the wire as a pause of normal Helix I/O traffic:
 
Larry>Followed by FIN ACK packets sent from the server to the clients, this is
Larry>Followed by ACK packets from the clients to the server.
 
I also show normal  TCP connection closures.
 
Although I'm using Wireshark filters within OpNet Ace.  OpNet Ace is decoding RTCP as HTTP continuation frames.  Within the TCP streams, I see occasional out-of-sequence and duplicate ACK's.  So I'm wondering if the Wireshark filters are not correctly handeling the decode of streaming video when you have TCP>HTTP>RTCP.
 
Do anyone of you Wireshark gods know if this is possibly my problem?  Considering that tcpip.sys may be interpreting these packets the same way?  Or is this pause on the wire some server resource issue.  Perhaps even a configuration issue?
 
--
Paula Dufour
(I did a better job of replying this time, the Subject is relevant to topic at hand.  She can be trained.)