Hot answers tagged

8

There isn't an existing DHCP option for this, so you have to add custom configuration to both the server and clients in order to support this. On the server (/etc/dhcp/dhcpd.conf), define a new option and set the value: option resolv-options code 224 = text; option resolv-options "timeout:2 attempts:4"; On the client (/etc/dhcp/dhclient.conf), define the ...


7

It goes: CLIENT -> DHCPDISCOVER SERVER -> DHCPOFFER CLIENT -> DHCPREQUEST SERVER -> DHCPACK You you are missing the DHCPREQUEST before the DHCPACK in your description. If the client is on a different subnet than the DHCP server the DHCPOFFER is sent unicast to the DHCP-relay on port 67 UDP. The DHCP-relay agent broadcasts the DHCPOFFER to the ...


6

While product recommendations are off-topic for ServerFault and I expect your question to be closed by the community in short order, I can offer two suggestions: Limiting yourself to a GUI-based system is limiting your ability to implement the best solution for your situation. Perhaps a system with a GUI will work well, or perhaps not. In spite of the ...


6

As you discovered, you cannot declare hosts inside a class. The class declaration can only contain match or match if statements. If you want to group your client requests into classes using the class construct, you could do it something like this: class "MyHosts" { match hardware; } subclass "MyHosts" 1:10:bf:48:xx:xx:xx; # host2 subclass "MyHosts" ...


5

I've looked at this before. Restarting named will flush updated data from .jnl files back to the zone file, but there's also another way.. rndc freeze <zone> but this will disable DDNS, so it should be followed with a rndc thaw <zone> to re-enable it, and should clear up the .jnl files. There's apparently a rndc sync in Bind 9.9.


4

Had the same issue. Not seeing any DHCPACKs. Problem here was: disk full dhcpd could not write to /var/lib/dhcp/dhcpd.leases.


3

With bind 9.9, "rndc sync" is not enough; you also need the "-clean" flag: sync [-clean] [zone [class [view]]] Sync changes in the journal file for a dynamic zone to the master file. If the "-clean" option is specified, the journal file is also removed. If no zone is specified, then all zones are synced.


3

DHCP uses broadcast traffic for it's discovery process. Routers do NOT forward broadcast traffic. If your VM's on the "inside"/eth1 side of your router are getting leases from your modem/router on the "outside"/eth0 side then you have a bridge somewhere between the 2 networks; either your "router" is actually a bridge (do you have an interface called br0 or ...


3

I've seen this a few times and so far I've seen only two reasons: The IP address the DHCP server gave is already in use by another device. Usually you'd see a DHCPNAK though. Your firewall is accepting the traffic to the dhcp server, but not the traffic back Fortunately both should be easy to test. Ping the IP address and check relevant firewalls.


2

The dhcpd server will check for IPs by trying to ping the IP first, then assign the IP if it doesn't reply. If it does reply, it will mark the IP "abandoned". If a DHCP client tries to get an IP address, but none are available, but there are abandoned IP addresses, then the DHCP server will attempt to reclaim an abandoned IP address. If you have users still ...


2

It is not DHCP who can do this, but PXE. An example (not necessarily useful for you) dhcpd.conf file: allow booting; allow bootp; authoritative; default-lease-time 600; max-lease-time 7200; option domain-name "domain.com"; ddns-update-style none; log-facility local7; deny unknown-clients; subnet 192.168.124.0 netmask ...


2

I don't know your dhcpd.conf, but if you have an allow unknown-clients statement, you should add allow known-clients. If I recall correctly, the fixed IP should not be inside the range your DHCP-Server hands out to clients. When the host has an old address from the same DHCP-Server, the server may hand out the old lease as long as it is valid, i.e. lease ...


2

DHCP will generally keep the lease until the expiry time in an attempt to reissue the same lease to a client that reconnects later. It will only start to free up candidates when there is pressure on the scope from new clients. This allows clients to reacquire the same address when they connect again without too long an interval between sessions and gives ...


1

If it's possible, try to allow TCP traffic to apple.com and icloud.com. On my hotspot it prevents iPhone from thinking that it uses a hotspot. Hope it'll help you.


1

but the word "bios" doesn't even appear anywhere in in my dhcpd.conf, so where could that filename be coming from? It surely comes from a "second" PXE enabled DHCP server you have in your net... or /etc/dchpd.conf is not the conf file really driving your DHCP daemon. In these cases a Wireshark traffic capture can really help a lot.


1

You might have some other competing DHCP server in your net. Running a traffic capture with Wireshark can help you pinpointing this problem. BTW range dynamic-bootp 10.13.0.20 10.13.0.150; option routers 10.13.0.138; the router's IP is within the assignation range; not good.


1

cp /proc/PID/fd/3 /tmp/recovered_file Source: http://superuser.com/questions/283102/how-to-recover-deleted-file-if-it-is-still-opened-by-some-process If you have had dhcpd.conf file at Ext3/Ext4 filesystem you can try: extundelete --restore-file /path/name.conf /dev/sdXY Source: http://unix.stackexchange.com/a/122323/99517 Memory dump: gcore $pid


1

If you have restarted your DHCP server already after DHCPDARGS=eth1, but the issue still exists, you need to do something to find where the problem is. Check if DHCP is really running on eth0. E.g., with 'netstat -tulpn'. If it is still running on eth0 - there is a problem with configuration of DHCP server. If not, check on the VM, where it gets the IP ...


1

Assuming your question is, "how do i stop the conflict?", simply up the start IP of the range, and put the static IPs below this, i.e. range 192.168.2.20 192.168.2.254; and then 192.168.2.1 -> 192.168.2.19 are free for statics. Obviously, you'll have to adjust your statics to fit this partitioning. EDIT: After RTFM'ing a bit, according to dhcpd manuals ...


1

This error occurs because scope options need to be defined in the top level of the configuration and not within any code block like a group: #This needs to be defined outside of any code block option space MSFT; option MSFT.nbt code 1 = unsigned integer 32;


1

There is no explicit mention anywhere in the dhcpd.conf man page (and I can't try it now), but I always assumed that there is only one statement allowed per line. host blah { hardware ethernet <mac address>; fixed-address <ip address>; }


1

I've found a good solution. I just put our Wifi devices on a different VLAN, so that I could configure a different dynamic DNS domain for that subnet. So now a reverse lookup for a wifi client IP returns <hostname>.wifi.lan, and a wired client returns <hostname>.office.lan.


1

In the end we figured out the best way to do this is to configured DHCPD to assign static IP based on device mac address. We control the devices that connect to these networks and there are only a limited number of them so this solution works for us. It is a bit of extra work but adds some security as well.


1

If I correctly understood, to make a static lease you have something like this in your config: host static-1 { hardware ethernet 00:01:02:03:04:05; fixed-address 192.168.1.40; } This will work as you expect, but will never release this IP-address (it does not matter if client send DHCPRELEASE or not) - because it is STATIC IP from dhcpd's point of ...


1

DHCPD is not pushing updates to BIND because it does not know what DNS name to update since no DDNS hostname is defined.


1

You are not detailing your OS so I'm assuming Linux. dhcpd does not appear to have an option or parameter for customizing the ddns server port, at least it's not in any man page I have seen. An option therefore could be to use iptables (or whatever firewall you have) to rewrite outbound packets to your dns server udp/53 or tcp/53, to the port it is really ...


1

It's not clear to me if your DMZ DHCP clients are getting addresses from the DHCP server. If they are not, have you confirmed with the Packet Capture Wizard, not sure if you have it in ASDM 5.2, that the DHCP discovery is arriving to the ASA? It will look something like 0.0.0.0.68 -> 255.255.255.255.67. I believe you will need at least UDP port 67 ...


1

Few (unrelated) points: - Look closely at the license - with most basic license you will see 'DMZ interface' in output of show ver , it means DMZ interface will be able to communicate ONLY with 'outside' destinations, not with other internal networks - Have you looked at inspection ? It greatly depends on ASA OS version , but under default class-map where ...


1

While what you're seeing is correct behavior, your best option will probably be either to change the client identifier in the device, or its MAC address. If the server receives a DHCPDISCOVER with the same MAC and client identifier, what other method will it have to differentiate between the machines? On the server side you can check and see what the ...



Only top voted, non community-wiki answers of a minimum length are eligible