Hi all,
sorry for the delay, but speaking of NAT components that spare IP addresses, I wanted to make you guys aware of my diploma thesis which treated exactly that topic, albeit on Linux:
http://os.inf.tu-dresden.de/papers_ps/unzner-diplom.pdf
In contrast to the source code that I wrote back then, for Genode, we would require a C++ solution which does not need Rump kernel patches (as that is not feasible in the long run) and performs a lot better. Also, unit and integration tests are missing, and by now I think they are a must-have.
My code base is quite small already, so all these issues call for a rewrite. I will see how far I can get with that effort, but it being a spare-time project of mine it is possible that I do not get anywhere at all.
Hence, if somebody wanted to work in that direction I would be glad to support them.
Cheers!
Martin
Am 23.12.2014 um 22:36 schrieb Christian Helmuth:
Hello,
thanks Norman for starting this already fruitful discussion right before the holidays - I'm looking forward to all the messages from the community.
Beside the desktop environment and pushing the exciting ideas of a data-centric approach for our user interface I see further challenges in the field of networking. With LAN and WiFi access on a good path, we should invest more time into network interoperability. First, the good old NIC bridge needs a companion NAT service as environments like hotel WLANs are not that generous with multiple IP addresses per client. Next, the new NAT component as well as existing services and drivers need to become adaptable and sensitive to changing network environments - also a manual approach would be feasible IMO.
Further (as Josef and Ben also brought up), the user interface to network services must be enabled. I would be more than glad with good old mutt plus IMAP sync and Chrome on Genode. Especially the latter sounds like a worthwhile challenge.
Greets and Happy holidays