Forum TI-Planet.org

Congrats!

I was on the live youtube for just a bit (enough to see it working ) so I can attest it's pretty cool 😎

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: Select all

git clone https://github.com/acagliano/lwip-ce # into whatever dir you want
cd lwip-ce
git submodule update --init --recursive


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.

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.

Hello,
I have a Ti-83 Premium CE, does lw-ip will work on it?
And I didn’t know how it’s work, can you explain me?
Thanks-you

tom-garnier wrote:I have a Ti-83 Premium CE, does lw-ip will work on it?

If it's an ez80 cpu, perhaps. Try it out and let us know.

tom-garnier wrote:And I didn’t know how it’s work, can you explain me?

It's not an easy thing to figure out but the main.c stub is a good starting point.

Headers

Code: Select all

// I recommend you include these 4 files AT LEAST for basic functionality.
// init and timeouts are needed to initialize the stack and to poll the timers
// netif is optional; since the usb interacts with netifs internally, you will need to poll for an up netif and use it
#include "lwip/init.h"
#include "lwip/timeouts.h"
#include "lwip/netif.h"


Initialization

Code: Select all

lwip_init();     // <== start with this before using lwip; it initializes the stack

// initialize the usb ethernet drivers
usb_Init(eth_handle_usb_event, NULL, NULL, USB_DEFAULT_INIT_FLAGS);


The above should come before pretty much anything.
Using lwip is modular. So what this means is that you have to make use of the API for whatever protocol you plan to use. For example, if you want to use TCP, you need to include "lwip/tcp.h" (or altcp.h). You will then need to follow the documentation provided by non-gnu for using it.
https://www.nongnu.org/lwip/2_1_x/group ... __api.html

*NOTE* you can only use the callback API ("raw" API). Anything else does not work on the calculator because it's NOSYS.

The 83PCE is the 84+CE with a better-featured OS (exact math engine), so the code really ought to work on both models.

Also I added better usage directives to the readme.
Hopefully this helps anyone aiming to use it.

https://github.com/cagstech/lwip-ce/blo ... /README.md

The work on TLS has begun.
https://github.com/cagstech/lwip-ce/blo ... ls/INFO.md

This file presents some notes on what cipher-suites are required versus what we can currently support and notes on what else would need to be implemented.
We are (or more accurately--I am, unless others offer help) building a TLS implementation completely from scratch in ez80 assembly.

I therefore request prayers for the state of my soul. Though, assistance from any who know cryptography would work as well.

TLS Implementation Progress

lwIP has been seeing strides towards a full TLS infrastructure baked into ALTCP with an exposed API for people to use for other purposes. Here are some of the recent bits of progress.

1. SHA-256 is ported, HMAC wrappers are ported.

2. TLS rand is ported with a new algorithm that is computed to produce even more entropy than the previous... 100.2 bits of entropy per u64. See computations: https://github.com/cagstech/lwip-ce/blo ... ls/INFO.md. The probabilities are based off the maximum allowable bias in the sampling.

3. AES CBC and GCM modes are ported -- I am dropping CTR. It's redundant of GCM but lacks authentication. CBC is there for file encryption mainly.

4. Base64 and ASN.1 are ported and an ASN.1 encoder is now provided as well. ASN.1 decode sports a better UI:

Code: Select all

bool tls_asn1_decoder_init(struct tls_asn1_decoder_context *ctx, const uint8_t *data, size_t len);
bool tls_asn1_decode_next(struct tls_asn1_decoder_context *ctx, const struct tls_asn1_schema *schema, uint8_t *tag, uint8_t **data, size_t *len, uint8_t *depth);


Simply initialize the decoder with "init" and then loop "decode_next" until false is returned. This function automatically traverses the tree structure properly.
It also takes an optional parameter (NULL to omit) that is a schema. Essentially this allows you to create arrays of structs containing schema data for what field names, tag values, some flags, and depth are expected in various positions in the struct. The schema struct also has fields for if a tag is optional (a mismatch returns true anyway), whether null is allowed, or if this field output is wanted (if this is passed as false, the passed pointers to len, tag, data, and depth are not touched). To see how the schema allows for easy parsing, check out https://github.com/cagstech/lwip-ce/blo ... eyobject.c

5. It follows from the previous but decoding of PKCS#1, SEC1, and PKCS#8 public and private keyfiles is now fully supported. The user can generate a .pem file with openssl, run it through convbin to create an .8xv, send it to their calc and it should be recognizable by the keyobject module. This includes encrypted private keys although -- and this is very important -- the only algorithms that are supported for this are: PBES2 (password-based encryption scheme) using PBKDF2_HMAC with SHA-256 and ciphers AES-128-CBC or AES-256-CBC. For reference a command that can create what is needed is:

Code: Select all

openssl pkcs8 -topk8 -inform PEM -outform PEM -in <private_key_path> -out <encrypted_key_path> -v2 aes-128-cbc -v2prf hmacWithSHA256 -iter <whatever>


Just remember this is a graphing calculator, so you probably want -iter to be something low. Like 100 (a few seconds) or 1000 (~30 seconds).
I plan to support for decoding X.509 structures as well, for reading certificates sent by remotes during handshakes.

Update to an update

Houston we have X.509 implemented.


Next step is to research commonly used CA roots/intermediary roots and add their public keys to a "trust store" that I will dump into an appvar. Because of the speed of the calc, this will be optional. You can either not send the trust store to your device or enable implicit trust in the tls configurator to not validate certificates.