Re: Discovering DHCP hostname during original system installation
On Wed 01 Jun 2022 at 06:32:07 (-0500), Richard Owlett wrote:
> On 05/31/2022 11:20 PM, David Wright wrote:
> > On Tue 31 May 2022 at 14:00:51 (-0500), Richard Owlett wrote:
> > > On 05/31/2022 11:13 AM, David Wright wrote:
> > > > On Tue 31 May 2022 at 08:13:57 (-0500), Richard Owlett wrote:
> [ … ] There is also an unwarranted
> assumption that I resemble a "normal" Debian user.
If I'm the one who's meant to be assuming, nothing could be further
from the truth.
> Though of late I've
> tended to use a particular machine - I have a half dozen available.
>
> The the _current_ install process is on a machine explicitly dedicated
> to learning by experimentation. It has had at least a dozen full
> installs from scratch - no more than 3 coexisting at a time.
Yes, that's why I presumed that any firmware requirement could be
supplied by yourself, from one of your installations at the very least.
> I religiously avoid any networking of my personal machines.
> Up to this current experiment I have avoided any intentional use of
> WiFi. This has been made easier by the majority of my machines
> requiring non-free drivers.
Again, the OP never made any mention of this.
> I tried to succinctly state MY topic in the Subject line.
> When The DHCP auto-detection during install fails,
> "How do I manually discover DHCP [server] hostname(s)?"
Ah, now, I recognise /that/ as a question.
> > Is that fair, and am I correct in pointing out that you still haven't
> > stated how the laptop is connected to the internet,
>
> The Alcatel [with WiFi disabled] is physically plugged into a USB port.
> To the unsophisticated user there is no way to distinguish it from a
> modem which has auto-dialed a specific server.
>
> > but that it's not
> > with a cat5 cable.
> As stated in this post the particular machine is dedicated to
> EXPERIMENTATION. The goal of the experimentation is to be able to
> describe how the Debian installation process could simultaneously be
> simpler and more versatile. [Decades in engineering support (hardware
> not software) informs me that is not easy ;]
Yes, but all too often, we are given a tiny glimpse of your
experiment, and then expected to supply fixes and reading lists
precisely relevant to whatever your experiment is meant to be doing.
> Did I succeed at all?
This time. Well, the way I would tackle this problem is
to run dhcp_probe on the interface name given by ip a,
from which I'd get a dotted quad, like 192.168.1.1.
Then I'd run host 192.168.1.1 and would get a result like
1.1.168.192.in-addr.arpa domain name pointer www.routerlogin.com.
I think in your case you'd probably get mobile.hotspot—perhaps.
I'm not sure what use that is to you. You can get that domain
out of the instruction manual. IIRC my router answers to the
example I gave, but I always use the hostname that I set up
in my /etc/hosts, because I have two routers from the same
manufacturer, so www.routerlogin.com would be ambiguous. Or
I can use the dotted quads themselves, ….1 and ….2.
But that's all in aid of logging in and configuring them,
not for when I'm asking them (one, actually) for DHCP service.
AFAIK, the hostname of a DHCP server is not particularly useful
to you, in that the negotiations are commenced by the client
broadcasting over the link, to which the server should respond.
(I take it you're not trying to run a DHCP server yourself on
one of your machines.) In all the joints in all the towns in
all the world, I don't recall ever finding out what the
hostnames of their DHCP servers were.
But I know nothing about how these negotiations take place on
your USB connection. Do you see them progressing, or failing,
in your daemon.log, as I do?
(ToD Host) dhclient[531]: DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 12
(ToD Host) sh[531]: DHCPDISCOVER on enp3s0 to 255.255.255.255 port 67 interval 12
(ToD Host) dhclient[531]: DHCPOFFER of 192.168.1.14 from 192.168.1.1
(ToD Host) sh[531]: DHCPOFFER of 192.168.1.14 from 192.168.1.1
(ToD Host) sh[531]: DHCPREQUEST for 192.168.1.14 on enp3s0 to 255.255.255.255 port 67
(ToD Host) dhclient[531]: DHCPREQUEST for 192.168.1.14 on enp3s0 to 255.255.255.255 port 67
(ToD Host) dhclient[531]: DHCPACK of 192.168.1.14 from 192.168.1.1
(ToD Host) sh[531]: DHCPACK of 192.168.1.14 from 192.168.1.1
(ToD Host) avahi-daemon[568]: Joining mDNS multicast group on interface enp3s0.IPv4 with address 192.168.1.14.
(ToD Host) avahi-daemon[568]: New relevant interface enp3s0.IPv4 for mDNS.
(ToD Host) avahi-daemon[568]: Registering new address record for 192.168.1.14 on enp3s0.IPv4.
Cheers,
David.
Reply to: