Device AH-xxxxxx Connect State Change: The CAPWAP connection was lost.

[stewart_mahoney]

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

[tvilo]

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.

[tvilo]

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.

[stewart_mahoney · Accepted solution]

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.

[tvilo]

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?