IMPORTANT Firmware Update for the Eggtimer Quantum, Proton, and Quasar

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

cerving

Owner, Eggtimer Rocketry
TRF Sponsor
TRF Supporter
Joined
Feb 3, 2012
Messages
6,354
Reaction score
5,566
We have had two reports of people in the field having their Eggtimer WiFi-enabled altimeter fire a charge on the pad. In both of those instances, the user had "swiped" the page from a deployment test that they had just conducted (instead of the recommended procedure of closing the page), powered off their altimeter, put the rocket on the pad, restored the "swiped" page, then connected to the altimeter again. Essentially, this is a browser "replay"... the browser is re-sending the last request to the server (your altimeter), and if the conditions are right then the server will repeat the last response (in this case, performing the deployment test). This is is essentially the same as being on a shopping site and clicking on "Pay" twice... since the server is busy handling the first request when you click on the second one, it caches the request and resends it when the server becomes available again. And your credit card gets billed twice.

The technical reason that this happened (besides not closing the page...) was that the 4-digit validation code that was entered into the deployment test page and imbedded in the browser's request was still valid in the altimeter, because the request was the first one that occurred after power-on. Previously, the validation codes were generated with a psudo-random number generator, the codes changed "randomly" but they were always in the same sequence after power-on. Since the user performed these tasks right after power-on, they got the same code, so the "swiped" page request was still valid, and the altimeter honored the request.

Although this is technically not the fault of the code (it did what it was told to do), we have made a change in the firmware to prevent such a browser replay from occurring. We have changed the validation code generation routine so that it is based on the number of milliseconds that the altimeter has been powered on, rather than a psuedo-random number generation. The validation codes no longer repeat on successive power-ups, no longer repeat in the same sequence, and it is extremely unlikely that a cached/swiped page will have the active validation code imbedded in them. We have also highlighted several times in the documentation that the recommended procedure after you have submitted a deployment test or arming page is to CLOSE the page, NOT "swipe" it "closed" (since swiping it does NOT close the page). Firmware updates with this updated code are now on the EggtimerRocketry.com web site under the Support tab, for the Quantum, Proton, and Quasar altimeters.

Although this "bug" is a consequence of going against the recommended operational procedure, we recommend that all users update their firmware regardless.

As usual, thanks for your continued support!

Cris Erving, Eggtimer Rocketry
 
I’m a little confused, so the random number generator was making a numbers in a way that the browser could have the valid number even if the egg timer was shut off? Or was it making the number right but it hadn’t made a new number by the time the request was sent?
 
The old "random" number sequence repeated on power-up, so if somebody cached/swiped a page that happened to have the same code as the active one it could repeat the command. It would have to have been submitted in the same 60-second period since power-up, since the codes change every 60 seconds after connecting. Since a new code is also generated on the page being opened or refreshed, this can't happen if you close the page after it's been submitted... which is what we have always told people to do.
 
The old "random" number sequence repeated on power-up, so if somebody cached/swiped a page that happened to have the same code as the active one it could repeat the command. It would have to have been submitted in the same 60-second period since power-up, since the codes change every 60 seconds after connecting. Since a new code is also generated on the page being opened or refreshed, this can't happen if you close the page after it's been submitted... which is what we have always told people to do.
Ok thanks, I’ll go update mine.
 
Yes, this is confusing. It took nearly a week to figure out what the user had done that made this happen... but the bottom line is that if you close the deployment test and arming pages after you're done with them, you won't have any issues, regardless of which firmware version you're running.
 
I’m a Closer not a Swiper but could use the practice updating firmware.
“Swiper no Swiping!” (inside joke for those with young kids/Dora fans)
 
The old "random" number sequence repeated on power-up, so if somebody cached/swiped a page that happened to have the same code as the active one it could repeat the command. It would have to have been submitted in the same 60-second period since power-up, since the codes change every 60 seconds after connecting. Since a new code is also generated on the page being opened or refreshed, this can't happen if you close the page after it's been submitted... which is what we have always told people to do.

If you want a really good random number generator, try plugging into my wife's head....

Hans.
 
I’m a little confused, so the random number generator was making a numbers in a way that the browser could have the valid number even if the egg timer was shut off? Or was it making the number right but it hadn’t made a new number by the time the request was sent?
Software dev here. Probably a surprising fact to folks not familiar with how computer processors work… but computers cannot do randomness. They do exactly what they are told, no more and no less.

When a random number is needed for something, math algorithms have been developed to simulate a random sequence but these always need a starting point or “seed.” What Cris has done is to change the seed.

@Cris nice find—that had to have been tricky to debug.
 
Software dev here. Probably a surprising fact to folks not familiar with how computer processors work… but computers cannot do randomness. They do exactly what they are told, no more and no less.

When a random number is needed for something, math algorithms have been developed to simulate a random sequence but these always need a starting point or “seed.” What Cris has done is to change the seed.

@Cris nice find—that had to have been tricky to debug.
I know that, I just didn’t want to say pseudo random.

Ps I just realized that egg timer is a exception, it has a barometer and if cris gets bored enough he could do this, True random numbers.
 
Thank you for fixing this. It had happened to me before when I was doing ground testing (with a quantum). I had tested a charge that was too small and then replaced it with a larger charge and powered on the altimeter. When I connected and opened Safari on my Iphone, it immediately fired, because it resent the request (with the same pseudo random code). Lesson learned. Now I close the safari page/tab after each test.

I do like the idea of using the baro (which includes temp and pressure?) to seed a random number generator.
 
I’d think so. But I don’t know what I’m talking about.
It doesn't affect the switches because if you replay the last command it's just going to tell it to do again what it already did. If it's on, it will tell it to turn on, if it's off it will tell it to turn off. No harm, no foul. I'll probably update the firmware for them anyway, but I have other features that I'd want to put in first.
 
I need more Quantum Altimeters to Build :D. Does the Same firmware work on the A18 and B2 versions?
Yes, the firmware works with all versions of the Quantum. I actually tried it on an A12, an A18, and a B1. We've released five versions of the Quantum over the years... they're all compatible. Ditto for the Proton versions (A9 and C14). We try to make our versions all firmware-compatible if at all possible... the only device we've ever released that had multiple firmware versions was the Eggtimer TRS, because we had to change out the baro sensor and we couldn't find a way to poll the sensor to see which one it was without hanging the altimeter.
 
Yes, very tough bug to find.

I did have this haapen once last year when settinh up ejection charges and testing. Never figured out what I did or have it happen again so left it alone.

I use an iPhone. How do I close an app (Safari) properly?
I have always hit the home button twice then swip the reduced app off screen to close.
 
To completely close the page in IOS/Safari, minimize the page by clicking on the tile view icon in the lower-right corner of the bottom toolbar (it looks like two squares), then click on the "X" in the upper-right corner of the tiled web page. Swiping or minimizing the page does not close it... the page is still open, it's just not in the active context.
 
That's a little extreme... but yeah, that would do it too.

It's amazing how many people don't close web pages. My wife sure doesn't... when her phone starts bogging down, I usually find about 50 pages open. Plus about 20 Facebook pages...
 
That's a little extreme... but yeah, that would do it too.

It's amazing how many people don't close web pages. My wife sure doesn't... when her phone starts bogging down, I usually find about 50 pages open. Plus about 20 Facebook pages...
Yup they drive me insane, I cant have more than 5 tabs at once.
 
Back
Top