Static IP Address Support #625
Replies: 7 comments 5 replies
-
@revision29 I think you accidentally opened this discussion at the level of the PlummersSoftwareLLC organization. As it clearly concerns an idea for the NightDriverStrip project, I'm transferring it to the repo in question. |
Beta Was this translation helpful? Give feedback.
-
With the discussion now in the NightDriverStrip repo, I'll share some thoughts I have about the idea itself.
I understand the preference from a perspective of work involved, but in line with what I've said in relation to other ideas, I think we should store this in device config, if we are going to make this a feature of the project (i.e. merge it into the main tree). The header approach would limit the usability of this to users who are comfortable with setting up the build environment, making changes to source code, building the image and then uploading it manually. That would effectively exclude a meaningful part of our user base. Furthermore, making it a device config affair would also allow us to take care of the validation part. We could choose different options here: either define a new setting type for IP addresses and have the web UI do the format checking on the spot, or make the new settings of the validated type - and update the web UI to actually use the respective endpoint for changing settings that support validation (up to this point, it doesn't). Finally, we should make a (small) modification to the logic that handles the WiFi configuration via the web installer: it should make the device revert to DHCP whenever the web installer WiFi configuration flow is completed. That way, a user can "fix" any connectivity issues related to the static IP configuration without having to reset/reflash their device. |
Beta Was this translation helpful? Give feedback.
-
This seems really niche, but people that manage a herd of IoT or headless devices already have infra to handle this. Most people that need to do this (including me) just have the upstream router hand out the oxymoronicly-named Static DHCP addresses based on the MAC address. The DHCP server looks up the MAC and hands back the preconfigured IP. I set aside a pool of statics (I use "under 64") and let the dynamics have the rest of the address block. |
Beta Was this translation helpful? Give feedback.
-
Additionally, if the device ever gets moved to another network, you don't
have to basically break into a devices to change a hard coded number.
…On Sat, May 4, 2024, 11:14 AM Rutger van Bergen ***@***.***> wrote:
With the discussion now in the NightDriverStrip repo, I'll share some
thoughts I have about the idea itself.
I am unsure if the required variables should be stored in device config or
defined in globals.h / cutsom_globals.h. I lean towards the latter option
as it would be much, much simpler.
I understand the preference from a perspective of work involved, but in
line with what I've said in relation to other ideas, I think we *should*
store this in device config, if we are going to make this a feature of the
project (i.e. merge it into the main tree). The header approach would limit
the usability of this to users who are comfortable with setting up the
build environment, making changes to source code, building the image and
then uploading it manually. That would effectively exclude a meaningful
part of our user base.
Furthermore, making it a device config affair would also allow us to take
care of the validation part. We could choose different options here: either
define a new setting type for IP addresses and have the web UI do the
format checking on the spot, or make the new settings of the validated type
- and update the web UI to actually use the respective endpoint for
changing settings that support validation (up to this point, it doesn't).
Finally, we should make a (small) modification to the logic that handles
the WiFi configuration via the web installer: it should make the device
revert to DHCP whenever the web installer WiFi configuration flow is
completed. That way, a user can "fix" any connectivity issues related to
the static IP configuration without having to reset/reflash their device.
—
Reply to this email directly, view it on GitHub
<#625 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD3YASTSKXYQA35INLG3ZAUCNTAVCNFSM6AAAAABHG4E2ASVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGMJUG4ZDM>
.
You are receiving this because you are subscribed to this thread.Message
ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/625/comments/9314726
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
Also, without turning this into a "boil the ocean" project when we know
this is "just" a few lines of code in improv, main, and network, have you
looked at the current state of just making improv go away?
When configuring my ESP32-S3-BOX, there was a BTLE app that allowed you to
enter WiFi credentials and, I think, IP info right on your phone without
the painful mess of not having SSL certs on .local and escaping captive
portals and all that. Because BTLE and WiFi (unlike "old" BT) can coexist
somewhat peacefully, the app for all the OSes that matter connects to the
device and lets you configure everything network-related from your desktop
or mobile device or whatever.
I probably wouldn't use this as the immediate justification to replace
improv, but it's worth checking the current state of those apps and tools
to see if it provides an overall better experience (one that's more
consistent with other ESP32 iot things) than Improv does. Espressif was
leaning into BLE provisioning pretty hard and helping provide apps for
browsers, mobile, etc. to make all that work better. There is, of course,
an Arduino wrapper if we can't move past that.
I don't *know* the exact current state of all of this, but it's one of
those projects I've mentally bookmarked to investigate when I'm otherwise
out of projects in this code.
...but don't let this turn into a snipe hunt. I'm just saying that before I
spent an hour (whatever) hacking up improv and web UI for this, I'd see if
I could spend two and replace Improv and related code comopletedly and use
Espressif's newer provisioning system, starting somewhere around:
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/provisioning/wifi_provisioning.html
…On Sun, May 5, 2024 at 7:03 AM Joe Schneider ***@***.***> wrote:
That is embarrassing. I thought for sure I navigated to the project first.
Thanks for moving this to the proper place.
—
Reply to this email directly, view it on GitHub
<#625 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACCSD35OVOGGEYSBBHQNW2LZAYNYPAVCNFSM6AAAAABHG4E2ASVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TGMJZGUZTS>
.
You are receiving this because you commented.Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/625/comments/9319539
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
I think the whole thing is rather niche, indeed. We're discussing a capability that would be used by people who a) know enough about networking to know what the required values (IP address, gateway, netmask, DNS server(s), ...) are, but b) don't have the access or the ability to issue allocated addresses over DHCP - which is indeed a common approach to take if IP addresses are not supposed to change. I'm not sure how often we'll end up running into that particular combination of characteristics. The thought has actually crossed my mind that this is so niche that it may just be best for @revision29 to implement a very basic static IP address implementation in a branch of his for, and just leave it there.
@robertlipe I'm not exactly sure who that question was aimed at, but I haven't. I think with your help (🙂) it's become clear that there are alternatives for everything we use, and I think there are other possible replacements that are likely to be more productive. The network stack (RAM use) comes to mind, certainly if we conveniently consider the web server part of that stack. @revision29 Improv is the framework/library/approach we use to allow WiFi to be configured via the web installer. Which means that switching away from Improv would also require the web installer UI to be replaced. |
Beta Was this translation helpful? Give feedback.
-
I'm not sure how often we'll end up running into that particular
combination of characteristics.
Yep.
The thought has actually crossed my mind that this is so niche that it may
just be best for @revision29 <https://github.com/revision29> to implement
a very basic static IP address implementation in a branch of his for, and
just leave it there.
"Not all things worth doing are worth doing well."
I lost the trail somewhere in improvserial.h, but I can see it's building
and manipulating a WiFi object. Something somewhere[1] (?) is presumably
calling a WiFi.config in a way that looks approximately like this:
https://forum.arduino.cc/t/fixed-ip-on-arduino-opta/1161906/6
If, by chance, it loses its Arduino-ness somewhere along the line (yes,
Rutger just heard me snort) the code would probably look more like this in
ESP-IDF:
https://esp32.com/viewtopic.php?p=101052#p101052
Since you're already (hopefully) holding a WiFi object,
WiFi.macAddress() should
give you the obvious thing according to the very first block of
https://randomnerdtutorials.com/get-change-esp32-esp8266-mac-address-arduino/
If I were in Joe's shoes, I'd do something a little sleazy, but that at
least let all the boards run the same code:
esp_netif_dhcpc_stop(eth_netif); // Or Arduino equivalent, whatever that
is.
char *ip = char* ip= "192.168.3.10";
auto mac = WiFi.macAddress();
if (mac == "00:11:22:33:44:55") // This is subject to "mac" being a string
or a String or a std::string or whatever macAddress() returns.
ip = "192.168.3.11";
else if (mac = "11;22:33:44:55:66")
ip = "192.168.3.12"
[ repeats as necessary. Sure, you want a table that you can call
binary_search() on, but you can type the above in the time it takes to look
up the syntax. ]
// continue, flagrantly liberating from that link on esp32 com.
// MAYBE i'd trap here if ip was still the unset value from the top because
that means we're about to have two boards with the same address and that's
super gnarly to debug. I'd rather debug one boot looping board instead of
two that alternately work and fail.
if (strcmp(ip, "192.168.3.10) == 0) { ESP.system_abort("potential duplicate
IP addresses"); // eat flaming death
<https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/misc_system_api.html#_CPPv416esp_system_abortPKc>
}
char* gateway = "192.168.137.1"; char* netmask = "255.255.255.0";
esp_netif_ip_info_t info_t; memset(&info_t, 0, sizeof(esp_netif_ip_info_t));
// I think that the above two lines are actually "esp_netif info_t {0};"
but I probably wouldn't try it unless I were submitting it. ipaddr_aton((
const char *)ip, &info_t.ip.addr); ipaddr_aton((const char *)gateway, &
info_t.gw.addr); ipaddr_aton((const char *)netmask, &info_t.netmask.addr);
esp_netif_set_ip_info(esp_netif, &info_t);
... then I'd find the code that did the WiFi auth and do some of that.
(It's already in there somewhere, right?)
If the code were in an Arduino accent, I'd borrow from a different post #6
and find something like:
https://forum.arduino.cc/t/fixed-ip-on-arduino-opta/1161906/6, noting that
subnet and gateway are being used interchangeably
// these three arguments are strings set up above...
WiFi.config(ip, subnet, gateway); while ( status != WL_CONNECTED) { Serial.
print("Attempting to connect to SSID: "); Serial.println(ssid); // Connect
to WPA/WPA2 network. Change this line if using open or WEP network: status
= WiFi.begin(ssid, pass); // wait 10 seconds for connection: delay(10000); }
Just remember that you have to get the lower ISO levels (IP addressing)
configured BEFORE you try authentication (wifi host selection, passwords,
etc.) If you get that order backward, you're in for a bad time.
Personally, I woukd then indeed use the header approach, but leave out any
fancy validation - if the device doesn't connect then check the device
logging, figure out what's wrong, fix it and reflash.
Totally. This sounds like a place for quick and dirty.
At the end, if you'd like to post a little "this is the ten lines it takes.
Sweeten to taste" recipe, I think that's a much better use of everyone's
time than trying to figure out the regex voodoo to handle IPV6 and web UI
and adding code to break into the device if they're on an "alien" network
and so on. UI is hard. Comparing numbers (even numbers wearing Groucho
Noses to look like strings) is easy.
have you looked at the current state of just making improv go away?
@robertlipe <https://github.com/robertlipe> I'm not exactly sure who that
question was aimed at, but I haven't.
Does tagging on GH actually work for you? I never get notices...
I think with your help (🙂) it's become clear that there are alternatives
for *everything* we use,
That's a blessing and a curse, but "yes". I didn't really set out to find
other approaches, it's just that I tinker with a lot of projects and read a
LOT of code, so I may know more about other alternatives.
and I think there are other possible replacements that are likely to be
more productive.
I knew that you had spilled a lot of sweat and blood into improv. I know
I've never used it personally as my credentials are compiled in, but I know
that's not great, either. Someone with a ladder and esptool could dump wifi
credentials from a physically 'captured' device...but, man, is it
convenient for development.
There is no shortage of Arduino implementations, but I've been eyeballing
Espressif's own as it also lets you do auth over BTLE
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/provisioning/wifi_provisioning.html
as they think about things like security
<https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/provisioning/provisioning.html>
in a way we really haven't.
I need to better understand mDNS (foo.LOCAL) and better understand the
impact of jettisoning the BTLE runtime OUT of precious RAM before we enter
a state to blink.We might have to make some formal decisions on what
happens if you've asked for a network build, but haven't successfully
configured - should you be allowed to blink (and keep BTLE in core) or
should it keep trying? These, not the copy-paste exercises, are the real
kinds of decisions to be made in this kind of stuff.
Also, TBF, I'm not super certain that any that I've looked at even cover
this specific case. It was more a case of musing about a known pain point
and a possible opportunity to shop for replacements. It really was an
open-ended question into space to see if anyone had shopped for
alternatives and found a better fit.
The network stack (RAM use) comes to mind, certainly if we conveniently
consider the web server part of that stack.
The Improv-based web installer seems to "work with exceptions", so it's
not on the top of my list of things to "fix".
I'd agree with those priorities. I have a fork on the side for LittleFS vs.
SPIFFS, too, but that's a slightly different boat. Both of our LED hardware
implementations are also candidates for a good intern project. (Somewhat
ironically, I saw the lead dev of WLED on the FastLED buganizer the other
day, shopping FastLED over NeoPixel and crashing into the same dumb thing
that we three struggled with - the inability to change LED pins at runtime,
such as from a web UI.) XLight, OpenRGB or https://www.ledfx.app/ protocol
support or even WLED's equivalents of our color server and frame data
(their frame data is not THAT different from our color protocols...) would
be nifty. So many possible pet projects!
The one causing us active pain is Net stack + web server. (OK, true for
large values of "one".)
But this is somewhat OT, as I'm known to do at this hour. Well, at least
more extreme at this hour. :-)
The highlight is that I really would just find wherever Improv (or
whatever) is setting the addresses and take control away from it and
basically hard-code in some values. Use the board's MAC address as a serial
number that becomes your "primary key" to compare against.
Good luck!
RJL
[1] It's probably whatever advances Command from WIFI_SETTINGS to IDENTIFY
, but when we have methods named parse() and check() that are mutating
state, darned if I can follow it. I get the feeling there's part of Improv
that my ack commands aren't finding.
… Message ID:
<PlummersSoftwareLLC/NightDriverStrip/repo-discussions/625/comments/9325584
@github.com>
|
Beta Was this translation helpful? Give feedback.
-
I was thinking about adding some lines of code to allow a person to set a static IP address on a device. Passing the data to the WiFi stack is trivial. I am unsure if the required variables should be stored in device config or defined in globals.h / cutsom_globals.h. I lean towards the latter option as it would be much, much simpler. I would create a class that would be instantiated in network.cpp to validate the address details (if defined) and create object properties for the various address pieces (ip, netmask, dns server, gateway). I would choose this route because the class would validate each of those elements when it initializes and convert the strings to ip address octets, making less of a mess in the ConnectToWiFi section.
For background, I am making 4 accent lights for an event in July. I want to be able to do simultaneous API calls to synchronize changing effects and brightness. I will be using the Apple application Shortcuts to do the API calls because I don't have time to learn / fiddle with NightDriverServer. I already use Shortcuts to interact with one light strip setup and it works well enough. It will be much easier to set static IP addresses ahead of time rather than look them up from console output. But of course it will take longer to write the code than it will to plug in a usb cable after the fact.
Beta Was this translation helpful? Give feedback.
All reactions