We have a completely different configuration, but for what it's worth, we
are using WISM 4.0.055, CCA 3.62 (virtual gateway mode), and DHCP
externally on a Win2k server box.  Other than having to allow port 67
traffic explicitly in CCA we had no problems.

Mark

>Not to continue beating a dead horse here,
> 
>Just more info.
> 
>We've only mentioned CCA 4.0.2 and WISM 4.0
> 
>This would happen with WISM 3.x as well?  (Just verifying)
>
>
>
>
>---------------------------------------------------------------------------From:
>Perfigo SecureSmart and CleanMachines Discussion List
>[mailto:[log in to unmask]] On Behalf Of Ryan Dorman
>Sent: Tuesday, August 15, 2006 8:00 AM
>To: [log in to unmask]
>Subject: Re: WISM and CCA
>
>
>Mike-
>
>Since the WiSM uses Airespace software you may run into the same issue I
>had.  It would crop up if you were using WiSM merely as a wireless
>pass-through and CCA for DHCP and Auth. The Airespace would drop CCA DHCP
>packets as malformed due to a change in how CCA sends back the IP of the
>DHCP server to clients. Here is procedure from my email a couple weeks
>ago I had to perform in order to correct the problem
>
>Login to the web console on the CAM
>
>Device Management --> CCA Servers
>Click the Manage link for the CAS in question
>Network --> DHCP --> Global Options
>
>Click "Enable" to allow User-Specified DHCP Options
>Click "New Option" under Root Global DHCP Option
>
>Type 54 under the ID field NOT the Option# field
>Change the type to IP-Address
>Click "Create Custom Option"
>
>In the next screen enter the eth1 (Untrusted) IP into the field and click
>"Update"
>
>You should then return to the DHCP options screen and see your new
>option.  You can also see it reflected in the /etc/dhcpd.conf file on the
>CAS.
>
>As an aside, in the midst of doing all of this (and I was changing
>settings _all over_) the wired portions of ResNet fell apart as well.  I
>don't think  they are related but I'll describe it anyway. Our ResNet
>works like this (for now, I have 150 new switches to be deployed in the
>next 3 weeks.. Joy..)
>
>35xxXL --GigaStack--> 2900XL --100BaseFX--> 4503 --Gig Trunk--> 3550-12T
>--> CCA --> 3550-12T (Same one) --> Firewall Cluster
>
>The link between the 4503 and the 3550-12T that caries untrusted traffic
>from the dorms to the CCA system up and displayed the following message
>in the middle of all my troubleshooting:
>
>%SW_VLAN-4-VTP_USER_NOTIFICATION: VTP protocol user notification: Version
>1 device detected on Gi1/2 after grace period has ended
>
>I of course, noticed wireless was back up and high tailed it home only to
>come into a completely broken ResNet (but working wireless!) this
>morning.  The 3550 runs in VTP transparent mode and the 4503 is the VTP
>server for the ResNet domain.  Both sides showed version 2 in their 'sh
>vtp status' ::shrug::  I put 'switchport nonegotiate' on both sides of
>the link, bounced them and then the VLAN's unpruned themselves.  Like I
>said, I don't think the problems are related but the timing is
>interesting.
>
>-- 
>Ryan Dorman, CCNP
>Network Engineering Specialist
>Millersville University
>717.871.5883
>
>
>On 8/14/06 6:38 PM, "King, Michael" <[log in to unmask]> wrote:
>
> 
>
>I felt I should ask before I upgrade.
>
>I've got a few WiSM's, running 3.2 code.  And CCA running 4.0.0 in Real
>lP Gateway Mode.
>
>I've seen a few messages on the list about how WISM's (in particular)
>Controllers on Release 4.0 and CCA 4.0 have had some problems.
>
>I'm getting ready to take the Wism to 4.0.155.5 code. (Lastest as of a
>last week)
>
>What should I expect to happen.  What should I need to do?  (Ideally,
>nothing, but that doesn't seem to be the case so far)
>
>Mike
>
>
>
>