887VAW dhcp server not working for wireless clients

[ciscojbird]

Hello,

Reposted from Getting Started with Wireless:

https://supportforums.cisco.com/discussion/13152826/887vaw-dhcp-server-not-working-wireless-clients

I have tried to setup a 887VAW to have two vlans (USERS and MGMT) with both wired and wireless clients in each. I want the embedded switch to act as the dhcp server for both wired and wireless clients connecting on either network.

When I connect wired clients, the dhcp server issues an address, however, when I connect a wireless client, the dhcp server does not issue an address, and I end up with a 169.* address. If I configure a static ip address on a wireless client connected to either network, I can't ping the gateway from the client, but I can see the MAC and the statically configured ip address of the client in the output of show dot11 associations on the access point.

I've attached my configuration files. Can anybody see what I've done wrong?

Thanks.

[ciscojbird]

Anyone?

[ciscojbird]

Hello,

I thought I'd put some more information relating to the problem here:

If I do "show ip bindings" I can see the MAC address of my wireless NIC come up, so I think the DHCPDISCOVER messages must be getting through to the server, but the DHCPOFFER messages are not getting back to the client.

I don't know how to debug using debug DHCP. I can enter "debug dhcp detail" and I get "DHCP client activity debugging is on", however, I cannot see any output when I renew the DHCP lease on my laptop.

I am using "show version" = Cisco IOS Software, C800 Software (C800-UNIVERSALK9-M), Version 15.2(4)M3, RELEASE SOFTWARE (fc2)

I thought the DHCP debug messages might be hidden due to the logging console level, but having set that to "logging console 7" there are no dhcp debug messages that come up!

Other debugging I have tried is as follows:

show arp - I can see wireless client NIC MAC addresses

show mac-address-table - I can see wireless client NIC MAC addresses

show dhcp bindings - I can see wireless client NIC MAC addresses

But the wireless clients themselves just timeout and take on a 169.* address.

[ciscojbird]

Hello,

I managed to find how to debug - "debug ip dhcp server packet". Here's the output:

*Nov  8 07:22:37.428: DHCPD: client's VPN is .
*Nov  8 07:22:37.428: DHCPD: No option 125
*Nov  8 07:22:37.428: DHCPD: DHCPDISCOVER received from client 01b8.27eb.b8b7.8c on interface Vlan10.
*Nov  8 07:22:37.428: DHCPD: Sending DHCPOFFER to client 01b8.27eb.b8b7.8c (10.0.0.39).
*Nov  8 07:22:37.428: DHCPD: no option 125
*Nov  8 07:22:37.428: DHCPD: broadcasting BOOTREPLY to client b827.ebb8.b78c.
R1#
*Nov  8 07:22:58.376: DHCPD: client's VPN is .
*Nov  8 07:22:58.376: DHCPD: No option 125
*Nov  8 07:22:58.376: DHCPD: DHCPDISCOVER received from client b827.ebb8.b78c on interface Vlan10.
*Nov  8 07:22:58.376: DHCPD: Sending DHCPOFFER to client b827.ebb8.b78c (10.0.0.51).
*Nov  8 07:22:58.376: DHCPD: no option 125
*Nov  8 07:22:58.376: DHCPD: ARP entry exists (10.0.0.51, b827.ebb8.b78c).
*Nov  8 07:22:58.376: DHCPD: unicasting BOOTREPLY to client b827.ebb8.b78c (10.0.0.51).

This seems to confirm my earlier suspicion that the DHCPOFFER is not getting to the clients. Does this help anyone to assist?

[ciscojbird]

Hello again,

After further attempts, I have found that a windows client will work, but a Linux/MacOS client will not!

I read somewhere that the native VLAN has to be associated with the bridge-group 1 so I changed the VLAN assignments so the 10 = MGMT and 20 = USERS, so that the native VLAN and VLAN 10 could be on bridge-group 1. I also changed the networks around so the third octet matches the VLAN number. I've uploaded updated configs. These changes shouldn't have any effect on the observed problem though.

Here's the DHCP debug output when a windows client attempts to retrieve an address:

When Associating to USERS

*Nov  9 04:32:40.291: DHCPD: client's VPN is .
*Nov  9 04:32:40.291: DHCPD: No option 125
*Nov  9 04:32:40.291: DHCPD: DHCPREQUEST received from client 01e8.2aea.4f9e.7b.
*Nov  9 04:32:40.291: DHCPD: Appending system default domain
*Nov  9 04:32:40.291: DHCPD: Using hostname '<DEL>.yourdomain.com.' for dynamic update (from FQDN option)
*Nov  9 04:32:40.291: DHCPD: Sending DHCPACK to client 01e8.2aea.4f9e.7b (10.0.20.5).
*Nov  9 04:32:40.291: DHCPD: no option 125
*Nov  9 04:32:40.291: DHCPD: ARP entry exists (10.0.20.5, e82a.ea4f.9e7b).
*Nov  9 04:32:40.291: DHCPD: unicasting BOOTREPLY to client e82a.ea4f.9e7b (10.0.20.5).

When associating to MGMT:

*Nov  9 04:37:09.864: DHCPD: DHCPREQUEST received from client 01e8.2aea.4f9e.7b.
*Nov  9 04:37:09.864: DHCPD: Appending system default domain
*Nov  9 04:37:09.864: DHCPD: Using hostname '<DEL>.yourdomain.com.' for dynamic update (from FQDN option)
*Nov  9 04:37:09.864: DHCPD: Sending DHCPACK to client 01e8.2aea.4f9e.7b (10.0.10.53).
*Nov  9 04:37:09.864: DHCPD: no option 125
*Nov  9 04:37:09.864: DHCPD: ARP entry exists (10.0.10.53, e82a.ea4f.9e7b).
*Nov  9 04:37:09.864: DHCPD: unicasting BOOTREPLY to client e82a.ea4f.9e7b (10.0.10.53).

Why the difference??