Hi Joerg,
> we are a company of experts for automotive software and are working for > many customers in the automotive industry. > > One of our customers (a big german automotive supplier) is looking for a > network configuration solution with some specific limitations and after > evaluating several alternatives (e.g. network manager, wicked, ...) we > ended up with netfid being the best solution giving the requirements. That sounds really awesome! > However netifd does not (yet) fully fit the requirements and instead of > developing a fork, our customer would like to contribute to OpenWRT > directly and integrate required features/changes. I am really happy to hear that, and it's certainly the correct approach imho. > Some examples of what we know at the moment what would be needed: > - We may need static linking of the libraries used in netifd. I saw > that this is basically possible, but a bit broken IIRC. It is entirely possible that this is broken, at least it is not something that is frequently tested (or tested at all). But I don't foresee any big issues in solving that. > - One of the requirement (For security reasons) is, that the system > should be able to run without a script interpreter (not even a shell), > but we need dhcp. So one of the first proposals would be creating a dhcp > protocol implementation in c Is the security policy also prohibiting embedded VMs that execute precompiled, immutable byte code? Using ucode would allow for this and implementing the higher level proto handling in it vastly simplifies things > - VPN configuration (possible ipsec with strongswan) will be required > and we would also need to implement this directly in c. That is a lot of complexity / a huge amount of code you're going to implement in C there, and it's mostly going to lie dormant upstream I suppose, since OpenWrt will likely stick to the existing external solutions integrated via scripting. > - As far as I can see, there is no tooling for QoS/tc in openwrt at the > moment. This is probably also required and could be implemented as part > of netifd. There's SQM scripts and the like. Or do you refer to QoS/tc integration directly in netifd? > - Traffic filtering is one more point on our list of requirements. I > know that you use fw3 and I saw fw4 for nftables. However I guess fw4 > will not work for us, because of ucode, but I could be wrong here. Same question as above. Theoretically the entire fw4 ucode sources could be precompiled into a single bytecode image which you could then embed into an ELF executable providing the ucode VM. The end result would also be a compiled executable running its own code and not externally modifiable source files. > > I guess most of the changes could also help the OpenWRT community. If > some of the changes are not really what you want for OpenWRT users, we > could also think about implementing a plugin API, much like the proto > handler API, but without additional exec-calls. That definitely makes sense. However to be usable in practice for the kind of use-cases OpenWrt aims for, that plugin API would need to rely on dlopen() to be able to load plugins at runtime, I guess that would violate your security architecture constraints, right? Obviously it could be made a compile time option to build-in modules directly in the executable - it's just something we should have in mind when designaing an implementation. > Would these kind of contributions be wanted by OpenWRT? I can not speak for the others, but personally I do think that (at least some of) the proposals are useful and I'd love to help. I am a bit wary of doing a custom DHCP implementation, Busybox udhcpc for example is quite old already and there's still issues being discovered with it nowadays. I guess such a custom implementation would require a lot of time to mature. On the other hand it's probably going to run in a very controlled environment so it might not be as problematic after all. Kind regards, Jo
signature.asc
Description: OpenPGP digital signature
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
