Hey Geoff, I absolutely agree with your explanation.
So if dnsmasq is behaving the way it should and is not doing anything special w.r.t. the RPis, then there is some other component in the Ubuntu Mate 20.04 image that may be playing truant. Quoting from the ltsp issue ( https://github.com/ltsp/ltsp/issues/582#issuecomment-951005481) where this originated - "It might be related to dnsmasq, or it might be related to initramfs-tools, or even to Ubuntu-specific netplan code inside the initramfs..." As explained in the ltsp issue, if the hostname would have remained blank, then ltsp takes care of assigning one as ltsp+\<last octet of the IP address\>. But since it is being set as 192 by something at some stage, the ltsp respects the same and that is not acceptable especially when there are multiple clients ending up with the same hostname 192. And I now feel that there is something very specific in the 20.04 image only, because I have a 18.04 image for x86 systems being served by the same dnsmasq and there is no such issue. One way would be to create a 20.04 image for x86 and see if this problem can be replicated. I may give that a shot sometime next month. As of now shall just wait for @Petr Menšík <pemen...@redhat.com>'s finding as it may reinforce the above explanations. Regards, Shrenik On Wed, 27 Oct, 2021, 21:45 Geoff Back, <ge...@demonlair.co.uk> wrote: > Hi Shrenik, > > On 27/10/2021 16:38, Shrenik Bhura wrote: > > Hi Geoff, > > I don't expect it to at all set a hostname. > > > I think this sentence points to the very heart of your problem. > > I have been following this thread in detail. Everything indicates that > the RPI device is getting an IP address set as hostname and sending that to > dnsmasq in the DHCP packet, which of course results in dnsmasq correctly > interpreting the "192" before the dot as the node part of the hostname, as > already pointed out by Matthias. > > You said, earlier on: > > *"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."* > > That's an invalid configuration. All Linux-based systems - in fact all > POSIX systems - have a hostname, even if it is only "(none)" and pretty > much everything will break if there is not something set. The same applies > to Windows, if you are netbooting that, and in fact every other OS I have > ever encountered that uses IP (which is a lot). > > Something must always set the hostname, and it definitely looks like yours > is being set by the OS image you are netbooting. If it's not explicitly > defined by the OS image, and also is not defined in the dnsmasq DHCP > parameters, then the OS image will likely be falling back to using the IP > address as a (unfortunate) last chance due to lack of anything else. > > If you are truly expecting that your RPI device can operate without having > a hostname of any kind, I'm afraid you are expecting something that simply > won't work and even if DHCP worked in that situation, pretty much > everything else you tried to run on the RPI would not work properly either. > > Regards, > > Geoff. > > But yet something involved in the entire transaction is doing so i.e. > setting the IP address as the hostname and in doing so it is getting it all > wrong. > > Kindly read the thread to understand what's exactly going on. > > Regards, > Shrenik > > > On Wed, 27 Oct, 2021, 20:52 Geoff Back, <ge...@demonlair.co.uk> wrote: > >> 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 <pemen...@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@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 <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 >> listdnsmasq-disc...@lists.thekelleys.org.ukhttps://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss >> >> >> -- >> Geoff Back >> What if we're all just characters in someone's nightmares? >> >> _______________________________________________ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@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? > >
_______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
