@MSGID: 1@dont-email.me> c70835fc
@REPLY: 1@dont-email.me> 8bea6be5
@REPLYADDR Don Y <blockedofcourse@foo.invalid>
@REPLYTO 2:5075/128 Don Y
@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> 1@dont-email.me>
@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 2:14 PM, Dimiter_Popoff wrote:
> On 9/7/2023 23:30, Don Y wrote:
>> 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

That just brings up a different set of problems.
You have to pick a range of IPs for the router`s clients.
How do you know that your choices won`t conflict with other
hosts in their organization?

> 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"

There is ALWAYS an advantage to be had from having a known,
working configuration that you can coax the user back to
trying.

But, getting from there to something that fits *his* needs
can be problematic (as above).

> [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.

I think the best approach for bootstrapping headless devices,
*today* would be to embed BLE (severely range constrained) or,
preferably, NFC in the device and kludge an interface that can
rely on something (app) present in all/most cell phones to bridge
the gap to a "familiar" UI.

But, this will still only address the one-off sites.  Handling
hundreds or thousands of devices (as is my bootstrap case) will
always be a challenge -- esp if no techies around to deal with 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