Controllerless Networks

Okay, I am seeing something very weird.  I a standalone IAP (no other IAP on the network) with a DHCP server running on it: 192.168.22.x subnet.

Client is wired to the network and is turned on (has the WLAN interface turned on at the same time as the ETH interface).

I see a DHCP exchange on the AP and the client recieves the address of 192.168.22.228 (timestamp of Feb 15 11:00:21 2017)

Feb 15 11:00:21 2017 192.168.4.30 <192.168.4.30 F0:5C:19:C2:AE:36> dnsmasq-dhcp[14413]: DHCPACK(br0) 192.168.22.228 00:0e:8e:38:5d:aa E0027
Feb 15 11:00:21 2017 192.168.4.30 <192.168.4.30 F0:5C:19:C2:AE:36> dnsmasq[14413]: dhcp_reply 1485: magic vlan user add (0 192.168.22.228 00:0e:8e:38:5d:aa 1 18 0.0.0.0 0.0.0.0 255.255.255.0)

However, the client table (show clients via the CLI) shows an IP address of 0.0.0.0 (still on the wire)

The client is removed from the wired connection at Feb 15 11:01:08 (client logs), but is unreachable as it has a 0.0.0.0 IP address.

We let the client sit for a few minutes and then reboot the client at Feb 15 11:04:55 2017.  The AP logs shows the client dissociating as expected.

When the client reconnects, we see another successful DHCP exchange, but this time the user IP address gets properly written.  Now the "show clients" table properly shows an IP address of 192.168.22.228

Feb 15 11:05:10 2017 192.168.4.30 <192.168.4.30 F0:5C:19:C2:AE:36> dnsmasq-dhcp[14413]: DHCPACK(br0) 192.168.22.228 00:0e:8e:38:5d:aa E0027
Feb 15 11:05:10 2017 192.168.4.30 <192.168.4.30 F0:5C:19:C2:AE:36> dnsmasq[14413]: dhcp_reply 1485: magic vlan user add (0 192.168.22.228 00:0e:8e:38:5d:aa 1 18 0.0.0.0 0.0.0.0 255.255.255.0)
Feb 15 11:05:17 2017 192.168.4.30 stm[3395]: <304008> <DBUG> <192.168.4.30 F0:5C:19:C2:AE:36> |ap| user ip:192.168.22.228 mac:00:0e:8e:38:5d:aa

Is there something up with the routing on the AP or Client side that affects whether a 0.0.0.0 address or the correct DHCP address is added to the client table based on if the client is also in a wired state?

Full logs related to the client are attached.

Attachment(s)

IPAddressIssue.txt   16 KB 1 version

When you say "client wired to the network" is it wired or wireless?  If it is wired, where is it connected?  Diagram please..

I apologize for the late reply.  It looks like this is a problem with how the client is routing their traffic.

To clarify to Joseph.

The client in this case is on a wired interface, but turned off.  The device is turned on and both the wired and wireless interfaces are on at the same time.  The client would be connected to wired port on one subnet (192.168.5.x) and then connect to an AP that is on a different subnet (192.168.22.x).

Some of the time (around 20%), we would see two sets up DHCP exchanges over the wired port; one from the client wired interface IP MAC Address and one from the wireless interface MAC address.

When this happened, the packet capture showed the wireless DHCP exchange on the wired with a source address of either 0.0.0.0 or a 192.168.5.x address (IP address of the eth port), which would be shown in the IP client table.  

We would see a response from the AP over the wire trying to communicate to a 192.168.22.x IP address following the same route as the inital DHCP Discover.

It doesn't make a bit of sense to me and I'm not quite sure how, but the client device looks to have a timing or race condition issue where some of the time, they route their wireless traffic over the wired port at the same time that they are initiating a wired interface DHCP.

Manufacturer of the client device came back to us with a firmware fix for the issue and we haven't seen the problem popup.

I was just utterly confused as to what was happening and it seems like there was a fix in place on the client side.