Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #32010
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Configure network of an embedded device |
| Date | 2023-09-08 00:53 +0300 |
| Organization | TGI |
| Message-ID | <uddgp2$34okl$1@dont-email.me> (permalink) |
| References | (2 earlier) <udbvit$2t598$2@dont-email.me> <TGs*lzOpz@news.chiark.greenend.org.uk> <uddbsg$3443p$3@dont-email.me> <uddef1$34hgr$1@dont-email.me> <uddffh$34jof$1@dont-email.me> |
On 9/8/2023 0:31, Don Y wrote: > On 9/7/2023 2:14 PM, Dimiter_Popoff wrote: >> On 9/7/2023 23:30, Don Y wrote: >>> How do you address the case of your (GUI) client discovering some other >>> DHCP service running on the network? >> >> 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. > >> 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. > >> [Most likely this was yet another sabotage against our devices at >> this customer (they have no legit second dhcp server there so someone >> must have set one up, the problems started some time after they changed >> routers and well, they have a history of sabotage attempts there, there >> was physical evidence for that).] >> >> If a design can afford a cheap router just include one and save yourself >> all the headache (that to the OP). Other than that, you are stuck to >> my other solution, which works - just technically, I saw no evidence >> anyone used it ever. People either can do what it takes with their >> router/network or they use the router we supply. > 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? > > But, this will still only address the one-off sites. Handling > hundreds or thousands of devices (as is my bootstrap case) will > always be a challenge -- esp if no techies around to deal with it! > Your case is completely different, I don't even want to think what you would have at your plate if you had to predefine the entire network of your user. Me, I just set a few fixed IP addresses on the router, some ports get forwarded (they want sometimes to access the spectra via http) and that's it. Including a display they can read the IP address on would have been a good idea which I may apply to our next version, not sure why I did not do it some 15 years ago. ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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