Update

NCM now tested and stable. The issue was due to me forgetting that pbufs are not a continuous region but instead a chain whose payloads may be in different places. With the appropriate edits made, the issue is resolved and compliant adapters with an NCM configuration can now be used with this project.
Since calculators are too slow for it to matter, NCM TX still is one Ethernet frame == 1 TX (with the appropriate NTH/NDP headers).

Additionally, at commandblockguy's urging, the appropriate modifications have been made to support an arbitrary number of compatible USB devices. Instead of a reserved `eth_device_t` object, upon successfully identifying a compatible device, malloc is used to reserve the space for the `eth_device_t` which contains the usb device address as well as the netif structure. We then use both usb_SetDeviceData() as well as the netif->state field to record the pointer to this region. That memory is then freed in response to the device disabled or device disconnected event.

I have have to do a bit of tinkering to sort some undefined behavior, such as move the NCM sequence counter into the ethernet device structure and some other things, but by and large, everything seems to be working gloriously. I did a quick test with my server with Jake the other day and there were again no client-side issues identified.

Thanks, for letting me participate in the beta tests. I am looking forward to the future progress and I am already amazed by what has come. I'm glad the community has come this far in general calculator programming. It's amazing what this community has accomplished.

Update

NCM is now merged to stable.
https://github.com/acagliano/lwip-ce

Preparation for distribution as a dylib is underway. In the meantime, if anyone wants to download the source, modify the main.c file to connect to other servers and edit the callbacks/main function in accordance with whatever a service they want to experiment with requires, have at it.
Keep in mind that there is a modified build environment here to make this build in lwip's format and I'm already aware that it doesn't play nicely with Windows, so if you require assistance getting this to build properly, let us know.

Meeeee!!

I may use this library for something cool. Among Us on TI-84 Plus CE, possibly.

So after discussion with commandblockguy, it has been stated that proper implementation of dynamic linking (especially for something so large) is going to take time to be done right, and for the time being the recommendation is that people who want to make use of this project do so statically. Once something for a dylib is available we will update, but for now we will release this in a manner in which you can just clone it, and edit main.c to write your app. This will, sadly, mean that for now anything using this needs to be an app, else it is just too big.
A usable version will be published later this evening.

[EDIT]: Public Beta Time
https://github.com/acagliano/lwip-ce
The latest commit should be usable as a static library. Please comment if you have any trouble. Unless you know what you are doing it is highly recommended that you touch NOTHING in the drivers folder, or any folder that is part of lwIP.
Please report on any issues you encounter.

Do we have to build it using the toolchain?
Cuz the toolchain isn't working for me.

Yes. There may be something command needs to fix in the makefile for it to work on Windows. Unless you've just...never gotten the toolchain working.

I haven't gotten it working at all.

EDIT: I had to reinstall to get cedev to work properly. At least it works now.
EDIT 2: where are the contents of app_tools?

* To answer the above questions and declare the beta more succinctly...

Public Beta Released

The implementation of lwIP for the TI-84+ CE is now officially moved into public beta as we await work from the toolchain devs on a method to make this a dynamic library. I was advised by commandblockguy that at present we use this as a static library.

Source: https://github.com/acagliano/lwip-ce
Simply run the following commands to set yourself with a working repo:


Code:


This will clone the repo and fetch app tools. For now, anything using lwIP will need to be build as an app due to the sheer size of the code-base; please do not abuse the tool for things that do not absolutely have to be an app.

For drivers, I have implemented USB CDC for ECM and NCM devices. This means that most 10/100/1000 and most Gigabit adapters will work fine. You may also use a WPS-capable Ethernet-Wifi adapter. WPS is needed because SSID polling and selection is not a thing, although if anyone would like to write, test, and submit a driver for that for a specific chipset, please do so.

It is the intent with this project to allow addons via extensions/modules that users can drop in that lwIP will load, either via some internal call like (eg) lwipce_load_ext(TLSDRVCE) [this would load a hypothetical TLS implementation) or as a dynamic library via LIBLOAD (more on that later - WIP). This would allow users to hypothetically build applications like HTTP(s), SMTP, SSH, as well as to extend the driver set (ex: adding a driver for a wireless card). We are unsure at present how this would actually function internally and are open to suggestions.

I wanted to get the community's opinion on the necessity of something. More specifically one portion of this. I have one person saying yes, another saying no, and another saying "cool".

I was toying with the idea to make lwIP not just be a library that other programs can access (at least when it's dylib-capable), but to also have it be a launchable utility that brings up an interface where you can configure the library directly for some automated options, like so:


Code:


These configurables would save into an appvar and be loaded by lwIP when it initalizes. Some are pretty straight forward. Enable IPv6, auto-start DHCP, and configure system clock should be pretty straightforward.
The security options might need a bit of an explanation.
With some tinkering to the IP layer handling it's possible to implement IP-based packet filtering. You'd essentially have a user-configurable IP blacklist that gets loaded at lwip_init(), and during parsing of any packets to/from that IP, it filters matches. It would be a static filter with IP match and IN/OUT chain rules only.
Secondly would make lwIP request that a program hash (or CRC [eww]) of the calling program and then connect to a software mirror when firing up a network connection and send the hash computed for the current program. If the hash does not match a published hash for an official release of the program the user is informed and asked if the user wants to deny internet access to the application. I suppose this would be considered an application level firewall.

Any thoughts? This would obviously slow down network connection and packet parsing a bit, but might it worth trying to implement?

General configuration sounds like a good thing to provide a common interface to; that saves a fair amount of complexity for application authors to manage the configuration. It should be possible for an application to request that a non-default configuration be used, however.

Firewall-like features seem like unnecessary complexity and are best omitted, at least initially. Unlike on a PC I would expect connecting to the Internet at all would typically be an opt-in thing, and integrity checking is best done at program acquisition time since programs are not frequently updated and are fairly difficult to modify in binary form: if you wanted to compromise a program, you'd be better off replacing the C libraries with malicious ones which program checksums wouldn't see.

I think it'd be great to be able to use IPv6. And I love settings menus.

At present IPv6 is always enabled. lwIP determines which version to use depending on the router defaults and the class of the IP you provide it (for example, if you pass it an IPv6 IP address, it will autoselect IPv6 routing for that connection/packet, but if you give it IPv4, it will use IPv4). DHCP is probably going to use IPv4 unless the router has IPv6 enabled, in which case it will use whatever the defaults are. So I'm not sure we even need interaction from the user in that regard, now that I think of it.

Update - TLS

So I've begun some work on trying to figure out how lwIP calls into its preferred TLS library... mbedtls... for use with, well TLS. I see that the application (apps/) altcp_tls seems to provide an abstraction layer on top of altcp that implements the callback functions for handling various stages of the TLS handshake. I am currently trying to sift through this mess to see where it calls into mbedtls to possibly replace it with a simpler, watered down implementation that supports a few choice algorithms. This will probably be the phase at which CryptX merges into this project [while remaining also standalone for application level stuff, but with no further major releases]. We'd definitely need to port the RNG in. But there are other requirements, more along the lines of algorithms. Here are the algorithms I would like to support:

ciphers: aes-cbc, aes-ctr, aes-gcm, aes-gcm-siv, rsa, ecc*
hashes/hmac/mac: sha-1, sha-256, sha-512, cbc-mac
codex: asn1, pkcs1, pkcs8, secg1
SHA-1 is implemented but is buggy and is being worked on.
*ECC as implemented supports SECT233k1 but can support any GF2 with modification to no longer hardcode the polynomial. If we want to add support for prime curves, an entirely new (and optimized) set of algorithms would need to be written.

The other thing we would need is:
modular exponentiation: uint2048_t ^ uint2048_t % uint2048_t
Our existing powmod written by jacobly covers exponent of uint24_t. This suffices for RSA encryption, but does not suffice for RSA decryption or RSA signing (which encrypts using a private key).


I'll be honest, I'm worn out. CryptX wore me down, lwIP wore me down, so my ability to sit down and labor away at more encryption logic is...quite depleted at the moment. Nonetheless I do want to do this and I will get it worked on, but probably slowly, starting with the RNG, then AES, the hashes, and the then the rest. That being said... if anyone in the community feels comfortable enough with crypto logic and has the time/willingness to help out, i would appreciate it. In the list of algorithms above, green indicates fully implemented algorithms, orange indicates something probably needing to be modified/expanded for inclusion into lwIP, and red indicates something we probably should add and hasn't been previously added. If you want to contribute something, you can clone the repository, move to the tls branch and add files to the src/tls directory.

Indeed, you need to take a breather, as getting too worn down is serious

I got myself somewhat worn down from libti* by the rework of the lab equipment support (in addition to work load in the day job, of course), and I switched back to playing computer games (quite a lot, even), as well as unexpectedly co-maintaining memtest86+... it's been quite a while, and I've never been completely back in the libti*/gfm/tilp game since then.

Its so wild how much it drains you. And then you get this second wind and its like let me open this and you see a bunch of l1%t and some l2*p and your brain goes "lmao you really thought".

At least the good news is much of it is usable as is.