@MSGID: JMRpz@news.chiark.greenend.org.uk>
e5119ee1
@REPLY: 3@dont-email.me> 5dde09ec
@REPLYADDR Theo
<theom+news@chiark.greenend.org.uk>
@REPLYTO 2:5075/128 Theo
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID:
JMRpz@news.chiark.greenend.org.uk>
@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>
@TZUTC: 0100
@PID: tin/1.8.3-20070201 ("Scotasay") (UNIX)
(Linux/5.10.0-22-amd64 (x86_64))
@TID: FIDOGATE-5.12-ge4e8b94
Don Y <blockedofcourse@foo.invalid> wrote:
> On 9/7/2023 11:40 AM, Theo wrote:
> >> How does the device know if send a DHCP request (to receive an IP
> >> address from an external DHCP server) or launch a DHCP server?
> >> Maybe it can try a DHCP request a revert back to internal DHCP server if
> >> that fails.
> > 
> > The device out of the box is a DHCP server.  Once somebody logs into it and
> > configures it, it reboots to become a DHCP client.  To revert back to being
> > a DHCP server again somebody has to hold down the factory reset button.
> > (or equivalent physical signal, eg smart lightbulbs you have to turn them on
> > and off several times in a predefined sequence of flashes)
> 
> How do you address the case of your (GUI) client discovering some other
> DHCP service running on the network?

You plug your widget into your laptop directly, with a cable, or connect to
its own wifi SSID.  The network contains exactly two devices, the widget and
your laptop (/desktop/phone/whatever).  If you normally use that interface
(ethernet or wifi) to connect to your LAN, you have explicitly unplugged so
there is no connectivity to the LAN and no chance of things getting
confused.

If you run both interfaces together (eg plug into the widget via ethernet,
while having wifi running to the LAN) that will work as long as widget and
routable LAN IP addresses don`t overlap.  This is safer with IPv6 since
there`s a much wider range of private addresses to choose from, so you pick
a private range (from fd00::/8, ie 2^120 addresses) and chances are good
it`s not used by the LAN.

> If you could modify the *client* code, you could use something like
> a different vendor magic to ensure only the server in the device
> would be recognized.
> 
> You could flip this around; distribute an app that acts as a
> special DHCP server.  Have the device only issue requests to
> services offered by *that* server (even if another was
> competing -- see above).

Offering a DHCP server likely requires administrator privileges, which the
user may not have[*].  It will also mess up the LAN if they ever connect back
to it while the DHCP server is running (since now there are two DHCPs on the
LAN).

[*] setting a static IP on the interface also requires admin privs, so
schemes where the device responds at some fixed address like
http://192.168.33.99/ where you need to configure your laptop for
192.168.33.0/24 also require admin privs

Theo
--- tin/1.8.3-20070201 ("Scotasay") (UNIX) (Linux/5.10.0-22-amd64 (x86_64))
 * Origin: University of Cambridge, England (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