{"action":"created","issue":{"url":"https://api.github.com/repos/digistump/OakCore/issues/54","repository_url":"https://api.github.com/repos/digistump/OakCore","labels_url":"https://api.github.com/repos/digistump/OakCore/issues/54/labels{/name}","comments_url":"https://api.github.com/repos/digistump/OakCore/issues/54/comments","events_url":"https://api.github.com/repos/digistump/OakCore/issues/54/events","html_url":"https://github.com/digistump/OakCore/issues/54","id":137819686,"number":54,"title":"BOUNTY: Find a workaround/fix for update issues - $1000","user":{"login":"digistump","id":1514319,"avatar_url":"https://avatars.githubusercontent.com/u/1514319?v=3","gravatar_id":"","url":"https://api.github.com/users/digistump","html_url":"https://github.com/digistump","followers_url":"https://api.github.com/users/digistump/followers","following_url":"https://api.github.com/users/digistump/following{/other_user}","gists_url":"https://api.github.com/users/digistump/gists{/gist_id}","starred_url":"https://api.github.com/users/digistump/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/digistump/subscriptions","organizations_url":"https://api.github.com/users/digistump/orgs","repos_url":"https://api.github.com/users/digistump/repos","events_url":"https://api.github.com/users/digistump/events{/privacy}","received_events_url":"https://api.github.com/users/digistump/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":27,"created_at":"2016-03-02T09:24:37Z","updated_at":"2016-03-03T12:51:41Z","closed_at":null,"body":"**Skills Required:** System Admin, Node, C++, Linux Sockets, ????\r\n**Difficulty:** Unkown\r\n\r\n## Challenges/Thoughts:\r\n\r\n**The technical limitations:** The firmware shipped on the Oak is solely there to let you configure your wi-fi and get the first update, it, of course - given the Oak does not have a USB interface, cannot be changed except for with this update, so any changes to make this work have to happen on the server side of things.\r\n\r\n**The technical details:** The Oaks preformed very well in our early testing at getting the update, before we sent in the firmware to the factory, while this was tested in a variety of ways the main development setup had the update file hosted on an Apache 2.2 server on Amazon EC2, and was being accessed from our machines over a 3mbps DSL connection. We also tested with it locally on our b/g/n wifi network. Our routers were run stock for testing with b/g/n enabled and auto for channel. - Between this point where we approved the firmware to be burned to the units and when people started to report issues the following changes occurred (or may have occurred): The hardware went from prototype to production, with likely ever so slightly different parts that should not have effected any performance and the update file was moved to an Apache 2.4 server on Ubuntu 14.04 on Digital Ocean (and then to various server setups - see github for more on this). After this updates were still working very well for us, since we didn't think it was an area we needed to worry about I can't say for sure if one ever failed, but they never failed enough to even catch my attention as a possible issue before I started shipping the factory produced units. The final point, and given that the update still works for me more than it doesn't over DSL, but not always over the local network, is why I believe connection speed may be involved.\r\n\r\n**Issue specifics**: Specifically the Oak seems to either disconnect from the server prematurely or fails to get the next packet/chunk of data from the server. This usually is seen on the oak as a Socket Timeout or the Oak restarts because the watchdog timer kicks in after it sits in a loop doing nothing for awhile. If the Oak makes it to the end of the update it works. This may have to do with WiFi interference (we don't expect you to magically make it work even if other things are on the same channel as the Oak) - we are just trying to get it to work with a minimal set of rules for the user (make sure your router is not on channel 1 is acceptable, make sure your router is set to B only and 1mbps is probably not). For some rather extreme router settings that seem to work, and support our idea that this is speed related please see this post by a fellow beta tester on the forums: http://digistump.com/board/index.php/topic,2046.0.html\r\n\r\n**Things we've tried:** We've tried various server setups including apache and basic node.js ssl servers. We've tried using Node.JS to make a custom https server that slowly pushes chunks of the firmware to simulate a slower connection. This seemed 100% reliable at one point in our testing, and then it wasn't any more, no idea why - but it is worth noting that the linux sockets buffer this data anyway, so it was unlikely this was actually helping, but we really don't know for sure yet.\r\n\r\n\r\n**How to test:**\r\n1. Generate a self signed certificate for your IP or domain you'll be using to test with, or use your existing SSL certificate if it is compatible. (a sha256RSA certificate is best for testing to avoid issues due to the certificate being incompatible)\r\n2. Get the fingerprint of that certificate and copy it.\r\n3. Restore your Oak to factory condition with github.com/digistump/OakRestore\r\n4. Open an Arduino Serial monitor on the port of your Oak/USB adapter connected to the Oak, select new line only from the drop down as to what line endings to send and baud to 115200, and then send (hitting enter after each line below:\r\n```\r\nset\r\n40 (where 40 is the length of the next line including the JSON markup)\r\n{\"first-update-domain\":\"yourdomainorip\"}\r\nset\r\n90\r\n{\"first-update-fingerprint\":\"00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\"}\r\n```\r\nwhere yourdomainorip is the domain or ip you are testing with, and the 00s are replaced by the SHA1 thumbprint of your SSL certificate. Your Oak will now expect this certificate, connect to this domain or IP, and expect the firmware file at /firmware/firmware_v1.bin (grab the latest firmware here to place on your server for testing: https://oakota.digistump.com/firmware/firmware_v1.bin)\r\n\r\n**NOTE** You should have these strings ready to send as there is a 30 second timeout between sending the set and sending the json string.\r\n\r\n_The Oak should respond with {\"r\":0} after each three lines (set, length, content) are sent - if you get {\"r\":-1} back then something is wrong with the input._\r\n\r\nTo confirm you have changed the two parameters send over serial these two lines:\r\n```\r\ninfo\r\n0\r\n```\r\nYou should get back a JSON response that includes those two settings.\r\n\r\n5. Now use the config app (github.com/digistump/OakSoftAP/) to set your wifi info, and when it says it is restarting to get the update disconnect it and use the OakRestore instructions but substitute this at the command line (grabbing the zip file in the comment below this to get the bin files): \r\n```\r\npython esptool.py --baud 115200 --port YOUR_COM_PORT write_flash -fs 32m 0x1000 blank.bin 0x2000 oakupdate_debug.bin 0x0081000 oakupdate_debug.bin 0x101000 blank.bin 0x102000 blank.bin 0x202000 blank.bin \r\n```\r\nThis will cause your Oak to endlessly loop trying to download the update, displaying a log to serial of its progress, and then rebooting and doing it again.\r\n6. Implement your solution in any way you can. (more below)\r\n7. Test with your solution being served both on fast and slow broadband connections (local network, phone hotspot, high speed connection, etc). You can repeat 3-5 to set it to connect to a different server to test locally/remotely - these test bin files don't check for a certificate domain match, so you can reuse the same certificate if desired.\r\n8. If you feel you have a good solution repeat step 5 but use oakupdate_debug_silent.bin instead - this does not show status counters during the update loop and therefore is more true to the speed of that loop on the factory Oak.\r\n9. Submit your fix.\r\n\r\n**Acceptable solutions:** The sky is pretty much the limit here, other than the firmware cannot be changed. The solution must run on a standard linux server (hey if you can get it to work with a windows server that'd be fine too), but can change the OS/server/etc in any way, this will run on a standalone cloud server. It does not have to be particularly performant (we can run many servers if we need to), though it must be able to serve the firmware to more than one device at a time. You can mess with linux sockets, you can write it in any language, you can use any existing software or packages - really we're open to anything. I have a fear it could be as easy as setting up Apache 2.2 again without any changes to the default linux socket setup (we've messed with that too many times now probably, without fully understanding - see comment at top of node scripts) - I don't think that's true as I'm sure I've tried that, but really even if it was that simple we would reward you the bounty.\r\n\r\n**Solution testing:** Any submitted solution will be tested first by ourselves, and then by a selected group of users who have experienced issues updating and are able and willing to carefully test. If your solution works for most of these case we will reward the bounty to you. Partial bounties for partial improvements may be granted as well. Solutions that require the user to run something locally on their network may be considered, but preference will be given to server only solutions (not sure if that would offer any advantage, but thought I'd throw it out there).\r\n\r\n## Bounty\r\n\r\n$1000 cash or $2000 credit or 200 Oaks\r\n\r\nCash or credit is your choice. Cash to be paid via Paypal. Credit has no expiration but can only be applied to a single order and does not cover shipping (because that is how our shopping cart works, not because we want to be limiting). Oaks reward includes shipping. You can also pick a split between any of the options.\r\n\r\nYou may credit yourself in the files as well, leaving in tact existing licenses and credits.\r\n\r\nLegal Stuff: We will choose a winner at our sole discretion. The winner will be the first pull request/comment that submits fully working code meeting the above requirements and following good coding practices, based on the timestamp of the pull request. Bounty will be awarded (or in the case of Oaks, sent) within 48 hours of confirming winner. Cash awards will be made in USD. This is not an offer for hire. All work submitted becomes the property of Digistump LLC to be used at our discretion in compliance with any associated licenses. Void where prohibited by law.\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/digistump/OakCore/issues/comments/191750344","html_url":"https://github.com/digistump/OakCore/issues/54#issuecomment-191750344","issue_url":"https://api.github.com/repos/digistump/OakCore/issues/54","id":191750344,"user":{"login":"DarkLotus","id":1056104,"avatar_url":"https://avatars.githubusercontent.com/u/1056104?v=3","gravatar_id":"","url":"https://api.github.com/users/DarkLotus","html_url":"https://github.com/DarkLotus","followers_url":"https://api.github.com/users/DarkLotus/followers","following_url":"https://api.github.com/users/DarkLotus/following{/other_user}","gists_url":"https://api.github.com/users/DarkLotus/gists{/gist_id}","starred_url":"https://api.github.com/users/DarkLotus/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/DarkLotus/subscriptions","organizations_url":"https://api.github.com/users/DarkLotus/orgs","repos_url":"https://api.github.com/users/DarkLotus/repos","events_url":"https://api.github.com/users/DarkLotus/events{/privacy}","received_events_url":"https://api.github.com/users/DarkLotus/received_events","type":"User","site_admin":false},"created_at":"2016-03-03T12:51:41Z","updated_at":"2016-03-03T12:51:41Z","body":"@DeuxVis oak2.jameskidd.net is running with MTU set to 576 if you want to give it a shot.\r\nand oak.jameskidd.net is running apache2.2 on CentOS 6 to try and match Erik's original server\r\n"}}