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@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/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 > > 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:pemen...@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/ email: pemen...@redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
