How to check why FortiAP got Offline from FortiGate

If the AP lost its channel connection with FortiGate you can check to see if the AP has just lost the contact with firewall missing the heartbeat or if has got rebooted for any reason.

Points to remember:

*Forti AP reboot only if has any power issue.

*FortiAP had any Software crash or kernal panic.

>>Following command on FortiGate can give you an idea why the AP is offline in FortiGate:

 

#Scene 1 :If the AP is offline because of any operation initiated from controller/FortiGate (changes that needs a AP reboot)

——————————-WTP 1—————————-
WTP vd : root
vfid : 0
id : FP221B3X12007124
mgmt_vlanid : 0
region code : N
regcode status : invalid
refcnt : 2 own(1) wtpprof(1)
plain_ctl : disabled
deleted : no
admin : enable
cfg-wtp-profile : praveen_wifi_integrated
override-profile : enabled
oper-wtp-profile : resv-dflt-FP221B3X12007124
wtp-mode : normal
wtp-group :
name :
location :
led-state : enabled
ip-frag-prevent : TCP_MSS
tun-mtu : 0,0
split-tunneling-local-ap-subnet : disabled
active sw ver : FP221B-v5.2-build0254
local IPv4 addr : 192.168.242.63
board mac : 00:09:0f:7c:1a:70
join_time : Tue Jan 17 13:51:56 2017
mesh-uplink : ethernet
mesh hop count : 0
parent wtp id :
connection state : Disconnected
image download progress: 0
last failure : 8 — AC daemon reset timer expired –<change caused AP reboot>     
last failure param: N/A
last failure time: Tue Jan 17 13:52:01 2017
station info : 0/0

 

#Scene 2: On the other hand FortiGate is reporting that the Heatbeat timed out and so the AP went offline.

#diagnose  wireless-controller  wlac -c wtp

——————————-WTP 1—————————-
WTP vd : root
vfid : 0
id : FP221B3X12007124
mgmt_vlanid : 0
region code : N
regcode status : invalid
refcnt : 3 own(1) wtpprof(1) ws(1)
plain_ctl : disabled
deleted : no
admin : enable
cfg-wtp-profile : praveen_wifi_integrated
override-profile : enabled
oper-wtp-profile : resv-dflt-FP221B3X12007124
wtp-mode : normal
wtp-group :
name :
location :
led-state : enabled
ip-frag-prevent : TCP_MSS
tun-mtu : 0,0
split-tunneling-local-ap-subnet : disabled
active sw ver : FP221B-v5.2-build0254
local IPv4 addr : 192.168.242.63
board mac : 00:09:0f:7c:1a:70
join_time : Tue Jan 17 13:41:18 2017
mesh-uplink : ethernet
mesh hop count : 0
parent wtp id :
connection state : Connected
image download progress: 0
last failure : 14 — ECHO REQ is missing        … <heatbeat missed>
last failure param: N/A
last failure time: Tue Jan 17 13:40:39 2017     …<Failure time>
station info : 0/0
geo : World (0)
LLDP : disabled
Radio 1 : AP

So FortiGate just reported its a heatbeat miss from AP that cause AP go offline and Wifi service interrupted.

*Here we need to find the reason if its the network or the AP itself didn’t sent out the heatbeat.

*Log into the AP and check to see if the AP got rebooted or even AP reports that WTP is  what its has  has to reconnect.

*To TELNET from FortiGate into the AP,Command ## execute telnet <dest>    IP address.

*Check the Uptime on AP,#cw_diag uptime

Log1:

FP221B3XXXXXXXXX # cw_diag uptime
Could not open fsm RUN uptime file /tmp/uptime_fsm_run.
Current uptime : 1567338
WTP daemon start uptime : 1565549                                         <Ap never got rebooted>
WTP daemon RUN uptime : 1567338
Time since WTP daemon started : 1789   
Time since WTP daemon connected : 0                        <Did loose the contact with FGT>

Watchdog timer triggered : 0
Watchdog timer action : 3
Watchdog timer time : 27

Log2:

FP221B3XXXXXXXX # cw_diag uptime
Could not open fsm RUN uptime file /tmp/uptime_fsm_run.
Current uptime : 78                                                                     <AP got rebooted>
WTP daemon start uptime : 31
WTP daemon RUN uptime : 78
Time since WTP daemon started : 47
Time since WTP daemon connected : 0

Watchdog timer triggered : 0
Watchdog timer action : 3
Watchdog timer time : 29

*By this way you could narrow down the issues and so next time could help to find Route Cause of the issue.

Other Handy AP commands:

>cfg -s
>fap-get-status
>cw_diag uptime
>cw_diag sys-performance
>iwconfig
>diag_debug_crashlog read
>cw_diag -c wtp-cfg
>cw_diag -c radio-cfg
>cw_diag -c vap-cfg
>cw_diag kernel-panic
>dmesg
>rcfg
>klog

 

 

 

Advertisements

BYOD fails because of those CNA agents on IOS and Android

I had this chance to work with an Australian Account for BYOD solution issue.

Deployment: Fortinet Infrastructure wifi solution with Forticonnect a Byod solution.

Issue: Windows devices are able to get on-boarded successfully but the Macintosh and android having issues.

Once i jumped onto troubleshoot this issue found the configuration seems to be totally fine. So is it a software bug?
What i get to find again is this tiny browser (CNA agent) on wifi clients which doesn’t have the full browser capacity is the cause of the issue.

Firstly , how a traditional BYOD solution works is users initially connect to a OPEN ssid and then they download a DOT1.X PROFILE and later using the profile user are on-boarded securely on the network.This can also be done using a single SSID also, It depends on how much your BYOD solution can assist you on this.

Coming back to my issue here, I say the user connected on the guest network and did authenticate to the CAPTIVE PORTAL/ BYOD. However this authentication success message was never passed back to the WLAN controller, So that WLC can initiate the RADIUS REQUEST to RADIUS SERVER.

>This is how a station log for problematic wifi client looks like.

2017-Jan- 9 13:14:27.306847 | 44:2a:60:fc:39:d4 | Station Assign | <AID=3>[abgn](v0) assigned to <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=Station probed
station-log>
2017-Jan- 9 13:14:27.352095 | 44:2a:60:fc:39:d4 | Band Steering | <AID=0>[abgn](v0) Steering to 5Ghz under policy=A Blocking 2.4Ghz, present staType=ABGN ESSID=e-smart-access B-BSSID=00:0c:e6:0a:cb:1f Ch=11
station-log>
2017-Jan- 9 13:14:27.554238 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=3>[abgn](v0) state change <old=Unauthenticated><new=Authenticated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.554248 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=3>[abgn](v0) state change <old=Unauthenticated> <new=Authenticated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.555616 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=3>[abgn](v0) state change <old=Authenticated><new=Associated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.555625 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=3>[abgn](v0) state change <old=Authenticated> <new=Associated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:14:27.555993 | 44:2a:60:fc:39:d4 | Band Steering | * <AID=3>[abgn](v0) Steered to 5Ghz under policy=A staType=ABGN[15] ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 Steering time = 0.203891 seconds
station-log>
2017-Jan- 9 13:14:27.563019 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=REQUEST><server_ip=127.0.0.1><client_ip=0.0.0.0>
station-log>
2017-Jan- 9 13:14:27.572135 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=ACK><server_ip=127.0.0.1><offered_ip=10.12.1.135>
station-log>
2017-Jan- 9 13:14:28.573801 | 44:2a:60:fc:39:d4 | IP Address Discovered | <Old IP discovery Method=none><Old IP=0.0.0.0><New IP discovery Method=dynamic><New IP=10.12.1.135

While if you want to compare how a successful CP authentication looks like on contrast:

2017-Jan- 9 13:50:53.401458 | 44:2a:60:fc:39:d4 | Station Assign | <AID=3>[abgn](v0) assigned to <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=RSSI changed
station-log>
2017-Jan- 9 13:50:55.921525 | 44:2a:60:fc:39:d4 | Station Assign | <AID=3>[abgn](v0) removed from <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=Inactivity timer expired
station-log>
2017-Jan- 9 13:52:33.440124 | 44:2a:60:fc:39:d4 | Station Assign | <AID=2>[abgn](v0) assigned to <AP=99> ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 reason=Station probed
station-log>
2017-Jan- 9 13:52:33.440941 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=2>[abgn](v0) state change <old=Unauthenticated><new=Authenticated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.440950 | 44:2a:60:fc:39:d4 | 802.11 State | <AID=2>[abgn](v0) state change <old=Unauthenticated> <new=Authenticated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441122 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated><new=Authenticated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441131 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated> <new=Authenticated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441549 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated><new=Associated><AP[99]=00:0c:e6:13:27:a5> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.441558 | 44:2a:60:fc:39:d4 | 802.11 State | . <AID=2>[abgn](v0) state change <old=Authenticated> <new=Associated> <AP=99> ESSID=e-smart-access Ch=149 A-<BSSID=00:0c:e6:0a:39:ee>
station-log>
2017-Jan- 9 13:52:33.442632 | 44:2a:60:fc:39:d4 | Band Steering | * <AID=2>[abgn](v0) Self-steered to 5Ghz under policy = A staType = ABGN ESSID=e-smart-access A-BSSID=00:0c:e6:0a:39:ee Ch=149 Steering time = 0
station-log>
2017-Jan- 9 13:52:33.448274 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=REQUEST><server_ip=127.0.0.1><client_ip=0.0.0.0>
station-log>
2017-Jan- 9 13:52:33.454929 | 44:2a:60:fc:39:d4 | DHCP | <msg_type=ACK><server_ip=127.0.0.1><offered_ip=10.12.1.135>
station-log>
2017-Jan- 9 13:52:34.507002 | 44:2a:60:fc:39:d4 | IP Address Discovered | <Old IP discovery Method=none><Old IP=0.0.0.0><New IP discovery Method=dynamic><New IP=10.12.1.135>
station-log>
station-log>
station-log>
station-log>
2017-Jan- 9 13:53:54.616485 | 44:2a:60:fc:39:d4 | CP User Authentication | <Captive Portal Profile= captive-portal> <User : chewc@xxxx.edu.au> <ipaddr=10.12.1.135> Sending User Authentication Request.
station-log>
2017-Jan- 9 13:53:54.616487 | 44:2a:60:fc:39:d4 | CP User Authentication | <User=chewc@XXXX.edu.au> <ipaddr=10.12.1.135> Sent Guest User Authentication Request.
station-log>
2017-Jan- 9 13:53:54.616626 | 44:2a:60:fc:39:d4 | CP User Authentication | <User=chewc@XXXX.edu.au> <ipaddr=10.12.1.135> Sent Radius Authentication Request.
station-log>
2017-Jan- 9 13:53:54.678054 | 44:2a:60:fc:39:d4 | CP User Authentication | <User=chewc@XXXX.edu.au> <ipaddr=10.12.1.135> Radius User Authenticated Successfully <session_time=0 secs> <filter_id=> <idle_time=0 secs>
station-log>
>You would see on the above successful station log that the client has forwarded the WiFi Auth credentials back to the WLAN controller (4th line from the last) and so Radius Auth session can now be initiated to RADIUS Server(last 3 lines)
Note:This is very important for the controller to know that the users is authenticated and so later when ANDROID user going to google play store or when an IOS user going to Apple store the controller lets the traffic go out. Since captive portal SSID always allows only ARP, DNS, DHCP traffic of client before authentication success. And in few other vendors you still need to allow the client subnet to access google play store and apple store.

>Else you would run into issues such that the wifi clients are not able to download the application(smart connect) from APP STORE that assists the device to download dot1.x profile from BYOD server.

Solution: After we just disabling the CNA agent(tiny browser) the wifi clients have no problem in onbording to a dot1.x network. We forced the client not to use the CNA AGENT by using the feature in WiFi controller.

>There are some parameter (SSID+CLIENT_MACADDRESS+SWITCHIP:PORT+BROWSERINFO+some other)on the fly(During onboard) the browser  remember till it POST the credential back to controller for radius authentication.

>Since those tiny browsers are  not capable to do this, Some times you have hard time to Successfully design BYOD Onboard.

First universal APs @fortinet

These U- FAPs can be managed by Infrastructure controllers or Fortigate Firewalls or via Cloud based management.

Like other Fortinet infrastructure Access points it support  Single channel Architecture/ Virtual Cell or Micro cell/Native cell too.

#802.11AC#Wave2#4*4#universal

Looking to find a CWNE to mentor you?

You have 200+  CERTIFIED WIRELESS NETWORK EXPERTS(CWNE) across the global now.  If you are looking to find some one in your country, Check the link below and get connected to them.

https://www.cwnp.com/forums/posts?postNum=308451#post308451

Source : https://www.cwnp.com

> this list is provided by @globeron  (https://twitter.com/Globeron)