Hi All,
Hardware IAP225 ROW
Software version 4.0.0.1 and tested on version 4.0.0.4
I've encountered an issue where a customer patched in an AP using eth1 instead of eth0. This caused a master election issue similar to the one in this post: click me
Essentially it looks to me like the master election doesn't work well on eth1.
This occurs on the master when another AP boots up with only eth1 patched in.
[ 1486.372737] OOPS. someone else thinks hes the master too
[ 1486.450896] I am MASTER. 192.168.100.51 recv-ed a master normal-beacon.
[ 1486.547781] (14:42:05) master provision, 0 vs. 0
[ 1486.619663] (14:42:05) Beacon ap-ip, 192.168.100.77 vs. 192.168.100.56
[ 1486.714449] (14:42:05) Beacon 3G capability, 0 vs. 0
[ 1486.790500] (14:42:05) Beacon ap-class, 25 vs. 25
[ 1486.863410] (14:42:06) Beacon uptime, 743229 vs. 54989
[ 1486.941547] (14:42:06) !!! Win the master election
[ 1487.015507] OOPS. someone else thinks hes the master too
[ 1487.095706] I am MASTER. 18 recv-ed a master hierarchy-beacon.
[ 1487.195718] (14:42:06) !!! Lose the master election
[ 1487.270727] (14:42:06) !!! Master ---> Slave
[ 1487.338433] Add bridge entry for magic vlan GW, ifindex 8453, 18:64:72:c5:47:04
[ 1487.442668] wait for stm to initialize over
[ 1487.509291] asap_send_elected_master: sent successfully
The AP reboots here.
Virtual controller IP address doesn't respond even though the AP that's using eth1 has the same configuration as the previous master.
All the APs in the "swarm" become unresponsive at this point.
Has anyone else encountered this issue?
Cheers
James