Security

Hi all,

 

I'm currently trying to troubleshoot some intermittent EAP-PEAP MSCHAPv2 auth timeouts from windows clients in a customer installation. 

 

win 10 clients with up to date intel drivers connecting using PEAP-MSCHAPv2 auth. 

 

I get mostly normal behaviour however i'm seeing intermittent timeouts which i'm yet to find a cause for (coverage is good, AP stability good).

 

I'm leaning towards client side issues as we're finding some weird events in the wlan report showing 802.1x supplicant restart however i've noticed something else common in the failed requests which can't explain. 

 

When a successful request is processed by ClearPass it shows a Framed-MTU value of 768 in the radius request. 

 

For a failed (i.e client did not respond) case the MTU value is 1100. 

 

I'm struggling to find a reason for this other than maybe the client is sending a large request for some reason and this is being fragmented and dropped?

 

Anybody else seen similar issues?

 

For reference IAP 8.5.0.3 with CPPM 6.6.5 (yeah its old!) and Win10 clients. 

Default MTU value in CPPM is 1500

 

https://community.arubanetworks.com/t5/AAA-NAC-Guest-Access-BYOD/How-to-configure-MTU-in-CPPM/ta-p/267394

 

You can check MTU value configure in IAP aswell

 

https://community.arubanetworks.com/t5/Controller-less-WLANs/How-to-configure-the-MTU-on-IAP-uplink-and-tunnel-interfaces/ta-p/292114

 

Compare access tracker log of both working auth and timed out auth. Mostly we see timeouts when server sent access challenge to client and when there is no response after multiple attempts if will result in timeouts.

 

 

Hi Pavan,

 

Thanks for your reply. 

 

I have checked the difference between successful and failed attempts and this is where i've noticed that there is a difference. 

 

Successful requests have a size of 768 and failed attempts 1100. 

 

I have intermittent issues on the same AP with different clients. 

 

The same client could work 3 times and then timeout on the same AP so i'm thinking its likely some kind of client side issue.  trying to get to the bottom of why the two MTU sizes listed in the request would be different. 

 

 

 

 

 

 

 

I know the post is old but I ran into the same thing at one point a couple months ago when I was having some odd issues. 

1100 - not passed to inner tunnel
768 - passed to inner tunnel and processed by peap-mschapv2

Since the framed mtu cant be changed per admin design in clearpass; the place that is changing it is once it gets processed by the inner tunnel. Based on what I had seen, its safe to assume that framed mtu of 1100 never was fully processed by the inner tunnel. 

This can also be observed in some debugs. Just keep in mind that debugs for the inner-tunnel will not fully exist as this could be a security concern with capturing the mschap info that is being handed off for authentication to the domain.

------------------------------
Justin Kwasnik
------------------------------

Original Message:
Sent: Sep 07, 2020 10:48 PM
From: Scott Doorey
Subject: CPPM EAP Timeouts - Framed MTU value

Hi Pavan,

 

Thanks for your reply. 

 

I have checked the difference between successful and failed attempts and this is where i've noticed that there is a difference. 

 

Successful requests have a size of 768 and failed attempts 1100. 

 

I have intermittent issues on the same AP with different clients. 

 

The same client could work 3 times and then timeout on the same AP so i'm thinking its likely some kind of client side issue.  trying to get to the bottom of why the two MTU sizes listed in the request would be different. 

 

 

 

 

 

 

 

Just curious if anyone has ever figured out what this issue is.  I'm running across the same problem.  Most devices connect just fine, but I have a handful of devices that always get a timeout and can never connect, other devices will connect at times and at other times will result in a timeout.

All windows 10 PCs, getting the same GPO pushed out, located in different locations, connecting to different ClearPass servers in different countries. PCs doing EAP-PEAP machine authentication. Recently upgraded to CPPM 6.10.5 to see if that would fix anything, but it has not.  APs are a mixture of 305s & 315s managed by Central.

Successful authentications always show  Radius:IETF:Framed-MTU  768  Requests that result in a Error Code: 9002  Timeout always show  Radius:IETF:Framed-MTU 1100 or 1400  Clearpass set for default EAP-TLS size of 1024.

------------------------------
Andy Jezierski
------------------------------

Original Message:
Sent: Sep 07, 2020 10:48 PM
From: Scott Doorey
Subject: CPPM EAP Timeouts - Framed MTU value

Hi Pavan,

 

Thanks for your reply. 

 

I have checked the difference between successful and failed attempts and this is where i've noticed that there is a difference. 

 

Successful requests have a size of 768 and failed attempts 1100. 

 

I have intermittent issues on the same AP with different clients. 

 

The same client could work 3 times and then timeout on the same AP so i'm thinking its likely some kind of client side issue.  trying to get to the bottom of why the two MTU sizes listed in the request would be different. 

 

 

 

 

 

 

 

Based on my experience..

I never found an answer and I am still using NPS as a proxy server for machine EAP-PEAP. I had issues with the certificate trust chain and GoDaddy now has 2 intermediates. They changed things at one point from a single intermediate to 2. NPS sees the cert different than OpenSSL with the trust chain. I was going to move to internal RootCA and then I had found out that the rootCA is still doing SHA-1 and I didn't want to generate a cert and use something that needs to be updated. 

All I can offer is what I had found from the inner-tunnel of authentication from freeradius. It never had anything to do with what the TLS size or MTU was of any features. If successful authentication happened from the inner-tunnel (mschapv2) then the Framed-MTU would be updated in the debugs. 

If there was a timeout or an issue with the inner-tunnel then the Framed-MTU would not be updated. I am not aware of their settings for the inner-tunnel and cant comment on what module is responsible for returning that value. 

I would probably recommend debugs on clearpass to find out where these clients had got to in the process of authentication. You will probably want to enable debugs on only the server for that region you are looking to process and you will need to be aware of when the TLS cert is accepted vs authentication is handed off to the inner tunnel for mschap. There is most likely a certificate not being accepted or something that is restricting authentication to be completed. 

Debugs to enabled (Radius Server - Debug, Policy Server [AD/LDAP - debug]) You may also need the following from the Policy Sever Module for logging as well.. [Request Handeling - info], [Common Framework - Info]. Just make sure you disable them when finished as they can append to logging. 

You should see something to inform you that you are passing to module rlm_mschap as this is the inner tunnel along the lines below. This example was from a user 802.1x and not machine 802.1x via EAP-PEAP.  (username and domain were updated with generic). 

We can see that MSCHAPv2 was successful, at this point you can look for the Framed-MTU in the debugs. You will see that the framed MTU changes post rlm_mschap vs before. Access tracker will only show you the final Framed-MTU of what was completed in the logic. 


DEBUG RadiusServer.Radius - modcall: leaving group svc_USER 802.1x]_inner_3007 (returns updated) for request 4560569
..
INFO RadiusServer.Radius - rlm_eap_mschapv2: Received MSCHAPv2 Response from client
..
DEBUG RadiusServer.Radius - Processing the authenticate section of radiusd.conf
INFO RadiusServer.Radius - rlm_mschap: MSCHAPv2 username used for challenge computation <USERNAME>
DEBUG RadiusServer.Radius - rlm_mschap: Using user account name <USERNAME> fetched from auth source
INFO RadiusServer.Radius - rlm_mschap: Using domain <DOMAIN> from objectSid attribute
DEBUG RadiusServer.Radius - rlm_mschap: Updating NetBIOS-Name to <DOMAIN>
DEBUG RadiusServer.Radius - rlm_mschap: socket directory of <DOMAIN> domain is /var/avenda/tips/samba/samba_<DOMAIN>/winbindd_privileged
INFO RadiusServer.Radius - rlm_mschap: authenticating user <USERNAME>, domain <DOMAIN>
INFO RadiusServer.Radius - rlm_mschap: user <USERNAME> authenticated successfully
DEBUG RadiusServer.Radius - rlm_mschap: MSCHAPv2 succeeded

Another side node... When looking at EAP-TLS for the certificate negotiation. It will be in a hash (not sure if its base64, or how its hashed / encrypted). It will not be in plan text, and instead will be more along the lines with the following...  If you are doing a radius debug in the IAP you may see the actual cert being offered. I have always done debugs in AOS vs IAP, so I can only talk there. 

Either way I was able to compare the section that said "EAP-MESSAGE" like below to when the cert was being offered and negotiated upon. After this is all checked out it will be passed to inner tunnel. 

EAP-Message = 0x0136040619410302010202021be715300d06092a86 ...
EAP-Message = 0x02031328476f20446164747920526f6f74204365727 ...
EAP-Message = 0x819a0e29c51ca8e95d1eb69e9e300a39cef18880fb4 ...
EAP-Message = 0x33293027a125a0238621687474703a2f2f63726c2e6 ...
EAP-Message = 0xafd5bf24fnb1c3d ...


You are welcome to PM me if you want to ask any additional questions. Based on what you are seeing with timeouts there is probably some sort of communication issue between the site and clearpass or there is a certificate issue similar to what I had seen on godaddy. I still have no resolution and hope to get back to this in a few months.

Justin

------------------------------
Justin Kwasnik
------------------------------

Original Message:
Sent: May 18, 2022 11:15 AM
From: Andy Jezierski
Subject: CPPM EAP Timeouts - Framed MTU value

Just curious if anyone has ever figured out what this issue is.  I'm running across the same problem.  Most devices connect just fine, but I have a handful of devices that always get a timeout and can never connect, other devices will connect at times and at other times will result in a timeout.

All windows 10 PCs, getting the same GPO pushed out, located in different locations, connecting to different ClearPass servers in different countries. PCs doing EAP-PEAP machine authentication. Recently upgraded to CPPM 6.10.5 to see if that would fix anything, but it has not.  APs are a mixture of 305s & 315s managed by Central.

Successful authentications always show  Radius:IETF:Framed-MTU  768  Requests that result in a Error Code: 9002  Timeout always show  Radius:IETF:Framed-MTU 1100 or 1400  Clearpass set for default EAP-TLS size of 1024.

------------------------------
Andy Jezierski

Original Message:
Sent: Sep 07, 2020 10:48 PM
From: Scott Doorey
Subject: CPPM EAP Timeouts - Framed MTU value

Hi Pavan,

 

Thanks for your reply. 

 

I have checked the difference between successful and failed attempts and this is where i've noticed that there is a difference. 

 

Successful requests have a size of 768 and failed attempts 1100. 

 

I have intermittent issues on the same AP with different clients. 

 

The same client could work 3 times and then timeout on the same AP so i'm thinking its likely some kind of client side issue.  trying to get to the bottom of why the two MTU sizes listed in the request would be different. 

 

 

 

 

 

 

 

I think we finally figured out our timeout issue.  We had a group of computers that had an InTune policy pushed to them that turned on Credential Guard.  

According to MS:  "When you enable Windows Defender Credential Guard, you can no longer use NTLM classic authentication for Single Sign-On. You will be forced to enter your credentials to use these protocols and cannot save the credentials for future use. If you are using WiFi and VPN endpoints that are based on MS-CHAPv2, they are subject to similar attacks as for NTLMv1. For WiFi and VPN connections, Microsoft recommends that organizations move from MSCHAPv2-based connections such as PEAP-MSCHAPv2 and EAP-MSCHAPv2, to certificate-based authentication such as PEAP-TLS or EAP-TLS."

Our users were never being prompted for an ID, thus the Timeout.  Turned off Credential Guard and problem is resolved.

------------------------------
Andy Jezierski
------------------------------

Original Message:
Sent: May 18, 2022 01:22 PM
From: Justin Kwasnik
Subject: CPPM EAP Timeouts - Framed MTU value

Based on my experience..

I never found an answer and I am still using NPS as a proxy server for machine EAP-PEAP. I had issues with the certificate trust chain and GoDaddy now has 2 intermediates. They changed things at one point from a single intermediate to 2. NPS sees the cert different than OpenSSL with the trust chain. I was going to move to internal RootCA and then I had found out that the rootCA is still doing SHA-1 and I didn't want to generate a cert and use something that needs to be updated. 

All I can offer is what I had found from the inner-tunnel of authentication from freeradius. It never had anything to do with what the TLS size or MTU was of any features. If successful authentication happened from the inner-tunnel (mschapv2) then the Framed-MTU would be updated in the debugs. 

If there was a timeout or an issue with the inner-tunnel then the Framed-MTU would not be updated. I am not aware of their settings for the inner-tunnel and cant comment on what module is responsible for returning that value. 

I would probably recommend debugs on clearpass to find out where these clients had got to in the process of authentication. You will probably want to enable debugs on only the server for that region you are looking to process and you will need to be aware of when the TLS cert is accepted vs authentication is handed off to the inner tunnel for mschap. There is most likely a certificate not being accepted or something that is restricting authentication to be completed. 

Debugs to enabled (Radius Server - Debug, Policy Server [AD/LDAP - debug]) You may also need the following from the Policy Sever Module for logging as well.. [Request Handeling - info], [Common Framework - Info]. Just make sure you disable them when finished as they can append to logging. 

You should see something to inform you that you are passing to module rlm_mschap as this is the inner tunnel along the lines below. This example was from a user 802.1x and not machine 802.1x via EAP-PEAP.  (username and domain were updated with generic). 

We can see that MSCHAPv2 was successful, at this point you can look for the Framed-MTU in the debugs. You will see that the framed MTU changes post rlm_mschap vs before. Access tracker will only show you the final Framed-MTU of what was completed in the logic. 


DEBUG RadiusServer.Radius - modcall: leaving group svc_USER 802.1x]_inner_3007 (returns updated) for request 4560569
..
INFO RadiusServer.Radius - rlm_eap_mschapv2: Received MSCHAPv2 Response from client
..
DEBUG RadiusServer.Radius - Processing the authenticate section of radiusd.conf
INFO RadiusServer.Radius - rlm_mschap: MSCHAPv2 username used for challenge computation <USERNAME>
DEBUG RadiusServer.Radius - rlm_mschap: Using user account name <USERNAME> fetched from auth source
INFO RadiusServer.Radius - rlm_mschap: Using domain <DOMAIN> from objectSid attribute
DEBUG RadiusServer.Radius - rlm_mschap: Updating NetBIOS-Name to <DOMAIN>
DEBUG RadiusServer.Radius - rlm_mschap: socket directory of <DOMAIN> domain is /var/avenda/tips/samba/samba_<DOMAIN>/winbindd_privileged
INFO RadiusServer.Radius - rlm_mschap: authenticating user <USERNAME>, domain <DOMAIN>
INFO RadiusServer.Radius - rlm_mschap: user <USERNAME> authenticated successfully
DEBUG RadiusServer.Radius - rlm_mschap: MSCHAPv2 succeeded

Another side node... When looking at EAP-TLS for the certificate negotiation. It will be in a hash (not sure if its base64, or how its hashed / encrypted). It will not be in plan text, and instead will be more along the lines with the following...  If you are doing a radius debug in the IAP you may see the actual cert being offered. I have always done debugs in AOS vs IAP, so I can only talk there. 

Either way I was able to compare the section that said "EAP-MESSAGE" like below to when the cert was being offered and negotiated upon. After this is all checked out it will be passed to inner tunnel. 

EAP-Message = 0x0136040619410302010202021be715300d06092a86 ...
EAP-Message = 0x02031328476f20446164747920526f6f74204365727 ...
EAP-Message = 0x819a0e29c51ca8e95d1eb69e9e300a39cef18880fb4 ...
EAP-Message = 0x33293027a125a0238621687474703a2f2f63726c2e6 ...
EAP-Message = 0xafd5bf24fnb1c3d ...


You are welcome to PM me if you want to ask any additional questions. Based on what you are seeing with timeouts there is probably some sort of communication issue between the site and clearpass or there is a certificate issue similar to what I had seen on godaddy. I still have no resolution and hope to get back to this in a few months.

Justin

------------------------------
Justin Kwasnik

Original Message:
Sent: May 18, 2022 11:15 AM
From: Andy Jezierski
Subject: CPPM EAP Timeouts - Framed MTU value

Just curious if anyone has ever figured out what this issue is.  I'm running across the same problem.  Most devices connect just fine, but I have a handful of devices that always get a timeout and can never connect, other devices will connect at times and at other times will result in a timeout.

All windows 10 PCs, getting the same GPO pushed out, located in different locations, connecting to different ClearPass servers in different countries. PCs doing EAP-PEAP machine authentication. Recently upgraded to CPPM 6.10.5 to see if that would fix anything, but it has not.  APs are a mixture of 305s & 315s managed by Central.

Successful authentications always show  Radius:IETF:Framed-MTU  768  Requests that result in a Error Code: 9002  Timeout always show  Radius:IETF:Framed-MTU 1100 or 1400  Clearpass set for default EAP-TLS size of 1024.

------------------------------
Andy Jezierski

Original Message:
Sent: Sep 07, 2020 10:48 PM
From: Scott Doorey
Subject: CPPM EAP Timeouts - Framed MTU value

Hi Pavan,

 

Thanks for your reply. 

 

I have checked the difference between successful and failed attempts and this is where i've noticed that there is a difference. 

 

Successful requests have a size of 768 and failed attempts 1100. 

 

I have intermittent issues on the same AP with different clients. 

 

The same client could work 3 times and then timeout on the same AP so i'm thinking its likely some kind of client side issue.  trying to get to the bottom of why the two MTU sizes listed in the request would be different. 

 

 

 

 

 

 

 

Good info on the topic, and thanks for sharing the info. I am not a windows user and was strictly speaking from back end radius server. If you had dove into the debugs you would have probably found that it was not being passed to inner tunnel properly. It's hard to say without testing this and reviewing debugs. 

The important part is just knowing that the Framed-MTU is updated once it hits the inner tunnel where MSCHAPv2 is passed. When using cert auth  for EAP-TLS as the outer authentication, there is no inner tunnel as its cert based auth. 

You did provide some useful info that I can look into when I can cycle back around on this myself. We use a GPO and only do machine auth and we verify the server cert CN plus root CA issuer.  I believe my issue was due to OpenSSL seeing the trust chain vs Microsoft with the GoDaddy Cert. GoDaddy mucked with the trust chain a couple years ago and I would rather not migrate internal users on an AD CA that is still using SHA-1.

EAP-PEAP can be compromised fairly easy if you are not enforcing the certificate check. Once someone accepts the spoofed cert they can capture the hash of password and run it through crackers. I can see why Microsoft would push security settings on this topic. 

Thanks again or sharing your feedback and fix!!

------------------------------
Justin Kwasnik
------------------------------

Original Message:
Sent: Jun 02, 2022 02:32 PM
From: Andy Jezierski
Subject: CPPM EAP Timeouts - Framed MTU value

I think we finally figured out our timeout issue.  We had a group of computers that had an InTune policy pushed to them that turned on Credential Guard.  

According to MS:  "When you enable Windows Defender Credential Guard, you can no longer use NTLM classic authentication for Single Sign-On. You will be forced to enter your credentials to use these protocols and cannot save the credentials for future use. If you are using WiFi and VPN endpoints that are based on MS-CHAPv2, they are subject to similar attacks as for NTLMv1. For WiFi and VPN connections, Microsoft recommends that organizations move from MSCHAPv2-based connections such as PEAP-MSCHAPv2 and EAP-MSCHAPv2, to certificate-based authentication such as PEAP-TLS or EAP-TLS."

Our users were never being prompted for an ID, thus the Timeout.  Turned off Credential Guard and problem is resolved.

------------------------------
Andy Jezierski

Original Message:
Sent: May 18, 2022 01:22 PM
From: Justin Kwasnik
Subject: CPPM EAP Timeouts - Framed MTU value

Based on my experience..

I never found an answer and I am still using NPS as a proxy server for machine EAP-PEAP. I had issues with the certificate trust chain and GoDaddy now has 2 intermediates. They changed things at one point from a single intermediate to 2. NPS sees the cert different than OpenSSL with the trust chain. I was going to move to internal RootCA and then I had found out that the rootCA is still doing SHA-1 and I didn't want to generate a cert and use something that needs to be updated. 

All I can offer is what I had found from the inner-tunnel of authentication from freeradius. It never had anything to do with what the TLS size or MTU was of any features. If successful authentication happened from the inner-tunnel (mschapv2) then the Framed-MTU would be updated in the debugs. 

If there was a timeout or an issue with the inner-tunnel then the Framed-MTU would not be updated. I am not aware of their settings for the inner-tunnel and cant comment on what module is responsible for returning that value. 

I would probably recommend debugs on clearpass to find out where these clients had got to in the process of authentication. You will probably want to enable debugs on only the server for that region you are looking to process and you will need to be aware of when the TLS cert is accepted vs authentication is handed off to the inner tunnel for mschap. There is most likely a certificate not being accepted or something that is restricting authentication to be completed. 

Debugs to enabled (Radius Server - Debug, Policy Server [AD/LDAP - debug]) You may also need the following from the Policy Sever Module for logging as well.. [Request Handeling - info], [Common Framework - Info]. Just make sure you disable them when finished as they can append to logging. 

You should see something to inform you that you are passing to module rlm_mschap as this is the inner tunnel along the lines below. This example was from a user 802.1x and not machine 802.1x via EAP-PEAP.  (username and domain were updated with generic). 

We can see that MSCHAPv2 was successful, at this point you can look for the Framed-MTU in the debugs. You will see that the framed MTU changes post rlm_mschap vs before. Access tracker will only show you the final Framed-MTU of what was completed in the logic. 


DEBUG RadiusServer.Radius - modcall: leaving group svc_USER 802.1x]_inner_3007 (returns updated) for request 4560569
..
INFO RadiusServer.Radius - rlm_eap_mschapv2: Received MSCHAPv2 Response from client
..
DEBUG RadiusServer.Radius - Processing the authenticate section of radiusd.conf
INFO RadiusServer.Radius - rlm_mschap: MSCHAPv2 username used for challenge computation <USERNAME>
DEBUG RadiusServer.Radius - rlm_mschap: Using user account name <USERNAME> fetched from auth source
INFO RadiusServer.Radius - rlm_mschap: Using domain <DOMAIN> from objectSid attribute
DEBUG RadiusServer.Radius - rlm_mschap: Updating NetBIOS-Name to <DOMAIN>
DEBUG RadiusServer.Radius - rlm_mschap: socket directory of <DOMAIN> domain is /var/avenda/tips/samba/samba_<DOMAIN>/winbindd_privileged
INFO RadiusServer.Radius - rlm_mschap: authenticating user <USERNAME>, domain <DOMAIN>
INFO RadiusServer.Radius - rlm_mschap: user <USERNAME> authenticated successfully
DEBUG RadiusServer.Radius - rlm_mschap: MSCHAPv2 succeeded

Another side node... When looking at EAP-TLS for the certificate negotiation. It will be in a hash (not sure if its base64, or how its hashed / encrypted). It will not be in plan text, and instead will be more along the lines with the following...  If you are doing a radius debug in the IAP you may see the actual cert being offered. I have always done debugs in AOS vs IAP, so I can only talk there. 

Either way I was able to compare the section that said "EAP-MESSAGE" like below to when the cert was being offered and negotiated upon. After this is all checked out it will be passed to inner tunnel. 

EAP-Message = 0x0136040619410302010202021be715300d06092a86 ...
EAP-Message = 0x02031328476f20446164747920526f6f74204365727 ...
EAP-Message = 0x819a0e29c51ca8e95d1eb69e9e300a39cef18880fb4 ...
EAP-Message = 0x33293027a125a0238621687474703a2f2f63726c2e6 ...
EAP-Message = 0xafd5bf24fnb1c3d ...


You are welcome to PM me if you want to ask any additional questions. Based on what you are seeing with timeouts there is probably some sort of communication issue between the site and clearpass or there is a certificate issue similar to what I had seen on godaddy. I still have no resolution and hope to get back to this in a few months.

Justin

------------------------------
Justin Kwasnik

Original Message:
Sent: May 18, 2022 11:15 AM
From: Andy Jezierski
Subject: CPPM EAP Timeouts - Framed MTU value

Just curious if anyone has ever figured out what this issue is.  I'm running across the same problem.  Most devices connect just fine, but I have a handful of devices that always get a timeout and can never connect, other devices will connect at times and at other times will result in a timeout.

All windows 10 PCs, getting the same GPO pushed out, located in different locations, connecting to different ClearPass servers in different countries. PCs doing EAP-PEAP machine authentication. Recently upgraded to CPPM 6.10.5 to see if that would fix anything, but it has not.  APs are a mixture of 305s & 315s managed by Central.

Successful authentications always show  Radius:IETF:Framed-MTU  768  Requests that result in a Error Code: 9002  Timeout always show  Radius:IETF:Framed-MTU 1100 or 1400  Clearpass set for default EAP-TLS size of 1024.

------------------------------
Andy Jezierski

Original Message:
Sent: Sep 07, 2020 10:48 PM
From: Scott Doorey
Subject: CPPM EAP Timeouts - Framed MTU value

Hi Pavan,

 

Thanks for your reply. 

 

I have checked the difference between successful and failed attempts and this is where i've noticed that there is a difference. 

 

Successful requests have a size of 768 and failed attempts 1100. 

 

I have intermittent issues on the same AP with different clients. 

 

The same client could work 3 times and then timeout on the same AP so i'm thinking its likely some kind of client side issue.  trying to get to the bottom of why the two MTU sizes listed in the request would be different.