Skip to main content
Matt_Garrett
Matt_Garrett
New Member
March 18, 2016
Question

FortiWiFi 60D units locking up

  • March 18, 2016
  • 2 replies
  • 36783 views

In the past months we upgraded a large number of FortiWiFi 60D units to 5.2.4 and started seeing issues with units locking up and not responding randomly.   The only way to resolve is to unplug power and reboot.

 

We are seeing this on a number of units.  We send out logs to FortiAnalyzer and we found that after this hard reboot logging to memory is again enabled.  We contacted Fortinet Support and this is a known big to be fixed in 5.2.7.  I am not entirely convinced that this setting is causing the lock ups.  Logs indicate nothing and in fact some units have few to no logs prior to lock up.  Seems to be very random in nature, but also appears to only when during normal business hours.

 

Anyone else having any similar issues or thoughts on this?

 

-M

    2 replies

    bartman10
    bartman10
    New Member
    March 21, 2016

    I know it's an entirely different unit.. but try disabling the WiFI and see what happens. See my rant about FWF-50E.

     

    My issue is related to new power management I was told is only used in the new 50E WiFi chip.. but hey who knows.. 

    Matt_Garrett
    Matt_GarrettAuthor
    New Member
    March 22, 2016

    Thank you for the response.  Unfortunately we are unable to disable the wifi at this juncture.

     

     

    Chris_Carson
    Chris_Carson
    New Member
    March 23, 2016

    We have had the same issue happen at two clients.  We went thru two different FWF60D units with random lockups and no errors to report.  The LEDs where illuminated, but nobody was home.  We had a dedicate USB cable with FortiExplorer and the unit would not detect(it would disappear) until a power cycle.  After about a month we ripped them out and put in a FGT-100D and 3 FortiAPs.  At the time support(TAC) was not of much help.  The physical units are back in our stock, but we are scared to deploy them to another client.  We cannot be deploying FGT 92D or 100Ds at clients with 5 computers.

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    March 23, 2016

    So if I understand OP and @Chris, v5.2.3 or v5.2.7 should fix the problem. I mean, the forum would be flooded by complaints if the FWF60D (as being a volume model) locked up all the time with all previous firmware versions.

     

    @Chris: any chance you'd put one FWF60D on v5.2.3 and let it run in the office for a week, and report back?

    Chris_Carson
    Chris_Carson
    New Member
    March 23, 2016

    We were running v5.2.3 and still had issues.  Again we don't have the equipment currently in production anymore since we replaced it with a bigger unit.  We can perform some testing next week.

     

     

    --

    This the only thing we ever got out of our two units when it would crash with a serial console cable was:

     

    "FWF60D login: Unable to handle kernel NULL pointer dereference at virtual address 00000030 mm = 80228500 pgd = e3a01e1f *pgd =

     

    and after a reboot..

     

    FWF60D# diag debug crashlog read 1: 2015-09-24 13:41:10 the killed daemon is /bin/pyfcgid: status=0x0 2: 2015-09-29 09:04:11 the killed daemon is /bin/dhcpd: status=0x0 3: 2015-09-29 09:04:54 the killed daemon is /bin/dhcpd: status=0x0 4: 2015-09-29 09:15:12 the killed daemon is /bin/dhcpd: status=0x0 5: 2015-10-01 09:16:57 the killed daemon is /bin/dhcpcd: status=0x0 6: 2015-10-01 09:16:58 the killed daemon is /bin/dhcpcd: status=0x0 7: 2015-10-01 09:20:52 Interface wan2 is brought down. process_id=33, process_name="cmdbsvr" 8: 2015-10-01 09:21:22 the killed daemon is /bin/dhcpcd: status=0x0 9: 2015-10-01 09:21:22 the killed daemon is /bin/dhcpcd: status=0x0 10: 2015-10-01 09:23:19 the killed daemon is /bin/dhcpcd: status=0x0 11: 2015-10-01 09:23:19 the killed daemon is /bin/dhcpcd: status=0x0 12: 2015-10-01 09:29:35 the killed daemon is /bin/pyfcgid: status=0x0 13: 2015-10-01 10:53:58 the killed daemon is /bin/pyfcgid: status=0x0 14: 2015-10-01 16:06:01 Interface dmz is brought down. process_id=123, process_name="httpsd" 15: 2015-10-01 16:06:01 Interface wan1 is brought down. process_id=123, process_name="httpsd" 16: 2015-10-01 16:06:01 Interface wan2 is brought down. process_id=123, process_name="httpsd" 17: 2015-10-01 16:06:01 Interface internal1 is brought down. process_id=123, process_name="httpsd" 18: 2015-10-01 16:06:01 Interface internal2 is brought down. process_id=123, process_name="httpsd" 19: 2015-10-01 16:06:01 Interface internal3 is brought down. process_id=123, process_name="httpsd" 20: 2015-10-01 16:06:02 Interface internal4 is brought down. process_id=123, process_name="httpsd" 21: 2015-10-01 16:06:02 Interface internal5 is brought down. process_id=123, process_name="httpsd" 22: 2015-10-01 16:06:02 Interface internal6 is brought down. process_id=123, process_name="httpsd" 23: 2015-10-01 16:06:02 Interface internal7 is brought down. process_id=123, process_name="httpsd" 24: 2015-10-07 10:11:31 the killed daemon is /bin/pyfcgid: status=0x0 25: 2015-10-07 11:44:06 the killed daemon is /bin/pyfcgid: status=0x0 26: 2015-10-07 11:58:27 the killed daemon is /bin/dhcpd: status=0x0 27: 2015-10-07 11:59:29 the killed daemon is /bin/dhcpd: status=0x0 28: 2015-10-07 12:03:22 the killed daemon is /bin/dhcpd: status=0x0 29: 2015-10-07 14:39:18 the killed daemon is /bin/pyfcgid: status=0x0 30: 2015-10-07 14:56:07 the killed daemon is /bin/pyfcgid: status=0x0 31: 2015-10-07 15:04:58 the killed daemon is /bin/pyfcgid: status=0x0 32: 2015-10-07 19:03:36 the killed daemon is /bin/pyfcgid: status=0x0

    Our Fortinet Ticket Number was: 1502710

     

    Hope this helps someone...

    Terms & ConditionsAccessibility statement