user156416
Member since Sep 2023 • Last active Apr 2024Most recent activity
-
- 35 comments
- 5,121 views
-
I did it again and can confirm I definitely released the button before
BOOTING
appears. Something I thought of is that somehow the way Espruino is using the flash for file storage could be overlapping with the nRF Flash Data Storage module that the Peer Manager uses for bond data storage as I've noticed Espruino seems to access the flash in a different way. But this is completely speculation.I will try and contribute some more wrapped bond management functions but I am a little scared to flash my bangle as I do use it as my watch.
Would I just use BLE DFU mode to test my builds on it? Would the bootloader be reflashed as well or does it just stay in place as other regions of flash are overwritten? I am a bit worried about wearing out the flash memory or getting it into an unusable state and having to open it up to reflash.
-
My bangle is on 2v19. I released the button as short as possible for it to still register a power on, releasing right as the "CHECK STORAGE" and "BOOTING" messages appear and the bond is still forgotten.
I am not exactly sure when this code is executed and the buttons are polled for the reset, but judging from the comments and macros this was designed to check if ALL buttons are held down, in this case the Bangle 2 only has 1 so it fulfills that condition.
I know this is Espruino code not specific to the Bangle, but the bangle also has the Recovery menu that appears to be triggered by holding the button during startup. I think that would be a good place to add a "Clear Bonds" option. I also think it would be good to add some granular control over bonds to the NRF class such as listing and removing individual ones, and then later on adding them to the bluetooth menu in settings app so regular users can manage all the devices their watch is bonded to.
I would like to help contribute these features to make the watch a bit more secure for everyone, I have some embedded experience, but I've never written an interpreter before and am not sure what files I should be looking at.
-
I've been wanting to use the whitelist with my Bangle as I don't particularly like leaving my devices unsecured. I am aware of the pin option but I would like to make the whitelist work. I've noticed people mention having issues on Android devices due to the apparently randomized MAC addresses. I have found the proper way to add these addresses to the whitelist but the bond info seems to be lost when the watch is turned off (through Settings>Utils>Turn Off)
My Android uses private resolvable addresses when connecting with Bangle.JS Gadgetbridge (nRF Connect seems to use my real public address, so the privacy option seems to be per app?). Private resolvable addresses can be resolved by bonded devices to obtain the public address.
If you bond to the Bangle while the whitelist is OFF, the Bangle can now resolve the addresses. You can now add your device to the whitelist by disconnecting (NOT removing the bond), selecting "Add Device", and connecting by tapping the Bangle card in Gadgetbridge.
Tapping the new whitelist entry you should see "XX:XX:XX:XX:XX:XX public (resolved)" with your unchanging public address. You can now connect and disconnect from the Bangle any number of times with the whitelist on as long as you don't turn it off.
Adding to the whitelist without bonding first will result in "XX:XX:XX:XX:XX:XX private-resolvable" being added to the list with a randomized address, as the Bangle does not have the IRK needed to resolve the public address.
I usually turn my Bangle off when it's off my wrist. I confirmed that the Bangle is unable to resolve addresses after a reboot by writing down and trying to resolve one of my phone's generated public-resolvable addresses using NRF.resolveAddress(). Before the reboot it resolves fine, but after the reboot it returns undefined meaning the address cannot be resolved.
I am not entirely sure, but this seems like it could be a firmware issue with the Nordic Peer Manager not successfully storing or loading bond keys and information from flash.
-
-
-
Starfield is the most recent game from Bethesda Game Studios (known for the Elder Scrolls and Fallout series). It is a futuristic space exploration RPG that has received a fair deal of press coverage.
As part of the collectors edition of the game, Bethesda worked with The Wand Company to produce a replica of the watch your character receives at the very beginning of the game. The watch and collectors edition are shown in this video at the timestamp.
I bought the collectors edition as I was rather excited for the game and was curious as to what the watch was running. I actually discovered Espruino by watching the firmware update process of the watch. I even bought a Bangle.JS 2 so I could play with Espruino more.
When connected to the IDE, there is no prompt and typed characters are not echoed but commands are still executed.
Here is the output of print(process.env)
{ "VERSION": "2v18.2174", "GIT_COMMIT": "f50bb7b20", "BOARD": "DICKENS", "RAM": 262144, "FLASH": 1048576, "SPIFLASH": 8388608, "STORAGE": 327680, "SERIAL": "xxxxxxxx-xxxxxxxx", "CONSOLE": "Bluetooth", "MODULES": "Flash,Storage,heatshrink,locale", "EXPTR": 566328, "APP_RAM_BASE": 536882880 }
I rather like the watch hardware, 4 buttons and a circular 240x240 screen with 16-bit color. Accelerometer, magnetometer, temperature, pressure sensors and a vibration motor just like the Bangle, although no GPS or touchscreen. It also has 2 (not 4) pogo pins on the back for charging. I am unsure if it a completely custom board or if it is repurposed with a custom shell.
If anyone has any suggestions I would be glad to run commands on it to learn about its hardware, as well as back up as much of the original firmware and files as I can. But I would prefer not to modify any of the storage to keep it as close to original as possible.
If it was retaining the bonds the whitelist would be able to resolve the addresses after a reboot and it cannot.
It appears to be re-learning the bond information after a reboot if there is no whitelist in place to stop it. Doing the steps you described with the whitelist off works the exact same way for me, the "Bonded" text never goes away on nRF Connect because Android retains the bond info irrespective of the watch.
Please try this:
public (resolved)
and notpublic
orprivate-resolvable
EDIT: Would this code be correct for dumping the 2 pages?
EDIT 2:
Android seems to stop and start using address privacy seemingly at random, I thought at first nRF Connect disabled it to make development easier, but the real
public
address (notpublic (resolved)
) started showing up while trying to add to the whitelist with Gadgetbridge.If I've done the code above correctly, I can confirm that the FDS pages don't get cleared on reboot which is what should be happening according to Gordon. Something else must be the problem, perhaps somewhere in the whitelist code. I will post more findings soon, I really want to get to the bottom of this.