Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Many dhclient[#####]: DHCPREQUEST entries in logs - explanation?

    Scheduled Pinned Locked Moved DHCP and DNS
    1 Posts 1 Posters 896 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • S Offline
      sully
      last edited by

      Hello.

      Today I switched from DSL after many years to cable internet. I am now using DHCP on the wan interface which is new to me, I've been static or pppoe in the past.

      As I am watching the logs, I see a great number of this entry

      Jan 3 00:30:19	dhclient[47188]: DHCPREQUEST on fxp0 to 255.255.255.255 port 67
      Jan 3 00:29:34	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      Jan 3 00:28:39	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      Jan 3 00:28:14	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      Jan 3 00:27:06	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      Jan 3 00:25:53	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      Jan 3 00:23:33	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      Jan 3 00:20:56	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      Jan 3 00:18:07	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      Jan 3 00:11:41	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      Jan 3 00:07:51	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      Jan 3 00:05:01	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      Jan 3 00:02:33	dhclient[47188]: DHCPREQUEST on fxp0 to 172.18.131.22 port 67
      

      I was under the assumption a 172.18. was a private segment like 192.168 is. Why is it showing this? The wan interface is continually asking for an address from the modem? But it already has one.

      I see this chunk of code

      dhclient[66107]: bound to 184.x.x.x -- renewal in 10800 seconds.
      Jan 2 15:03:54	dhclient: Creating resolv.conf
      Jan 2 15:03:54	dhclient: /sbin/route add default 184.x.x.1
      Jan 2 15:03:54	dhclient: Adding new routes to interface: fxp0
      Jan 2 15:03:54	dhclient: New Routers (fxp0): 184.x.x.1
      Jan 2 15:03:54	dhclient: New Broadcast Address (fxp0): 255.255.255.255
      Jan 2 15:03:54	dhclient: New Subnet Mask (fxp0): 255.255.252.0
      Jan 2 15:03:54	dhclient: New IP Address (fxp0): 184.x.x.x
      Jan 2 15:03:54	dhclient: ifconfig fxp0 inet 184.x.x.x netmask 255.255.252.0 broadcast 255.255.255.255
      Jan 2 15:03:54	dhclient: Starting add_new_address()
      Jan 2 15:03:54	dhclient: Comparing IPs: Old: New: 184.x.x.x
      Jan 2 15:03:54	dhclient: Starting delete_old_states()
      Jan 2 15:03:54	dhclient: REBOOT
      Jan 2 15:03:54	dhclient[66107]: DHCPACK from 69.x.x.x
      Jan 2 15:03:53	dhclient[66107]: DHCPREQUEST on fxp0 to 255.255.255.255 port 67
      

      Am I correct that the first request is udp to port 67, and a respons initiates the ip address lease from the modem? Once the address is assigned pfsense sets the subnet and routes (gateway). Then after 10800 seconds it will check and see if lease is up or something of that nature?

      Shouldn't I expect to see some logs then after the expiration of 10800 seconds, not hundreds and hundreds constantly? And shouldn't the dchp requests or acks be going to the 69.x.x.x address rather than 172.18?

      Happy to provide more info if needed, but this is new stuff to me, so not sure exactly what I would need to provide. And it might be normal, but it sure looks like something is seeking resolution and not getting an answer.

      Perhaps there is something about cable modems that I don't understand? Do they behave differently than a dsl modem? I've always had modems that were bridges really. Some had routers in them but I disabled that part and used pfsense instead.

      1 Reply Last reply Reply Quote 0
      • First post
        Last post
      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.