@MSGID: 1@dont-email.me> 1d567178
@REPLY: 2@dont-email.me> f052af94
@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>
@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 1:21, Don Y wrote:
> 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).

Well they get a router which is meant to be used only with the
devices we supply; we set it with fixed IP addresses for each
MAC address they get for their convenience, so far nobody has
complained. Their laptops/phones whatever they use connect through a
number of ways - wifi, Ethernet behind the router we give them,
Ethernet in front of this router with port forwarding would be
a next option (we don`t supply this by default).
All devices - our netMCA-s and their terminal units - go through
DHCP, it is just that we have set the router to give some fixed
addresses to certain MACs. Customers do have access to the router
so if they know what they are doing they can change what they
need. Can`t think of a more flexible configuration nowadays;
anything, any additional protocol you insert will only add problems
without simplifying anything.

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

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

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

======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

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