Bruce123 Posted May 12, 2016 Posted May 12, 2016 Afternoon, We have recently been experiencing issues with AP 832 (e and i) connected to MC4200 (N+1) controller. Occasionally, users report that clients can no longer connect to the wireless network (sometimes not even establishing a connection other times establishing a connecting but not getting an IP from DHCP). It turns out that they are trying to connect to a particular AP, and the only solution we have is to reboot the AP. We have over 200 of these APs, and are needing to reboot APs 2-3 times a day. We still have a small number of AP 332, which don't appear to be affected. Does anyone have any experience of this particular issue? The slightly odd thing is we only recently (around February) started experiencing this issue. Firmware is 7.0-9-1, and we are planning to upgrade to 8.0_SR1-2 (30 Mar 2016) to if this helps. Kind Regards, Bruce.
ninjapirate Posted May 19, 2016 Posted May 19, 2016 Hi Bruce, We had the same issue here with version 7 and 832 APs, our controller is a MC3200. We upgraded to the version you listed above (8.0-SR1-2) and that cured it. The latest version on their site is 8.0-6-0 by the way and support seem a bit confused when you say you are running the SR1 build instead as if it doesn't exist! Cheers, Mike 1
Bruce123 Posted May 23, 2016 Author Posted May 23, 2016 Thanks Ninjapirate. We'll see if the firmware upgrade helps. Bruce.
CyberNerd Posted May 23, 2016 Posted May 23, 2016 With 8.0 the 832's reboot themselves ! It's a bit better since the SR1 release but we still see a few random reboots.
ninjapirate Posted May 23, 2016 Posted May 23, 2016 7.x did that for us quite a lot (sometimes down to 3mins!). 8.0 is better but the APs don't seem very rock solid like they were back in the 6.x days, shame considering the price of the kit!
Bruce123 Posted May 25, 2016 Author Posted May 25, 2016 With 8.0 the 832's reboot themselves ! It's a bit better since the SR1 release but we still see a few random reboots. I'd prefer a occasional random reboots, than what is happening currently. As we don't know of any way to identity when an AP goes into the failed state (still shows as online in Meru Admin), we have to depend on users reporting the issue, then rebooting that we think has the issue. The only warnings/alerts we see on Meru Admin are "memory usage is above the threshold" (70%) on APs, but we can't relate this to APs going into the failed state. Incidentally, how do you become aware that an AP has rebooted? Are you just looking at the Events/Alerts in Meru Admin? We use Solarwinds NPM to monitor the controllers via SNMP, which does report on connected APs, but it doesn't always spot an AP reboot if the reboot occurs quickly in-between polls. Kind Regards, Bruce.
Bruce123 Posted June 6, 2016 Author Posted June 6, 2016 Thanks for the help. We upgraded to 8.0-6-0 last week, so we'll see how it goes over the coming weeks as regards APs not allowing connections. I noticed that memory usage high(>70%) alarms we were getting intermittently for APs, seems to have ended. We noticed some additional features appear on the Web GUI. Thanks, Bruce.
Bruce123 Posted June 20, 2016 Author Posted June 20, 2016 Just to let people know the firmware upgrade seems to have resolved the issue. There have been no reported instances of this issue in the 3 weeks since the upgrade. Kind Regards, Bruce.
Affray Posted June 23, 2016 Posted June 23, 2016 Hi Bruce, having a similar situation to you, APs dropping wifi access and needing to be rebooted. We are on 8.0-SR1-2 (new install replaces the old Juniper/Trapeze system) and I was wondering if I could ask how long it took to run the 8.0-6-0 update, as we might have to do it after the school day has ended (about 100 aps) as they rarely let us have any downtime in term. Thanks.
Bruce123 Posted October 10, 2016 Author Posted October 10, 2016 (edited) Update: Since the upgrade in June, it looked like the upgrade had resolved this issue, but 6 weeks into 2016 term and the problems are back. We find that we are having to reboot APs (832 and 332) every couple of weeks now. The symptoms are that the client cannot connect to the SSID (e.g. on Android it says SSID "Saved", but just won't connect, similar issues with other e.g. Apple/Windows). Now I am wondering if 8.1 (I think that's the latest firmware but now 100% sure, things have become a bit unclear since Fortinet took over) might contain a fix for this issue (which we hope would be fixed by the upgrade to 8.0.6 but alas...). To be honest we've had other issues with the wireless, but we are focussing on tackling one issue at a time. It's a real shame that the (unoffical) MerUniverse online forum was closed after Fortinet took over as it was a useful was of getting support and sharing issues/solutions amoung other customers. Now the only way to get answers is to open a Ticket with Fortinet. When we were experiencing connectivity issues with Chromebooks the Fortinet engineer told me to try reducing the "roaming aggressiveness" in Adaptor settings on the Chromebook, they didn't understand that on ChromeOS you don't have access to those settings. I managed to provide them with remote access to one, which seemed to bamboozle them. We are operating in Virtual Cell mode. Kind Regards, Bruce. PS the firmware upgrade to 8.0.6 didn't take long as far as I am aware (less than 30 mins). Edited October 10, 2016 by Bruce123
free780 Posted October 11, 2016 Posted October 11, 2016 Interesting I've seen similar on 8.1 firmware. I thought its the meruconnect/IDM/fortinetconnect server .
ninjapirate Posted October 17, 2016 Posted October 17, 2016 hmm, we are on 8.1-2 at the moment and have started getting some of the issues you describe. some clients can 'see' the wifi but can't connect to it - nothing on the radius server or DHCP to say a connection was even attempted, others are now not seeing any SSID until i reboot the APs in the area... Not looking very good to be honest, im not sure what Fortinet are doing with the Meru systems other than making them look pretty. Finding firmware updates is a bit of a chore now since they started rebranding System Director to FortiWLM - now i can't find the 3200 any more!
Bruce123 Posted October 18, 2016 Author Posted October 18, 2016 hmm, we are on 8.1-2 at the moment and have started getting some of the issues you describe. some clients can 'see' the wifi but can't connect to it - nothing on the radius server or DHCP to say a connection was even attempted, others are now not seeing any SSID until i reboot the APs in the area... Not looking very good to be honest, im not sure what Fortinet are doing with the Meru systems other than making them look pretty. Finding firmware updates is a bit of a chore now since they started rebranding System Director to FortiWLM - now i can't find the 3200 any more! I agree with this entirely, Fortinet should be focused on fixing the stability of the firmware on their APs above anything else (e.g. rebranding/adding features). It is clear from the forums that this issue has been present through a range of firmware versions with no fix yet. It has to be an issue with their firmware because when it occurs it prevents all clients from connecting (not vendor specific). Whatever the interactions the clients are having with the APs, an AP should never end up in the state where the only solution to reboot it. It sounds to me like there is some kind of memory leak or something similar in the processes running on the APs. Also, this is especially disappointing when you consider this is supposed to be "enterprise class" equipment (with a price tag to suite) and even a basic home broadband router can stay online for months/years without needing a reboot. Kind Regards, Bruce.
njc235 Posted October 19, 2016 Posted October 19, 2016 Has anyone raised a Fortinet support ticket? That's what you pay for when you pay that annual support fee.
Bruce123 Posted October 20, 2016 Author Posted October 20, 2016 Yes, we have previously raised a ticket for this issue and was advised to update the firmware to the most recent, which we did in June. Initially it seemed to resolve the issue as and the release notes referred to the update fixing a stability/connectivity issue, it looked promising.... However, I am now wondering if the issues only subsided because the client count dropped substantially over the Summer period. I also understand that we were informally advised to reboot the APs periodically. I have raised another ticket for the issue and we will see what comes of it... Thanks, Bruce.
njc235 Posted October 20, 2016 Posted October 20, 2016 Try the following; In the CLI or via Putty login: admin Password: MC1550V(15)# station-log Interactive Per-Station Event Logging Shell (enter "help" for help) By default logging is Disabled (enter "enable" to Enable logging) station-log> ? Interactive Event Logging Shell Usage: help, ? This help message exit, quit Exit/Quit enable Enable logging of events to console disable Disable logging of events to console ------------------------------------------ Station Filtering Commands ------------------------------------------ station show Show stations in the filter list station add Add a station to the filter list by MAC station del Delete a station from the filter list by MAC station del <#> Delete a station from the filter list by index station del all Delete all stations from the filter list ------------------------------------------ Event ID Filtering Commands ------------------------------------------ event id show Show the event ID filter list. event id set Enables an event ID filter. event id remove Disables an event ID filter. can be : all:, or value from 1 to 11. ------------------------------------------ Event Severity Filtering Commands ------------------------------------------ event severity show Show the event Severity filter list. event severity set Enables an event Severity level filter. event severity remove Disables an event Severity level filter. can be : all, info, minor, major, critical. ------------------------------------------ Show Commands ------------------------------------------ show events Show the event ID filter list. show severity Show the event Severity filter list. show stations Show stations in filter list. show filters Show all the filters. station-log> station add aa:bb:cc:aa:bb:cc (MAC address of one of the wireless clients experiencing problems) Added station aa:bb:cc:aa:bb:cc at position 0 station-log> enable Logging enabled station-log> The resulting lines may help to diagnose the issue .
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now