Wireless Access

 View Only
last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

DHCP DENY in a legacy system

This thread has been viewed 2 times
  • 1.  DHCP DENY in a legacy system

    Posted Mar 05, 2018 06:28 PM

    Hey there!

     

    I have a legacy system that I'm trying to retrofit and upgrade to a new system. Unfortunately, the devices that are connecting to this network cannot be reprogrammed to connect to a different IP/Hostname. 

     

    The original design had these old falcon scanners that connect to an ssid, obtain a dhcp lease, and then connect to the machine hosting the application. Works great. The machine is linux with a second interface which runs dhcpd, has the ip address of 10.10.0.1 and the dhcp server issues out a /24 block. To provide wireless connectivity, I use WRT54G in bridge mode. Works great.

     

    The hybrid system brings the linux host into my data center and uses AP93/105 in RAP mode to connect the SSID to the VLAN that is attached to the second interface on the linux host. Each site has its' own linux box in the DC, and the interface that the scanner uses to connect is on its' own vlan. DHCPD is still providing the DHCP lease. I've split up the range into a bunch of /27's and issued a seperate range to each site. Everything works except when the scanning device goes to sleep and powers back up. It goes to request an IP address, DHCPD gives it its' old IP and it gives a DHCPD deny forcing the DHCPD server to issue a new one. Our easy fix for this is to hard restart the scanner. Some people are finding this fix extremely inconveinent and I need to get a real fix in place until we can convert all of the sites to new scanning devices which use the native DHCP server on the Aruba Controller with a seperate hostname for each of the sites linux boxes.

     

    I think this might be a problem with ARP but I'm not certain.

     

    How would I go about diagnosing this? I have pcaps of the DHCP conversation that shows this happening, and I also have a pcap of the original architecture where it works. I will post them in another comment when I locate where I put them.

     

     

    Thanks!



  • 2.  RE: DHCP DENY in a legacy system

    Posted Mar 06, 2018 01:32 PM

    @tealethetoolmanwrote:

    Hey there!

     

    I have a legacy system that I'm trying to retrofit and upgrade to a new system. Unfortunately, the devices that are connecting to this network cannot be reprogrammed to connect to a different IP/Hostname. 

     

    The original design had these old falcon scanners that connect to an ssid, obtain a dhcp lease, and then connect to the machine hosting the application. Works great. The machine is linux with a second interface which runs dhcpd, has the ip address of 10.10.0.1 and the dhcp server issues out a /24 block. To provide wireless connectivity, I use WRT54G in bridge mode. Works great.

     

    The hybrid system brings the linux host into my data center and uses AP93/105 in RAP mode to connect the SSID to the VLAN that is attached to the second interface on the linux host. Each site has its' own linux box in the DC, and the interface that the scanner uses to connect is on its' own vlan. DHCPD is still providing the DHCP lease. I've split up the range into a bunch of /27's and issued a seperate range to each site. Everything works except when the scanning device goes to sleep and powers back up. It goes to request an IP address, DHCPD gives it its' old IP and it gives a DHCPD deny forcing the DHCPD server to issue a new one. Our easy fix for this is to hard restart the scanner. Some people are finding this fix extremely inconveinent and I need to get a real fix in place until we can convert all of the sites to new scanning devices which use the native DHCP server on the Aruba Controller with a seperate hostname for each of the sites linux boxes.

     

    I think this might be a problem with ARP but I'm not certain.

     

    How would I go about diagnosing this? I have pcaps of the DHCP conversation that shows this happening, and I also have a pcap of the original architecture where it works. I will post them in another comment when I locate where I put them.

     

     

    Thanks!


    I think you are on the right-track. What do the ARP Packets look like prior to the "DHCP Decline" - that could indicate the cause of the declines?