 |
Support FAQ |
|
Since all WildPackets products make use of the underlying Operating System for all time computations, no patch will be necessary for our products to operate correctly with the new Daylight Saving Time Change. Important Vista Note: Vista Operating System has a facility for dynamic Daylight Saving Time calculations that takes into account the fact that different years may have different DST dates. The next release of the OmniPeek Product Family (available end of Jan. 2007) will include the code to use this new operating system facility. The end result is that everything will work correctly with Vista, but if a user has XP with the DST hotfix installed, the duration of captures that span the actual time change in past years may be incorrect since XP does not have the facility to understand that different years may have different DST dates.
AiroPeek VX 1.1 will load and run on 64 bit operating systems in 32 bit compatibility mode and supports AMD and Intel x86 processors including the 64 bit capable Pentium and Xeon processors.
G.711 µ-law
No, at this time Windows Server 2003 is not supported with AiroPeek VX.
Configuration changes in the VoIP view do not take effect unless packets are reprocessed. Packets are reprocessed by using the Edit->Reprocess All Packets menu item or by hiding and then unhiding packets via the Edit menu while the Packets view is active.
CRC errors are the only error type captured by AiroPeek. All error packets are processed by Network, Summary, Size, and History statistics. However, in Network statistics, error packets only count for total packet and byte count, not for broadcast and multicast counts. Node, Protocol, and Channel Statistics do not process error packets. The "802.11 Analysis" plug-in is currently the only plug-in that processes error packets. Most summary statistics information comes from plug-ins.
Send functions (e.g., commands in the Send menu and Send window) cannot send packets via a wireless adapter when that adapter is being used to capture packets.
The BSSID and ESSID option under the Select Channel is only for selecting a wireless channel. This option does not filter out specific wireless traffic, creating an advanced filter will accomplish this for you.
When selecting the channel by ESSID in the 802.11 section of the Capture Options dialog, the behavior varies depending on which driver you're capturing from. For example, the Atheros driver will search for the specified ESSID for 2 seconds. If that ESSID is found, it will change to the channel which corresponds to that ESSID; otherwise, it will remain on the current channel.
The Profile tab lets you save Peer Map configurations settings into a single profile that controls the appearance and layout of the Peer Map. The Configuration tab lets you control what part of the traffic in the Capture window’s buffer is displayed in Peer Map. The Node Visibilities tab displays node counts, and nodes that are both shown and hidden in the Peer Map. For example, if this option is set to Always Hide, then all nodes that have not had their visibility assigned by the user will be hidden. This is useful if, during a live capture, the user doesn’t want new nodes to appear on the Peer Map as they are discovered.
AiroPeek VX does not support Hyper-Threading. If Hyper-Threading is enabled on your computer's processors, you may encounter program errors when capturing with AiroPeek VX.
The space shows you where protocol segments start and stop within conversations. This option is configurable by clicking the Options button. (Different from going to Tools -> Options).
Please refer to the AiroPeek Supported Wireless Adapters page, for a current list of wireless adapters that are supported by AiroPeek.
This may be caused by a display DPI setting that is larger than 96 DPI. Confirm that the display's DPI setting is set to 96 DPI by checking the configuration for this setting in the Advanced Settings portion of the Display Control Panel.
Yes, with the use of an Atheros chipset based adapter and the WildPackets 3.0.1.x Atheros driver, WPA-PSK is supported in AiroPeek 3.x.
Currently WPA2 is not supported.
AiroPeek supports TKIP and WEP encryption.
It is not possible to use the 'Send' feature for control and management packets. The Send feature will work with 802.3 data packets only. Control and management packets in a trace file were used for previous wireless transmissions. When you attempt to send them via AiroPeek, the driver for the 'Send Adapter' will not forward them. While AiroPeek has the ability to send 802.3 frames, it was not designed to replay wireless trace files and 'simulate' wireless traffic.
Yes, if your adapter has an Atheros chipset, the WildPackets Atheros driver will allow noise measurements to be passed to AiroPeek. (This is an approximate measurement by the wireless adapter).
If the adapter driver hasn't already timestamped the packet, the timestamp is provided by the Peek driver.
Network analysis tools are powerful and must be protected from misuse. Data captured and sent across the network may be sensitive, so AiroPeek has been designed from the ground up to adhere to strict IT security requirements.
AiroPeek VX performance may degrade noticeably when more than one capture or packet file window is open. Additional captures may be performed if Voice Analysis is disabled in the Performance section of the Capture Options dialog. In the Capture/Monitor Options, select Performance. For peak performance, right click on one of the features and choose Disable All. This way, AiroPeek will function at peak performance, but the features are still available when needed. When you need a particular feature, you can always enable it. As you enable/disable individual features, the performance bar at the bottom of the Performance Options dialog will move to show you an estimate of the impact of each feature. Here are a few more tips to improve the performance of AiroPeek:
At this time, simultaneous voice playback for both directions is not supported.
The expert threshold is based on jitter as reported by RTCP packets. The expert converts the value in each RTCP packet to milliseconds, based on the codec (G.711, G.729. etc) being used by the RTP stream.
Packet Loss is calculated by looking at the RTP and RTCP headers generated by the endpoints on each side of a VoIP conversation and examining the sequence numbers in those headers. Any differences between the sequence numbers from packet to packet are counted as lost Audio packets. For instance, let’s say AiroPeek VXis examining a sequence of 200 RTP packets as part of a Voice call and the sequence number starts with 1001. If AiroPeek VXsees a gap in sequence numbers, such as 1020, 1021, 1026, 1027, 1028, it would be noted that 4 packets (1022, 1023, 1024, and 1025) were lost. If these were the only missing packets out of the 200, then the percentage of lost packets 4/200 * 100% = 2%.
This error can sometimes point to the amount of memory in your computer. Please be sure that your system meets the required specifications.
Here is a snippet from RFC3611 that defines one-way delay: end system delay: 16 bits The most recently estimated end system delay, expressed in milliseconds. End system delay is defined as the sum of the total sample accumulation and encoding delay associated with the sending direction and the jitter buffer, decoding, and playout buffer delay associated with the receiving direction. This delay MAY be estimated or measured. This value SHOULD be provided in all VoIP metrics reports. If an implementation is unable to provide the data, the value 0 MUST be used. Note that the one way symmetric VoIP segment delay may be calculated from the round trip and end system delays is as follows; if the round trip delay is denoted, RTD and the end system delays associated with the two endpoints are ESD(A) and ESD(B) then: one way symmetric voice path delay = ( RTD + ESD(A) + ESD(B) ) / 2 " RT Delay is calculated in a couple of ways: 1) It can be calculated using RTCP SR/RR (if available) or 2) external means such as ping. Since RT delay is a component of one-way delay and if not available, then one-way delay may not be available also.
Although dual-direction playback is not supported within the application at this time, this can be accomplished by using one of the popular shareware audio programs available such as Awave or Audacity. The individual media steams can then be exported as .wav files into one of these programs for merging and adjacent playback. |
| Copyright © 2008 WildPackets, Inc |
| All registered and unregistered trademarks are the sole property of their respective owners |
