With modemmanager you get a lot of nice stuff for "free", like automatic reconnect, DHCP, good logging, and an APN database (useful if you don't provide your own SIMs). It also allows you to easily set up correct priorities between WiFi and LTE, both for routing and DNS. Especially DNS is something I didn't think about at first, but the DNS server provided by your LTE connection is not always reachable over your WiFi/ethernet connection.
You can run modemmanager in debug mode, which allows you to send AT commands over dbus (or mmcli) in case you still want to configure some stuff manually or get debug info.
Have you experimented with modemmanager/networkmanager to handle the configuration of the modem? For me that has worked quite reliably across a pretty large fleet of devices with a Quectel EG25 (qmi over usb).
Regarding FW updates, have you tried opening a support ticket with Quectel? For me they have been extremely responsive and helpful, providing extra documentation on special AT commands and stuff.
In this case the EPS already came stock with the functionality to request torque over CAN, that part of the code or the amount of torque was not touched. I agree it would not be a good idea to patch that functionality into an EPS that doesn't come with that from the factory.
Ghidra uses an intermediate language called p-code. When defining the CPU opcodes (and how to parse them), you also write a small snippet of p-code that represent that instruction. This makes the decompiler architecture agnostic.
The XOR encryption was just for the update container. Newer update files usually employ some stronger forms of compression/encryption. However, it's usually some strange in-house crypto, so eventually people figure it out.
bri3d refers to using RSA signatures on the firmware once it's written to the flash. By ensuring the firmware is signed using the manufacturers private key it should (in theory) prevent messing with the firmware, even if all encryption/flashing steps have been reverse engineered.
At some point the values have no deeper meaning and are just whatever VW decided on as their API. DBC files have concepts of enums, but that’s really diminishing returns and wouldn’t make the code that much easier to understand.
Also sometimes there are fixed values in the message that we’ve only observed as static data. Ironically that makes it impossible to reverse engineer what they mean. So those just have to be labeled as hardcoded value.
Those are actually magic. Those are the ECU firmware identifiers from the manufacturer that are used by openpilot to recognize which car it’s connected to.
The file you referenced is related to Ford, which is not a supported car/brand. The code for Ford is provided as a reference and is forced into “read-only” both by openpilot and panda (the bridge between openpilot and the car).
Seems like the https://www.vector.com/int/en/products/products-a-z/hardware... has some similar functionality. I have never used it, but by reading the documentation I'm not sure if it would have been useful here. The frame with ID 65 which needs be overwritten, actually contains 4 different messages indicated by the last byte in the payload. To properly time the modification you need to sync up on that, which the Vector box can't do.
Also price on request, so probably not in the price range of our target audience.
This is the config I'm using: https://github.com/commaai/agnos-builder/blob/master/userspa...
You can run modemmanager in debug mode, which allows you to send AT commands over dbus (or mmcli) in case you still want to configure some stuff manually or get debug info.