Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #32015

Re: Configure network of an embedded device

From Don Y <blockedofcourse@foo.invalid>
Newsgroups comp.arch.embedded
Subject Re: Configure network of an embedded device
Date 2023-09-07 18:57 -0700
Organization A noiseless patient Spider
Message-ID <uddv2f$3a8oe$2@dont-email.me> (permalink)
References (7 earlier) <uddgp2$34okl$1@dont-email.me> <uddid4$3531m$2@dont-email.me> <uddkvm$3591e$1@dont-email.me> <uddnun$35lhh$1@dont-email.me> <uddt91$369hb$1@dont-email.me>

Show all headers | View raw


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!)]

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Configure network of an embedded device pozz <pozzugno@gmail.com> - 2023-09-05 10:37 +0200
  Re: Configure network of an embedded device Dimiter_Popoff <dp@tgi-sci.com> - 2023-09-05 13:43 +0300
    Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 11:03 -0700
  Re: Configure network of an embedded device Theo <theom+news@chiark.greenend.org.uk> - 2023-09-06 21:56 +0100
    Re: Configure network of an embedded device pozz <pozzugno@gmail.com> - 2023-09-07 09:54 +0200
      Re: Configure network of an embedded device Theo <theom+news@chiark.greenend.org.uk> - 2023-09-07 19:40 +0100
        Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 13:19 -0700
        Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 13:30 -0700
          Re: Configure network of an embedded device Dimiter_Popoff <dp@tgi-sci.com> - 2023-09-08 00:14 +0300
            Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 14:31 -0700
              Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 14:34 -0700
              Re: Configure network of an embedded device Dimiter_Popoff <dp@tgi-sci.com> - 2023-09-08 00:53 +0300
                Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 15:21 -0700
                Re: Configure network of an embedded device Dimiter_Popoff <dp@tgi-sci.com> - 2023-09-08 02:05 +0300
                Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 16:55 -0700
                Re: Configure network of an embedded device Dimiter_Popoff <dp@tgi-sci.com> - 2023-09-08 04:26 +0300
                Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 18:57 -0700
          Re: Configure network of an embedded device Theo <theom+news@chiark.greenend.org.uk> - 2023-09-08 10:17 +0100
            Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-08 03:20 -0700
  Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-07 10:57 -0700
    Re: Configure network of an embedded device pozz <pozzugno@gmail.com> - 2023-09-08 09:41 +0200
      Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-08 03:50 -0700
        Re: Configure network of an embedded device pozz <pozzugno@gmail.com> - 2023-09-08 13:56 +0200
          Re: Configure network of an embedded device Don Y <blockedofcourse@foo.invalid> - 2023-09-08 09:45 -0700
            Re: Configure network of an embedded device George Neuner <gneuner2@comcast.net> - 2023-09-08 16:50 -0400

csiph-web