Centos 5.2 DHCPD Issue with certain MAC's

I have a Arris CMTS 1000; with a new Centos 5.2 DHCPD (3.04) server.  I am trying despirately to hand out IP's to cable modems and there are three different MAC subsets that refuse to bind.  There was on the old server (which crashed) some type of "wildcard" and I can not figure this out...
The MAC's starting with 00:10:95, 00:90:64 and 00:11:e3; get the DHCP lease from the server but will not bind; however the 00:50:da, and some others have no problem.
CMTS OUTPUT---------------------------START
 1    2   00:0f:9f:57:8a:2a DHCP OFFER                    0.0.0.0         1729
 2    2   00:10:95:5c:c3:06 DHCP ACK                      0.0.0.0         1730
 3    2   00:10:95:5e:1f:7e DHCP ACK                      0.0.0.0         1744
 5    2   00:90:64:98:0f:6a DHCP OFFER                    0.0.0.0         1752
 6    2   00:10:95:28:99:f3 DHCP ACK                      0.0.0.0         1745
 9    2   00:50:04:a5:3f:32 Registered                    172.17.5.247    1737
 10   2   00:50:da:9d:29:92 Registered                    172.17.5.246    1738
 12   2   00:90:64:ee:4a:17 DHCP OFFER                    0.0.0.0         1748
 13   2   00:50:da:9c:83:74 Registered                    172.17.5.243    1749
 14   2   00:50:da:9e:64:e8 Registered                    172.17.5.242    1750
 15   2   00:11:e3:7f:20:66 DHCP OFFER                    0.0.0.0         1751
 16   2   00:50:04:a6:4e:28 Registered                    172.17.5.240    1753
 17   2   00:50:da:9c:88:bc Registered                    172.17.5.239    1754
 18   2   00:50:da:a0:1e:58 Registered                    172.17.5.238    1755
 19   2   00:90:64:95:b3:da DHCP OFFER                    0.0.0.0         1756
CMTS OUTPUT----------------------------END
 
filename "15.bin";
authoritative;
allow unknown-clients;
option domain-name "domain.com";
option domain-name-servers 208.67.222.222, 208.67.220.220;
option subnet-mask 255.255.255.0;
option broadcast-address 172.17.5.255;
default-lease-time 14400;
max-lease-time 172800;
ddns-update-style none;
allow client-updates;
# file for the cable modems
# filename "/LCN_DATA/15.bin";
shared-network Inside {
	allow client-updates;
	allow unknown-clients;
	authoritative;
	filename "15.bin";
	subnet 64.207.54.0 netmask 255.255.255.248 {
		authoritative;
		filename "15.bin";
		}
	# Cable Modems
	subnet 172.17.0.0 netmask 255.255.0.0 {
		allow client-updates;
		allow unknown-clients;
		authoritative;
		filename "15.bin";
		option routers 172.17.0.1;
		range 172.17.5.128 172.17.5.254;
		pool {
			allow unknown-clients;
			filename "15.bin";
			range dynamic-bootp 172.17.5.128 172.17.5.150;
			}
		}
	# test1
	host test1 {
		allow unknown-clients;
		filename "15.bin";
		hardware ethernet 00:10:95:5e:1f:7e;
		fixed-address 172.17.5.99;
		}
	}

Open in new window

tmcarter3Asked:
Who is Participating?
 
tmcarter3Author Commented:
No the issue was the logging option was defaulted and not specifically listed.  Once enabled the modems started working.
0
 
gheistCommented:
It boils down to particular type of network adapters not connecting to cable modem's ethernet port.
http://standards.ieee.org/regauth/oui/oui.txt
0
 
tmcarter3Author Commented:
Great.. I understand that.... but my question is what and how do I fix this?
0
Protect Your Employees from Wi-Fi Threats

As Wi-Fi growth and popularity continues to climb, not everyone understands the risks that come with connecting to public Wi-Fi or even offering Wi-Fi to employees, visitors and guests. Download the resource kit to make sure your safe wherever business takes you!

 
gheistCommented:
It is physical interface - Layer 1 problem involving electrical circuitry between cable modem and customers netcard.
Most straightforward fix is cable modem firmware update, if release notes mention something about ethernet auto-negotiation, MDI-X and things like that.
There is nothing your customer is able to do to fix given they do not have internet connection.
0
 
tmcarter3Author Commented:
No.. Sorry, but I think your wrong...
This was working fine on the previous DHCP server with some wildcard issue;   This IP is for the Cable Modem; not the customers computer equipiment...
0
 
gheistCommented:
You can try different network card, maybe current driver is bad.
Or CentOS5
or up2date

it is definetly lowlevel frame loss, hard to trace etc.
maybe ethtool can disable udp/tcp checksumming - I am out of ideas

let tcpdump run for an hour n interface not doung checksumming, then load report into wireshark and have a look

tcpdump -s 1600 -w outfile.log -i eth0

or like that

0
 
lanboyoCommented:
Maybe some of the cable modems are too stupid to understand dhcp and need the old bootp. Which are really similiar...

add the" allow bootp"  directive to the configuration block for the subnet containing the client and restart dhcpd.

Failing that install boopd on the box.

Good luck and remember to take a shower tonight.
0
 
tmcarter3Author Commented:
The problem was two fold...

1.  The cable plant operator had NO equipment to analyze the incoming signal.
2.  The ISC DHCP option were default on most options.  I specifically designated the TOD and Logging servers and they came up; but only after thecable plant operator cleaned up the signal at the ingress port.

Thanks!
0
 
gheistCommented:
So it was physical interface problem far outside DHCP server....
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.