05-08-2019 09:05 AM
Device AH-xxxxxx Connect State Change: The CAPWAP connection was lost.
I am getting the above error happen every 10-15 minutes on each of my connected APs. They all seem to work in that I can browse out onto the Internet, and have access to all relevant network resources when connected to them. All relevant traffic is allowed via our firewall.
Below are the logs I have found around the time it last happened:
2019-05-08 09:17:50 info amrp2: l2routing: amrp receive capwap-statistic-request Mod_id (4) No.(183) ifindex 9
2019-05-08 09:17:49 info capwap: application: CAPWAP: can not find the event query confirm information type request id (44).
2019-05-08 09:17:49 info capwap: application: CAPWAP: can not find the event request id (39).
2019-05-08 09:17:49 info capwap: application: CAPWAP: can not find the event query confirm information type request id (39).
2019-05-08 09:17:49 info capwap: application: CAPWAP: can not find the event request id (40).
2019-05-08 09:17:49 info capwap: application: CAPWAP: can not find the event query confirm information type request id (40).
2019-05-08 09:17:48 info capwap: application: CAPWAP: receive DCD send response to CAPWAP event!, length:570
2019-05-08 09:17:48 info capwap: application: receive event DCD send response to CAPWAP: eventid = 169: length = 570
2019-05-08 09:17:48 info capwap: application: CAPWAP: receive DCD send response to CAPWAP event!, length:1308
2019-05-08 09:17:48 info capwap: application: receive event DCD send response to CAPWAP: eventid = 169: length = 1308
2019-05-08 09:17:48 info capwap: application: CAPWAP: receive DCD send response to CAPWAP event!, length:38
2019-05-08 09:17:48 info capwap: application: receive event DCD send response to CAPWAP: eventid = 169: length = 38
2019-05-08 09:17:48 info capwap: application: CAPWAP: receive DCD send response to CAPWAP event!, length:146
2019-05-08 09:17:48 info capwap: application: receive event DCD send response to CAPWAP: eventid = 169: length = 146
2019-05-08 09:17:48 info capwap: application: CAPWAP: receive DCD send response to CAPWAP event!, length:336
2019-05-08 09:17:48 info capwap: application: receive event DCD send response to CAPWAP: eventid = 169: length = 336
2019-05-08 09:17:48 info capwap: application: CAPWAP: receive DCD send response to CAPWAP event!, length:66
2019-05-08 09:17:48 info capwap: application: receive event DCD send response to CAPWAP: eventid = 169: length = 66
2019-05-08 09:17:48 info capwap: application: CAPWAP: can not find the event request id (38).
2019-05-08 09:17:48 info capwap: application: CAPWAP: can not find the event query confirm information type request id (38).
2019-05-08 09:15:20 info ah_dcd: application: get track-ip trigger access console request: cancel.
2019-05-08 09:11:12 info last message repeated 3 times
2019-05-08 09:11:11 info kernel: [wifi]: [CLT_CAPS]Probe request from 48:f1:7f??e9:e6 is too short: 74
2019-05-08 09:10:20 info ah_dcd: application: get track-ip trigger access console request: cancel.
2019-05-08 09:10:12 info capwap: application: CAPWAP: receive capwap query interface map info response event!, length:1096
2019-05-08 09:10:12 info capwap: application: receive event capwap query interface map info response: eventid = 172: length = 1096
2019-05-08 09:09:03 info capwap: application: CAPWAP: receive RedSec get proxy info response event!, length:29
2019-05-08 09:09:03 info capwap: application: receive event RedSec get proxy info response: eventid = 240: length = 29
2019-05-08 09:09:03 info ah_scd: aaa: response to HM successfully, self isn't a elected Radsec proxy server.
2019-05-08 09:09:03 debug ah_scd: aaa: Get proxy server info success, 1 totally.
2019-05-08 09:09:02 info capwap: application: receive event statistics recv event to auth: eventid = 129: length = 48
2019-05-08 09:09:02 info capwap: application: CAPWAP receive IDP push all event!
2019-05-08 09:09:02 info capwap: application: receive event capwap_idp_pull_all: eventid = 122: length = 15
2019-05-08 09:09:02 info capwap: application: CAPWAP: receive DCD send response to CAPWAP event!, length:20
2019-05-08 09:09:02 info capwap: application: receive event DCD send response to CAPWAP: eventid = 169: length = 20
2019-05-08 09:09:02 info capwap: application: receive event statistics recv event to dcd: eventid = 125: length = 4
Solved! Go to Solution.
05-15-2019 04:30 PM
Hi Tyler,
I seem to have resolved this now. The paragraph below is the one I followed which resolved it. What I think is happening is the SonicWall is changing the source port on some packets from the original UDP 12222 (can't tell you why it does that though) which is obviously causing issues.
"If persistent NAT is not enabled, the Sonicwall FW is allowed to change the NATted (source) port address, which intermittently breaks CAPWAP connection. There is a quick fix which is not obvious in the Sonicwall GUI. It’s under VoIP ->Settings -> General Settings -> “Enable consistent NAT”."
Once that's done, you should be able to change the transport method via the CLI and it not cause problems.
Give me a shout if that doesn't work.
05-15-2019 05:34 PM
It apparently tells you in the help menu. Last sentence of first paragraph.
With Consistent NAT enabled, all subsequent requests from either host 192.116.168.10 or 192.116.168.20 using the same ports illustrated in IP address and port pairs result in using the same translated address and port pairs. Without Consistent NAT, the port and possibly the IP address change with every request.
NOTE: Enabling Consistent NAT causes a slight decrease in overall security, because of the increased predictability of the address and port pairs. Most UDP-based applications are compatible with traditional NAT. Therefore, do not enable Consistent NAT unless your network uses applications that require it.
05-15-2019 05:24 PM
Oh man you are definitely a lifesaver! I remember one time I had enabled Persistent NAT and I could have swore it caused other issues, but that was probably 7 SonicOS fw updates ago. Thank you again, I had been searching all over for a while and came across this one today.
05-15-2019 04:30 PM
Hi Tyler,
I seem to have resolved this now. The paragraph below is the one I followed which resolved it. What I think is happening is the SonicWall is changing the source port on some packets from the original UDP 12222 (can't tell you why it does that though) which is obviously causing issues.
"If persistent NAT is not enabled, the Sonicwall FW is allowed to change the NATted (source) port address, which intermittently breaks CAPWAP connection. There is a quick fix which is not obvious in the Sonicwall GUI. It’s under VoIP ->Settings -> General Settings -> “Enable consistent NAT”."
Once that's done, you should be able to change the transport method via the CLI and it not cause problems.
Give me a shout if that doesn't work.
05-15-2019 04:20 PM
I have been having this same issue for almost a year now (with SonicWall on-site). Do you just change the transport method to http in the cli? Or is it an actual change to the firewall config?