It has bitten us in the butt big time. I have been promised by cisco that the next code version MR5 (.141 is MR4) has the intel issue resolved.
We too, even with the latest 19.2 Intel drivers, had issues with devices connecting. For what that is worth..... -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Slone, Kelly Sent: Thursday, January 19, 2017 9:53 AM To: [email protected] Subject: Re: [WIRELESS-LAN] Clients unable to obtain an IP address via DHCP Roger, Has there been any changes? Is this a new turn up of your 5508’s? Is LAG enabled on the 5508’s? Are you using interface groups? We ran into a very similar issue at the startup of the semester after turning up a new pair of 8540’s. Interfaces in our interface group were becoming marked “dirty” as a result and this scope/interface was taken away from our available pool form the interface group limiting the addresses available to us to hand out to clients. Not sure if the is the exact issue you are seeing but it sounds very similar. Feel free to hit me up offline if I could be off assistance. [email protected]<mailto:[email protected]> Thanks, Kelly Slone [email protected]<mailto:[email protected]> Lag was enabled on our 8540’s but not he connecting switch a port channel was not setup. Each interface was just trunked. We were seeing On Jan 19, 2017, at 9:39 AM, Schwartz, Roger J <[email protected]<mailto:[email protected]>> wrote: Has anybody been able to resolve this issue. A couple of things about our issue. We are a Cisco shop We are using 3602s, 3702s and 3802s Wireless controllers are 5508’s running code 8.2.141.0 We are using inCommon certificates This is a portion of the client debug. *apfLbsTask: Jan 19 08:31:38.718: c0:f2:fb:31:a3:d6 Copy IP LOCP: 0xac1795ce *apfLbsTask: Jan 19 08:31:38.718: c0:f2:fb:31:a3:d6 Copy MobilityData LOCP status:1, anchorip:0x0 *IPv6_Msg_Task: Jan 19 08:31:39.450: c0:f2:fb:31:a3:d6 Link Local address fe80::412:e6bd:6087:da74 updated to mscb. Not Advancing pem state.Current state: mscb in apfMsMmInitial mobility state and client state APF_MS_STATE_AS *radiusCoASupportTransportThread: Jan 19 08:31:42.372: c0:f2:fb:31:a3:d6 apfMsDeleteByMscb Scheduling mobile for deletion with deleteReason 6, reasonCode 252 *radiusCoASupportTransportThread: Jan 19 08:31:42.372: c0:f2:fb:31:a3:d6 Scheduling deletion of Mobile Station: (callerId: 30) in 1 seconds *radiusCoASupportTransportThread: Jan 19 08:31:42.372: c0:f2:fb:31:a3:d6 PMK: Sending cache delete *radiusCoASupportTransportThread: Jan 19 08:31:42.373: c0:f2:fb:31:a3:d6 Removing PMK cache entry for station c0:f2:fb:31:a3:d6 *radiusCoASupportTransportThread: Jan 19 08:31:42.373: c0:f2:fb:31:a3:d6 0 PMK-remove groupcast messages sent *osapiBsnTimer: Jan 19 08:31:43.318: c0:f2:fb:31:a3:d6 apfMsExpireCallback (apf_ms.c:638) Expiring Mobile! *apfReceiveTask: Jan 19 08:31:43.318: c0:f2:fb:31:a3:d6 apfMsExpireMobileStation (apf_ms.c:7394) Changing state for mobile c0:f2:fb:31:a3:d6 on AP fc:5b:39:bc:f4:e0 from Associated to Disassociated *apfReceiveTask: Jan 19 08:31:43.318: c0:f2:fb:31:a3:d6 apfSendDisAssocMsgDebug (apf_80211.c:3459) Changing state for mobile c0:f2:fb:31:a3:d6 on AP fc:5b:39:bc:f4:e0 from Disassociated to Disassociated Thanks Roger Roger Schwartz |Senior Wireless Network Technician| Information Technology Services UNIVERSITY OF TENNESSEE HEALTH SCIENCE CENTER 877 Madison Ave., Suite 738 | Memphis, TN 38163 From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> on behalf of "Osborne, Bruce W (Network Operations)" <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Friday, December 30, 2016 at 6:58 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [WIRELESS-LAN] Clients unable to obtain an IP address via DHCP It is generally good practice to have clients upgrade to the latest Intel driver before troubleshooting further. In occasion, we have even used our RADIUS authentication logs to get a list to email wireless Intel users recommending they upgrade to the latest drivers. We have generally done this after a bad batch if drivers has been remedied. Bruce Osborne Senior Network Engineer Network Operations - Wireless (434) 592-4229 LIBERTY UNIVERSITY Training Champions for Christ since 1971 From: Atanas P Atanasov [mailto:[email protected]] Sent: Friday, December 23, 2016 12:30 PM Subject: Re: Clients unable to obtain an IP address via DHCP Jen, I appreciate the suggestion. I was pretty sure our was set to authoritative but just double checked just in case. <image001.png> Somebody from the list said they had the issue resolved after upgrading the wireless controller code. We recently upgraded our code to version 8.2.141.0 but we’re still seeing this randomly pop up around the campus. On the windows clients it seems that an older Intel driver (version 17.x) is the culprit but we haven’t had enough sample size to make that conclusion. Atanas From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Jennifer Francis Wilson Sent: Friday, December 23, 2016 7:22 AM To: [email protected]<mailto:[email protected]> Subject: Re: [WIRELESS-LAN] Clients unable to obtain an IP address via DHCP Probably not the issue in this case but it's worth checking that Infoblox (or whatever other DHCP server you are using) has been set to authoritative, which isn't always the default (and has hit us in the dim and distant past). Infoblox setting for this is in Grid DHCP properties/General setting (we get to it by going Data Management/DHCP, then on the toolbar click the "Grid DHCP properties" button/item. If the DHCP server isn't authoritative then the client is free to ignore the response. Regards, Jen. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Schwartz, Roger J Sent: 21 December 2016 19:17 To: [email protected]<mailto:[email protected]> Subject: Re: [WIRELESS-LAN] Clients unable to obtain an IP address via DHCP Has this issue been resolved by any one yet? We are seeing this issue on wireless with some iPad’s and iPhone’s. We are now encountering this on the wired network with printers, Printers in a mab state do not get an ip address. Considering rolling our ISE server patch back. From: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> on behalf of Atanas P Atanasov <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Tuesday, December 13, 2016 at 3:23 PM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [WIRELESS-LAN] Clients unable to obtain an IP address via DHCP In our case it does hit a router, I’ve seen the discovers and offers on both sides. I’ve verified it also in a packet capture on the controller “wireless“ VLAN. In the capture below client gets its IP after packet 294. In my mind either the client doesn’t see the offer or the controller doesn’t see the request. I was able to capture some traffic from a client having the problem but it is of a little use to me since I can’t decrypt the traffic. Jake, We are in bridge mode. <image002.png> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Brian Helman Sent: Tuesday, December 13, 2016 4:06 PM To: [email protected]<mailto:[email protected]> Subject: Re: [WIRELESS-LAN] Clients unable to obtain an IP address via DHCP Does the Infoblox go through a router to hit the 8510? I wonder if the router isn’t liking something from the update re: the lease response? If that is the case, have you sniffed the line on both sides of the router (hmm, that didn’t sound as Breaking Bad in my head)? -Brian From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Mike Atkins Sent: Tuesday, December 13, 2016 3:49 PM To: [email protected]<mailto:[email protected]> Subject: Re: [WIRELESS-LAN] Clients unable to obtain an IP address via DHCP We are an Infoblox shop with Cisco 8510 controllers running 8.2.121.0. We updated the software on our Infoblox appliances around the beginning of the semester because of similar symptoms. In our case I was capturing traffic on the wired side between the controller and Infoblox servers because I saw debug logs on the controller indicating dirty interface. Capturing DHCP traffic between client and DHCP server showed the client sending discover and no response from the DHCP servers for long periods of time (minutes.) When I looked at the syslogs from the DHCP servers I did not see log entries for the discovers. One of our engineers updated the Infoblox software and opened a ticket with Infobox to run debug on the Infoblox servers. However, after updating the software we were not able to successfully replicate the issue so we had to close the Infoblox ticket. After the software update I was not able to catch any instances where DHCP discovers were greater than DHCP offers. I checking this by running a packet capture and graphing discovers vs offers. We never received reports of wired users not getting DHCP leases but I doubt they would notice. I’m still suspicious because I have wireless debugs where the client repeated requests IP address and DHCP server repeatedly ACKs. (even with good RSSI and good SNR) From the group it sounds like we might need to update controller software in addition to the Infoblox update. We are running 7.3.8-3405 on Infoblox now. Mike Atkins Network Engineer Office of Information Technology University of Notre Dame From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Atanas P Atanasov Sent: Tuesday, December 13, 2016 2:35 PM To: [email protected]<mailto:[email protected]> Subject: Re: [WIRELESS-LAN] Clients unable to obtain an IP address via DHCP Yes, This has been going on for at least 3 months. Seeing the issue on all kinds of clients Apple, Windows and Android. From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]] On Behalf Of Mike Atkins Sent: Tuesday, December 13, 2016 2:33 PM To: [email protected]<mailto:[email protected]> Subject: Re: [WIRELESS-LAN] Clients unable to obtain an IP address via DHCP Atanas, Has this been going on for a while? It is not related to a recent Microsoft patch? (so more than just Windows clients?) Mike Atkins Network Engineer Office of Information Technology University of Notre Dame From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Atanas P Atanasov Sent: Tuesday, December 13, 2016 2:23 PM To: [email protected]<mailto:[email protected]> Subject: [WIRELESS-LAN] Clients unable to obtain an IP address via DHCP We’re a seeing some odd behavior in our wireless deployment, seemingly random clients aren’t able to obtain an IP via DHCP When analyzing the DHCP logs and also debugs on the wireless controller, we see the clients sending a DHCP DISCOVER packet and the DHCP server responds with a DHCP OFFER. However the client doesn’t follow up with a DHCP REQUEST. This behavior continues sometimes for hours, until the client finally sends a DHCP REQUEST and obtains a lease. The side effect of this is our DHCP servers are getting long delays when the dhcp service is restarted. We are using Infoblox dhcp severs in a failover group. From a support case we have opened with Infoblox, they have determined that these excessive dhcp requests are increasing the number of dhcp leases in the database which causes the long restart. We have seen similar behavior with our wired clients but in lot smaller numbers. We’re a Cisco shop, using 8450 controllers, code version is 8.2.121 Attached is a Splunk search on one of the “misbehaving” clients’ MAC Any comments are appreciated. Atanas Atanasov Network Engineer Syracuse University <image003.png> ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss. ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/discuss.
