RfidResearchGroup / ChameleonUltra

The new generation chameleon based on NRF52840 makes the performance of card emulation more stable. And gave the chameleon the ability to read, write, and decrypt cards.
https://chameleonultra.com
GNU General Public License v3.0
873 stars 147 forks source link

Start working on TCP comms #96

Open szymex73 opened 1 year ago

szymex73 commented 1 year ago

This change will allow for connecting to a TCP server that exposes the chameleon serial interface, similar to how the PM3 CLI allows for connecting to a TCP server exposing a Proxmark. This should allow for the use of the CLI on devices like Android phones with Termux.

Currently, it's working for communicating with a device but needs a bug fixed with a thread locking up when trying to close the socket.

github-actions[bot] commented 1 year ago

You are welcome to add an entry to the CHANGELOG.md as well

github-actions[bot] commented 1 year ago

Built artifacts for commit b8e11bd6791913c22972b553dfa7a34232ef88fa

Firmware

Client

doegox commented 1 year ago

Just sharing some thoughts, feel free to ignore, I don't want to make your life harder neither unless you think it's worth investigating...

To also support BLE in CLI, the way seems to use Bleak, which is based on asyncio. If we move to a unified asyncio model for transports, there is also pyserial-asyncio. Now for TCP, if you use Streams it's also asyncio.

So, maybe should we investigate moving to a unified asyncio API for transport? (I must confess I've always more difficulties thinking with async than sync, but well...)

GameTec-live commented 1 year ago

Just sharing some thoughts, feel free to ignore, I don't want to make your life harder neither unless you think it's worth investigating...

To also support BLE in CLI, the way seems to use Bleak, which is based on asyncio. If we move to a unified asyncio model for transports, there is also pyserial-asyncio. Now for TCP, if you use Streams it's also asyncio.

So, maybe should we investigate moving to a unified asyncio API for transport? (I must confess I've always more difficulties thinking with async than sync, but well...)

migrating to async might be worth it to prevent future issues, etc.

szymex73 commented 1 year ago

It would require some rearchitecturing but I do agree that going async might be a better choice with the transaction model we currently have. Could take a look at that pretty soon but can't say for sure