Can the WLC capture be trusted?

[patoberli]

Hi All

I'm debugging a EAP-TLS issue at the moment, between some iPads a WLC 8540 with 8.10.181.3 and 2800 APs. 
It works with 2700 AP models on this WLC, but nearly always fails with 2800 APs.

I've now captured the radius communication between the WLC and ISE and it seems that either the WLC doesn't receive all (fragmented) packets, or the capture on the WLC is not trustworthy. The whole setup worked fine with 8.5.140.0. Disabling 802.11r (Fast Transition) didn't help. The ISE shows a lot of Radius communication, until the client starts a new session.

I've used this information for the capture: http://wifinigel.blogspot.com/2014/08/cisco-wlc-per-client-packet-capture.html

On the left side is the capture from the WLC, on the right side is the capture from the firewall interface between the WLC and ASA. Please note, I didn't do the captures at the exact same time, but the symptom is the same always. ASA interface and WLC Management Interface are on the same VLAN/segment. As you can see, the third fragmented Radius packet, is either not completely captured by the WLC capture function, or indeed lost.

Have you seen something like this already?

I haven't yet had the possibility to capture on the switch where the WLC is attached to.

Thanks
Patrick

[patoberli]

Hi Leo

Thanks for the heads up. So far I haven't had any customer complaints about that. I also wonder if this bug might already be fixed in 17.9.4, but thanks to the castrated release notes we don't know this.

[Rich R]

I've already provided feedback about the release notes as per Friday's TAC Time Pat - hope you have too.
Everyone else - please check out the latest release notes (17.9.4 and 17.12.1) - they no longer provide a list of fixed and open bugs (even though that list was always only a selected list) - they now link to the bug search tool but the queries are wrong and return a meaningless and completely useless list of bugs (the supposed fixes are actually bugs affecting the IOS!).  Please check it out and use the feedback link to give your opinion.  Cisco asked for feedback on a call last Friday so give them all you can...

[eglinsky2012]

@Rich R , any idea why they changed the release notes to link to the BST? Are they trying to save time, being lazy, maybe avoiding the bad look of bug lists that seem to get longer and longer?

[Leo Laohoo]

---

@eglinsky2012 wrote:
Are they trying to save time, being lazy

---

Both.  If they just put links then the "publication team" do not need to regularly put out Release Notes.  Saves money and management cost.  A real cut-n-paste team.

[patoberli]

Who knows, maybe they actually improve the data inside the BST now, if
enough people complain. But honestly, I doubt it.

[Leo Laohoo]

---

@patoberli wrote:
if enough people complain

---

It is not a question of "if enough people complain" but, rather, "if the right people complain".

Ordinary people, like you and me, will not get any traction, however, if a "whale" taps their accounts team and makes a "demand", it will be done.  

And after the backdown of the decision to continue WLC support of 2700/3700/1570 from 17.9.3, I strongly believe this is the only way.   

[Rich R]

On the one hand I think the objective is to ensure that the list is always accurate and up to date with what's in the bug database - but that will only work when using the correct queries and (most importantly) having complete and accurate data in the bug database.  But the reality is that the info in the database is still far from complete and accurate and gets entered in so many different ways by the Cisco staff that it's practically impossible to get the right results at the moment in my opinion.

So can they get the data right? Well they've been trying for years and it has improved slightly but it's still not up to standard as far as I'm concerned.  It also has the problem that they still keep dozens of bugs hidden - sometimes for security reasons but also a whole lot of other reasons they make up (which mostly amount to that it's embarrassing for Cisco or their suppliers).  Some of those used to get put in the release notes even though they were hidden on the tool so at least we were aware of them from the notes.  Now we won't even know about them.

End result is that we will know less about the bugs affecting the code we use, and how to work around them - meaning we'll be forced to open TAC cases instead of solving problems for ourselves.  You can come to your own conclusions on why Cisco might want that...

Like Leo says we need the right customers to raise the issue (if anybody knows them then urge them to do so) but at least we might have some slight influence if enough of us give feedback.

Personally I'd like the bug tool to work much better but I just don't have much faith that they are capable of achieving that based on how little progress I've seen in the last 10 years and they've actually made some of it significantly worse - for example you're not even allowed to report hidden bugs that you think should be visible anymore - it just pops a brief message (easy to miss) then goes back to search - so no way of getting it reviewed other than opening a new TAC case...  I think you can see where this is going!

[patoberli]

Not yet, but soon.

[Leo Laohoo]

@patoberli, some of the newly discovered Bug IDs involving the new Catalyst 9k are pretty scary.  Some actually do look like the same issues as 2800/3800/4800/1560, like certain models dropping ARP or beacons getting delayed up to 100 msec.  

[patoberli]

@Leo Laohoo Just discovered a new bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwh84302

So far no fix available. 

Btw. 8.10.190.0 was just released:
https://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn810mr10.html

[Leo Laohoo]

Thanks, Pat.  

I am trying to understand how this bug is related to the 2800/3800/4800 APs.  

[patoberli]

Sorry, I completely forgot that this thread is for the 2800/3800/4800 specific bugs. That one is a more general one.

[Leo Laohoo]

All good.  

[patoberli]

One more for the list:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCwf79175

I had this on 17.9.4a though, but according the bug, every 8.x version is also affected.