L

9 Messages

 • 

200 Points

Mon, May 31, 2021 5:54 AM

Unstable connection with Unleashed 200.9.10.4.243

Hi,

Following the FragAttacks announcement I have upgraded my R550 AP to 200.9.10.4.243 only to find subtle connection stability issues between the AP and a Linux ThinkPad T480s with a Intel 8265 wireless chipset. The symptom is that any tcp/udp/icmp package transmission just stops after 1-2 hours of usage. After reverting to 200.9.10.4.233 everything is rock solid once again with connection not breaking at all for days at a time. I have tried WPA2-only and WPA3-only modes both with both firmwares and the results are the same (233 is stable, 243 causes dropouts).

Any ideas where to look next or what might be causing this?

Regards,

Lenno

Accepted Solution

Official Solution

Official Rep

 • 

1.3K Messages

 • 

17.7K Points

6 m ago

Hi Lenno,

Problem may or may not be due to FragAttacks fix.

Also, you can upgrade to 200.10.10.5.229, same has been released on support portal.

Again, not all the vulnerabilities under FragAttacks can be fixed by just upgrading APs, you also have to upgrade the UE card drivers.

9 Messages

 • 

200 Points

Oh, thanks for this remark regarding 200.10! I've been waiting a long time for this news also and now upgraded to 200.10.10.5.229 last evening.

I ran iperf on the device for 12 hours during the night - not a single disconnect or any other issue. But of course the network/device itself had no other usage. I will test this throughout the day as well.

9 Messages

 • 

200 Points

I was wondering whether 200.10.10.5.229 actually includes the FragAttacks mitigations?

Official Rep

 • 

1.3K Messages

 • 

17.7K Points

It has the fix!

Regards,

Syamantak Omer

Official Rep | Staff TSE | CWNA | CCNA | RASZA | RICXI

Follow me on Linkedin

9 Messages

 • 

200 Points

Thanks! I think 200.10 solved this as it's been really stable so far :)

Official Solution

Employee

 • 

103 Messages

 • 

1.5K Points

6 m ago

Hi Lenno,

Since the issue is seen only after upgrade to a specific code and a downgrade resolves it we would need to collect debug log on the AP and packet capture to identify the root cause. Can you please log on a case with us to track the issue and for initial debug attach the AP support and from Master diagnostic log along with it. Please be noted in case TAC doesn't have the specified device we would need your help in reproducing the problem again.

You can open up a case using below :

1) You can call our support helpline and a rep would help creating a case :

https://support.ruckuswireless.com/contact-us

2) You can directly open a case via our support portal :

https://support.ruckuswireless.com/cases/new

Best Regards

Vineet

9 Messages

 • 

200 Points

Thank you for the suggestion. I've opened the case via the support portal just now. I can help to reproduce it, I'll await the instructions.

EDIT: Sorry, I didn't realize that I don't have a support contract, so unfortunately the support team is unable to assist in this matter.

(edited)

Employee

 • 

103 Messages

 • 

1.5K Points

Hi Lenno,

Can you please once update the driver on the client device and update the performance behavior. 

Best Regards

Vineet

477 Messages

 • 

5.9K Points

6 m ago

It is possible, that the problem is directly related to FragAttacks fixes. FragAttacks fixes limit WiFi working mode to more secure modes, and any additional security is expected to add requirements to connection quality.

As example from different area --  you may have quit good experience looking on WEB pages over connection with packet loss rate about 1%, and you will never even suspect it. But if you try to do IPSEC connection for same traffic over same connection, you'll feel this packet loss as connection drops and disconnects. Reason is that IPSEC  doesn't like packet loss at all  -- packets are all numbered, and when some packet is missing, you can be disconnected. 

It unfortunately means, that your problem may be not even a bug, but just a result of higher requirements of more secure connection to media (RF) -- so it can be not fixable.

I can't say if it is so in your case, but it is definitely possible (unfortunately).

Another reason of problem may be that client driver is expected to use less secure modes, and is not so good tuned or even is baggy, when working in secure mode.

Unfortunately, such issues are very difficult to diagnose, and fix, as they require both client and AP vendors involvement.

By the way, do you have fix for client device installed (Linux ThinkPad T480s with a Intel 8265 wireless)? With fix you have better chance that client driver will work reliably in secure modes. 

If you don't have fixes on all client devices, I don't see much good from upgrading just AP.

9 Messages

 • 

200 Points

Thank you for the insight regarding the security and connection quality requirements. This makes a lot of sense.

I will test WPA2 vs WPA3 now on 200.10.10.5.229 firmware.

Important Announcement