Elks With a different networking stack

[parabyte]

my company been using a 8 or so year old version of elks with a really old version of Uip instead of Ktcp.
I spoke to company and explained really the source code should be released for public consumption as its from a open source project.
they agreed but i had to trim out a huge amount of propriatory code from the userland. and due to how outdated and kludged the sourcec tree was, it was just easier to merge the Uip from there elks into current elks and fix issues.

I hope someone finds this useful

elks with Uip

[ghaerr]

Wow, @parabyte, this is incredible! I'm studying this now to see how it works. Thank you very much for getting this published!

It appears the basics remain the same: the TCP/IP stack still resides in userspace, running as /bin/uip, and /dev/tcpdev is essentially replaced by /dev/netdev with cleaner code, but essentially copying socket data <-> network daemon the same way. The UIP port opens the NIC char devices explicitly just like ktcp did, which allows use of the same NIC driver model, and the glue in uip_main.c makes pulls it all together.

So in some sense, the architecture is much the same. But the big enhancements are UDP, and DHCP and local resolver clients, very cool. And uIP is apparently much easier to understand than ktcp? Is that about right or are there other major enhancements? I am not that familiar with uIP internally, nor am I current on how much has changed from its early (~2006?) version used here and a current version.

Have you much information on speed and buginess issues? That is, how fast does it compare to ktcp, and is the stack demonstrably better? There have been a number of problematic issues with ktcp with regards to ACK/syncing, etc between slow and fast systems, and of course UDP is entirely missing.

I am very interested to learn more about how much smaller uIP actually is than ktcp. What is the /bin/uip memory footprint? Also, huge enhancement being able to operate with ~20 users rather than ~6+ with ktcp. Is that limited by the /bin/uip heap?

Having DHCP and a resolver is huge. Do the remote SSL and SSH repos work? This is pretty awesome!

Also very interesting to learn about differences testing SLIP and ethernet within QEMU that does not work using ktcp.

I will continue to study this. Overall, a fantastic piece of work!!!

[parabyte]

only bit of work i did here was merge it with current elks over the last week.
the actual implementation was done by team of 3 over a 12 year period.
from the standard Uip that was released on github i believe 14 or so years ago.

Speed never been measured, only reliability. never really took notice of any speed measurements.

I will test on real desktop hardware with a compatible isa card in a week or so when home.

Basically how this whole Uip thing came about is the client has scientific measurement equipment very old equipment with x86 based boards, and obscure network cards. (that i am fortunate to have gotten the source code for the network card device from the company even after 25 years! even more so now cause these elks systems been in operation for years at this point)
They require the hosts to be functional with a internal name server and for multiple internal Desktop clients to connect and grab the sensor data.

we looked at all the options, and elks was a good fit for the pc/104 boards but also contiki was cause of its networking stack, so we kinda compromised