redox issueshttps://gitlab.redox-os.org/redox-os/redox/-/issues2023-06-13T04:42:49Zhttps://gitlab.redox-os.org/redox-os/redox/-/issues/966Rethink the network interfaces (network scheme, drivers)2023-06-13T04:42:49ZJeremy SollerRethink the network interfaces (network scheme, drivers)*Created by: real-unoriginal*
Currently (it seems) that redox has two nic drivers, each of which when ran mounts the **one** nic directly to the *network* scheme. The additional networking daemons that use the *network* scheme directly ...*Created by: real-unoriginal*
Currently (it seems) that redox has two nic drivers, each of which when ran mounts the **one** nic directly to the *network* scheme. The additional networking daemons that use the *network* scheme directly or indirectly also depend on the fact that there is only one interface (so there is no routing table for example).
This design makes using more than 1 physical nic at the same time impossible. Also since many networking protocols (eg: PPP(oE), WIREGUARD) that require setting up virtual network interfaces (that than will be used to route appropriate IP packets through), currently they cannot be implemented.
In order to fix this we would need to do something similar to the *disk* schemes, that mounts multiple disks as *disk:/1*. *disk:/2* etc. The following questions arise:
* How to name physical interfaces (traditional eth{x}, something like systemd does: "enp0s3" or the same as *disk* names disks /1 /2 /3 ...) ?
* Where do virtual interfaces are connected to? Do we mount them under the network scheme too or do we want to make a separete scheme for phisical nics, and virtual ones?
* Who maintains the routing table (ipd?)? When creating a new virtual interface that has an ip address and can reach a set of ip adresses how do we signal this to the daemon that maintains the routing table?https://gitlab.redox-os.org/redox-os/redox/-/issues/647OS level support for TLS sockets2023-06-13T04:42:45ZJeremy SollerOS level support for TLS sockets*Created by: NilSet*
TLS (aka SSL) in the form of libraries like OpenSSL is unwieldly to use. We should expose a sockets api which is in line with other socket types like raw, TCP, and UDP sockets, using sane default parameters which ca...*Created by: NilSet*
TLS (aka SSL) in the form of libraries like OpenSSL is unwieldly to use. We should expose a sockets api which is in line with other socket types like raw, TCP, and UDP sockets, using sane default parameters which can be tweaked through setsockopt.