A May 24th 2023 change of GitHub’s RSA SSH host key just hit me on an older, less used, system doing a git clone. The change was prompted by an unintended exposure of the private part of the host key by GitHub itself.
GitHub.com’s RSA SSH private key was briefly exposed in a public GitHub repository Github blog-post, “We updated our RSA SSH host key”, 2023-03-23
GitHub.com’s RSA SSH private key was briefly exposed in a public GitHub repository
I’m getting even more reluctant to trust a large organization where such a thing can happen. Additionally they didn’t communicate about this in a way that caught my attention. And now that it has my attention, they do not want to share the specifics about the incident to enable assessment of impact (like exposure duration, popularity of repository etc).
Below is the manual recovery with explanations of what happens and why. I don’t like the way the official blog-post instructs users to retrieving the validated host key in a non-visible way, without human eye balls doing the validation. This is the only chance in the process for injecting human trust into the validation of the host key, don’t skip it!
Consequence #1: fatal MitM warningWhen an SSH server’s host key is different to a connecting client (system) compared to what the system has previously seen and acknowledged by the user to be a valid key from the intended counterpart (you do check those host key fingerprint strings, right? If not; PHComp help, WinSCP help), it obviously should and do warn the user about this. Whether the change is of malicious origin or not, is up to the user to investigate. So with OpenSSH this happens;
$ git clone git@github.com:mikini/name-suggestion-index Cloning into 'name-suggestion-index'... @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is SHA256:uNiVztksCsDhcc0u9e8BujQXVUpKZIDTMczCvj3tD2s. Please contact your system administrator. Add correct host key in <~>/.ssh/known_hosts to get rid of this message. Offending RSA key in <~>/.ssh/known_hosts:17 remove with: ssh-keygen -f "<~>/.ssh/known_hosts" -R "github.com" RSA host key for github.com has changed and you have requested strict checking. Host key verification failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. $
Remedy #1: remove known host keys for domain (pr. OpenSSH instruction)Remove host keys associated with github.com domain using -R option to ssh-keygen (default for -f is the UserKnownHostsFile config keyword with default ~/.ssh/known_hosts, so no need to specify that):
$ ssh-keygen -R github.com# Host github.com found: line 17# Host github.com found: line 18# Host github.com found: line 19<~>/.ssh/known_hosts updated.Original contents retained as <~>/.ssh/known_hosts.old$Consequence #2: non-fatal domain and IP mismatchNow, because host key references are cached for both the domain and IP there are still mismatches caused by the key exchange choosing ECDSA host key and the key associated with the IP address is the old RSA key. This is prompted during each connection attempt:
$ git clone git@github.com:mikini/name-suggestion-index Cloning into 'name-suggestion-index'... Warning: the ECDSA host key for 'github.com' differs from the key for the IP address '140.82.121.3' Offending key for IP in <~>/.ssh/known_hosts:63 Matching host key in <~>/.ssh/known_hosts:72 Are you sure you want to continue connecting (yes/no)? yes remote: Enumerating objects: 153255, done. remote: Counting objects: 100% (177/177), done. remote: Compressing objects: 100% (103/103), done. remote: Total 153255 (delta 103), reused 121 (delta 74), pack-reused 153078 Receiving objects: 100% (153255/153255), 550.17 MiB | 2.39 MiB/s, done. Resolving deltas: 100% (111423/111423), done. $
Remedy #2: remove known host keys for IPsTo get rid of the mismatch warning, the known host keys associated with IP addresses needs to be removed also. Potentially any of the listed endpoint IP addresses used with an RSA host key on the system earlier will now conflict with the ECDSA from server, requiring removal:
$ ssh-keygen -R 140.82.121.3 # Host 140.82.121.3 found: line 63 <~>/.ssh/known_hosts updated. Original contents retained as <~>/.ssh/known_hosts.old $ $ ssh-keygen -R 140.82.121.4 # Host 140.82.121.4 found: line 161 <~>/.ssh/known_hosts updated. Original contents retained as <~>/.ssh/known_hosts.old $ After remedy Now, the SSH client will see an unknown host key and prompt for validation. Be sure to verify the presented host key with the officially communicated one (from doc. article or API):
$ git clone git@github.com:mikini/name-suggestion-index Cloning into 'name-suggestion-index'... The authenticity of host 'github.com (140.82.121.4)' can't be established. ECDSA key fingerprint is SHA256:p2QAMXNIC1TJYWeIOttrVc98/R1BUFWu3/LiyKgUfQM. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added 'github.com,140.82.121.4' (ECDSA) to the list of known hosts. remote: Enumerating objects: 153152, done. remote: Counting objects: 100% (183/183), done. remote: Compressing objects: 100% (83/83), done. Receiving objects: 100% (153152/153152), 550.22 MiB | 1.42 MiB/s, done. remote: Total 153152 (delta 109), reused 158 (delta 100), pack-reused 152969 Resolving deltas: 100% (111352/111352), done. $
While once again being annoyed by the obnoxious way modern GNOME handles in-application dialogues (fx. Nautilus’ Properties dialog) as modal (ie. freezes the parent window) AND even prevents movement of the dialogue relative to the parent I did some searching which revealed a partly solution!
This was also complained about in a 2017 LibreOffice bug report which concluded that the immobility is a GNOME 3 desktop default behaviour caused by the setting attach-modal-dialogs.
Details in the related GNOME bug report shows how to disable this by modifying gsettings;
In a regular upstream GNOME session, `gsettings set org.gnome.shell.overrides attach-modal-dialogs false`, a schema of ‘org.gnome.shell.extensions.classic-overrides’ for the classic session and afaik ‘org.gnome.mutter’ for a Ubuntu-patched GNOME.
Now knowing which term to search for, lots of discussion about this shows up (including posts similar to this), the best write up of the mitigation is probably this askubuntu question. And the mother opinionated Ubuntu bug report is this where Ubuntu officially states;
We do not consider Gnome’s defaults in this area unreasonable.
But the reason for this behaviour? Seems to be unknown as even this 2018 bug report on gnome-shell hasn’t received any official answer or comment about why this would be a sane default. Go figure…
TLDR;On Ubuntu 20.04 and similar distributions turn off GNOME’s attach-modal-dialogs feature by doing;
$ gsettings set org.gnome.mutter attach-modal-dialogs false
Or if you like the mouse; install & launch gnome–tweaks and click “Windows” -> “Attach Modal Dialogues”;
Oh, and remember to read the Nielsen Norman Group article “Modal & Nonmodal Dialogs: When (& When Not) to Use Them” (summary: Modal dialogs interrupt users and demand an action. They are appropriate when user’s attention needs to be directed toward important information).
Edit:2023-07-30: add gnome-tweaks approach
If you end up in a situation where your PHP installation gets ahead of your application (like fx. if your hosting provider deprecates PHP 7.4 without you having had the opportunity to update your WordPress 4.9.22 blog), here is a small tip if this results in errors related to the, in PHP 8 removed, function get_magic_quotes_gpc() (see PHP RFC from 2018 about this decision).
As this function has been a dummy function returning false since PHP 5.4 (see php-src commit removing the functionality) and emitting a deprecation warning since PHP 7.4 (see php-src commit deprecating function) in almost any case perceivable you would be able to fake this function and satisfy your application’s need for it to exist.
To fix this for WordPress add the following line to the wp-includes/load.php file (fx. at line 7 for v4.9.22);
function get_magic_quotes_gpc() {return false;}
And voila! WordPress will be functional again (please consider using the chance to upgrade).
Unless, of course, there are other problems related to the PHP upgrade…
This could fx. be ancient themes (like Ahimsa) that use deprecated associative array notation (unquoted string literal indexes). These needs fixing first by adding quotes to all of the indexing strings in sub-arrays of the $skin_fields array, like below;
$skin_fields = array ( array ( "name" => "skinpagebgtopbg", "desc" => "Page Background Top", "csssel" => "#bgtop", "attr" => "background-color" ), array ( "name" => "skinpagediv", "desc" => "Page Background Divider Colour", "csssel" => "#bgtop", "attr" => "border-bottom-color" ), array ( "name" => "skinpagebgbotbg", "desc" => "Page Background Bottom", "csssel" => "BODY", "attr" => "background-color" ), array ( "name" => "skinhyperlinks", "desc" => "Hyperlinks", "csssel" => "A", "attr" => "color" ), array ( "name" => "skincapsulebg", "desc" => "Default Bubble Background", "csssel" => ".capsule", "attr" => "background-color" ), array ( "name" => "skincapsulefg", "desc" => "Default Bubble Text Colour", "csssel" => ".capsule", "attr" => "color" ), array ( "name" => "skinheaderbg", "desc" => "Header Background", "csssel" => "#header", "attr" => "background-color" ), array ( "name" => "skinheaderfg", "desc" => "Header Text Colour", "csssel" => "#header, #header table, #header a", "attr" => "color" ), array ( "name" => "skinheadersepcolour", "desc" => "Colour of Separator Bar in Header", "csssel" => "#title", "attr" => "border-right-color" ), array ( "name" => "skinsidebarbg", "desc" => "Sidebar Background", "csssel" => ".sidebar, .tdsidebar", "attr" => "background-color" ), array ( "name" => "skinsbwidgetbg", "desc" => "Sidebar Widgets Background", "csssel" => ".sidebarlist", "attr" => "background-color" ), array ( "name" => "skinsbwidgetfg", "desc" => "Sidebar Widgets Text Colour", "csssel" => ".sidebarlist", "attr" => "color" ), array ( "name" => "skinsblegendbg", "desc" => "Sidebar Widget Title Background", "csssel" => ".sidebarlist > legend", "attr" => "background-color" ), array ( "name" => "skinsblegendfg", "desc" => "Sidebar Widget Title Text Colour", "csssel" => ".sidebarlist > legend", "attr" => "color" ), array ( "name" => "skinsblistdiv", "desc" => "Sidebar/Action Lists Divider Colour", "csssel" => ".sidebarlist li, #postaction li", "attr" => "border-top-color" ), array ( "name" => "skinsblink", "desc" => "Sidebar Widget Hyperlinks", "csssel" => ".sidebarlist a", "attr" => "color" ), array ( "name" => "skincalcaption", "desc" => "Sidebar Calendar Caption Colour", "csssel" => "#wp-calendar caption", "attr" => "color" ), array ( "name" => "skincalheaderbg", "desc" => "Sidebar Calendar Column Header Background", "csssel" => "#wp-calendar thead th, #wp-calendar tfoot td.pad", "attr" => "background-color" ), array ( "name" => "skincalheaderfg", "desc" => "Sidebar Calendar Column Header Text Colour", "csssel" => "#wp-calendar thead th", "attr" => "color" ), array ( "name" => "skincalcellfg", "desc" => "Sidebar Calendar Entries Text Colour", "csssel" => "#wp-calendar tbody td", "attr" => "color" ), array ( "name" => "skincalnpbg", "desc" => "Sidebar Calendar Next/Prev Links Background", "csssel" => "#wp-calendar #next, #wp-calendar #prev", "attr" => "background-color" ), array ( "name" => "skincalnpfg", "desc" => "Sidebar Calendar Next/Prev Links Text Colour", "csssel" => "#wp-calendar #next, #wp-calendar #prev, #wp-calendar tfoot a", "attr" => "color" ), array ( "name" => "skintextwdgtfg", "desc" => "Sidebar Text Widget Text Colour", "csssel" => ".textwidget", "attr" => "color" ), array ( "name" => "skincontentbg", "desc" => "Main Content Background", "csssel" => "#content", "attr" => "background-color" ), array ( "name" => "skinpostpagebg", "desc" => "Post or Page Entry Background", "csssel" => ".post > fieldset", "attr" => "background-color" ), array ( "name" => "skinpostpagefg", "desc" => "Post or Page Entry Text Colour", "csssel" => ".entry", "attr" => "color" ), array ( "name" => "skinpptitlebg", "desc" => "Post, Page, Comments Title Background", "csssel" => ".post .title, #comments > legend, .comment > legend, #responsebox > legend", "attr" => "background-color" ), array ( "name" => "skinpptitlefg", "desc" => "Post, Page, Comments Title Text Colour", "csssel" => ".post .title, .post .title a, " . "#comments > legend, .comment > legend, #responsebox > legend", "attr" => "color" ), array ( "name" => "skinmetabarbg", "desc" => "Post/Page/Comment Bottom Bar Background", "csssel" => ".postmetadata", "attr" => "background-color" ), array ( "name" => "skincattagbg", "desc" => "Category/Tag Lists Background", "csssel" => ".postcattags", "attr" => "background-color" ), array ( "name" => "skincattagfg", "desc" => "Category/Tag Lists Text/Link Colour", "csssel" => ".postcattags, .postcattags a", "attr" => "color" ), array ( "name" => "skin1cattagbubblebg", "desc" => "Single Post Cat/Tag Bubble Background", "csssel" => "#single .postcattags .capsule", "attr" => "background-color" ), array ( "name" => "skin1cattagbubblefg", "desc" => "Single Post Cat/Tag Bubble Text/Link Colour", "csssel" => "#single .postcattags .capsule, #single .postcattags .capsule a", "attr" => "color" ), array ( "name" => "skinbqbg", "desc" => "Blockquote Background", "csssel" => "blockquote", "attr" => "background-color" ), array ( "name" => "skinbqfg", "desc" => "Blockquote Text Colour", "csssel" => "blockquote", "attr" => "color" ), array ( "name" => "skinlistbg", "desc" => "Page/Post Ordered/Unordered List Background", "csssel" => ".entry UL, .entry OL", "attr" => "background-color" ), array ( "name" => "skinlistfg", "desc" => "Page/Post Ordered/Unordered Text Colour", "csssel" => ".entry UL, .entry OL", "attr" => "color" ), array ( "name" => "skinpost1stletterfg", "desc" => "Post First Letter Colour", "csssel" => ".entry > P:first-child:first-letter", "attr" => "color" ), array ( "name" => "skinactionbg", "desc" => "Action Bubbles (Edit, Reply, etc) Background", "csssel" => ".actbubble", "attr" => "background-color" ), array ( "name" => "skinactionfg", "desc" => "Action Bubbles (Edit, Reply, etc) Text Colour", "csssel" => ".actbubble, .actbubble a", "attr" => "color" ), array ( "name" => "skincommentsbg", "desc" => "Comments Block Background", "csssel" => "#comments", "attr" => "background-color" ), array ( "name" => "skincommentbg", "desc" => "Comment Background", "csssel" => "fieldset.comment, fieldset.comment .commenttext", "attr" => "background-color" ), array ( "name" => "skincommentfg", "desc" => "Comment Text Colour", "csssel" => "fieldset.comment .commenttext", "attr" => "color" ), array ( "name" => "skinresponsebg", "desc" => "Response Box Background", "csssel" => "#responsebox", "attr" => "background-color" ) );
Will investigate later and amend the post (promise!).
$ free; find . -size +25M -exec bash -c 'ls -l {}; eog {}; echo' \;; free total used free shared buff/cache available Mem: 7746692 5767656 843228 317764 1135808 1271048 Swap: 7950332 5113012 2837320 -rw-rw-r-- 1 miki miki 39926496 Jun 10 19:25 ./20190609_184124.jpg ** (eog:23320): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed. bash: line 1: 23320 Aborted (core dumped) eog ./20190609_184124.jpg -rw-rw-r-- 1 miki miki 38286099 Jun 10 19:26 ./20190609_183714.jpg ** (eog:23332): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed. bash: line 1: 23332 Aborted (core dumped) eog ./20190609_183714.jpg -rw-rw-r-- 1 miki miki 36181801 Jun 9 17:13 ./20190609_160437.jpg ** (eog:23343): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed ** (eog:23343): CRITICAL **: eog_reload_plugin_deactivate: assertion 'G_IS_MENU (menu)' failed -rw-rw-r-- 1 miki miki 39059177 Jun 10 19:25 ./20190609_184146.jpg ** (eog:23354): CRITICAL **: eog_reload_plugin_activate: assertion 'G_IS_MENU (model)' failed eog: ../../../../src/cairo-xlib-surface-shm.c:619: _cairo_xlib_shm_pool_create: Assertion `*ptr != ((void *)0)' failed. bash: line 1: 23354 Aborted (core dumped) eog ./20190609_184146.jpg total used free shared buff/cache available Mem: 7746692 5773448 495604 659944 1477640 922956 Swap: 7950332 5112700 2837632 $
Until your device is sufficiently patched against the Stagefright vulnerabilty I recommend disabling automatic MMS retrieval on any Android phones from 2.2 and up (which is hopefully all in current use) to prevent unattended triggering.
Howtos for Google and Samsung devices are here.
Below are screenshots of how to do it on HTC One M7 using the stock (HTC Sense) messaging application called “SMS”. The procedure is likely to be very similar on most HTC devices using Sense. The UI shown is in Danish locale, the English menus will be something like SMS->Settings->Multi Media Messages (MMS)->Automatic Retrieval.
Schneier discusses details here and this seems to be the commit in CyanogenMod for the underlying problem in the media library. Check aælso the issue’s review page
Investigating further on the BBB boot issue described in this earlier post and following discussion in the mailinglist, here is a test of another BBB modification trying to remedy this.
This time the modification is done on the non-cpu side of U15 (75LVC2G241 buffer/driver), where the buffered uart0 input (B_UART0_RX) is kept stable using a voltage divider. B_UART0_RX is already pulled low by a 100k resistor, but adding another 82k5 ohms pulling against 3,3v makes up a voltage divider, keeping input 1A on U15 stable at all times at approx. half (~55%) of the voltage between VDD_3V3B and DGND. At stable 3,3V that voltage will be 3.3V*100k/(82k5+100k)= 1.81V (EDIT: first edition of this post erroneously stated the voltage drop of ~1.4V over the pull up as the B_UART0_RX’s voltage level).
Beware that this modification might affect the functionality of uart0 rx capability. I’ll probably test this some time soon (TM) when I got access to my TTL<->USB converter.
These results are summed up in this post on the BBB mailinglist.
Providing a stable B_UART0_RX at 1.8V results in a booting BBB in every test case!
The third picture below shows an easy and relatively safe way to make this a permanent fix on the backside of the BBB. It places a resistor (this one is 82k5 ohm ) between VDD_3V3B from terminal 5 on the non-populated P2 header marked as “CTI JTAG, DNI” and the B_UART0_RX signal on J2 (UART0 Serial Port) pin 4.
Mocked up voltage divider keeping B_UART0_RX stable. Test equipment and setup. First attempt at a more robust modification on the solder side of the PCB.
(formatted in nice emacs org-mode)
* BBB boot lockup test report 2 ** Equipment*** Device Under Test #1 Unmodified Beaglebone Black (BBB) produced by Element 14 (PCB REV B6, serial EM-400524+XA6001961, marked "Element 14"). *** Device Under test #2 Modify DUT#1 by applying a 82k5 ohm pull up resistor from J1, pin 4 (B_UART0_RX, U15-pin 2, signal 1A) to P8, pin 4 (VDD_3V3B), effectively creating a voltage divider with existing pull down resistor R165 (100k ohm) fixing voltage on B_UART0_RX to 3.3V*100k/(82k5+100k)= 1.81V. *** Device Under Test #3 Modify DUT#1 by applying a 82k5 ohm pull down resistor from J1, pin 4 (B_UART0_RX, U15-pin 2, signal 1A) to P8, pin 1 (DGND), thus forming a stronger pull down on B_UART0_RX with resistive value of 1/(1/100k+1/82k5)= 45k2 ohm *** Power Supply Unit Huawei HW-050200E3W, output 5V 2A, USB A-connector. Danish plug. Sourced from Huawei E589 mobile wifi. *** Power Cable 20 cm no-name USB A male connector to USB Mini-B male connector. ** Test 1 Procedure Insert PSU into mains socket. Test boot capability of DUT#1 by inserting the USB A connector into the mains socket adaptor while keeping the USB Mini-B connector inserted into the BBB. Then verify that the power led light up, and note whether boot succeeded or failed by watching if USR0-USR3 lights up indicating boot. Then remove the A connector from the mains adaptor wait 3 seconds and repeat. Results can be seen in section Test Results, column Test 1. ** Test 2 Procedure Repeat Test 1 procedure using DUT#2. Results can be seen in section Test Results, column Test 2. ** Test 3 procedure Repeat Test 1 procedure using DUT#3. Results can be seen in section Test results, column Test 3. ** Interpretation DUT#1 failure rate= 4 fails/65 boots= *6,2%* DUT#2 failure rate= 0 fails/50 boots= *0,0%* DUT#3 failure rate= 3 fails/50 boots= *6.0%* Test 2 in reference to Test 1 shows that fixing B_UART0_RX to 1.4v using a voltage divider increases the system boot success rate from 94% to 100%. Though the modification might affect the functionality of uart0 rx capability. Test 3 shows that forming a stronger pull down on B_UART0_RX (100k->45k), dosn't change the failure rate as might be expected. This suggest that some strong (internal?) signal that a pull down in itself can't correct is driving the the 75LVC2G241's 1A input sometime during powerup. ** Test results | Boot no. | Test 1 | Test 2 | Test 3 | | 1 | boot | boot | boot | | 2 | boot | boot | boot | | 3 | boot | boot | boot | | 4 | boot | boot | boot | | 5 | boot | boot | boot | | 6 | boot | boot | boot | | 7 | boot | boot | boot | | 8 | boot | boot | boot | | 9 | boot | boot | boot | | 10 | boot | boot | boot | | 11 | boot | boot | boot | | 12 | boot | boot | boot | | 13 | boot | boot | boot | | 14 | boot | boot | boot | | 15 | boot | boot | boot | | 16 | boot | boot | boot | | 17 | boot | boot | boot | | 18 | boot | boot | boot | | 19 | boot | boot | boot | | 20 | boot | boot | boot | | 21 | no boot | boot | boot | | 22 | boot | boot | boot | | 23 | boot | boot | boot | | 24 | boot | boot | boot | | 25 | boot | boot | boot | | 26 | boot | boot | boot | | 27 | boot | boot | boot | | 28 | boot | boot | boot | | 29 | boot | boot | boot | | 30 | boot | boot | boot | | 31 | boot | boot | boot | | 32 | boot | boot | boot | | 33 | boot | boot | no boot | | 34 | boot | boot | no boot | | 35 | boot | boot | boot | | 36 | boot | boot | boot | | 37 | boot | boot | boot | | 38 | no boot | boot | boot | | 39 | boot | boot | boot | | 40 | boot | boot | boot | | 41 | boot | boot | boot | | 52 | boot | boot | boot | | 53 | boot | boot | boot | | 44 | boot | boot | no boot | | 45 | no boot | boot | boot | | 46 | boot | boot | boot | | 47 | boot | boot | boot | | 48 | boot | boot | boot | | 49 | boot | boot | boot | | 50 | boot | boot | boot | | 51 | boot | | | | 52 | boot | | | | 53 | boot | | | | 54 | boot | | | | 55 | boot | | | | 56 | boot | | | | 57 | boot | | | | 58 | boot | | | | 59 | boot | | | | 60 | boot | | | | 61 | boot | | | | 62 | boot | | | | 63 | boot | | | | 64 | boot | | | | 65 | no boot | | |
* BBB boot lockup test report 2 ** Equipment*** Device Under Test #1 Unmodified Beaglebone Black (BBB) produced by Element 14 (PCB REV B6, serial EM-400524+XA6001961, marked "Element 14").
*** Device Under test #2 Modify DUT#1 by applying a 82k5 ohm pull up resistor from J1, pin 4 (B_UART0_RX, U15-pin 2, signal 1A) to P8, pin 4 (VDD_3V3B), effectively creating a voltage divider with existing pull down resistor R165 (100k ohm) fixing voltage on B_UART0_RX to 3.3V*100k/(82k5+100k)= 1.81V.
*** Device Under Test #3 Modify DUT#1 by applying a 82k5 ohm pull down resistor from J1, pin 4 (B_UART0_RX, U15-pin 2, signal 1A) to P8, pin 1 (DGND), thus forming a stronger pull down on B_UART0_RX with resistive value of 1/(1/100k+1/82k5)= 45k2 ohm
*** Power Supply Unit Huawei HW-050200E3W, output 5V 2A, USB A-connector. Danish plug. Sourced from Huawei E589 mobile wifi.
*** Power Cable 20 cm no-name USB A male connector to USB Mini-B male connector.
** Test 1 Procedure Insert PSU into mains socket. Test boot capability of DUT#1 by inserting the USB A connector into the mains socket adaptor while keeping the USB Mini-B connector inserted into the BBB. Then verify that the power led light up, and note whether boot succeeded or failed by watching if USR0-USR3 lights up indicating boot. Then remove the A connector from the mains adaptor wait 3 seconds and repeat.
Results can be seen in section Test Results, column Test 1.
** Test 2 Procedure
Repeat Test 1 procedure using DUT#2.
Results can be seen in section Test Results, column Test 2.
** Test 3 procedure
Repeat Test 1 procedure using DUT#3.
Results can be seen in section Test results, column Test 3.
** Interpretation
DUT#1 failure rate= 4 fails/65 boots= *6,2%* DUT#2 failure rate= 0 fails/50 boots= *0,0%* DUT#3 failure rate= 3 fails/50 boots= *6.0%*
Test 2 in reference to Test 1 shows that fixing B_UART0_RX to 1.4v using a voltage divider increases the system boot success rate from 94% to 100%. Though the modification might affect the functionality of uart0 rx capability.
Test 3 shows that forming a stronger pull down on B_UART0_RX (100k->45k), dosn't change the failure rate as might be expected. This suggest that some strong (internal?) signal that a pull down in itself can't correct is driving the the 75LVC2G241's 1A input sometime during powerup.
** Test results
| Boot no. | Test 1 | Test 2 | Test 3 | | 1 | boot | boot | boot | | 2 | boot | boot | boot | | 3 | boot | boot | boot | | 4 | boot | boot | boot | | 5 | boot | boot | boot | | 6 | boot | boot | boot | | 7 | boot | boot | boot | | 8 | boot | boot | boot | | 9 | boot | boot | boot | | 10 | boot | boot | boot | | 11 | boot | boot | boot | | 12 | boot | boot | boot | | 13 | boot | boot | boot | | 14 | boot | boot | boot | | 15 | boot | boot | boot | | 16 | boot | boot | boot | | 17 | boot | boot | boot | | 18 | boot | boot | boot | | 19 | boot | boot | boot | | 20 | boot | boot | boot | | 21 | no boot | boot | boot | | 22 | boot | boot | boot | | 23 | boot | boot | boot | | 24 | boot | boot | boot | | 25 | boot | boot | boot | | 26 | boot | boot | boot | | 27 | boot | boot | boot | | 28 | boot | boot | boot | | 29 | boot | boot | boot | | 30 | boot | boot | boot | | 31 | boot | boot | boot | | 32 | boot | boot | boot | | 33 | boot | boot | no boot | | 34 | boot | boot | no boot | | 35 | boot | boot | boot | | 36 | boot | boot | boot | | 37 | boot | boot | boot | | 38 | no boot | boot | boot | | 39 | boot | boot | boot | | 40 | boot | boot | boot | | 41 | boot | boot | boot | | 52 | boot | boot | boot | | 53 | boot | boot | boot | | 44 | boot | boot | no boot | | 45 | no boot | boot | boot | | 46 | boot | boot | boot | | 47 | boot | boot | boot | | 48 | boot | boot | boot | | 49 | boot | boot | boot | | 50 | boot | boot | boot | | 51 | boot | | | | 52 | boot | | | | 53 | boot | | | | 54 | boot | | | | 55 | boot | | | | 56 | boot | | | | 57 | boot | | | | 58 | boot | | | | 59 | boot | | | | 60 | boot | | | | 61 | boot | | | | 62 | boot | | | | 63 | boot | | | | 64 | boot | | | | 65 | no boot | | |