@MSGID: 1@dont-email.me> 8bea6be5
@REPLY: 3@dont-email.me> 5dde09ec
@REPLYADDR Dimiter_Popoff <dp@tgi-sci.com>
@REPLYTO 2:5075/128 Dimiter_Popoff
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@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>
3@dont-email.me>
@RFC-Reply-To: dp@tgi-sci.com
@TZUTC: 0300
@PID: Mozilla/5.0 (Windows NT 10.0; Win64; x64;
rv:102.0) Gecko/20100101 Thunderbird/102.15.0
@TID: FIDOGATE-5.12-ge4e8b94
On 9/7/2023 23:30, Don Y wrote:
> 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?

This is another point added to my approach "sell them a router you have
set up". In fact I had exactly this at some point, a customer for our
TLD readers decided to stray from the router we had delivered with the
units they had purchased. The people who had to do the measurements
(sometimes 1000+ a day) had no access to the corporate router so someone
there had set some fixed IP addresses for our devices on their
network, not behind the router we supplied. Things worked - until they
did not.
They started to call "your device won`t boot at times".
"Does the LED always indicate the unit did get an IP address?"
"Yes it does."
Well does it always boot behind the router we supplied?
"Hmm let us test... Yes it does"

[Most likely this was yet another sabotage against our devices at
this customer (they have no legit second dhcp server there so someone
must have set one up, the problems started some time after they changed
routers and well, they have a history of sabotage attempts there, there
was physical evidence for that).]

If a design can afford a cheap router just include one and save yourself
all the headache (that to the OP). Other than that, you are stuck to
my other solution, which works - just technically, I saw no evidence
anyone used it ever. People either can do what it takes with their
router/network or they use the router we supply.
 --- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.15.0
 * Origin: TGI (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