@MSGID: 1@dont-email.me> 4d9e44a5
@REPLY: 1@dont-email.me> 0669a31a
@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> 1@dont-email.me> 1@dont-email.me>
1@dont-email.me> 2@dont-email.me> 1@dont-email.me>
1@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/8/2023 2:55, Don Y wrote:
> 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.

Exactly. Which is the purpose of the entire exercise.
They get a router and some units, power everything up,
look at the "quick start" paper, connect to the router
and type in the IP address(es) to some laptop, often
wifi connected to the router - we name its wifi usually
"netMCA".
You *cannot* simplify that, not in today`s world.

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

By accessing the IP address the router we have supplied
gets on their network to ports which have been forwarded
to the IP sockets behind our router.You are familiar with
port forwarding?

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

Not at all. The IP addresses on the net behind our router
are fixed and unique. They can connect to that same subnet
right away; if they want to access from their network they
will have to set as many port forwarding pairs as there
are devices on the network behind our router. In any case
tuning their network to accommodate the one we have supplied
is a second step. The first step is to install things and
ensure they work - for which they don`t need to even connect
our router to their network. After that they know it is up
to them, like once you have tested your new vacuum cleaner
to work you don`t call support if it needs a cable extender etc.

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

This sounds too generic to me, I don`t understand how
you will make a phone bluetooth simplify the DHCP protocol
for a device you connect to a network. Then I don`t think
there are many phones with bluetooth and no wifi so what
is stopping you to look at the router`s DHCP list? You
won`t need another bluetooth device to pair with, software
for the two to talk to each other etc., can`t see any
benefit out of this approach in the cases discussed so far.
 --- 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