https://github.com/acagliano/lwip-ce/

So commandblockguy recently provided to me a variant of the lwIP library that he got to build for the CE but that lacks a hardware-capable communication interface. To this end, I'm trying to write a CDC-ECM driver that would allow this library to support the following modes of communication:
1. Connect to a computer, bridge the virtual Ethernet interface to your computer's Ethernet interface to allow networking (presumably host mode on calc)
2. Connect to a router, switch, or hub and communicate directly to them with a USB to Ethernet adapter (presumably device mode on calc).

As part of this process I'm trying to figure out how to properly handle the correct descriptors for a CDC ECM device. Command tells me I need device and configuration descriptors. What I'm not sure about is how to properly construct a set of descriptors for the calculator as an ECM device. I've been getting information from both Kerm and command that kind of conflicts on the best way to handle this, so hopefully by posting this here, I can get to the bottom of this. Would I be better served by dumping the the descriptors from a generic device and loading them in, or by perhaps using the structs provided in usbdrvce.h and filling them out with the correct hardware-specific info to the best of my ability?

I think you have those modes backwards: device mode when connecting to the computer, and host mode when connecting to the adapter.

To be extra clear, ACagliano is trying to solve two separate problems, namely both acting as a device that is somehow connecting to the computer's internet connection (which seems like a hard problem to me, especially without any kind of software running on the computer? This is a la gCn with Direct USB, which certainly required software on the computer) and also directly connecting to a USB-to-Ethernet adapter to access the internet without a computer.

Update

ECM driver test successful. As you can see from the screenshots above, we send a string over the wire, and the computer, running wireshark detects an ethernet packet containing the same string we sent over the wire.




There is still a strange bug where when the cable is pulled after the ecm device is initialized, the calculator hangs in usb_HandleEvents within a few cycles. Attempts to resolve this have been unsuccessful as of yet.

Next up -- backporting lwIP into this code and testing that.

After much continued development, backporting of the ECM driver into lwIP code, we have achieved a successful ICMP echo test.




Every now and again, one gets missed, but hey, the calc is slow.
Now to figure out why httpd_init doesn't work and do some testing with basic tcp/udp packets.

Update

Basic networking appears to function. What you will see below are screenshots, first of a basic UDP test, and second of a HTTP test page served... from my calculator.




There are issues with the DHCP client... I'm beginning to suspect this issue is specific to the DHCP implementation and not to the actual networking stack. I'll be doing more udp and tcp tests over the next few days. We're almost there folks.

Also, there is a TLS implementation already embedded into lwIP. As much as CryptX was a glorious thing, I think I am going to retire it in favor of using the TLS implementation within lwIP, while porting in some of the platform-specific implementations such as the RNG from CryptX.

Good work! It's pretty cool to see the calculator communicating!

Any plans to use the newer EEM specification?

Great work, this is awesome

I am pleased to inform that DHCP is now functional.
Part of the issue was that, because there was no await network up, DHCP would init and timeout before the link could actually go up. Adding an interrupt transfer and parsing for the NetworkConnection management notification before firing up network services seems to reliably fix the issue. Also we had to disable ACD.

I am currently working on a lightweight calc-based TCP chat client to distribute as public beta for testing. Who would be interested in being part of this beta test?

A fantastic milestone achievement for this project! Calc chat will be fun 😀

It's good to see a handful of internet related projects springing up!

I believe that tkbstudios has plans to rewrite his chat using this library. Also this a really good achievement.

A bit of testing done in CEmu to try to debug TCP only to discover it's working fine and I'm just dumb.
Either way, we got a nice screenshot of lwIP in action from CEmu. DHCP doesn't complete transaction bc it's a dummy network set up using a tap device.



Here is a link to a video of lwIP running on actual hardware, connected to a TCP server that receives UTF strings and then replies with the same string.
https://cagstech.com/images/demo/lwip_tcphw_test.mp4

Feast your eyes.


I think we are ready to release this to a limited subset of people for some private beta testing one day in the near future. Anyone interested in participating, please lmk either in thread, DM, or Discord. You will need:

1. Your calculator (TI-84+ CE)
2. A USB-miniB to USB-A OTG adapter
3. A USB-A to Ethernet device with an ECM configuration (NCM/EEM devices not currently supported)*
4. An Ethernet cable plugged into a router or switch.

You will also need the USBDRVCE library on your calculator.

* can anyone share some recommendations for how to identify an adapter that has ECM? I've noted that in a few cases the 10/100/1000 adapters tend to use ECM, while Gigabit adapters tend to use only NCM, but I'm not sure how reliable this is.

EDIT: You may get updates for the project or join the beta test by going to https://discord.gg/3hBR9QwJyC. When prompted for what you want to do, select "Help Test Things" and you'll be given tester role which will allow you to see lwIP's beta testing channel.

Addendum

If you are like some others I've talked to who feel like plugging their calc into their router is an inconvenience, I have good news for you. I have purchased and tested this device: https://a.co/d/igLQRQl. You need to use WPS to connect the adapter to your router, at which point, connect your USB-mini -> USB-A -> Ethernet rig to this adapter via an Ethernet cable and you can connect your calc to your network wirelessly. I imagine any similar device will also work as long as it supports Ethernet to WiFi and WPS as well as onboard encryption.

Cheers!

That would be epic to start seeing more projects with internet connectivity. Imagine being able to run Telnet and dialing a BBS on your calculator...

Wondering if I could setup a system using a Raspberry Pi Pico W instead, as it is cheaper and would allow straight up WiFi support without so many adapters. Could send info to the calc about networks, and yes, it would be called a PIpe.

I'm sure you could. There are many different ways of achieving connectivity with the internet. lwIP's intent is provide a completely internalized way of doing so (yes it requires a few adapters), but it's on-device and has a single point of failure as opposed to a 2-device system where both the calc and a Pi or computer are points of failure. Also I'd argue lwIP would be marginally faster as you don't need a device in the middle basically proxying the packets.
Edit: [Disclaimer] There's nothing wrong with using a bridged network (ie: the calc + Pi method). It works fine. Imo the only real drawback is the necessity of maintaining software for two platforms (the calc and the Pi) as opposed to just one. But at the end of the day, use whatever you feel to be most convenient.

The lwIP private beta will occur on Thursday at 7:30 PM US Eastern. I call it private because the executable is still not publicly released, but anyone who wants can hop into my discord server's lwip #beta channel and grab the installer binaries from there. There's an event scheduled as well, indicating where the beta will be discussed. It will also be live streamed to my YT channel, NefariousArcher. If there's a way to cross-stream it on cemetech, someone can let me know. Be aware that the voice chat will be in the stream and thus by being in the channel unmuted you are aware your voice may be streamed. Please take action to disguise your voice or mute up during the stream if you do not want that.
https://discord.gg/r4hpsTDh?event=1214766328921980928

Everyone come check out the stream. https://www.youtube.com/watch?v=fD2n7CzFeZU

Ok, I'm going to need some assistance.
This is like revision 6 of this NCM code that fails to send anything. I know it sends nothing because Wireshark on the computer detects no Ethernet frames from the device at all. I have followed the NCM spec to the best extent that I understand it, and TX refuses to send anything. I have even compiled a dump of the buffer being sent to the adapter and things appear correct. I even asked beck to take a look as well and compare it to his understanding of the spec and he didn't find any issues either.
The next step would be to plug the NCM adapter into the computer and see what it does but for reasons I can't get USB sniffing in wireshark working on OSX yet.
Can someone who may be knowledgeable on the NCM spec please take a look at this and help me understand what I'm doing wrong?

The driver code is at: https://github.com/acagliano/lwip-ce/blob/ncm/src/drivers.c
NCM RX is at line 263
NCM TX is at line 333
The dump file is at: https://github.com/acagliano/lwip-ce/blob/ncm/bin/ncmdump.8xv

Update

NCM is now somewhat functional, though I have noticed that UDP connection to servers isn't working.
Other protocols that use UDP, such as DHCP work, but attempting to sendto() a server fails. Pbuf allocation works, the packet hits the driver, the driver sends the TX and no errors are reported. But the packet does not reach the destination. Seems like a routing issue.

TCP works with NCM and appears stable.
UDP works for ECM only.
Does UDP do anything fundamentally different that would break routing under circumstances that wouldn't affect TCP?