On 5/15/19 1:25 AM, Geert Stappers wrote:
Share that dhcp-host lines with your audience here.
Make it possible that they can verify how far they match
From my /etc/dnsmasq/dhcp-lana.hosts file, in which all lines are
comments beginning with #, whitespace, or lines which resemble the
Again, these lines match incomming requests, and send dhcp offers just
fine. I have tried alternate formatting, which included tag sets which
then attempted to use dhcp-option and dhcp-option-force. No combination
I have tried will send a hostname to a client that included a hostname
in its request to dnsmasq.
Put a netwerk capture in libpcap format on-line and provide the URL to wget it.
I would like to see what goes over the wire.
What goes over the wire, according to wireshark, using a capture filter
of "port 67 or 68" on the interface in question, is a valid dhcp
discover, offer, request, ack sequence, that includes the following dhcp
options in the Offer and ACK packets from dnsmasq -> the clients, in the
| Option: (53) DHCP Message Type
| Option: (54) DHCP Server Identifier ( ip address )
| Option: (51) IP Address Lease Time
| Option: (58) Renewal Time Value
| Option: (59) Rebinding Time Value
| Option: (66) TFTP Server Name
| Option: (42) Network Time Protocol Servers
| Option: (15) Domain Name
| Option: (6) Domain Name Server
| Option: (3) Router
| Option: (1) Subnet Mask (255.255.255.0)
| Option: (255) End
If you wish to recreate the problem I am having in more detail for some
reason, all you need do is have a dhcp client send option 12 Host Name
to dnsmasq and attempt to configure dnsmasq to send a response with a
different host name and capture the packets.
Yes, that is your problem^Wchallenge. I'm interrested in knowing
how far it a dnsmasq problem is.
The following thread is the one I referenced earlier, which contains the
following comment from Simon:
| option 12 in DHCP replies will be sent only if option 12 appears in the
My clients, which are the spa3000 telephone adapter boxes running
embedded firmware which I don't have access to, *do not request option
12* in the parameter request list, but do send an option 12 hostname
announcing the name they think they have to dnsmasq.
Hopefully this is enough information such that the problem can be
recreated and tested on other members systems with minimal interruption
to their configurations if they are interested.
Dnsmasq-discuss mailing list