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

[Geoff Back]

Hi Shrenik,

Looking at that configuration file I see nothing that specifies the host
name that the RPI device should initialise itself with.  Where do you
expect it to obtain a hostname from, and what specific hostname are you
expecting to set?

Regards,

Geoff.


On 27/10/2021 14:06, Shrenik Bhura wrote:
> > but my rpi machines received hostname set from dnsmasq. I used
> static allocations only for my testing.
>
> Try without setting any.
>
> > Can you share at least relevant part of dnsmasq configuration?
>
> Config file attached below.
>
> > Does it have dhcp-host record for that machine?
>
> No, it doesn't.
>
> The results are the same for any RPi 4B or RPi 400. I have tested with 3.
> --
>
>
> On Wed, 27 Oct 2021 at 17:46, Petr Menšík <pemensik at redhat.com
> <mailto:pemensik at redhat.com>> wrote:
>
>     Hi,
>
>     I would try tomorrow, but my rpi machines received hostname set
>     from dnsmasq. I used static allocations only for my testing. Can
>     you share at least relevant part of dnsmasq configuration?
>
>     Does it have dhcp-host record for that machine?
>
>     On 10/25/21 16:00, Shrenik Bhura wrote:
>>
>>     On Mon, 25 Oct, 2021, 01:24 Matthias May via Dnsmasq-discuss,
>>     <dnsmasq-discuss at lists.thekelleys.org.uk
>>     <mailto: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 FQDN.
>>         * https://en.wikipedia.org/wiki/Hostname
>>         <https://en.wikipedia.org/wiki/Hostname>
>>         * https://en.wikipedia.org/wiki/Fully_qualified_domain_name
>>         <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 hostname.
>>
>>     > the problem here is the client looks to be misconfigured if it
>>     is telling the
>>     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 -
>>     https://drive.google.com/file/d/1WmbdcjFf6OYU-lcwwHw2LM40eSEIvllL/view?usp=drivesdk
>>     <https://drive.google.com/file/d/1WmbdcjFf6OYU-lcwwHw2LM40eSEIvllL/view?usp=drivesdk>
>>
>>     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 <mailto: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.
>>
>>     Regards,
>>     Shrenik
>>
>>     Regards,
>>     Shrenik
>
>     -- 
>     Petr Menšík
>     Software Engineer
>     Red Hat, http://www.redhat.com/ <http://www.redhat.com/>
>     email: pemensik at redhat.com <mailto:pemensik at redhat.com>
>     PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
>
>
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

-- 
Geoff Back
What if we're all just characters in someone's nightmares?

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