We have 16 controllers also on 4.2.130.0 and so far so good. We have seen a couple of DHCP issues as you mentioned, but our workaround was to turn the DHCP assignment requirement off for right now.
Hector Louisiana State University -----Original Message----- From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto:[EMAIL PROTECTED] On Behalf Of Charles Spurgeon Sent: Tuesday, July 22, 2008 10:18 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] WiSM Code 4.2.130 (MR2) - in use? On Mon, Jun 09, 2008 at 10:16:07AM -0400, Lee H Badman wrote: > > Has anyone in the WiSM community gone to 4.2.130 which is Cisco's MR2 > for 4.2 yet? Any issues? FYI - status report on our 4.2.130.0 rollout, for those running Cisco gear. We have 10 WLCs with 1,251 APs on them upgraded to 4.2.130.0 so far, with another 10 WLCs and 1,100 APs left to do. So far so good, with the exception of the DHCP bug. After moving to 4.2.130.0 we had an intermittent problem with DHCP that was hard to debug, in which some clients would occasionally have problems getting an address. When the problem occurs the client doesn't see a DHCP response and reverts to the private address (169.254.n.n). If you left certain clients alone then they would sometimes pick up a DHCP address after a couple of minutes and work OK (Win XP). At least one Mac user reported that they had to disable/re-enable their wireless int to make things work after DHCP failed. The problem was traced to a bug that was first found in 4.2.112.0 and is present in 4.2.130.0. Cisco bugID: CSCsq23961. The bug occurs in interaction with "ping before reply" which our ISC DHCP server does as a check before responding with an address. The bug causes the WLC to stop forwarding DHCP traffic after the ping happens. We have DHCP proxying and enforcement configured on the WLCs ("DHCP Addr Assignment Required" in the Web GUI). There's a workaround described in the bugID that consists of putting a fake DHCP config into the WLC, apparently causing it to use a different code path and avoiding the bug. We've applied the workaround and it appears to be working in our environment and has fixed the problem on the clients we were using in our tests. -Charles Charles E. Spurgeon / UTnet UT Austin ITS / Networking [EMAIL PROTECTED] / 512.475.9265 ********** 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/.
