@MSGID: 2@dont-email.me> 4c79aff7
@REPLY: 1@dont-email.me> 4d9e44a5
@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> 2@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 6:26 PM, Dimiter_Popoff wrote:
>> 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

Exactly.  Did you not recall my comment that you were
"kicking the can into their court"?  The *ideal* way
to configure something is to have a DHCP server issue
an IP address that is compatible with THEIR network
addressing and register a symbolic name via DDNS.

But, this puts additional constraints on the user.

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

>> 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 *want* something generic.  So, it can be applied to
many different products/scenarios.

> 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

You have to access the WiFi router.  What`s the passphrase?
Who *controls* access?

If you`re a small company/department, you can possibly
go your own way -- and avoid the eyes of little hitlers.
But, if you have to interface to a corporate infrastructure,
you may find just connecting your *device* to the network
requires vetting ("How do we know the device isn`t
malevolent?")

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

You can offer the FTP profile from your device over BT.
Then, just let the user retrieve a status page from
your device and.or *send* a configuration page to it.

The phone is just a display + keyboard/pad.  No special
apps (beyond the BT stack).

Because BLE is relatively short-range, you don`t worry
about seeing every host in the department, etc.

Accessing the DHCP server`s client list means you have to
have a DHCP server *and* have to have permission to access
it.  These are things outside of the scope of the device.

A "portable UI" that can talk directly to the device
doesn`t require any cooperation from anyone to have
a service in place AND a means of accessing that service
(likely by an "unprivileged" user).

[Many larger organizations have IT departments that strictly
control what they allow on their networks (you`ve heard the
phrase BOfH?).  I`ve had to implement clandestine tunnels
under common protocols to get through the "policies"
(defined and implemented by folks with their own sense of
self-importance) that customers have had in place that
would prevent me from doing what I would have otherwise
done safely.  (escalating to upper management doesn`t
make you any friends among the IT folks and, *if* there is
ever a problem with your device, you can be SURE they will
gleefully stand in your way of fixing 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