• November 16, 2018, 08:16:59 PM
Welcome, Guest. Please login or register. Registration is free.
Did you miss your activation email?

Author Topic: New software code 8.0MR3  (Read 1574 times)

0 Members and 1 Guest are viewing this topic.

Offline Jeroen

  • Full Member
  • ***
  • Posts: 56
New software code 8.0MR3
« on: June 03, 2014, 03:56:32 AM »
Last weekend Juniper made code 8.0MR3 available on their website.

I've been running 8.0MR2 for quiet some time now with minor issues. Besides some WLA crashes nothing really impacted our business. Until we changed our Lenovo laptops for brand new HP 840's. These units do support 802.11ac, although my current WLA does not. However, I received more and more complaints of people who were occasionally disconnected from the WLAN. This was easily solved by disabling and enabling the WLAN adapter, but it becomes annoying when this happens several times a day.
As we were using the latest Intel driver with our Intel 7260 NIC (16.6) , and latest software on the WLA's (8.0MR2) we decided to address this issue at HP, Intel and Juniper.

After several months of investigation, it finally became clear that the disconnect issue was casued due to a timing issue in communication between the Intel NIC and Juniper WLA.
Although Intel had changed the behaviour of the driver by enforcing these timers now, in the end it was caused by a timing issue the way the Atheros chipset worked in the Juniper WLA. The chipset seemed not to be fully compliant with the standards.

Besides the Juniper access points, people complaint about disconnects in their homes too. The issue occured on different router models and types. After Intel released driver version 17.0, most of the issues were solved at home and the amount of disconnects were reduced. However they still occur and the real solution should now be available with the new Juniper 8.0MR3 code.
I've been testing this release for 2 days now and I'm not able to reproduce the issue anymore. Seems like Juniper has fixed the timing issue in this code, which makes me want to install this code in the production environment asap!

Besides further testing this is definitely a code that you would want to run in your production environment, especially when running into disconect issues with Intel and Juniper gear.

As mentioned by HP, this was one of the toughest issues to solve in his 20 years carreer.

Many thanks to HP, Intel and Juniper for diving into this issue, analyzing all the traces and logs and being able to resolve this issue.

Although this resolved issue is not mentioned in the Juniper release notes, according to Juniper it has been solved now.

Two more other issues that I addresed at Juniper are resolved in this issue as well. The first one is a WLA crash. WLA's seems to crash randomly without any reason. This has been fixed now.
The second issue caused a huge delay for a client in receiving a correct IP-address when moving from one network to the other when using local switching in combination with the 'no broadcast' feature enabled. The problem was the client never received the DHCP NAK when accesing anohter network. Client behaviour is that it tries to use its last (cached) IP-address and the DHCP server should send the client a DHCP NAK as the client is accesing another IP-network. The client never received the NAK as this message was broadcasted and therefore blocked by the WLA with the 'no broadcast' option set to true. This caused the Winodws client to wait on the buildin timer which could take up to several minutes for the client to release its cached IP-address by itself, and do a DHCP request. According to Juniper, this should have been fixed as well.


Currently all my issues have now been fixed in this release, and I don't have anymore cases open at JTAC. Ofcourse I will have to see how 8.0MR3 runs for a longer period of time. Hopefully no new issues are introduced with this release.

Anyone running into an issue with 8.0 code? Start a topic and lets see if it can be solved  :)