It was all working fine with Odyssey client Manager version 0.15.
Suddenly after reboot i observed "adapter not available" in Odyssey. Exit, disable/enable the service, reboot of the laptop does not resolve the issue.
Embedded software development and testing
"The duration value in the WLAN frame indicates the time duration in milliseconds for which the channel is reserved. The Network Allocation Vector (NAV) stores this duration information. The rule is that any node can transmit only if the NAV reaches zero.
Attackers make use of the above vulnerability. They inject packets into the WLAN with huge duration values. This would force the other nodes in the WLAN to keep quite as they cannot send any packet until this value reaches zero. If the attacker sends such frames continuously it will prevent other nodes in the WLAN from operation for a long time and there by disrupting the entire wireless service."
In other words, by manipulating the carrier sense in an unorthodox manner, the Cisco APs never get a chance to talk on the RF.
For some reason, Cisco products appear to be more susceptable to this Meru-induced issue.
Your Cisco WLC should be able to see the adjacent WiFi devices - if any exist.
Or, if you have a wireless sniffer (AirMagnet, etc.), you might be able to see adjacent "rogue" access points. Even a laptop with WiFi might be able to see a list of foreign SSIDs that are not yours.
If you can get the wireless MAC address of these foreign APs (assuming that they are there), you can lookup OUI (the first three bytes of the MAC address) at the following site to determine the manufacturer of the access point:
http://standards.ieee.org/regauth/oui/index.shtml
If Meru pops up, it might be the source of your problem. If so, you may be able to work around this problem by using a channel other than that of the neighboring Meru WLAN (since Meru uses the *same* channel for *EVERY* access point in its WLAN - yes, bizarre, but true).
=======================================================
As per RFC 2131In Linux the default arp timeout value is 60 sec and is configured using this parameter
/proc/sys/net/ipv4/neigh/eth1/gc_stale_time
After the arp entry for DHCP server will get deleted, the device will send ARP REQUEST for the DHCP server. After T1 time, if it does not get any arp reply, it is sending the BROADCAST DHCPREQUEST message.
If the server is always connected, the ARP will get resolved and it will send the unicast DHCPREQUEST.
So it seems not an issue. If ARP entry is present in the device, the client will send the unicast DHCPREQUEST, if it gets expired before T1 it will send broadcast DHCPREQUEST.
Keep learning, Keep sharing !!!
config link_aggregation group_id 1 master_port 20 ports 20-21 state enable
config link_aggregation algorithm mac_destination
config lacp_port 20-21 mode active
DLINK 2
config link_aggregation group_id 1 master_port 20 ports 20-21 state enable
config link_aggregation algorithm mac_destination
config lacp_port 20-21 mode passive
config vlan default delete 1-26
config vlan default add untagged 1-14
create vlan vlan_100 tag 100
config vlan vlan_100 add untagged 18
config vlan vlan_100 add tagged 19-20
create vlan vlan_200 tag 200
config vlan vlan_200 add untagged 10
config vlan vlan_200 add tagged 11-12