[Dnsmasq-discuss] Option 12 hostname sent to RPi seems incorrect

Shrenik Bhura shrenik.bhura at gmail.com
Mon Oct 25 14:00:27 UTC 2021

On Mon, 25 Oct, 2021, 01:24 Matthias May via Dnsmasq-discuss, <
dnsmasq-discuss at lists.thekelleys.org.uk> wrote:

> On 21/10/2021 13:05, Shrenik Bhura wrote:
> > May be the code that logs this line needs to be checked if it is just
> printing part of the complete hostname i.e. IP
> > address.
> >
> Hi Shrenik
> The code is doing what it is supposed to do.
> Please take a look at the definition of a hostname and what makes up an
> * https://en.wikipedia.org/wiki/Hostname
> * https://en.wikipedia.org/wiki/Fully_qualified_domain_name
> Valid characters for hostnames are:
> * ASCII(7) letters from a to z
> * The digits from 0 to 9
> * The hyphen (-)
> * A hostname may not start with a hyphen
> * When following the old RFC 952, a hostname may not start with a digit.
> The dot '.' is used to concatenate the different domain labels.
> In your case you are using an IP address as hostname which is not a valid
> hostname.
> The first dot in the name you provide is interpreted as domain label
> separator, thus the hostname is 192.

> BR
> Matthias

Hi All,

Clarifying on the last two posts -

> In your case you are using an IP address as hostname which is not a valid

> the problem here is the client looks to be misconfigured if it is telling
server its name is an IP address... they are very different...

No, I am not using such an IP address anywhere as a hostname.
Nothing on the server is configured to set the same.
The Raspberry Pi client is netbooting, so nothing on the client side could
be setting it.
Or may be it is something in the Raspberry Pi 4B and 400 netbooting
firmware which could be responsible for this, if it is not something wrong
with dnsmasq?

See -

May be something in the dns handling implementation within dnsmasq which
doesn't differentiate the absence of a hostname uses the same IP address
that has been served to the client to play along, eventually truncating
what it calculates as the domain part (168.67.53) from the fqdn (i.e. after
the first . "dot"), and serving just the hostname (192). This sequence is
visible in the snap above.

If this is still not clear then I suggest that the only way to understand
this situation best is by netbooting a RPi 4B yourself from a dnsmasq
powered authoritative dhcp server.

Do note that this is not reproducible with a x86 client.

@Petr Menšík <pemensik at redhat.com>  may be you will be able to replicate
this easily as you have gone through this sequence while nailing the
UEFI+non-proxy bug.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20211025/e2f7a889/attachment.htm>

More information about the Dnsmasq-discuss mailing list