Dhcpleases: bad name …



  • I'm getting "dhcpleases: bad name in /var/dhcpd/var/db/dhcpd.leases" messages flooding my syslog file.  Here is what I find in the leases file referenced in the error message above:

    The format of this file is documented in the dhcpd.leases(5) manual page.

    This lease file was written by isc-dhcp-4.2.4-P2

    lease 10.0.1.21 {
      starts 0 2012/09/23 00:43:20;
      ends 1 2012/09/24 00:43:20;
      tstp 1 2012/09/24 00:43:20;
      cltt 0 2012/09/23 00:43:20;
      binding state active;
      next binding state free;
      rewind binding state free;
      hardware ethernet 00:0b:86:29:28:27;
      uid "\001\000\013\206i\030r";
      client-hostname "00:0b:86:29:28:27";
    }

    Why is the client-hostname in the entry above showing up as the mac address?  That isn't a valid hostname.  What would cause this?

    Thanks,
    David/Treffin



  • Hm, the hostname is what is sent by the client in its DHCP request. What's the client that's sending that? Never seen any OS or device that does that.



  • It's an Aruba AP RAP-5WN that my company sent out to me.  It extends the wireless lan from corporate, to my house/home office.  It has 4 ports on it and one of them is active for use with an Avaya VOIP phone.  That friggin thing has anywhere from 60-200pps worth of traffic in/out at all times.  That's why I'm putting it into a DMZ.  As I don't know why any traffic not intended for devices on my network (my macbook pro or my voip phone) would be getting piped down the tunnel to my access point.  I've sent them RRD graphs showing the traffic patterns and opened several tickets on this, but no changes yet on the corporate side of the pipe to keep that traffic from being sent my direction.

    As I have no access into the thing, I'm certainly not going to give it free reign to snoop my office, test lab or IPsec networks here at home.  I haven't ever seen a mac being sent as a hostname –at least not without the ":"'s removed.

    A little about me, just so you know where I stand:
    I have to deal with this stuff all day long in my normal job.  I'm responsible for DHCP and DNS migrations/deployments for a number of very large fortune 100 companies on any given day/week.  But I have a load of diagnostic tools and analysis stuff that I can work with via API calls to the equipment that I deploy and to which I migrate these large scale environments.  When I come home, I am usually so burned out that I don't even wanna see this stuff much less troubleshoot it.

    And while I am quite familiar with ISC DHCPd, BIND, Infoblox, MetaInfo, MSDNS/DHCP, QIP, etc., there are things available on those that I would have to configure manually in pfSense and truthfully I just don't care that much.  When I have to do this stuff on weekends too, instead of spending time on my Ducati it makes things even uglier.

    That said, the pfSense product ROCKS.  I was referred by some of my engineer friends in DC while looking for a Pix replacement.  I've been running it for over a year now and it has been solid.  But...as I am heavily into IPv6 and am a NANOG/ARIN member/attendee, the v6 bump in the new beta code was of critical interest to me.  Thus my reason for using the beta stuff.

    Sorry for the extra diatribe but just felt like typing for once.

    David



  • One more thing…I did manage to kill the symptom by configuring a static reservation on the opt2 dhcp config.  That forced the unit to get an address and use the name that I had assigned to it.  After stopping the service, killing the dhcpd.leases file and restarting the service with the new host reservation, it doesn't seem to be killing my syslog file any longer.  But as I said, I resolved what would be a "symptom" of the actual problem.

    Most DHCP servers implementations with which I work on a regular basis have a method of generating a client hostname if none is returned by the client.  If that doesn't exist, some of those implementations will build a hostname out of the mac address by removing the ":" and either replacing that with "-" or nothing at all.  This, combined with some bounds checking on the hostname returned by the client, would likely resolve the problem going forward.  I haven't dealt with the "dhcpleases" issue before in any of the commercial stuff before.  Most of that is obscured by WebUI or API and I don't have to go to the actual process level on the boxes.  Sorry I can't be of much more help here.

    David


Locked