Nп/п : 41 из 60
 От   : Don Y                               2:5075/128        07 сен 23 13:30:00
 К    : Theo                                                  07 сен 23 23:31:01
 Тема : Re: Configure network of an embedded device
----------------------------------------------------------------------------------
                                                                                 
@MSGID: 3@dont-email.me> 5dde09ec
@REPLY: lzOpz@news.chiark.greenend.org.uk>
46079a13
@REPLYADDR Don Y <blockedofcourse@foo.invalid>
@REPLYTO 2:5075/128 Don Y
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 3@dont-email.me>
@RFC-References: 1@dont-email.me>
FNJpz@news.chiark.greenend.org.uk> 2@dont-email.me>
lzOpz@news.chiark.greenend.org.uk>
@TZUTC: -0700
@PID: Mozilla/5.0 (Windows NT 6.1; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.2.2
@TID: FIDOGATE-5.12-ge4e8b94
On 9/7/2023 11:40 AM, Theo wrote:
>> How does the device know if send a DHCP request (to receive an IP
>> address from an external DHCP server) or launch a DHCP server?
>> Maybe it can try a DHCP request a revert back to internal DHCP server if
>> that fails.

> The device out of the box is a DHCP server.  Once somebody logs into it and
> configures it, it reboots to become a DHCP client.  To revert back to being
> a DHCP server again somebody has to hold down the factory reset button.
> (or equivalent physical signal, eg smart lightbulbs you have to turn them on
> and off several times in a predefined sequence of flashes)

How do you address the case of your (GUI) client discovering some other
DHCP service running on the network?

If you could modify the *client* code, you could use something like
a different vendor magic to ensure only the server in the device
would be recognized.

You could flip this around; distribute an app that acts as a
special DHCP server.  Have the device only issue requests to
services offered by *that* server (even if another was
competing -- see above).

In addition to servicing DHCP requests, it could query any
*existing* DHCP service to obtain a lease FOR THE DEVICE
(acting as a proxy).  In that way, it learns the subnet that
the user`s network would LIKE to be used (resolving RFC1918
ambiguities as well as *assigned* IP ranges)

This covers the case for no DHCP server present as well as
a competing DHCP service.  And, gives the user a handle
into the configuration process as a desired side effect.

But, it`s yet another app -- hosted OUTSIDE the device -- that
has to be maintained  :<

And, you can`t lose sight of the fact that the user has to
arrange for any sort of "persistence" that he may require...
in light of a network that may not inherently want to offer it!

 --- Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.2.2
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441



   GoldED+ VK   │                                                 │   09:55:30    
                                                                                
В этой области больше нет сообщений.

Остаться здесь
Перейти к списку сообщений
Перейти к списку эх