@MSGID: 2@dont-email.me> f052af94
@REPLY: 1@dont-email.me> f80df85c
@REPLYADDR Don Y <blockedofcourse@foo.invalid>
@REPLYTO 2:5075/128 Don Y
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 2@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> 1@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:53 PM, Dimiter_Popoff wrote:
>>> 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?
> 
> In our case, this is easy. The customer gets a sheet of paper titled
> "quick start"; some of them write the IP addresses on stickers etc.
> Mind you, this is a solution to our operation where an MCA is not
> just a cheap gizmo you won`t remember what/where it was after two days.

Yes, but you`re just kicking the can into their court.  If
the addresses you picked coincide with addresses they are
already using, then those hosts are inaccessible "across"
the router (regardless of which way you are going).

The advantage of an in-place DHCP server is that they,
presumably, set up the range of addresses served to be
compatible with their network design.

>>> 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).
> 
> In this case it fits their needs perfectly. The router we supplied
> lives behind their router *and* the net behind our router is meant
> solely for what we have supplied. They can access the devices from
> their network, port forwarding does what it takes. Our devices
> can access the internet - if they want them to - so they can get
> live online support etc.

Again, see above.
>> 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.
> 
> So how do I instruct the user where to find the IP address they
> have to enter after they start realVNC? Will the IP stay static
> so they can get just as many clickable options after they have
> entered the IP address the first time?

You would use it to TELL the device what IP it should use.
If they tell it something "bad", then that`s their problem.

>> 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!
>>
> 
> Your case is completely different, I don`t even want to think
> what you would have at your plate if you had to predefine the entire
> network of your user. Me, I just set a few fixed IP addresses
> on the router, some ports get forwarded (they want sometimes to
> access the spectra via http) and that`s it.

If it was just IP address assignment, it would be easy -- let
them all fight for leases and then DDNS so they`re all resolvable
symbolically.

The problem comes from having to install (device-specific) secrets
in all of them.  If you don`t have physical control/oversight of
the entire network, you can`t know if someone hasn`t eavesdropped
on the process.

> Including a display they can read the IP address on would have
> been a good idea which I may apply to our next version, not sure
> why I did not do it some 15 years ago.

Displays cost money.  If you can leverage it for some OTHER
purpose ("Measurement in Progress"), then it`s easier to justify
the expense.

If the user must be able to enter information, then the input
device(s) becomes another issue.

[I have a NAS that has a display and a means whereby the user can enter
initial configuration parameters -- e.g., IP/Mask/etc.  But, it is
incredibly brain-damaged:  scroll through menu to find item of interest;
SELECT item; scroll to select subitem of interest; SELECT subitem;
scroll through available values; SELECT value (advancing to next subitem
in the process).  So, configuring a network interface requires setting
12 items for an IP address (one for each of 4x3 digits), another 12
for a mask (ditto), and another 12 for DNS (or GW, I can`t recall which).
The selected (sub)item flashes so that puts a limit on how fast you
can select subitems/values.  An error requires you to cycle through ALL
of the items/subitems until you loop around back to the item you munged.]

Engineers are typically penny-wise and pound-foolish in their
designs of fallback UIs!


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