@MSGID: 1@dont-email.me> 0669a31a
@REPLY: 1@dont-email.me> 1d567178
@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> 1@dont-email.me>
1@dont-email.me> 2@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 4:05 PM, Dimiter_Popoff wrote:
>> 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.
> 
> So what`s wrong with them using their IP addresses as they
> want them and accessing our units through the router we have
> supplied via the IP address it has received via DHCP from
> their network. Many do exactly that, let realVNC remember
> the IP address/port numbers and just click on the one
> they want to talk to. We don`t sell them a general purpose router
> so they build a home network, we sell them something to make their
> life easier with our products, perhaps just initially. That`s all.
> There are *no* IP address conflicts which can possibly arise in
> this scenario.

You can`t know which IP addresses they haven`t already
used for their own hosts.  The router solution only
works on the subnet that *it* manages.

You pick some range of IP addresses.  Assume A.B.C.D is
one of them.  The WAN port of your router conects to
THEIR network and gets an IP address from their DHCP
server.

THEY have a host at A.B.C.D.  How do the devices on
the router`s subnet access THAT host?  How do the
hosts on their existing network access *your* A.B.C.D?

The only way you can ensure that the addresses you
assign are unique if if you assign them under a domain
that you control (tgi-sci.com).

>>>> 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.
> 
> What`s wrong with DHCP telling the device which IP address it has
> to use, the ordinary way? How does bluetooth help here? (other
> than making things messier, perhaps way messier)
> Or do you mean our device has to tell their router which IP
> address to assign us via DHCP (what nonsense... I am sure you
> don`t mean that).

No, the problem with existing solutions is that they
don`t give you an easy way to convey that information
to the *user* (unless you have a display capability
*in* the device or enough tech-savvy to know how
to talk to the DHCP server to figure out where the
device resides in the IP space).

I`m suggesting using a UI device that is reasonably
ubiquitous (a cell phone) as that interface.  This
is similar to using PDAs decades ago as UIs for
headless devices.

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