intel
RFC: Handling networking configuration
This is offshot of https://github.com/01org/zephyr.js/pull/659, where one of the known issues of the initial implementation merged is that it has hardcoded local IPv4 and IPv6 addresses: https://github.com/01org/zephyr.js/blob/master/src/zjs_dgram.c#L332
My initial idea, from a very quick look at the iotivity-constrained, was that it would have a similar issue. But looking at more detail, while I see that it issues a call to net_if_ipv6_maddr_add() to set OCF multicast address, it doesn't set any other address explicitly. Instead, it binds to unspecified address of "::", that's all (good to know it works, I was too shy to try it in my UDP examples, to not find that it doesn't work and not get dragged into fixing it upstream; I'll test it and submit a patch for my examples). So, my idea how that works is that OCF client issues a multicast discovery, and an OCF server replies using it's (effectively private) link-local address, and that's how they able to communicate. Note that while OCF is free from IPv6 addressing issues, there's apparently an issue with BLE addressing for IPv6-over-BLE, why Zephyr.js allows to set it via make argument while building.
Ok, that all doesn't help generic UDP/TCP networking, where there's no "discovery", and a server needs to have a well-known public address to be accessed.
So, I don't expect there to be a well-known API to do networking configuration in Node.js. That's simply because on full-fledged OS systems which it targets, networking configuration is a part of OS, nor application, configuration, and done by a separate (existing) set of tools. That's different from Zephyr RTOS, where there's a single application, and the RTOS doesn't provide any pre-configuration services accept the bare minimum (like providing private link-local address).
This ticket is to discuss approaches to do the needed configuration for Zephyr.js.
Some ideas:
- We can push more of this stuff onto upstream, like tell: "guys let everyone configure addition (public) address using config option, or configure that it should be gotten via DHCP, or ...". I personally think that's how it should be done eventually, and e.g. right now on the Zephyr ML there's a thread on how to do DHCP well. But doing that might take some time, and doing it well isn't exactly easy (which again should be a reason for RTOS to do it in one place, instead of burdening each and every app).
- While solution 1) isn't available, we can try to emulate it on Z.js side, like, have a build config param, with a default, but which can be overriden on make command line.
- More advanced approach would be to allow to do networking (re)configuration at runtime, by introducing a dedicated module for that (which, per above, unlikely would come from Node.js core, but we'd need to look for 3rd-party module for API affinity for sure). Note that while this is definitely the most flexible approach, it's not without drawbacks, naive approach to using would be to hardcode system-level params in an application, which is violation of separation of concerns principle.
Well, I wanted to dump what I had in mind on that, comments are welcome. I'll try to explore each of the options above in more detail going forward.
Good topic. You're right, we've been solving similar problems lately (temporarily) by adding make arguments to set the values, solution #2. So I think that's probably the immediate path forward and then we need to watch what Zephyr does and adjust when they solve these problems well.
This makes it pretty easy to script building custom images per platform to flash unique values. Another technique I used preparing for the Hackathon last week was to set a unique value like de:ad:be:ef in the BLE address and then find the offset in the final zephyr.bin image, so I could then use dd to stamp new addresses into the image w/o actually rebuilding. A hack, but it could be made pretty resilient with some work.
Subnet mask, default gateway, and DNS servers would be in the same situation. Clearly DHCP is the nice way to handle all this.
