print

Support FAQ

General FAQs

• What is the extent of 802.11n support in Omni5?
• What adapters do you support for 802.11 n captures?
• When I configure a capture with my Buffalo card, it reports a speed of 1Mbps instead of 54Mbps in the Capture Options. Why?
• Why are the 40Mhz 802.11n channels missing from the Expert Network Policy screen?
• Are you going to release a patch for WildPackets Products in order to make them compatible with the new 2007 Daylight Savings Time changes?
• What if the DHCP configuration cannot be obtained?
• Can I also use both Ethernet ports to manage the sensor?
• What do the LEDs on the sensor represent?
• How do I reset to factory defaults?
• From where does the sensor obtain its time?
• Does the sensor support international channels?
• What channels will the sensor capture from?
• What are the antenna specifications for the Omni Wireless Sensor?
• When I make modifications on the sensor sometimes those changes do not take affect, what could be wrong?
• Will I lose my captures if I reboot the sensor?
• Can I select channels based on ESSID and BSSID?

Omni Wireless Sensor v4.0 FAQs

• Why can’t I see the VoIP and Application views when I capture with OWS ?
• Why are the Apdex and Apdex Sample Count columns empty when capturing with OWS?
• Which Omni 4.0 Expert events are not supported with OWS?
• Which Expert events are not supported with OWS?

General FAQs

What is the extent of 802.11n support in Omni5?

Capturing of 802.11n packets
Fully decode all 802.11n specific information elements in packets.
Provide 802.11n-specific statistics, analyses and expert diagnoses.

What adapters do you support for 802.11 n captures?

At the present time, we support the Buffalo Nfiniti, Model # WLI-CB-AG300N adapter using the Marvell driver that is supplied with Omni 5.

When I configure a capture with my Buffalo card, it reports a speed of 1Mbps instead of 54Mbps in the Capture Options. Why?

This is because Omni 5 is reporting the actual speed of the adapter’s connection, not its maximum data rate.

Why are the 40Mhz 802.11n channels missing from the Expert Network Policy screen?

We apologize for any inconvenience. These channels will be added to the Network Policy screen in a subsequent version of OmniPeek.

Are you going to release a patch for WildPackets Products in order to make them compatible with the new 2007 Daylight Savings Time changes?

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 Platform products (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.

If a DHCP configuration cannot be obtained, the sensor uses a temporary static assignment of address 169.254.4.1, subnet mask 255.255.0.0, and default gateway 169.254.1.1. The sensor will continue trying to get its IP address via DHCP approximately once per minute unless it is explicitly configured with a static assignment.

Only the "ETH1" port can be used to manage the sensor.

When facing the front of the sensor, moving from left to right, the LEDs are:

• Power - Lit when the sensor has power.
• Wireless - Lit when the sensor has power, flashes when a wireless capture is active and there is wireless activity.
• Second Ethernet port - Lit when the port has a valid link, flashes when there is activity on the port.
• First Ethernet port - Lit when the port has a valid link, flashes when there is activity on the port.

Reset the sensor using the reset button on the rear of the sensor.
Wait for all four LEDs to light, then within 5 seconds press the reset button again and immediately release it.
Repeat step 2 two more times for a total of three times.
Once the reset is complete, the wireless and both Ethernet port LEDs all flash rapidly and simultaneously for a short period of time.

If the sensor is not configured to obtain its system time from an NTP server, it shall obtain its system time from the first OmniPeek console that connects to it.

Yes, the Omni Wireless Sensor can be set to work with standard a/b/g channels for all countries.

The sensor will capture on the following 802.11a and 802.11b/g "normal" channels: 1-11, 36, 40, 44, 48, 52, 56, 60, 64, 149, 153, 157, 161, 165.

The sensor will also capture on the following 802.11a "turbo" channels: 42, 50, 58, 152, 160.

The sensor will not capture on the 802.11g "turbo" channel 6.

Portions of the OmniEngine Configuration UI do not update dynamically. The work-around is to use the F5 keyboard key to force a UI update.

Packets saved to the sensor’s 32 RAM disk will be lost if the sensor is rebooted, reset, or power cycled so save all needed traces to your hard drive.

The sensor can not use the BSSID or ESSID of the wireless network when selecting the channel to use for a capture.

Omni Wireless Sensor v4.0 FAQs

These views are disabled when capturing with OWS.

Apdex events are not available when capturing with OWS.

1. H.225 Call Signaling (Q.931)- Call Dropped
2. H.225 Call Signaling (Q.931)-Call Rejected
3. Low MOS – CQ
4. Low R Factor Conversational
5. MGCP Transient Error
6. MGCP Permanent Error
7. MGCP Connection Deleted or Restart in Progress
8. RTP Excessive Jitter Detected
9. RTP Excessive Packet Loss Detected
10. RTP Not Marked for QOS
11. SIP Post-Dial Delay Exceeded
12. SIP Redirection Request
13. SIP Client Authentication Required
14. SIP Client Error
15. SIP Server Error
16. SIP Global Error
17. Frame Relay Excessive FECN
18. Frame Relay Excessive BECN
19. Frame Relay DLCI Status Change
20. PPP Reject
21. PPP Configure NAK
22. PPP Terminate Request
23. Wireless Access Point – Possible Spoof
24. Wireless Access Point-Too Many Clients
25. Wireless Low Signal-to-Noise Ratio
26. Wireless Client – No Response to Probe Request (rename of "Wireless Access Point –Not Responding to Probe Request")
27. Apdex Score – Client Too Low
28. Apdex Task Ended – Tolerating User
29. Apdex Task Ended – Frustrated User
30. DHCP Multiple Server Response
31. DHCP Request Storm
32. RSVP Error
33. ARP Request Storm
34. MAC Flooding

1. TCP Fast Retransmission (by ACK)
2. TCP Triple Duplicate ACK
3. IP Network Duplicated Packet
4. Wireless Access Point - Inconsistent Configuration
5. Wireless Access Point - Missing
6. Wireless Access Point - Not Responding to Probe Request
7. Wireless Access Point - Repeater Mode Detected
8. Wireless Association Denied
9. Wireless Client - Associated with Rogue Access Point
10. Wireless Client - Excessive Roam Time
11. Wireless Client - High Fragmentation Rate
12. Wireless Client - Power Save Interval Exceeded
13. Wireless Client - Power Save Listen Interval Too Long
14. Wireless Client - Power Save Missed Packet
15. Wireless Client - Probe Response Not Accepted
16. Wireless Client - Using Access Point ESSID
17. Wireless Duration Attack
18. Wireless RF Interference
19. Wireless RF Jamming